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@debian.org]