[Twisted-Python] INCOMPATIBLE CHANGE: removing dependency on PyCrypto

[Glyph Lefkowitz]

> On Nov 1, 2015, at 10:16, Brian Warner <warner at lothar.com> wrote:
> 
> On 10/31/15 11:16 PM, Glyph Lefkowitz wrote:
> 
>> I'm working on a ticket - https://twistedmatrix.com/trac/ticket/7413 -
>> to eliminate the dependency on PyCrypto. Right now, in that branch,
>> those objects are Cryptography key objects instead of PyCrypto key
>> objects.
>> 
>> It is /possible/ to preserve compatibility with keyObject, and we
>> could deprecate and then remove objectType, with conditional
>> dependencies on PyCrypto. But before I go through the effort there,
>> I'm wondering if any users of conch actually care.
> 
> Tahoe-LAFS uses Conch for two features: an SFTP frontend, and a
> "manhole" repl-inside-the-app debugging interface. Neither uses the keys
> objects.

Thanks for checking on that.

> Tahoe *does* indicate a dependency on PyCrypto because conch uses it,
> and at the time we found it was more reliable to depend upon the
> transitive closure of our subdependencies. We'll need to fix that (as we
> bring our packaging up to modern standards).

I am definitely feeling the pain with you on that one :).

> Our SFTP frontend currently uses "from Crypto import Util" as a test to
> see whether twisted.conch.ssh.filetransfer is going to work, so the
> failure happens early and we can provide a better "your configuration
> isn't going to work" error message. I'm guessing we imported pycrypto
> rather than t.c.ssh directly to work around some old importer bug (I
> vaguely remember something about half-complete imports causing confusion
> in some old version of python). The code in question is ancient and
> we'll need to update that when Twisted stops using PyCrypto.

That interpreter bug was something Twisted had workarounds for too, and I am fairly certain it was fixed in python *2.5*, so it's been QUITE a while since it was a real concern :).  If you can, I'd recommend fixing that conditional import now rather than waiting for a Twisted release that has switched backends.

> But in general, yeah, we'd love to see PyCrypto go away. We currently
> depend on pycryptopp (for AES/RSA/Ed25519), PyCrypto (via conch for SFTP
> and manhole), and 'cryptography' (via pyOpenSSL via Foolscap for server
> connections). Reducing the dependency graph by one node would be great.

Excellent.

It's worth noting that Cryptography now provides good support for AES and RSA (pretty sure this was not true when I was last discussing Cryptography in the context of Tahoe), and has plans for Ed25519 - https://github.com/pyca/cryptography/issues/856 - so you may be able to reduce this even further in the future :).

-glyph