In my opinion, this is not a bug, but rather expected behavior[1]:

| Returns FALSE if input contains character from outside the
| base64 alphabet.

[1] <http://php.net/manual/en/function.base64-decode.php>

Whitespace (at least line breaks) is allowed in Base64.

And even with your logic, at least the whitespace should be handled equally in all cases. In other words, base64_decode("VV ==") and base64_decode("VV= =") should yield the same result.

> Whitespace (at least line breaks) is allowed in Base64.

Line breaks are allowed, but as far as I know, not in arbitrary
places, and no other whitespace characters are allowed.

> In other words, base64_decode("VV ==") and base64_decode("VV=
> =") should yield the same result.

ACK. Obviously that is not the case now: <https://3v4l.org/4ZV7T>.

> Line breaks are allowed, but as far as I know, not in arbitrary
> places, and no other whitespace characters are allowed.

RFC 4648 (Base* encoding) doesn't cover these issues;
it only says that any characters outside the Base64 alphabet
MUST be rejected, UNLESS another specification says otherwise.
This means that we can really do as we please, since the same
function may be used in different contexts.

RFC 2045 (MIME) says that "any characters outside of the
base64 alphabet are to be ignored in base64-encoded data".
This is what the "non-strict" mode does, so this is fine,
even though it's really weird to accept stuff like !"#%&.

The current C code specifically tries to ignore white-space
even in "strict" mode. I think that the PHP documentation is
"wrong" in this regard and that this bug should be fixed.
It's obvious that the current "strict" mode is actually
intended as a sensible mode for any sensible input, with
the benefit that anything weird like leaked errors inside
the Base64 string will probably produce FALSE.
Many tools add line breaks in Base64 data, so it's nice to
accept that. (`echo -n U | base64 -w3` == "VQ=\n=\n") == true.
Also, changing the current behavior to be more strict would
cause a BC break, which is probably not acceptable.

PHP doesn't really implement a strict mode for Base64.

So maybe some day we should implement all three modes:
- MIME mode, the current default, ignores any weirdness.
- sensible mode, the current "strict", with Base64 + white space
- really strict mode, which only accepts 0-9A-Za-z+/=