5 ms·

I don't quite understand the point concerning executable downloads and comparing hashes. Yes, comparing a hash found on a file downloaded from mozilla.com and a

I don't quite understand the point concerning executable downloads and comparing hashes. Yes, comparing a hash found on a file downloaded from mozilla.com and a hash also on mozilla.com is stupid. However comparing a hash on mozilla.com and a download/torrent from an untrusted source seems to be valid and useful. The only attack vector in that case is at mozilla.com and not the download source.

sarciszewski 11y ago
> I don't quite understand the point concerning executable downloads and comparing hashes. Downloading a file from Server A and checking the hash delivered by Server A is security theater. In this case, only a digital signature (with a pre-established public key that you already trust) can really stop the server from being compromised (or malicious). Downloading a file/torrent from Server B and verifying the hash delivered by Server A is a different situation entirely, and that boils down to a trust decision. Do you trust Server A to not be compromised? Do you trust them to not be malicious or in cahoots with Server B? If not, at the very least it's probably a larger attack service than the previous scenario. (Trusting the public key for the digital signature is also a trust decision. Only the details are different.) Basically: If you're going to do anything at all, verifying hashes from the same source is a waste of CPU and human effort. I hope that helps at all.
- haberman 11y ago
  You made exactly the same point as the post you are replying to, you just used more words.
  - sarciszewski 11y ago
    I wasn't really trying to argue, they said they didn't understand the point.
    - meowface 11y ago
      Re-read their post. I think you probably didn't understand their point. :)
      - sarciszewski 11y ago
        That's certainly possible. I'm not seeing what I missed. Maybe if I sleep on it, it will be clearer?
    - haberman 11y ago
      They didn't understand why the article says that comparing hashes is "a completely ludicrous waste of time." In some cases, it's not (as you both mentioned).
nadams 11y ago
I recall a story about an infected version of qemu (might have happened to other software) for Windows. Basically they hacked the site, replaced the binaries with infected ones AND updated the hashes. I also recall one or two stories where the binaries were infected but the hashes not updated - this was obviously caught pretty quickly and fixed. However, I remember a time when Firefox served downloads directly from their mirrors. This case could be good for comparing hashes - but now it looks like they use Amazon's cloudfront. But yes - for the average guy generating a hash for your releases (where your release and hash comes from the same server) doesn't provide any real benefit.
MichaelGG 11y ago
Running it through VirusTotal is neat, as it'll tell you when it has first seen a file. If the file is old enough and the hash has been seen for a long time then it makes it less likely to be a fake. (Unless you think e.g. Mozilla has been compromised for a long time.)
sarciszewski 11y ago
I've updated the article to make the context (and consequences) a bit clearer. I'm sorry for wording that part so weirdly before.

sarciszewski 11y ago

> I don't quite understand the point concerning executable downloads and comparing hashes. Downloading a file from Server A and checking the hash delivered by Server A is security theater. In this case, only a digital signature (with a pre-established public key that you already trust) can really stop the server from being compromised (or malicious). Downloading a file/torrent from Server B and verifying the hash delivered by Server A is a different situation entirely, and that boils down to a trust decision. Do you trust Server A to not be compromised? Do you trust them to not be malicious or in cahoots with Server B? If not, at the very least it's probably a larger attack service than the previous scenario. (Trusting the public key for the digital signature is also a trust decision. Only the details are different.) Basically: If you're going to do anything at all, verifying hashes from the same source is a waste of CPU and human effort. I hope that helps at all.

haberman 11y ago
You made exactly the same point as the post you are replying to, you just used more words.
- sarciszewski 11y ago
  I wasn't really trying to argue, they said they didn't understand the point.
  - meowface 11y ago
    Re-read their post. I think you probably didn't understand their point. :)
    - sarciszewski 11y ago
      That's certainly possible. I'm not seeing what I missed. Maybe if I sleep on it, it will be clearer?
  - haberman 11y ago
    They didn't understand why the article says that comparing hashes is "a completely ludicrous waste of time." In some cases, it's not (as you both mentioned).

nadams 11y ago

I recall a story about an infected version of qemu (might have happened to other software) for Windows. Basically they hacked the site, replaced the binaries with infected ones AND updated the hashes. I also recall one or two stories where the binaries were infected but the hashes not updated - this was obviously caught pretty quickly and fixed. However, I remember a time when Firefox served downloads directly from their mirrors. This case could be good for comparing hashes - but now it looks like they use Amazon's cloudfront. But yes - for the average guy generating a hash for your releases (where your release and hash comes from the same server) doesn't provide any real benefit.

MichaelGG 11y ago

Running it through VirusTotal is neat, as it'll tell you when it has first seen a file. If the file is old enough and the hash has been seen for a long time then it makes it less likely to be a fake. (Unless you think e.g. Mozilla has been compromised for a long time.)

sarciszewski 11y ago

I've updated the article to make the context (and consequences) a bit clearer. I'm sorry for wording that part so weirdly before.