[tahoe-dev] 1.9 update: soon! Need help with PyCrypto-2.4!

[Zooko O'Whielacronx]

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