Draft PEP: Enabling certificate verification by default for stdlib mail modules

[nitram2342]

Basic requirements (all PEP Types)

• Read and followed PEP 1 & PEP 12
• File created from the latest PEP template
• PEP has next available number, & set in filename (pep-NNNN.rst), PR title (PEP 123: <Title of PEP>) and PEP header
• Title clearly, accurately and concisely describes the content in 79 characters or less
• Core dev/PEP editor listed as Author or Sponsor, and formally confirmed their approval
• Author, Status (Draft), Type and Created headers filled out correctly
• PEP-Delegate, Topic, Requires and Replaces headers completed if appropriate
• Required sections included
  • Abstract (first section)
  • Copyright (last section; exact wording from template required)
• Code is well-formatted (PEP 7/PEP 8) and is in code blocks, with the right lexer names if non-Python
• PEP builds with no warnings, pre-commit checks pass and content displays as intended in the rendered HTML
• Authors/sponsor added to .github/CODEOWNERS for the PEP

Standards Track requirements

• PEP topic discussed in a suitable venue with general agreement that a PEP is appropriate
• Suggested sections included (unless not applicable)
  • Motivation
  • Rationale
  • Specification
  • Backwards Compatibility
  • Security Implications
  • How to Teach This
  • Reference Implementation
  • Rejected Ideas
  • Open Issues
• Python-Version set to valid (pre-beta) future Python version, if relevant
• Any project stated in the PEP as supporting/endorsing/benefiting from the PEP formally confirmed such
• Right before or after initial merging, PEP discussion thread created and linked to in Discussions-To and Post-History

---

📚 Documentation preview 📚: https://pep-previews--3602.org.readthedocs.build/

[hugovk]

Before we proceed any further, do you have a sponsor for this PEP? It's an important first step.

Please re-read PEP 1, specifically:

https://peps.python.org/pep-0001/#submitting-a-pep

I've renamed the PR to make it clear that 738 has not been assigned yet, we need a sponsor first.

Edit: 738 (and 739) has already been assigned but not yet merged.

[gvanrossum]

There's also no Discussions-To: header. Where was this proposal discussed prior to writing the PEP?

[gvanrossum]

In general I think you're making a decent point. It would just be nice if you followed the process and discussed this with the developer community before submitting a PEP. Maybe a PEP wouldn't even be necessary? The only issue is one of backwards compatibility.

Anyway, here are a few nits/questions about the PEP as it stands -- but probably you should just start a discussion on discuss.python.org first.

[gvanrossum]

This sounds like the abstract! And what you wrote in the abstract sounds like the motivation. :-)

[gvanrossum]

consistent

[gvanrossum]

Which IIUC you wrote.

[nitram2342]

The proposal wasn't discussed and I do not have a sponsor, yet, at least not for the text as it is. I thought Christmas is coming, maybe I can make a wish. :-) I wrote a PEP, because there was already PEP 476 to change the certificate verification for HTTP libs and it was a recommendation to write a PEP over in a Cpython discussion. As far as I understand, writing a PEP seems to be a very specific thing, while for me it feels like the most complicated way of filing a security ticket I have ever experienced. Nevertheless, I can start a discussion at discuss.python.org, maybe in the Ideas section.

[Mariatta]

While you can propose a PEP, there is still a certain procedure to be followed and some pre-requisites.
I know not everyone is keeping up with core devs workflow and process, so you might find my PEP Talk useful. In this talk, you'll learn about what PEPs are, what might need a PEP, and how Python community can participate in the PEP process.

Slides: https://speakerdeck.com/mariatta/pep-talk

[gvanrossum]

Yeah, to file a security ticket you typically email security@python.org, but given that there’s already public discussion of the problem, you would generally just be advised to open a regular ticket. The need to write a PEP would come up in the discussion on that issue — or not. I don’t immediately see why this particular issue requires a PEP. So either discuss.python.org or GitHub.

[gvanrossum]

Whoa. I got the chronology all wrong. In the CPython issue you referenced (which you should have mentioned in the PEP and in the initial comment) it's clear that @vstinner wants to sponsor your PEP, but he prefers it if you contact him, asking him to be a sponsor, so he can guide you through the PEP authoring and submission process. You already submitted an earlier draft PEP, which was closed for this same reason. I am honestly not sure why you didn't just contact him (possibly via the CPython issue) instead of once again breaking protocol and submitting a PEP without context.

I'll leave it to @vstinner to deal with the rest of the process now, I am done trying to mentor you, sorry.

[hugovk]

I wrote a PEP, because there was already PEP 476 to change the certificate verification for HTTP libs and it was a recommendation to write a PEP over in a Cpython discussion

Ah right. So this PR is a duplicate of your #3537 from last month.

What happened:

• In April 2022 in Enable TLS certificate validation by default for SMTP/IMAP/FTP/POP/NNTP protocols cpython#91826 (comment), @vstinner suggested a PEP is needed as the change would impact many users.

• After more discussion, last month Victor offered to sponsor such a PEP.

• @nitram2342 wrote a PEP and opened PR Added a new PEP as draft: Enabling certificate verification by default for stdlib mail modules #3537, but hadn't talked to Victor so it came as a surprise, who said he would have preferred to been asked first and given the chance to review before it was posted. This is after all the PEP process.

• In Added a new PEP as draft: Enabling certificate verification by default for stdlib mail modules #3537 (review), I suggested Martin contacts Victor privately so they can decide how to proceed, and we close it until they agree on the text.

It seems that hasn't happened, and we're back to needing a sponsor, if we want to take the PEP path. I think a discussion at discuss.python.org is the way forward, and hopefully you can find a sponsor there.

Let's close this PR as a duplicate, and if you find a sponsor, then you can open a new PR once they're on board.

[hugovk]

Let's open this for a bit longer.

@nitram2342 Please will you contact @vstinner and see if he's happy to sponsor? You can find his email on his profile.

Let us know if you've any questions.

Thanks!

[nitram2342]

Yes, this pull request is the second attempt for a PEP. What I did not understand at the time of the first attempt is that there is a sponsor for a specific form of a PEP and not the general idea. I did it wrong and added @vstinner as sponsor without asking him and going into discussion. So, after the first pull request, I contacted @vstinner, because he offered to be a sponsor, but he had no time to review the PEP draft. If people don't have time, that's the way it is. I didn't want to interrupt any further.

I started this pull request without a sponsor. I assumed there would be a sponsor if someone considers this important enough.

Meanwhile I opened a discussion over on discuss.python.org. We will see where the discussion leads.

[hugovk]

Thank you! For reference, here's a link to the discussion: https://discuss.python.org/t/42313

[AA-Turner]

This has been open for ~18 months with little movement. Feel free to start a topic on Discourse, and if there is support and a core developer willing to act as a Sponsor, we can revisit this PR.

Thanks!

A