4 ms·

> 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 executabl

> 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?

Aachen 5y ago
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.
- Black101 5y ago
  > Mirrors. Remember when you were asked to pick a mirror? And they'd invariably use plain http. With http, you can man-in-the-middle the file and the hash.
  - r1ch 5y ago
    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.
  - Aachen 5y ago
    "they" refers to the mirror, not the place where you get the hash from.
nullc 5y ago
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.
- Black101 5y ago
  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.
  - nullc 5y ago
    Tar doesn't, nor does the classic unix 'compress' (the thing we all used before gzip). :)
    - Black101 5y ago
      if you are using tar by itself, you are asking for trouble
  - r1ch 5y ago
    Downloading over HTTPS also protects against data corruption in transit.
    - vbezhenar 5y ago
      Downloading over HTTP also protects against data corruption in transit, because HTTP uses TCP and TCP uses CRC32 checksums. Though those checksums are not extremely reliable and have tiny chance of being corrupted.
xorcist 5y ago
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.
- Black101 5y ago
  > 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).
jnwatson 5y ago
The CircleCI hack was (eventually) caught because the hash of the downloaded file no longer matched. If the checksum is hosted in a different place than the file, it requires an attacker to compromise two separate systems. In the typical system, though, the hash sitting next to the file isn't particularly useful.

Aachen 5y ago

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.

Black101 5y ago
> Mirrors. Remember when you were asked to pick a mirror? And they'd invariably use plain http. With http, you can man-in-the-middle the file and the hash.
- r1ch 5y ago
  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.
- Aachen 5y ago
  "they" refers to the mirror, not the place where you get the hash from.

nullc 5y ago

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.

Black101 5y ago
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.
- nullc 5y ago
  Tar doesn't, nor does the classic unix 'compress' (the thing we all used before gzip). :)
  - Black101 5y ago
    if you are using tar by itself, you are asking for trouble
- r1ch 5y ago
  Downloading over HTTPS also protects against data corruption in transit.
  - vbezhenar 5y ago
    Downloading over HTTP also protects against data corruption in transit, because HTTP uses TCP and TCP uses CRC32 checksums. Though those checksums are not extremely reliable and have tiny chance of being corrupted.

xorcist 5y ago

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.

Black101 5y ago
> 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).

jnwatson 5y ago

The CircleCI hack was (eventually) caught because the hash of the downloaded file no longer matched. If the checksum is hosted in a different place than the file, it requires an attacker to compromise two separate systems. In the typical system, though, the hash sitting next to the file isn't particularly useful.