Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

nitram2342
Copy link

@nitram2342 nitram2342 commented Dec 22, 2023

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/

@nitram2342 nitram2342 requested a review from a team as a code owner December 22, 2023 15:43
@hugovk hugovk changed the title Added PEP-0738 - Enabling certificate verification by default for stdlib mail modules Draft PEP: Enabling certificate verification by default for stdlib mail modules Dec 22, 2023
@hugovk
Copy link
Member

hugovk commented Dec 22, 2023

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.

@hugovk hugovk marked this pull request as draft December 22, 2023 16:16
@gvanrossum
Copy link
Member

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

Copy link
Member

@gvanrossum gvanrossum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +24 to +26
This PEP proposes to enable verification of X509 certificates for Python's
mail clients by default, subject to opt-out on a per-call basis. This change
would be applied to all maintained Python versions.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

action should require and explicit confirmation. Not verifying a server certificate
and accepting it violates PEP 20's principle "errors should never pass silently."

It can also be expected that Python standard libraries behave in a consitent way.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

consistent

.. [#] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-39441
.. [#] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-38686
.. [#] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-39441
.. [#] https://www.pentagrid.ch/en/blog/python-mail-libraries-certificate-verification/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which IIUC you wrote.

@nitram2342
Copy link
Author

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

hugovk commented Dec 22, 2023

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:

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 hugovk closed this Dec 22, 2023
@hugovk
Copy link
Member

hugovk commented Dec 22, 2023

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!

@hugovk hugovk reopened this Dec 22, 2023
@nitram2342
Copy link
Author

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
Copy link
Member

hugovk commented Jan 2, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants