Further to the considerations below — which upon further analysis are
even less in favor of checksums than I initially thought — checksums in
release announcements have a bigger flaw that a colleague pointed out:
the archives in release assets are cached but can be regenerated
(confirmed in https://github.com/orgs/community/discussions/45830), so
they are at the whims of changes in the underlying software, for example
if the compression changes.
So even if we generate correct checksums at release time, and even if
there's no confusion between archive names, historical checksums are
likely to become wrong over time.
I think this forces us to drop checksums, since we define a release as a
git tag and not as a tarball.
We may switch to hosting official tarballs and PGP-signing announcements
in the future, but if we do that we'll have to create a process from
scratch. Please file an issue on GitHub if there's interest for that.
Best regards,
--
Gilles Peskine
Mbed TLS developer
On 01/02/2024 18:21, Gilles Peskine via mbed-tls 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!
Well, maybe. For further confusion, the download link below a release
has a URL in …/v…, but the file name after downloading with a browser
(or any download tool that respects the Content-Disposition: header) is
mbedtls-…, and the toplevel directory name in the archive is mbedtls-… !
>
> 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.
Contrary to what I wrote earlier, edits to a release announcement do not
have a public log. So tampering (which merely requires write access to
the repository) would be anonymous and undetected. The release
announcement is thus less well protected than the tag.
>
> If we stop providing checksums, is that a real loss?
>
