Please also see this thread about release integrity and authenticity:
On 03/21/2016 07:15 PM, Michael Witten wrote:
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.
Of course, it's irritating (and unlikely) for a user to take the time to check multiple publishers for such integrity information every time a new release is made. Thus, it makes more sense to abstract away this process into a one-time dissemination of integrity information with which a user may determine the authenticity of other, related data that is provided by any publisher.
Such an abstraction is provided by cryptographic signatures.
By widely publishing a public key, a maintainer provides a [reasonable] means by which a user may calculate the authenticity (and thus also the integrity) of any other data that is signed by the associated private key.
Now, that calculation is only as trustworthy as the private key itself, so it's important that there be a strong incentive to keep that private key trustworthy; this possibly implies that the private key in question should be intimately associated with the individual who uses it; this suggests that, as a matter of explicit policy, there should not be some generic project-level private key shared by multiple individuals across space or time.
The easiest solution is to require that some *individual* maintainer of data be responsible for signing that data with his own personal signature.
Of course, not every user has the machinery or desire to work with cryptographic signatures; some people are satisifed with merely checking that the hash of data matches the result provided by a trusted publisher.
Fortunately, all parties can be satisfied simultaneously and cheaply: Provide the list of hashes as a cryptographically signed message.
Furthermore, the source-control management tool `git' (which this project already uses) provides support for integrating cryptographic signatures; not only can a tag object be cryptographically signed, but every commit object can also be cryptographically signed. It's probably enough just to sign tags (those of releases, at the very least), but perhaps it would be worthwhile to sign a commit object that sits some sufficient number of commits ahead of the object last signed, so as to give users a kind of checkpoint of authenticity.
It might be worthwhile to include in every repository the public key of each relevant maintainer (say, one file for each maintainer); this kind of publication would allow for compounding a key's trustworthiness with each new commit, and it would make dissemination of that information both easier and more specialized to its purpose.
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.
Sincerely, Michael Witten
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost