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."
Your quote's incorrect, in my opinion. Under CT, users are able to mistrust the issuing CA -- we start by assuming they want to give us malware (in the CT case, MITM certs) and trust them only to the extent that they are distributing publicly announced and tracked artifacts to us. This happens at the end user's computer, when their browser refuses to accept a cert with no CT announcement attached. This all happens in running Chrome browsers today.
If other software (e.g. your Linux distro) similarly checked for publicly announced artifacts (e.g. an offered package upgrade) then you would be protected against targeted malware from your last mile vendor. The malware has to be either offered to everyone (ensuring detection) or no-one.
I think the CT mechanism is simply better than a system that "isn't intended for end users", because a CT mechanism projects both administrators and end users.
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."
Thanks, "last mile" confused me because it implies a transfer. With CT applied to software updates, I think you really could be suspicious-by-default of your software vendor.
Do you have any thoughts on why codebase.db should exist, versus pushing the same hashes to a CT log and having clients check for CT announcements? Seems like CT is a clear improvement.
"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...