Handling of inner "=" in Base64 and Base32

Base64 and Base32 implementations may be not conforming to RFC 4648, Section 3.3 in handling the pad character occurred before the end of the encoded data. The RFC allows to ignore the inner "=" if it was explicitly specified. This was the behavior in uutils coreutils 0.2.2. But in uutils coreutils 0.8.0 they are not ignored, but used for padding even if not at the end of the encoded data.

$ echo -n QQ==Qg==Qw== | base64 -di | hd
00000000  41 42 43                                          |ABC|
00000003
$ echo -n QQQgQw== | base64 -di | hd
00000000  41 04 20 43                                       |A. C|
00000004

If they were ignored, you should get t6he same result in both cases.

There is a similar issue with Base32.

$ echo -n IE======II======IM======IQ======IU====== | base32 -d | hd
00000000  41 42 43 44 45                                    |ABCDE|
00000005
$ echo -n IEIIIMIQIU====== | base32 -d | hd
00000000  41 10 84 31 10 45                                 |A..1.E|
00000006

The problem is that different Base64 and Base32 decoders produce different result for the same input. This may pose a security risk. The implementation that literally follows RFC 4648 (for example Python after recent change https://github.com/python/cpython/issues/145264) will treat inner "=" as error or ignore it.

I think that Base64 and Base32 decoders should treat "=" before the end of the encoded data as error by default, and have option to ignore them as non-alphabet characters (it can be combined with -i). It may also have option for the current behavior, but it should not be default.

Start by reproducing the Base64 and Base32 command examples and compare their behavior with RFC 4648 and other decoder implementations. Trace the decoder paths used by the base64 and base32 commands, then determine how inner = should behave by default and with -i. Done means both decoders have consistent, documented handling and regression coverage for the shown inputs.