Hi Michael, [I've rearranged your email slightly] On 3/21/2016 9:15 PM, Michael Witten wrote:
I'm new to this community, so forgive my ignorance if I've missed an existing solution.
This topic was raised about a week ago.
In short, I request that the maintainers start publishing cryptographically signed, strong hashes of:
* downloadable files.
This specific question, even.
* git objects (tags, and even commits).
It seems a low-priority idea to me. Say, you have a github commit by me, which means that somebody in possession of my RSA private key has pushed it. What does PGP signature adds - the fact that somebody also has my PGP private key? If I can't protect one, I probably can't protect the other, so the only thing we'll be protecting is GitHub security issues?
A cryptographic signature should probably be a personal signature of a relevant maintainer (rather than some generic project-level signature for which nobody has a sufficiently strong incentive to maintain the trustworthiness).
Perhaps, each repository should include a collection of relevant public keys, so as to compound trustworthiness and ease dissemination.
For better or for worse, this won't ever happen due to number of repositories and maintainers.
With each release, there should be included conspicuously (and widely) published means by which to check the authenticity of the relevant content.
[...]
Fortunately, all parties can be satisfied simultaneously and cheaply: Provide the list of hashes as a cryptographically signed message.
If you propose that a release announcement includes a list of checksums along with a PGP signature, then it's doable, as discussed previously. Though, I don't know which release managers actually have PGP keys and how widely they are known. Say, my PGP key is signed by about 3 other people.
In any case, something must be done; this project sits at the core of much critical software, and its integrity should be ensured with greater zeal.
That's true, but it's not clear whether tampered source archives is the biggest risk. If you look at other open-source projects, all the huge security problems were either genuine bugs, or government-mandated "export crypto", not so much of directly evil code. If one wanted to use Boost as attack vector, he'd probably try to introduce buffer overflow inside otherwise reasonable patch, for which the above solutions would not help. -- Vladimir Prus http://vladimirprus.com