[tahoe-dev] bugs in SHA-256 Re: Crypto++ stable release

[Zooko O'Whielacronx]

Folks:

I finally got around to doing some of this work:

On Mon, Jul 26, 2010 at 12:16 AM, Zooko O'Whielacronx <zooko at zooko.com> wrote:
>
>  * http://tahoe-lafs.org/trac/pycryptopp/ticket/37# Win64 and MSVC9
> compilation fixes

This might be fixed. If it isn't fixed, I think we need another
buildslave which has the right compiler on it to demonstrate this
problem. I'm not going to try to do any more work on it until then.

>  * http://tahoe-lafs.org/trac/pycryptopp/ticket/43# add a quick
> start-up self test for SHA-256

Done.

>  * http://tahoe-lafs.org/trac/pycryptopp/ticket/44# test what happens
> if another Python module loads Crypto++ dynamic link library

Done, and the result is somewhat disturbing. Read the whole thread on
the ticket (pycryptopp #44), but the disturbing result is that once I
turn off the RTLD_GLOBAL hack then I can't reproduce any problem with
RTTI crossing shared library boundaries. In particular we have unit
tests that throw a C++ exception from libcryptopp.so and catch it in
_pycryptopp.so, and this now works on all of our buildslaves. So
perhaps we were using older versions of gcc a year ago and current
versions have somehow fixed the problem. I'm not comfortable with that
"grasping at straws" explanation, but I guess as long as I don't see
evidence of a current problem we might as well move on.

>  * http://tahoe-lafs.org/trac/pycryptopp/ticket/45# upgrade to latest
> Crypto++ with SHA-256 bugfixes

Not yet done. I'm doing some more packaging, versioning, buildbot
herding, etc., first. If someone wants to help, port raeburn's SHA-256
tests from http://sourceforge.net/apps/trac/cryptopp/ticket/2 to
pycryptopp.

Regards,

Zooko