Thanks to Brian Vincent for the really good bug report. I can't yet tell if this bug could effect my use of Crypto++. My use of Crypto++ is in the pycryptopp library:
https://pypi.python.org/pypi/pycryptopp I think whether this bug can affect my users may depend on whether Python sets signal handlers in the main thread. Also, we already have this patch: http://cryptopp.svn.sourceforge.net/viewvc/cryptopp?view=revision&revision=525 . Our version of it is: https://github.com/tahoe-lafs/pycryptopp/commit/906683989eddadb9a5f4da17ce49867b3e27a24a I can't tell if that patch would fix this bug. Apparently Brian Vincent didn't try it (for the very good reason that he didn't see why it would help). It's a shame that the way to exercise this bug requires sending a signal from a separate process. I really like testing (https://tahoe-lafs.org/buildbot-pycryptopp/waterfall), but even I may balk at writing a test that spawns a subprocess and then sends signals at it. I'm seriously thinking of just defining CRYPTOPP_DISABLE_ASM always in our build system. This would have eliminated about 90% of the bugs we've had to deal with over the years. I honestly don't know if the performance penalty would be detectable to my users, but I guess I could experiment. (We have benchmarks as well as unit tests on that buildbot.) In any case, defining that would guarantee that my users are safe from this bug (unless they link at runtime to a system-provided libcryptopp.so instead of letting pycryptopp's build system build Crypto++ for them). In the future, I intend to work toward replacing Crypto++ entirely in pycryptopp, for reasons of compilation, portability, deployment, etc. The biggest single problem I have with Crypto++ is that it is written in C++. Every couple of years this causes a deployment headache for me. The most recent example is that the newest and best way to interface native code to Python -- cffi (http://cffi.readthedocs.org/en/latest/) doesn't support C++ at all. I think I'd rather have the simplicity of using cffi and give up the advantages of Crypto++. That means I have to adopt some other implementation of AES and of RSA, most likely by relying on a future release of pyOpenSSL which is itself based on cffi and which exposes the lower-level API of OpenSSL to Python land. Thanks! Regards, Zooko -- -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com. --- You received this message because you are subscribed to the Google Groups "Crypto++ Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
