Boost logo

Boost :

Subject: Re: [boost] 1.51.0] Beta 1 release candidate 2 available
From: Tom Kent (lists_at_[hidden])
Date: 2012-08-02 23:08:05

On Thu, Aug 2, 2012 at 10:18 PM, Marshall Clow <mclow.lists_at_[hidden]>wrote:

> Ok, you've whetted my curiosity.
> What "doesn't work" in md5?
> I'm aware of the attacks against it.
There's a lot of stuff out there on the problems with md5 (search "chosen
prefix collision")'s one good one:

The (albeit far fetched) attack here is that someone could hack the server, replace the file with another
boost_1_51_0_beta1_rc1.* that has something malicious in it. Usually if a
user checked the md5 of it, then they would be able to see that someone had
replaced the file that you vouched for with a malicious one. However,
because md5 is broken, it would be easy for the attacker to add padding
somewhere in the file so that the final md5 that they generate matches the
md5 that you published.

I don't think this is a realistic attack on a server with the beta/rc
builds. For instance, it would be easier to send a fake e-mail with
different checksums if you were an attacker here. The real reason I was
asking for the sha256 sums was that I'm already using those in my build
script (it is the current, top of the line cryptographic hash function) and
then I wouldn't have to lift my fingers to type another command.
*groan...sooo difficult*

If we really did want to secure things (like when we push the official
stuff to sourceforge) the thing to do would be to make a file (SHA256SUMS)
with all the hashes for the various builds (.zip, .7z, .tar.gz, .tar.bz2)
in it. Then make a second file (SHA256SUMS.gpg) that contains the
signature for the first file, signed by the build maintainer's GPG key.
 This way if the sourceforge account should ever be breached, we'll know if
the files up there were the ones the build maintainer actually published.
 Or we could just keep going as is, I don't think this is a very high-risk


Boost list run by bdawes at, gregod at, cpdaniel at, john at