Repository navigation
Base64 decode with altchars still accepts non-altchars #125346
Description
Activity
It's intentional behavior that was decided upon years ago. found the following as i'm trying to fix, which related to a commit in 2016.
cpython/Lib/test/test_base64.py
Lines 266 to 269 in 4a943c3
But I think the original alphabet should be discarded because an alphabet should always remain singular. if alternative characters are provided, the original ones should be deprecated to avoid confusion and maintain consistency.
Should we document this behaviour if it is not already the case? cc @serhiy-storchaka
- added a commit that references this issue
on Nov 20, 2024 We should look at the discussion when that feature was added, but I think it is not intentional behavior.
I think it is not intentional behavior
17 remaining items
Hello @serhiy-storchaka , will this fix be backported to v3.12 and 3.10?
Unless this is considered a security issue, it won't.
cc @sethmlarson
No, it will not be backported, because there is a risk of breaking existing "working" code, when the code uses
altchars, but the input actually uses the standard alphabet. This is a programming error, but the behavior should not be changed so drastically in a bugfix release, even a warning is too much.User can check that neither "+" nor "/" occurr in the input before decoding. They need to do this in 3.15 to avoid warnings (or they can ignore warnings).
In 3.15+ you can also pass the
ignorecharsargument (evenignorechars=b''works) to enable more strict and explicit behavior. If "+" and "/" in ignorechars, they will be silently ignored, otherwise they will be errors.Should the issue be closed now, then?
Can we expect a backport for 3.10 & 3.12 as well?
No, and the rationale is just a few comments above.
Reacted by Seth Larson- added a commit that references this issue
on Feb 14, 2026 - added a commit that references this issue
on Feb 18, 2026 - added a commit that references this issue
on Apr 16, 2026 - added a commit that references this issue
on Apr 21, 2026
Bug report
Bug description:
If you run
it gives
b'\xff\xef\xfe'This is expected.
If you run
It gives the same output.
This is expected.
However, if you run
It also gives the same output.
This is not expected.
This is concerning because I'm trying to use file safe base64 (urlsafe_b64decode/encode do not have validate arg, which I need). I can work around this by also checking for / and + as well.
CPython versions tested on:
3.9, 3.11
Operating systems tested on:
Linux, Other
Linked PRs