I'm extremely annoyed at the fact that we depend on PyCrypto, which I regard as too sloppily-written to be secure, and also as too sloppily-written to build and install on all the platforms we support. For a while there the pain had lessened because there were no new releases of PyCrypto, and people had worked-around all of the known problems in the most recent release. But unfortunately they are apparently maintaining PyCrypto again, so now it is going to resume interfering with our work.
Short term solution: declare that Tahoe-LAFS v1.9 doesn't support Python 2.4 anymore. (This is because this particular bug in PyCrypto is probably specific to being it built for Python 2.4) I'm okay with that, and it is a fast way to reduce our load, and I have a lot of other things that I want to do (launch Least Authority Enterprises to live customers, doc writing and auditing for Tahoe-LAFS v1.9, preparing for the Summit, ...). If anybody is dying to use Tahoe-LAFS v1.9 with Python 2.4, speak up now! Possible long-term solution: replace the place where Twisted depends on PyCrypto with a dependency on something else (pycryptopp, botan, ?). This is a lot of work, because there isn't a ready-made crypto library for Python which does everything that Twisted wants from PyCrypto. See Twisted ticket #4633. Possible long-term solution: replace the place where Twisted depends on PyCrypto with a null plugin that doesn't actually encrypt, and replace the warning in https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/frontends/FTP-and-SFTP.rst#configuring-sftp-access so that instead of saying "We don't trust the crypto on the SFTP connection, so be cautious about it.", it says "There is no crypto on the SFTP connection, so don't use it except over loopback or a secure network.". (What does "be cautious" mean, anyway? I guess it means feel worry in your heart but do it anyway.) I'm not sure that would work, but I prefer giving people a thing that claims to not have security over a thing that claims to have security but that claim is suspect. :-( Oh by the way, I think those docs are now obsolete -- they say there are no AES timing defenses in the PyCrypto code, but I think they might have added that. Not sure. Impatiently yours, Zooko http://twistedmatrix.com/trac/ticket/4633# allow applications to "bring their own crypto" to avoid the dependency of conch on PyCrypto _______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev