GeezerVison

@gpshead @serhiy-storchaka @bitdancer @warsaw: Would you mind to review this security fix?

See issue gh-102988 for the context.

This PR is a copy of PR #108250 but I added strict=True parameter, so it's possible to get the old behavior. I added tests on both modes, strict=True and strict=False.

This PR is a copy of PR #108250 but I added strict=True parameter

My colleague Lumir Balhar @frenzymadness ran an impact check of PR #108250 on Fedora: in short, there is no impact, the test suite of all Python packages (in Fedora) pass with the change. While there were some build errors, they were unrelated to the email issue. For details, see https://copr.fedorainfracloud.org/coprs/lbalhar/email-CVE/builds/ COPR which as more than 4300 builds.

Now with an additional strict parameter, if there is any impacted project, at least there is a way to "opt out".

@tdwyer: Would you mind to review my change, to see if I preserved your work correctly? (code and tests)

I think that we should backport the change to all branches accepting security fixes. Problem: the change refer to version numbers, which as .. versionchanged:: 3.13. I suppose that if the change is backported, we should compute the next version of each branch, so backport manually.

@ambv @SethMichaelLarson: Would you mind to review this PR?

Why is this a separate PR from #108250?

Why is this a separate PR from #108250?

I'm not the author of the other PR. I copied the other PR and added strict parameter.

I'm not the author of this PR and I was able to make commits to it.

I'm not the author of this PR and I was able to make commits to it.

I don't feel comfortable to make significant change of a PR without asking the author. I prefer to create a separated PR and ask for review.

Is this behavior a bug or a feature? I don't know how ; is supposed to behave.

$ python
Python 3.11.6 (main, Oct  3 2023, 00:00:00) [GCC 13.2.1 20230728 (Red Hat 13.2.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from email.utils import getaddresses
>>> from pprint import pprint
>>> pprint(getaddresses('<[email protected]>; <[email protected]>'))
[('', ''),
 ('', 'b'),
 ('', 'o'),
 ('', 'b'),
 ('', ''),
 ('', 'e'),
 ('', 'x'),
 ('', 'a'),
 ('', 'm'),
 ('', 'p'),
 ('', 'l'),
 ('', 'e'),
 ('', '.'),
 ('', 'o'),
 ('', 'r'),
 ('', 'g'),
 ('', ''),
 ('', ''),
 ('', ''),
 ('', ''),
 ('', 'a'),
 ('', 'l'),
 ('', 'i'),
 ('', 'c'),
 ('', 'e'),
 ('', ''),
 ('', 'e'),
 ('', 'x'),
 ('', 'a'),
 ('', 'm'),
 ('', 'p'),
 ('', 'l'),
 ('', 'e'),
 ('', '.'),
 ('', 'o'),
 ('', 'r'),
 ('', 'g'),
 ('', '')]

Is this behavior a bug or a feature? I don't know how ; is supposed to behave.

Oh. getaddresses() expects a sequence, not a string :-)

Except of parsedate_tz() function, Lib/email/_parseaddr.py file didn't evolve much it was added in 2002 by commit 030ddf7. The file was created from Lib/rfc822.py which was added in 1992 (commit 01ca336).

The latest major change was done in... 1997 with commit be7c45e

New address parser by Ben Escoto replaces Sjoerd Mullender's parseaddr()

The latest minor change was done in 2019 to fix CVE-2019-16056: commit 8cb65d1 of issue #78336.

What if the input is '"Jane Doe" [email protected], "John Doe" [email protected]'?

Oh, realname_comma_re replaces "Jane Doe" <[email protected]>, "John Doe" <[email protected]> with "Jane Doe <[email protected]> which is invalid...

Email addresses have multiple standards:

• 1982: https://datatracker.ietf.org/doc/html/rfc822
• 2001: https://datatracker.ietf.org/doc/html/rfc2822 (replace 822)
• 2008: https://datatracker.ietf.org/doc/html/rfc5322 (replace 2822)
• 2012: https://datatracker.ietf.org/doc/html/rfc6532

Is it time to backport the change to Python 3.8-3.12? So far, nobody reported any regression in Python 3.13.

• Patch for Python 3.8
• Patch for Python 3.9
• Patch for Python 3.6

Of course, I am eager for reviews and comments.

So far, the only issue I have heard about was confusion about str/unicode objects in Python 2.7 (https://bugzilla.suse.com/1222537), which I think may be your problem as well.

Also, I left some comments on that commit.

Is it time to backport the change to Python 3.8-3.12

According to this comment, not yet: #102988 (comment)

Thanks @vstinner for the PR 🌮🎉.. I'm working now to backport this PR to: 3.10.
🐍🍒⛏🤖

Thanks @vstinner for the PR 🌮🎉.. I'm working now to backport this PR to: 3.12.
🐍🍒⛏🤖

Thanks @vstinner for the PR 🌮🎉.. I'm working now to backport this PR to: 3.11.
🐍🍒⛏🤖

Thanks @vstinner for the PR 🌮🎉.. I'm working now to backport this PR to: 3.9.
🐍🍒⛏🤖

Thanks @vstinner for the PR 🌮🎉.. I'm working now to backport this PR to: 3.8.
🐍🍒⛏🤖

Sorry, @vstinner, I could not cleanly backport this to 3.12 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker 4a153a1d3b18803a684cd1bcc2cdf3ede3dbae19 3.12

Sorry, @vstinner, I could not cleanly backport this to 3.10 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker 4a153a1d3b18803a684cd1bcc2cdf3ede3dbae19 3.10

Sorry, @vstinner, I could not cleanly backport this to 3.11 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker 4a153a1d3b18803a684cd1bcc2cdf3ede3dbae19 3.11

Sorry, @vstinner, I could not cleanly backport this to 3.9 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker 4a153a1d3b18803a684cd1bcc2cdf3ede3dbae19 3.9

Sorry, @vstinner, I could not cleanly backport this to 3.8 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker 4a153a1d3b18803a684cd1bcc2cdf3ede3dbae19 3.8

GH-123766 is a backport of this pull request to the 3.12 branch.

GH-123767 is a backport of this pull request to the 3.11 branch.

GH-123768 is a backport of this pull request to the 3.10 branch.

GH-123769 is a backport of this pull request to the 3.9 branch.

GH-123770 is a backport of this pull request to the 3.8 branch.

supports_strict_parsing is not mentioned in the email.utils docs.

please open a new issue if there's a lingering docs problem.