Providing means to verify integrity and authenticity for releases
The current download page at
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
where a user was tricked into downloading some arbitrary binary while downloading a Boost release. Unfortunately there does not seem to be a secure and convenient way to download Boost releases. Although Github's Boost "releases" can be found at
but those are only repository snapshots, from which you can not even build a Boost distribution. And whereas the Boost 1.60 rc1 announcement mail at least provides checksums
The official 1.60 release announcement mail does not
Correct me if I'm wrong, but there is no way for obtaining a Boost release and verifying its integrity and authenticity. The only option I'm seeing is recursively cloning all Boost repositories from Github and building a release by myself. Can we please change this situation? Here are some options that come to mind ordered by amount of effort: - Providing checksums - Educating users on the Downloads page - Signing releases with a trusted Release Team key - Changing the hosting platform Cheers, Daniel J H
On Mon, Mar 14, 2016 at 6:10 AM, Daniel Hofmann wrote:
Can we please change this situation?
+1 Sourceforge has been called out numerous times for its practices. It's probably more reliable now to get a Boost release via The Pirate Bay than the official download link.
Here are some options that come to mind ordered by amount of effort:
- Providing checksums
Yes.
- Educating users on the Downloads page
This probably won't be effective in my opinion. Many people see checksums available but won't actually use them to verify anything.
- Changing the hosting platform
A thousand times, yes. Glen
On Mon, Mar 14, 2016 at 5:10 AM, Daniel Hofmann <daniel@trvx.org> wrote:
Can we please change this situation?
All changes in Boost start with volunteers providing solutions. Here are some options that come to mind ordered by amount of effort:
- Providing checksums
Right. Although I doubt most people use checksums.
- Educating users on the Downloads page
The only education I can think of is step by step instructions on doing checksum verification. Is that what you mean? Can you clarify?
- Signing releases with a trusted Release Team key
OK. Can you provide instructions on doing this securely? - Changing the hosting platform
Do you have suggestions for providers? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On 14.03.2016 09:21, Rene Rivera wrote:
- Changing the hosting platform Do you have suggestions for providers?
Hasn't github grown the means to do proper releases (including binary packages and other artifacts that are not directly tracked in the repository) ? (From https://github.com/blog/1547-release-your-software: "You can also attach binary assets (such as compiled executables, minified scripts, documentation) to a release. Once published, the release details and assets are available to anyone that can view the repository.") It seems that might be one other logical step to get rid of sf.net. Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Monday, March 14, 2016 5:15 AM, Daniel Hofmann <daniel@trvx.org> wrote:
The current download page at
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
where a user was tricked into downloading some arbitrary binary while downloading a Boost release.
Unfortunately there does not seem to be a secure and convenient way to
download Boost releases.>
Although Github's Boost "releases" can be found at
but those are only repository snapshots, from which you can not even
build a Boost distribution.
Ideally, all boost libraries should be installable directly from their github repo like Boost.Hana. However, there is cycles everywhere you turn right now in Boost.
On Mon, Mar 14, 2016 at 5:10 AM, Daniel Hofmann <daniel@trvx.org> wrote:
The current download page at
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
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 sourceforge. 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 situation. Tom
Hi Tom, On 3/15/2016 5:34 AM, Tom Kent wrote:
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.
You make it sounds as if the use of md5 checksums is a huge problem, but I think that for release checking we only care about second-preimage resistance, and there's no remotely practical attack on md5 still. Of course, sha2 is better and just as easy to compute.
2. Sign these sums with a secure PGP/GPG key. 3. Publish this signed file with the sums alongside the downloads.
This is indeed not very hard to do, but do you think many people will go to the trouble of: - Getting PGP key of a release manager and verifying that - Checking signature of the sums file - Checking the checksum proper Maybe detached GPG signature of release binary itself will be a tad more convenient? -- Vladimir Prus http://vladimirprus.com
On Tue, Mar 15, 2016 at 2:31 AM, Vladimir Prus <vladimir.prus@gmail.com> wrote:
Hi Tom,
On 3/15/2016 5:34 AM, Tom Kent wrote:
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.
You make it sounds as if the use of md5 checksums is a huge problem, but I think that for release checking we only care about second-preimage resistance, and there's no remotely practical attack on md5 still. Of course, sha2 is better and just as easy to compute.
Very true, but A) why not? B) this might not be the case ten years from now, and some developer may want to use an old archive.
2. Sign these sums with a secure PGP/GPG key.
3. Publish this signed file with the sums alongside the downloads.
This is indeed not very hard to do, but do you think many people will go to the trouble of:
- Getting PGP key of a release manager and verifying that - Checking signature of the sums file - Checking the checksum proper
Maybe detached GPG signature of release binary itself will be a tad more convenient?
No, I don't think many people at all will care one iota about this, I would expect less than 1%. However, of that 1% that might care at all, I would expect 90% of those would just care that they got a valid download and want to check the sums, only that final 10% of the 1% would want to verify the signature. Because of this, I think it is better to have a separate sums file....but I would be completely happy with either solution. Tom
On 03/16/2016 12:36 PM, Tom Kent wrote:
2. Sign these sums with a secure PGP/GPG key.
3. Publish this signed file with the sums alongside the downloads.
This is indeed not very hard to do, but do you think many people will go to the trouble of:
- Getting PGP key of a release manager and verifying that - Checking signature of the sums file - Checking the checksum proper
Maybe detached GPG signature of release binary itself will be a tad more convenient?
No, I don't think many people at all will care one iota about this, I would expect less than 1%. However, of that 1% that might care at all, I would expect 90% of those would just care that they got a valid download and want to check the sums, only that final 10% of the 1% would want to verify the signature. Because of this, I think it is better to have a separate sums file....but I would be completely happy with either solution.
In the end those few situations could be package maintainer for Linux distributions or alternative package managers like brew for OSX in need of verifying the Boost release they got for their thousands of users. For example, here's how brew does it currently:
https://github.com/Homebrew/homebrew/blob/master/Library/Formula/boost.rb
And although there is a SHA256 checksum in there, it probably comes from the initial developer downloading the Boost release and calculating the checksum locally, as there are no checksums I could find from the Boost Release Team. Therefore all it does is verifying file integrity _for the file that Sourceforge hosts_.
participants (7)
-
Daniel Hofmann -
Glen Fernandes -
paul Fultz -
Rene Rivera -
Stefan Seefeld -
Tom Kent -
Vladimir Prus