gh-125346: Fix decoding with non-standard Base64 alphabet

[serhiy-storchaka]

The "+" and "/" characters are no longer recognized as the part of the Base64 alphabet in base64.urlsafe_b64decode() and base64.b64decode() the altchars argument that does not contain them.

• Issue: Base64 decode with altchars still accepts non-altchars #125346

[sethmlarson]

@serhiy-storchaka Thanks for this, can you link this PR to either the original issue or a new issue for tracking purposes.

[sethmlarson]

I'm really concerned about the subtle breakages that this change could cause, especially because the default behavior is to throw away characters that aren't in the current alphabet. If the default behavior was to raise an error I would feel better about this change.

Makes me wonder if we should target validate=True with this behavior change (because IMO, the silent dropping of invalid characters is in itself a concerning behavior) and then long-term move to having validate be enabled by default?

[serhiy-storchaka]

This worries me too. We can keep the old behavior but emit a warning if characters + or / occur in Base64 data with the alternative alphabet.

But urlsafe_b64decode() does not have the validate parameter.

[sethmlarson]

But urlsafe_b64decode() does not have the validate parameter.

I wonder if for urlsafe_b64decode() it is okay to error out on bad characters as the function name is more clear that this is for a specific base64 alphabet?

[serhiy-storchaka]

But is not passing altchars to b64decode() also makes it clear that it uses a different alphabet?