1.51.0] Beta 1 release candidate 2 available
Release candidate files for 1.51.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: e3a51b82894a67ac438eaa08192929eb *boost_1_51_0_beta1_rc2.tar.gz 1c541236f98dcaa706e7f8eabb11ebfc *boost_1_51_0_beta1_rc2.tar.bz2 964f150ce9d7bcaba74255aba73d338a *boost_1_51_0_beta1_rc2.zip e23467c3369a53189300c76e8c848aa1 *boost_1_51_0_beta1_rc2.7z Thanks to everyone who tried out rc1, and especially Neal Becker, who helped me track down a permissions error in the build process --The release managers
Hi.
Release candidate files for 1.51.0 beta 1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
boost_1_51_0_beta1_rc2.7z built correctly on Windows 7/x64 using msvc-9.0. Tested with Boost Build/Jam from the trunk and the one contained in the distribution itself. Command-line: bjam.exe stage --stagedir=xxx --without-mpi --build-type=complete Hope this helps. Best regards, Jurko Gospodnetić
On Wed, Aug 1, 2012 at 4:42 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
Release candidate files for 1.51.0 beta 1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
This helps ensure the candidates build OK before we push them out to SourceForge.
The files (and associated md5s) are: e3a51b82894a67ac438eaa08192929eb *boost_1_51_0_beta1_rc2.tar.gz 1c541236f98dcaa706e7f8eabb11ebfc *boost_1_51_0_beta1_rc2.tar.bz2 964f150ce9d7bcaba74255aba73d338a *boost_1_51_0_beta1_rc2.zip e23467c3369a53189300c76e8c848aa1 *boost_1_51_0_beta1_rc2.7z
Thanks to everyone who tried out rc1, and especially Neal Becker, who helped me track down a permissions error in the build process
--The release managers
Works for me. Builds under VC8, VC9, VC10 for 32 & 64 bit. Links/Runs with a test exe on all those platforms in debug and release configurations. One suggestion for the release process: can we use sha256 sums? I've dumped md5 from all my processes, its not a huge deal but if we're going to have cryptographic checksums we might as well do the ones that work. Thanks, Tom
On Aug 2, 2012, at 11:58 AM, Tom Kent <lists@teeks99.com> wrote:
On Wed, Aug 1, 2012 at 4:42 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
Release candidate files for 1.51.0 beta 1 are available at http://boost.cowic.de/rc/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
This helps ensure the candidates build OK before we push them out to SourceForge.
The files (and associated md5s) are: e3a51b82894a67ac438eaa08192929eb *boost_1_51_0_beta1_rc2.tar.gz 1c541236f98dcaa706e7f8eabb11ebfc *boost_1_51_0_beta1_rc2.tar.bz2 964f150ce9d7bcaba74255aba73d338a *boost_1_51_0_beta1_rc2.zip e23467c3369a53189300c76e8c848aa1 *boost_1_51_0_beta1_rc2.7z
Thanks to everyone who tried out rc1, and especially Neal Becker, who helped me track down a permissions error in the build process
--The release managers
Works for me.
Builds under VC8, VC9, VC10 for 32 & 64 bit.
Links/Runs with a test exe on all those platforms in debug and release configurations.
One suggestion for the release process: can we use sha256 sums? I've dumped md5 from all my processes, its not a huge deal but if we're going to have cryptographic checksums we might as well do the ones that work.
Ok, you've whetted my curiosity. What "doesn't work" in md5? I'm aware of the attacks against it. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On Thu, Aug 2, 2012 at 10:18 PM, Marshall Clow <mclow.lists@gmail.com>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")...here's one good one: http://www.mscs.dal.ca/~selinger/md5collision/ The (albeit far fetched) attack here is that someone could hack the boost.cowic.de 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 project. Tom
participants (3)
-
Jurko Gospodnetić -
Marshall Clow -
Tom Kent