pycryptopp: some features require more careful linking than Ubuntu Gutsy default build provides

[zooko]

Per the ​pycryptopp buildbot waterfall, Ubuntu Gutsy's versions of Crypto++ and/or g++ fall afoul of this problem:

​http://www.mail-archive.com/cryptopp-list@eskimo.com/msg02882.html

(Side note: the reporter in that mailing list message is Eric Hughes, visionary author of The Cypherpunk Manifesto and the Universal Piracy Network (an early, and possibly the first, elucidation of the "darknet" or "illicit file-sharing network" idea), and the guy who hired Bram Cohen and me in 1999.)

[zooko]

Here is an explanation for the actual problem:

​http://lists.apple.com/archives/xcode-users/2006/Jul/msg00386.html

I suspect, but haven't confirmed, that newer versions of Crypto++ work-around this issue. Hm... but the Crypto++ "What's New?" page doesn't mention this explicitly. Perhaps it's partly caused by the way the Ubuntu Gutsy and Debian stable Crypto++ libraries are built?

To shed light on this this, someone should try Crypto++ v5.5.2 on Ubuntu Gutsy and see if it works, try Crypto++ v5.5 as provided in the .deb package for Ubuntu Gutsy, and see if it fails just as the buildslave does and then compile Crypto++ v5.5 from source on Ubuntu Gutsy and see if that also fails.

[zooko]

Three optional features of pycryptopp: SHA256.hexdigest(), handling of invalid key lengths, and ECDSA, all try to compare run-time type information ("RTTI") across dynamic linking boundaries. This works -- for some reason -- on many platforms and fails on others. I believe it is possible to do the linking carefully so that each type which you intend to compare (including catching an exception according to its exception type) is defined exactly once, so that g++'s modern behavior of comparing such things by reference instead of by string comparison on their name will work.

Currently, Tahoe does not use any of these three features of pycryptopp.

[zooko]

This is fixed by pycryptopp >= 0.5 or so.