Repository navigation
Adopt binacii.a2b_base64's strict mode in base64.b64decode #88856
Description
Activity
idan22moral commented
on Jul 20, 2021 idan22moralmannequinMannequinAuthorThis is a follow-up PR to #68590.
Currently, *base64.b64decode* uses a generic regex to validate *s* (when *validate* is true),
which sometimes results in unexpected behavior and exception messages.Example:
(1) base64.b64decode('ab==', validate=True) # b'i'
(2) base64.b64decode('ab3==', validate=True) # b'i\xbd'
(3) base64.b64decode('ab=3=', validate=True) # raises binascii.Error: Non-base64 digit found
(4) base64.b64decode('ab==3', validate=True) # raises binascii.Error: Non-base64 digit found
(5) base64.b64decode('ab===', validate=True) # raises binascii.Error: Non-base64 digit found
(6) base64.b64decode('=ab==', validate=True) # raises binascii.Error: Non-base64 digit foundThe only strict-base64 valid example here is (1).
(2), (4) and (5) should raise 'Excess data after padding',
(3) should raise 'Discontinuous padding not allowed',
and (6) should raise 'Leading padding not allowed'.To get this behavior, we can use the new (at the time of creating this PR) *binascii.a2b_base64* functionality of strict mode.
I have one (not so big) concern - efficiency.
I'm not that experienced with how fast regex-es are (in Python or in general) compared to the implementation of *binascii.a2b_base64* in C.
So, I've no idea what would be the impact of migrating from regex pre-validation to input parsing.
Let me know if you find it inefficient.-----
Referenced issue (GH-24402): https://bugs.python.org/issue43086
I'm not worried about the regex vs binascii C implementation performance at all.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields: