Skip to content

gh-56698: Fix base64-url parsing errors in email headers #136830

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

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

matthieucan
Copy link
Contributor

@matthieucan matthieucan commented Jul 19, 2025

Accept urlsafe base64 in email headers, as those are sometimes created by email clients.

Copy link
Member

@encukou encukou left a comment

Choose a reason for hiding this comment

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

Thank you! This looks good to me, but, I'm not the expert here.
@bitdancer, could you take a look whenever you have a bit of time?

@picnixz
Copy link
Member

picnixz commented Jul 20, 2025

What does the RFC says here? should we be strict or not? should it be added as a defect if it fails?

@matthieucan
Copy link
Contributor Author

What does the RFC says here? should we be strict or not? should it be added as a defect if it fails?

The RFC states that + and / must be used (https://www.rfc-editor.org/rfc/rfc2047.html#section-4.1 points to the alphabet in https://www.rfc-editor.org/rfc/rfc2045#section-6.8).

I believe we should not be strict - as reported in the original bug issue, some mailers use a different alphabet. A defect is indeed added when that happens.

Copy link
Member

@picnixz picnixz left a comment

Choose a reason for hiding this comment

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

I believe we should not be strict - as reported in the original bug issue, some mailers use a different alphabet

To be clear: we would still reject the bad alphabet because the first base64.b64decode() with validate=True would fail, and then we try to indicate that there is an error, but at this point, we would still fail because we still can't decode right? (and your PR fixes this path)

b'QW5tZWxkdW5nIE5ldHphbnNjaGx1c3MgU_xkcmluZzNwLmpwZw==',
b'Anmeldung Netzanschluss S\xfcdring3p.jpg',
[errors.InvalidBase64CharactersDefect])
# Mix of 2 base64 alphabets
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
# Mix of 2 base64 alphabets
# mix of different base64 alphabets

I was a bit confused with "2 base64" so let's be a bit more verbose in the comment (in this case the 2 and the 64 from base64 look odd but maybe I'm tired)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agreed!

@matthieucan
Copy link
Contributor Author

I believe we should not be strict - as reported in the original bug issue, some mailers use a different alphabet

To be clear: we would still reject the bad alphabet because the first base64.b64decode() with validate=True would fail, and then we try to indicate that there is an error, but at this point, we would still fail because we still can't decode right? (and your PR fixes this path)

Yes, I believe that description is correct

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