Skip to content

Conversation

LamentXU123
Copy link
Contributor

@LamentXU123 LamentXU123 commented Sep 24, 2025

Make definition of Incorrect padding clearer by adding descriptions about extra padding and discontinuous padding.


📚 Documentation preview 📚: https://cpython-previews--139301.org.readthedocs.build/

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.

Actually, there is nothing to change. The details about strict padding is already mentioned below:

For more information about the strict base64 check, see :func:binascii.a2b_base64

We should not expand the docs more as we would otherwise repeat ourselves.

@LamentXU123
Copy link
Contributor Author

LamentXU123 commented Sep 24, 2025

The details about strict padding is already mentioned below:

Yeah I saw this before. The link below is about strict mode. But I think the paragraph of incorrect padding is talking about the case of validate=False? The thing is we still raise errors if we get "incorrect padding" not in strict mode. And I think we could have a doc indicating when errors would be raised not in strict mode here, since the feature of ignoring extra and discontinuous paddings but raise errors when missing paddings is undocumented.

Actually, the definition of an invalid padding is given in binascii.a2b_base64. we should just link this.

That is the definition of strict_mode, which is not the default mode of b64decode. I agree that the doc is very clear about when we raise errors in strict mode.

@picnixz
Copy link
Member

picnixz commented Sep 24, 2025

I think the distinction will be too verbose in the end. The documented part for validate is because it's a pre-processing step. By "incorrectly padded", we only mean "if len(s) is invalid" without taking into account extra padding for validate=False. Being overly verbose is not good. What's important is it's possible that decode() raises an error even in non-validate mode and that it will raise even more errors if validate is true.

In general, users that want to validate the input should just worry about validate=True and that in validate=False, we may raise an error in case of an invalid padding (but we minimally check it).

That is the definition of strict_mode, which is not the default mode of b64decode

strict_mode is also false in a2b_base64(). It's just another parameter name.

@LamentXU123
Copy link
Contributor Author

strict_mode is also false in a2b_base64(). It's just another parameter name.

They are actually equal when users call b64decode. I mean they are equal so the default mode is not strict lol:

b0ec5522fdff5dc50abcc6fdfcdbdcbf

In general, users that want to validate the input should just worry about validate=True and that in validate=False, we may raise an error in case of an invalid padding (but we minimally check it).

Sure. Users who want to validate this strictly should turn on the validate arg. The doc would be too verbose.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting review docs Documentation in the Doc dir skip news
Projects
Status: Todo
Development

Successfully merging this pull request may close these issues.

2 participants