> They do offer SHA-256 hashes for the executables, so people can check by hand
I never understood how this is useful... If someone would replace the executables, wouldn't they also replace the SHA-256 hashes that you are getting from the same source?
The practice of checkums/hashes with files really stems back to FTP and even less reliable transfer mechanisms would randomly corrupt your data. They also let you use a less trustworthy source, while you get just the hashes from a slow but more trustworthy source.
In Bitcoin's case what is actually provided is a PGP signature. The relevant key isn't provided along with the download files for the reason you mention. Though there are instructions on obtaining and validating the key on the download site. ... and if you're depending on reading those instructions' they're vulnerable to substitution.
For checking data corruption it makes more sense but most archive formats have this built-in, don't they? I.E.: You won't be able to extract it if it got corrupted.
It uses a 16-bit ones complement addition. At the packet sizes used on the internet it's extremely weak, much more so than you'd expect just from it being 16-bits, especially on data that isn't a uniform binary.
It would indeed offer no security if the hashes weren't signed (which they are).
The question is rather why distribute a separate file with hashes and their signatures, rather than just the signatures themselves, seeing how all useful cryptographic signatures contains the hash anyway?
I suspect the answer is that it is somehow more convenient for the build and release process to distribute one file with all hashes, rather than lots of individual signatures for each artifact. The release process is quite elaborate with several parties independently reproducing that exact build. But someone would have to correct me on that.
That's probably also why they don't consider the broken Windows certificate important enough to stall the release. Relying on a single CA does not provide them with the type of security they are looking for.
> The question is rather why distribute a separate file with hashes and their signatures, rather than just the signatures themselves, seeing how all useful cryptographic signatures contains the hash anyway?
that is what needs to be fixed, and ideally would become part of the archive format so that it can be automatically checked (but also should have the option to disable it).
Mirrors. Remember when you were asked to pick a mirror? And they'd invariably use plain http. And CDNs are still common, whereas the hash sum comes from the https main site.
At least that was the original point. These days you usually just host stuff yourself (on your domain or someone you pay, like a paid CDN) rather than having people mirror stuff independently. And it's all https, so it's mostly moot like you say, but old habits seem to die hard though it's already far less common than in the past.
Whenever you still see one, look at where the download really comes from. Often it's third party whereas the hash is first party. If not, then it's probably just a page with old habits.
You don't download the hash from the mirror, you use a signed hash from the distributor, allowing you to test that the untrusted mirror is serving you the correct file.
I never understood how this is useful... If someone would replace the executables, wouldn't they also replace the SHA-256 hashes that you are getting from the same source?