[boost] Boost libraries cannot yet be trusted

Subject: [boost] Boost libraries cannot yet be trusted
From: Michael Witten (mfwitten_at_[hidden])
Date: 2016-03-21 14:15:30

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