Author orsenthil
Recipients asvetlov, brandon-rhodes, christian.heimes, dstufft, giampaolo.rodola, jcea, jgehrcke, kristjan.jonsson, martius, njs, orsenthil, pitrou
Date 2017-12-05.20:17:11
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1512505031.5.0.213398074469.issue16487@psf.upfronthosting.co.za>
In-reply-to
Content
Hi Cristian,

>  I don't want to have three ways to load certificates, especially when it involves more C code.

I think this (more C code) is the primary and the *only* negative point against the current patch. And that seems necessary for the feature specific to OpenSSL. 

Not sure if you looked at the latest version (https://github.com/python/cpython/pull/2449/files) recently. 

The current patch does not deviate in-principle from the PEP 543.

It maintains the same API arguments ` SSLContext.load_cert_chain(certfile, keyfile=None, password=None)`

* We expect the migration of ssl module to newer ABC of PEP-543 not be one-to-one. We could foresee this API living. (And we haven't deprecated this API).

* The patch provides the feature along with plenty of tests that PEP-543 talks about (Loading of certs from memory).

* Has an implementation refactorable for OpenSSL-specific TLS backend (as one of the provider), that again will be useful to PEP-543 implementation.

These are the benefits in my opinion.

PEP-543 is important and seems like a *major effort*. The current patch might still be valuable and perhaps might be useful towards PEP-543 implementation. It deals only with certificates only.
History
Date User Action Args
2017-12-05 20:17:11orsenthilsetrecipients: + orsenthil, jcea, pitrou, kristjan.jonsson, giampaolo.rodola, christian.heimes, njs, asvetlov, jgehrcke, brandon-rhodes, dstufft, martius
2017-12-05 20:17:11orsenthilsetmessageid: <1512505031.5.0.213398074469.issue16487@psf.upfronthosting.co.za>
2017-12-05 20:17:11orsenthillinkissue16487 messages
2017-12-05 20:17:11orsenthilcreate