On Thu, Feb 01, 2024 at 06:21:24PM +0100, Gilles Peskine wrote:
Checking our historical releases, it turns out we've made this mistake many times. In fact we've almost never posted the checksum for the correct name!
Are checksums important in this day and age? They were very useful back in the days when a release announcement was a PGP-signed email, and a release tarball was something you'd grab from some local FTP mirror. But nowadays the most secure way to get our release announcements is an HTTPS web page from GitHub, and the normal way to get the tarball is an HTTPS download from GitHub. So there's not much of a difference in terms of security, so what advantage does the checksum have?
In terms of integrity, only insiders (people with write permission on the GitHub repository) can edit a release announcement, and this is unlikely to be detected in real time but has a public log. Changing the release itself (as in, moving the tag to a different commit) is also something only insiders can do, with a more restricted access list; it is unlikely to be detected in real time (but trivial to check), but I'm not sure how apparent it would be who and when the tampering happened. I don't see a clear advantage to the release announcement in terms of integrity. Unless a third party decides to guarantee the integrity of the release announcement somehow, but then they could also guarantee the integrity of the release content if they want — and in fact I'd expect them to actually archive the release, since that guarantees availability of the content in addition to non-tampering.
If we stop providing checksums, is that a real loss?
First, let me state that I'm not a contributor to mbedtls, only a downstream user and repackager [0], so I'm not in position to propose any changes to mbedtls release process. Having said that:
1) Everything depends on threat model. For example, "insiders [...] that can edit a release announcement" also include GitHub operators, state personnel that can reasonably coerce them and/or anyone that can "cause issuance" in WebPKI, i.e. MITM HTTPS connection. Does your model consider all those actors trusted? We don't have a full list of those people, in contrast to holders of release keys who can usually be named. Disposing of PGP in this area is a significant regression from those elder days you mentioned.
2) It's demonstrably false that GitHub provides reliable public log for its various features that accompany repositories. In another project we have a list of issues that suddenly disappeared without trace and notification. Critically, GitHub refuses to comment or reinstate those issues unless contacted by original issue author, and not by the project that those issues were posted to. Because of two distinct incidents, separated by 3 years across MS acquisition, I don't agree to the assumption that GH is a reliable append-only record of any information not in git log.
Here's one of the threads for posterity: [1]. I admit it looks relatively innocent, content was removed and not edited, but nevertheless, they simply lost trust.
For those two reasons, stopping providing checksums as they are currently, just pasted in the release notes, does not seem like a meaningful change. Also probably no-one checks on them in any capacity, since IIUC I'm the first one to notice the problem. Charitable assesment would say, that's because people are thoroughly educated in contemporary threat models, well versed in state-of-the-art cryptosystems that solve attacks in those models, and refuse to even read unsigned hashes. Instead they're resorting to TOFU and just pin to whatever hash they observed when downloading from developer's workstation for the first time (myself I'm guilty of just that).
But maybe you could go the other way, and use this opportunity to provide signed releases? There are many options: signed tags, detached signatures over tarballs added to GitHub releases, or even just clearsigned output of sha256sum tool (```-----BEGIN PGP SIGNED MESSAGE----- 0123abcd mbedtls-12.34.5.tar.gz```). Yet another possibility would be to provide signed binaries: in the project I'm currently caring for, we sign just apt repo and don't provide signed sources, but AFAICT it's not an option here.
Thank you for your consideration.
[0] https://github.com/gramineproject/gramine/blob/1cf1f46646646a3b9c6b371e67c80... [1] https://groups.google.com/d/msgid/qubes-devel/YJkKmslcFlMUiCNt%40mutt