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.

I honestly don't know enough about CT to have an opinion.

> Also, "web of trust" only works for a tiny subset of people. If I'm a "lone wolf" FOSS developer, my key won't be signed by anyone, there won't be any WoT to verify. Downstream packagers just have to swallow that or TOFU.

One way to mitigate this nowadays is through services like keybase.io, which allow you to aggregate evidence for the authenticity of your key from social media accounts and websites. You can also do this yourself by posting your PGP fingerprint in many different places. These methods make it much more difficult for someone to create a new key in order to impersonate you. Accordingly, it's easy to trust that a key really belongs to a certain person -- even if there are no signatures on it -- when there's a long history of evidence from many different sources that would collectively be very difficult to spoof.

Software Heritage looks excellent, but it sounds like the two projects may have different goals. It sounds like Software Heritage is focused on collecting, preserving, and sharing code (and, as you say, potentially compiled software), whereas codehash.db is focused on allowing people to securely authenticate it after they've obtained it through some other means.

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.

I don't speak for Joanna, but I interpret that quotation as saying something like:

"Users are always fated to trust the 'last mile' vendor because the last mile vendor (e.g., Google Chrome), has control over what the user sees and does (i.e., sends and receives). If your Chrome browser is compromised or malicious, it can silently ignore the fact that no CT announcement is attached to a cert. In this sense, the user is fated to trust Chrome.

"Moreover, there's little feasibility in implementing any form of trust distribution for them, but this is not to say that there's little feasibility in implementing a system that keeps them relatively secure. Users running a non-malicious, non-compromised instance of Chrome do not have any form of trust distribution, since they place all their trust in Chrome (though they probably don't realize it). Nonetheless, Chrome may be keeping them relatively secure as long as it's working properly."

> The NSRL dataset has signatures that are typically used to verify both integrity and veracity. > http://www.nsrl.nist.gov/RDS/rds_2.54/split-hash.txt

Can you explain this signature scheme? I'm not familiar with it. The link you provided just appears to show hashes and sizes for a file that has been split into four pieces.

> Alleging the NSRL is untrustworty is inconsistent with the track record of the NSRL and NIST scientists.

I'd just like to point out that neither I nor anyone else here has alleged that.

> Please be aware that there are thousands of forensic experts who have relied on the NSRL over the last decade or more as a basis for testimony in court. Those experts verify hashes for everything they do, and for every case, and as a result there has been significant amount of independent peer review of the contents.

I'm genuinely glad to hear that! That's good to know.

> While Codehash.db provides a hash for a package, the NSRL provides hashes for individual installed files.

I don't think that's necessarily true. Codehash.db is open to hashes for anything (source code, ISO, package, binary installer).

> This in no way diminishes the value of the Codehash.db design. They target different use cases.

Likewise, my remarks aren't meant to be in any way derogatory toward the NSRL. As far as I'm concerned, it's OK if they do, in the final analysis, target the same use case. If that's the case, the best solution should be adopted, whichever one that turns out to be. :)

Fair enough, but this system isn't intended for end users who, as you point out, are unlikely to bother checking the hashes of their downloads. Quoting Joanna Rutkowska:

"Also, in case it wasn't clear: the primary audience for such a DB should be developers or admins (e.g. IT department in a large organization), I think. Not users. Users are always somehow fated to trust the 'last mile' vendor, and there is little feasibility in implementing any form of trust distribution for them."

https://secure-os.org/pipermail/desktops/2016-November/00014...

The main difference seems to be that the NSRL does not include PGP signatures (or any substitute), so there's no way to verify that the hashes are authentic, in the sense that the hashed software is bitwise identical to the software that the developer intended to distribute. This is precisely the problem that codehash.db is designed to solve. Without any way to verify the authenticity of the hash values, we have to rely on the authority of the NSRL itself. (In addition, the fact that the NSRL appears to have close ties to the U.S. government might make it even harder for some people to trust it.)

If you scroll down a bit on that page, there's a brief text introduction to Qubes (aimed at a non-technical audience):

https://www.qubes-os.org/tour/#what-is-qubes-os

Is that more like what you were looking for?