Subject: Re: [boost] Providing means to verify integrity and authenticity for releases
From: Tom Kent (lists_at_[hidden])
Date: 2016-03-14 22:34:06
On Mon, Mar 14, 2016 at 5:10 AM, Daniel Hofmann <daniel_at_[hidden]> wrote:
> The current download page at
> > http://www.boost.org/users/download/
> redirects the user to SourceForge for downloading sources and / or
> binary Boost distributions. SourceForge can no longer be trusted as a
> hosting platform, as you can for example see following this thread
> > http://lists.boost.org/boost-users/2016/02/85662.php
> where a user was tricked into downloading some arbitrary binary while
> downloading a Boost release.
I think that this has been fixed with the change of sourceforge ownership
and the new management's discontinuing of this program. However, I also
believe that your point is very important, independent of the issues with
For the windows binary releases that I provide (through sourceforge), I
also include a file containing the SHA-256 cryptographically secure
checksums, this file is then signed with my private GPG key (which can be
obtained by other means, e.g. my website or the pgp directory). This gives
a confirmation that I am vouching for the authenticity of the checksum
file, which can be used to verify the authentication of the builds
contained within it.
This has been the case going back to 1.38, and since the source release is
contained within the windows binary you can get an authenticated (by me)
version going back to then.
I would really like to see the core release team adopt a similar procedure
in their release. This would only take a few steps:
1. Switch from md5 sums to a secure hash, such as SHA-256.
2. Sign these sums with a secure PGP/GPG key.
3. Publish this signed file with the sums alongside the downloads.
For bonus points, we could have multiple people sign with different keys
(if you want to be super-paranoid, in different jurisdictions) to ensure no
one person's key has been compromised, but IMO this is overkill for our
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk