[andrewdavidwong]

That's precisely the point. Doug could trivially change some of the hashes before signing them. If he were to do that, he wouldn't be trustworthy, and you, as a security-conscious individual, would want additional witnesses to corroborate the hashes before you're willing to accept that the software you downloaded is authentic. This is what codehash.db is designed to provide. (If you would be willing to chalk up the hash difference to a version difference, then this is probably aiming at a higher level of security than what you seek.)

In reality, Doug would never change hash values like that because he's trustworthy. At least, he wouldn't willingly or knowingly do it. But if Doug's signature is the only thing that guarantees the authenticity of a list of millions of hashes, that paints an awfully large target on his back. How do you know that Doug hasn't been coerced into changing some hash values before signing them. How do you know that Doug's signing key hasn't been compromised? We can't know these things for certain, but we'd have much greater assurances if we could check the signatures of multiple independent parties in addition to Doug's, and that's exactly what codehash.db aims to allow. It's a way of distributing trust across a larger group of people instead of centralizing it into a single point of failure.

By the way, does Doug actually sign the hashes? I haven't been able to find any signatures, so please point me to them if there are any.

[jonstewart]

How do you determine identity with hash values? Alice could say that svchost.exe's hash is deadbeefdeadbeef and Bob could say it's baadcodebaadcode, but, of course, they both could be right because there are umpteen versions of svchost.exe. So, how do you solve the identity problem in order to detect evil?

[andrewdavidwong]

It depends on the entity being hashed, but in the case of software, it's usually a version number. In the case of source code, maybe a git commit hash.