Re: [boost] Boost libraries cannot yet be trusted

Subject: Re: [boost] Boost libraries cannot yet be trusted
From: Vladimir Prus (vladimir.prus_at_[hidden])
Date: 2016-03-22 02:48:41

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