Re: [boost] Boost libraries cannot yet be trusted

Subject: Re: [boost] Boost libraries cannot yet be trusted
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2016-03-22 06:09:41

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Michael Witten
> Sent: 21 March 2016 18:16
> To: boost_at_[hidden]
> Subject: [boost] Boost libraries cannot yet be trusted
> 
> In short, I request that the maintainers start publishing
> cryptographically signed, strong hashes of:
> 
>   * downloadable files.
>   * git objects (tags, and even commits).
> 
> 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.
> 
> ------------------------------------------------------------------------
> 
> I'm new to this community, so forgive my ignorance if I've missed an
> existing solution.
> 
> With each release, there should be included conspicuously (and widely)
> published means by which to check the authenticity of the relevant
> content.
> 
> As far as I can tell, this is not yet the case.
> 
> At the very least, within an email that announces a release, there
> should be a list of suitably safe (e.g., SHA-256) hashes for the
> downloadable files in question, including the hash of the relevant
> git commit object[s].
> 
> Now, SourceForge does indeed list SHA-1 and MD5 hashes of each file it
> offers for download, but they are not conspicuous; the user must know
> to click on an `i' symbol that sits next to each link (the `i' presumably
> stands for `information', but I wouldn't be surprised if it actually
> stood for `ignore me'). To make matters worse, that very icon and its
> associated functionality is only available when JavaScript is enabled,
> which is absurd.
> 
> Furthermore, it's important that this list of hashes appear in as
> many independent places as possible, so that it becomes increasingly
> difficult to alter the association; for instance, if Gmane picks up an
> announcement email that includes such hashes, then an attacker will
> also have to compromise Gmane's servers in order to forge a new record
> of the intended payload.
> 
> That is, widely published integrity information strongly suggests a
> [reasonable] means by which to calculate authenticity; certainly, the
> converse is true: Authenticity implies integrity.

I believe the risk from C++ source code is very small,
so I feel that very public SHA-1 and MD5 hashes would be sufficient.

Other solutions are no doubt better, but too expensive in time and effort.

(Boost is not a commercial venture, nor even a legal entity).

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]