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

Brian Warner warner at lothar.com
Sun Nov 1 11:16:06 MST 2015


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.

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).

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.

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.

cheers,
 -Brian




More information about the Twisted-Python mailing list