On Thu, Sep 23, 2010 at 7:14 AM, Greg Troxel <[email protected]> wrote: > > Is 0.5.19 acceptable? That's what is in pkgsrc, and probably what was > current when I added packages over the summer. I am running 1.8.0c4 > with py-cryptopp 0.5.19 and it seems ok.
pycryptopp contains a copy of some source code from the Crypto++ project which source code it uses by default. It offers an optional build-time option to not use that source code and instead link against an extant libcryptopp.so library. pycryptopp-0.5.19 had some bugs in the included copy of the Crypto++ source code, which bugs were also present in Crypto++ v5.6.0 and are fixed in Crypto++ v5.6.1. Here are the patches: http://tahoe-lafs.org/trac/pycryptopp/changeset/20100919041310-93fa1-d7f528bbba69d9ca14112b5f44ee1765ef34fefc/trunk http://cryptopp.svn.sourceforge.net/viewvc/cryptopp?view=revision&revision=471 http://tahoe-lafs.org/trac/pycryptopp/changeset/20100919041746-93fa1-fdb77ae7c52be25dd3f3578a7958dcf66e6d6fcb/trunk http://cryptopp.svn.sourceforge.net/viewvc/cryptopp?view=revision&revision=480 http://tahoe-lafs.org/trac/pycryptopp/changeset/20100919041827-93fa1-e9107606cdd3e1328230655fd25ebcaf3fcf2e99/trunk http://cryptopp.svn.sourceforge.net/viewvc/cryptopp?view=revision&revision=492 If the pkgsrc build of pycryptopp v0.5.19 is rebuilt against Crypto++ v5.6.1 instead of against Crypto++ v5.6.0 then that will also fix these issues. However, Tahoe-LAFS is currently marked as requiring pycryptopp >= v0.5.20, see: http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/_auto_deps.py?rev=4739 Therefore Tahoe-LAFS will refuse to build or will attempt to download a new version of pycryptopp at build time if the version of pycryptopp that it finds is v0.5.19. So I think it would be best if you could update the pkgsrc build of pycryptopp to the latest release (pycryptopp v0.5.25). Would that work? Regards, Zooko _______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
