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