gh-118658: Return consistent types from get_un/verified_chain in SSLObject and SSLSocket#118669
gh-118658: Return consistent types from get_un/verified_chain in SSLObject and SSLSocket#118669Yhg1s merged 27 commits into
get_un/verified_chain in SSLObject and SSLSocket#118669Conversation
|
I restored my old branch from which I created the original PR #109113. There is one file missing about NEWS, I am not sure if that was removed on purpose or not. |
Sorry, something went wrong.
sethmlarson
left a comment
There was a problem hiding this comment.
Seems good to me, since these methods are now documented would it make sense to have a test case?
Sorry, something went wrong.
Why not, it will not hurt. I will add it. |
Sorry, something went wrong.
|
@matiuszka do you plan to add the test cases soon? I would love to see this PR merged. |
Sorry, something went wrong.
Sorry, I forgot about this issue. I will be available next week, so probably next Monday I will have it ready. |
Sorry, something went wrong.
|
@sethmlarson, @felixfontein I tried to write tests for it but I am not sure how to start. There are no tests for the SSL module, so there is nothing that I can use to start. I would need a boilerplate code to see how to execute such a test. |
Sorry, something went wrong.
felixfontein
left a comment
There was a problem hiding this comment.
From my POV this is ready to go. (I have no idea who actually has to approve/merge this though, and how to get it backported to 3.13...)
Sorry, something went wrong.
|
As far as backporting to 3.13, I'll tag in @Yhg1s. The gist is that this API solidified, but didn't get applied to both places where peer certificates can be fetched. Not backporting this will be confusing to other Python implementations which will start implementing the API now that it's public in 3.13 and potentially leave the APIs in a strange place wrt backwards compatibility. There are only two projects which used these APIs that I'm aware of prior to their public availability and they both should be robust to a backport of this API. |
Sorry, something went wrong.
Sorry, something went wrong.
|
Thanks @matiuszka for the PR, and @Yhg1s for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13. |
Sorry, something went wrong.
… in `SSLObject` and `SSLSocket` (pythonGH-118669) (cherry picked from commit 8ef358d) Co-authored-by: Mateusz Nowak <nowak.mateusz@hotmail.com> Co-authored-by: Gregory P. Smith [Google LLC] <greg@krypto.org>
…` in `SSLObject` and `SSLSocket` (GH-118669) (#123082) gh-118658: Return consistent types from `get_un/verified_chain` in `SSLObject` and `SSLSocket` (GH-118669) (cherry picked from commit 8ef358d) Co-authored-by: Mateusz Nowak <nowak.mateusz@hotmail.com> Co-authored-by: Gregory P. Smith [Google LLC] <greg@krypto.org>
… in `SSLObject` and `SSLSocket` (python#118669) Co-authored-by: Gregory P. Smith [Google LLC] <greg@krypto.org>
… in `SSLObject` and `SSLSocket` (python#118669) Co-authored-by: Gregory P. Smith [Google LLC] <greg@krypto.org>
|
Sadly, I think this has to be reverted, as it broke certificate generation script, and doesn't contain any other way to generate cert3.pem: Alternatively, you need to produce a fix to that script that includes correct regeneration of cert3.pem. |
Sorry, something went wrong.
…d_chain` in `SSLObject` and `SSLSocket` (python#118669)" This reverts commit 8ef358d.
|
@kanavin how about simply disabling the broken test instead of reverting the whole PR? It would be pretty sad if the interface would be re-broken by reverting this. |
Sorry, something went wrong.
|
I looked at the certs; |
Sorry, something went wrong.
|
#124598 should fix Lib/test/certdata/make_ssl_certs.py to extract cert3.pem from keycert3.pem. |
Sorry, something went wrong.
|
|
Sorry, something went wrong.
Fixses inconsistent return types between
SSLObjectandSSLSocketas described ingh-118656