On Wed, 2022-11-30 at 14:14 -0800, Gregory P. Smith wrote:
On Wed, Nov 30, 2022 at 12:47 PM Steve Dower <steve.dower@python.org> wrote:
On 11/30/2022 4:52 PM, christer@weinigel.se wrote:
Does this seem like a good idea? As I said, I feel that it is a bit ugly, but it does mean that if someone wants to use some SSL_really_obscure_function in libcrypto or libssl they can do that without having to rebuild all of CPython themselves.
Broadly, no, I don't think it's a good idea. We don't like encouraging users to do things that make it hard to support them in the future.
+1 ... and in general if you want access to other OpenSSL APIs not already in the ssl module, getting them via non-stdlib packages on PyPI would be a better idea.
https://pypi.org/project/cryptography/ is very well supported.
Does not support TLS at all as far as I can see.
https://pypi.org/project/oscrypto/ exists and is quite interesting.
Does not support ALPN nor export keying material. It would probably be possible to add support though.
the old https://pypi.org/project/M2Crypto/ package still exists and seems to be maintained (wow).
Does not support ALPN nor export keying material. And considering your surprise at it still being maintained it doesn't feel like something that one should use as a base for new code.
More context: We don't like the ssl module in the standard library - it is already too tightly tied to OpenSSL: https://discuss.python.org/t/our-future-with-openssl/21486
So if you want specific OpenSSL APIs that are not exposed, seeking to see them added to the standard library where they would then become features that need to be supported for a very long time, is going to be the most difficult approach as there'd need to be a very good reason to have them in the stdlib.
What I have tried to add support for the last two years is not an API specific for OpenSSL, it is part of TLS. It was introduced in TLSv1.2 in 2010 by RFC5705 "Keying Material Exporters for Transport Layer Security (TLS)". OpenSSL added support for it in 2011 and the API has basically been unchanged since (the parameter names in the prototype in openssl/tls1.h has changed but is functionally identical). Support for RFC5705 is available in GnuTLS, Microsoft Schannel, Mbed-TLS, Botan and even good old Mozilla NSS. So basically what you are telling me is that there is no interest in adding support for a 12 year old part of TLS to the standard ssl library in Python, nor any interest in adding hooks to make it possible to extend the ssl library. Because the latter is basically what I was told to do when my patch to add support for RFC5705 was rejected: https://bugs.python.org/issue43902
Third party libraries that can provide what you need, or rolling your own libssl API wrappings however you choose to implement them, are better bets
I have not found any third party library that supports RFC5705, none of the ones you mentioned above has support for it and are also missing other functionality such as ALPN that is needed by RFC8915 "Network Time Security for the Network Time Protocol" which is what I actually want to implement. The standard ssl library in Python is so very close to what I need, it has support for everything else needed by RFC8951, so I would very much prefer to use it if possible. It just feels so silly somehow to have to have my own fork of all of CPython or to use a completely different TLS library just to be able to use a functino that has been a part of TLS and OpenSSL since basically forever. :) /Christer