Tested in Python 2.7 and 3.5 - the base64 module contains a couple of decoding methods, 'standard_b64decode()' and 'b66decode()' which incorrectly decode certain invalid base64 strings. This is outlined in detail here: "https://stackoverflow.com/questions/44347819/python-3-5-base64-decoding-seems-to-be-incorrect". I've checked with a few other developers, and they agree that there is an issue here. I can't see that the issue has been resolved on the bug tracker, so I've worked up an alternative version of "standard_b64decode()" which I'll upload, which ought to solve the issue.

RFC 4648 section 3.5 says:

   The padding step in base 64 and base 32 encoding can, if improperly
   implemented, lead to non-significant alterations of the encoded data.
   For example, if the input is only one octet for a base 64 encoding,
   then all six bits of the first symbol are used, but only the first
   two bits of the next symbol are used.  These pad bits MUST be set to
   zero by conforming encoders, which is described in the descriptions
   on padding below.  If this property do not hold, there is no
   canonical representation of base-encoded data, and multiple base-
   encoded strings can be decoded to the same binary data.  If this
   property (and others discussed in this document) holds, a canonical
   encoding is guaranteed.

   In some environments, the alteration is critical and therefore
   decoders MAY chose to reject an encoding if the pad bits have not
   been set to zero.

If decoders may choose to reject non-canonical encodings, then they may also
choose to accept them. (That's the meaning of "MAY" in RFC 2119.) So I think
Python's behaviour is conforming to the standard.

Not only is it conforming, it is required, since the primary use (originally) of the base64 module was in the email package, where generous interpretation of the input is the standard.

This does not mean that adding a strict mode would be out of line, but that would be an enhancement request, and would require some discussion about the API.

I'm going to close this issue as not a bug.  If you want to submit an enhancement proposal, please do so in a new issue.  You'll probably want to wait for the design discussion to resolve before (re)writing the code :)

Ah, that is enlightening. It hadn't occured to me that you might want to allow for minor mistakes in the encoder - I must've missed that part of the standard. Thanks to both of you for clearing that up :).

Actually, the API discussion may be short: we already have a 'validate' option, whose spirit matches with this, so adding the check for the padding issue to that of the non-alphabet characters check would seem to me to be quite reasonable.