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.do...@python.org>
> wrote:
> > On 11/30/2022 4:52 PM, chris...@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



_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/J5ASRHNV7ZS22QBE2NWHGISV5RGB7W5W/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to