Re: [boost] Boost libraries cannot yet be trusted

Subject: Re: [boost] Boost libraries cannot yet be trusted
From: Daniel Hofmann (daniel_at_[hidden])
Date: 2016-03-22 03:36:56

Please also see this thread about release integrity and authenticity:
> http://lists.boost.org/Archives/boost/2016/03/228428.php

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
>