> On Jul 25, 2016, at 02:03, Matěj Cepl <mc...@cepl.eu> wrote: > > 3) Moreover, I would like to know how much interest there is in > maintaining the M2Crypto module for Twisted. I got some hope from > http://twistedmatrix.com/trac/wiki/TransportLayerSecurity > <http://twistedmatrix.com/trac/wiki/TransportLayerSecurity> which seems > like there is an interest in more complete OpenSSL bindings,
That is a very old wiki page. I will delete it to avoid confusing people in the future! Not only has pyOpenSSL had complete enough bindings to implement the feature described on that wiki page for several years now (a Twisted developer, Jean-Paul Calderone, actually took over maintenance of pyOpenSSL expressly for the purpose of adding those APIs), we actually implemented the TLS implementation based on those APIs <https://github.com/twisted/twisted/blob/trunk/twisted/internet/_newtls.py <https://github.com/twisted/twisted/blob/trunk/twisted/internet/_newtls.py>> in 2011, and fully finished transitioning to that new API in 2014 <https://github.com/twisted/twisted/commit/ee2070fe9e3f539ff702d9ff133aafa33ea19ac5> when we deleted the older, SSLSocket based API. > but OTOH I see on the list that Twisted now seems to use more and more of > Cryptography (why in the world somebody made such confusing name of > their project ...). The choice of name is intentional: it is designed to convey a sense of authoritativeness. I.e. if you need cryptography in Python, you should 'import cryptography', and ignore everything else. The Cryptography project specifically calls out M2Crypto, PyCrypto, and PyOpenSSL as having problems and lacking maintenance: <https://cryptography.io/en/latest/#why-a-new-crypto-library-for-python <https://cryptography.io/en/latest/#why-a-new-crypto-library-for-python>>. pyOpenSSL is now just a thin wrapper over Cryptography itself, and PyCrypto's maintainer now generally suggests Cryptography <https://github.com/dlitz/pycrypto/issues/158#issuecomment-140833926 <https://github.com/dlitz/pycrypto/issues/158#issuecomment-140833926>>. So it is 2/3 of the way to achieving its goal of eliminating these libraries which duplicate so much effort - M2Crypto is all that remains :). > Obviously the most simple way for me to be cutting > Twisted module from M2Crypto and let it be (although I am afraid I have > still some legacy users who would like to see it maintained, and given > that the legacy support is still the most important reason for > maintaining M2Crypto, I don't want to give up lightly). I do not want to denigrate the work you've done maintaining a legacy library. I think it's noble to take on this kind of work. But if you don't have any particular reason for needing to maintain this library beyond "legacy support", and it is not different from Cryptography in any meaningful way, the best thing that you could do for its existing users would be to do the same thing that was done with pyOpenSSL: make it a thin wrapper over the bindings layer in Cryptography, get rid of all of the SWIG code in M2Crypto, and start gently directing users in the direction of Cryptography for any new code. This would get everyone onto a supported base platform for their security primitives, allow them to share code with other parts of large systems that already use Cryptography or pyOpenSSL, and provide a well-maintained path forward. M2Crypto's main claim to superiority in past years was its higher degree of completeness of OpenSSL APIs, but Cryptography has since far surpassed it. Even if there are some APIs that Cryptography's bindings layer doesn't export, it's easier and safer to add more bindings there than in M2Crypto. Even if you're not going to get rid of M2Crypto entirely, M2Crypto's implementation of Twisted TLS copies the terrible no-security defaults it inherits from OpenSSL, the same ones that Twisted had 5 years ago, and Twisted has moved on to have actual security (certificate verification, service identity, and trust root configuration). We also continue to improve that security regularly. Given all that, this is a rare case where I would not mind seeing Twisted support disappear from a library. Unless I were to get some new information I would have to very strongly discourage anyone who wanted to use the SSL backend in M2Crypto. I realize you have users, but possibly the best thing you could do for their own good would be to force them to move to Twisted's much better native TLS support, which thankfully is easy to adopt at this point. -glyph
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
