[Twisted-Python] Conch Ed25519: testing advice wanted

Colin Watson cjwatson at debian.org
Mon Dec 23 08:02:57 MST 2019


Hi,

I've been working for a while on adding Ed25519 SSH key support to
Conch.  This is almost done: if and when
https://github.com/twisted/twisted/pull/1210 lands, everything should
work provided that you're using the cryptography wheel or otherwise have
a new enough OpenSSL to support X25519 (for curve25519-sha256 key
exchange) and Ed25519 (for the key format itself).

My professional interest in having this feature is for Launchpad, and in
that case we want to use the Ubuntu-packaged OpenSSL (since we're in the
same company as the security team supporting it, after all).  The
awkward thing is then that we're currently on Ubuntu 16.04, which has
OpenSSL 1.0.2g, which is too old to support either X25519 or Ed25519.
Ubuntu 18.04 has fortunately been updated to OpenSSL 1.1.1, which
supports X25519, but cryptography's Ed25519 support requires OpenSSL
1.1.1b.  I've asked about getting 18.04 updated to 1.1.1b or newer, but
as I understand it, despite the innocuous-looking change in version
number, this is a pretty complicated endeavour and may well not happen.

In https://github.com/twisted/twisted/pull/644, I brought up the
possibility of using PyNaCl as an alternative implementation to cope
with this sort of case, and Glyph seemed generally supportive of that
idea, so I've been looking into the details.  Using PyNaCl as an X25519
alternative seems unfortunately difficult, as it only exposes a wrapped
version of X25519 which isn't quite what we need, so I'm assuming that
I'll need to update to Ubuntu 18.04 and have been confining my
investigations to just the Ed25519 compatibility portion.

The actual code in this case isn't difficult: it's only 50 lines or so
for versions of nacl.signing.SigningKey and nacl.signing.VerifyKey which
implement cryptography's Ed25519PrivateKey and Ed25519PublicKey
interfaces.  The bit I'm stuck on is how best to test this.  Of course I
can easily enough make some tests pretend that cryptography doesn't
support Ed25519, but Twisted doesn't currently depend on PyNaCl, and it
doesn't need it for anything other than this edge-case compatibility
layer.

I can see a few options:

 * Make Twisted[conch] depend on PyNaCl, and use that to test the
   compatibility layer.  This would work, but it seems a bit rude.

 * Add extra test matrix entries with different dependencies to test the
   PyNaCl-based compatibility code.  This seems kind of excessive and
   awkward, not to mention fiddly to maintain just for this.

 * Add a Twisted[test] extra or similar for things that are only needed
   by the test suite.

 * Just don't test the compatibility layer.  I don't imagine this would
   be a popular option.

Any preferences, or any other suggestions?

-- 
Colin Watson                                       [cjwatson at debian.org]



More information about the Twisted-Python mailing list