-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Michael Witten Sent: 21 March 2016 18:16 To: boost@lists.boost.org 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 +44 (0) 1539 561830