Added a new PEP as draft: Enabling certificate verification by default for stdlib mail modules#3537
Added a new PEP as draft: Enabling certificate verification by default for stdlib mail modules#3537nitram2342 wants to merge 8 commits intopython:mainfrom
Conversation
|
All commit authors signed the Contributor License Agreement. |
…ection names, added backward compatiblity section.
Please check this again, it looks like this file has been created from an old PEP rather than the PEP 12 |
| Author: Martin Schobert <martin@pentagrid.ch> | ||
| Sponsor: Victor Stinner <vstinner@python.org> |
There was a problem hiding this comment.
I would prefer that you ask me to be a sponsor, and ask me to review the PEP before you go ahead and propose it directly.
| Author: Martin Schobert <martin@pentagrid.ch> | |
| Sponsor: Victor Stinner <vstinner@python.org> | |
| Author: Martin Schobert <martin@pentagrid.ch> |
There was a problem hiding this comment.
Context: I offered to sponsor a PEP if someone wants to write it: python/cpython#91826 (comment)
There was a problem hiding this comment.
Thanks for the background.
It's great to be proactive and write the PEP, but it's also very important to have a sponsor beforehand who's happy with the text, and also to help with the process. PEP 1 says:
Once the sponsor or the core developer(s) co-authoring the PEP deem the PEP ready for submission, the proposal should be submitted as a draft PEP via a GitHub pull request.
I suggest we close this PR for now, and @nitram2342 contacts @vstinner privately and they decide how to proceed. If they can agree on a text together, then update and re-open this PR, or a fresh one, and we can take it from there.
How does that sound?
There was a problem hiding this comment.
If someone wants me to sponsor a PEP, I would prefer to read it and approve it ahead, right.
@nitram2342: If you would like to sponsor your PEP, I suggest you closing this PR, as @hugovk suggests.
There was a problem hiding this comment.
Okay, that is fine. I will do it this way.
The Python docs say:¹ _ssl_context_ is a `ssl.SSLContext` object which allows bundling SSL configuration options, certificates and private keys into a single (potentially long-lived) structure. Please read Security considerations for best practices. … For client use, if you don’t have any special requirements for your security policy, it is highly recommended that you use the `create_default_context()` function to create your SSL context. It will load the system’s trusted CA certificates, enable certificate validation and hostname checking, and try to choose reasonably secure protocol and cipher settings. … By contrast, if you create the SSL context by calling the `SSLContext` constructor yourself, it will not have certificate validation nor hostname checking enabled by default. While this is clear, it is counter-intuitive behaviour of which I was unaware. I only learned of this through an oss-sec posting.² This issue seems to have a long history and we are not the only software affected by it.³ ¹ https://docs.python.org/3/library/imaplib.html#imaplib.IMAP4_SSL ² https://www.openwall.com/lists/oss-security/2024/02/01/4 ³ python/cpython#91826, https://peps.python.org/pep-0476/, python/cpython#91875, https://www.pentagrid.ch/en/blog/python-mail-libraries-certificate-verification/, python/peps#3537
4 participants
Basic requirements (all PEP Types)
pep-NNNN.rst), PR title (PEP 123: <Title of PEP>) andPEPheaderAuthororSponsor, and formally confirmed their approvalAuthor,Status(Draft),TypeandCreatedheaders filled out correctlyPEP-Delegate,Topic,RequiresandReplacesheaders completed if appropriate.github/CODEOWNERSfor the PEPStandards Track requirements
Python-Versionset to valid (pre-beta) future Python version, if relevantDiscussions-ToandPost-History📚 Documentation preview 📚: https://pep-previews--3537.org.readthedocs.build/