Should decodeBase32 be strict on requiring padding?

[BlackAsLight]

Jumping from this conversation: #6479 (comment)

The question is should decodeBase32 be strict on requiring padding (aka, having a length that is equally divisible by 8) or if some or all of the padding should be omittable when decoding?

When it comes to this question, I think there are arguments on both sides. For instance, implementations of base32 in other languages throw an error when decoding if the padding is short, so aligning with the behaviour of other implementations is good for interoperability. On the other hand, base64url has optional padding, and our implementation of base64 has never required it.

In my opinion we shouldn't be strict here. While I think it's very unlikely that there is a base32 encoder that would produce a result omitting padding, I don't see a benefit in being strict on padding since it adds no useful information nor would it change the decoded result. When making encoders, it is important to try and make them produce a perfect spec compliant result, and when making decoders you often want them to be lenient, where possible, to make up for the bad encoders that exist.

[WWRS]

Thoughts on an option like checkPadding or ignorePadding? What should the default be?

[BlackAsLight]

Thoughts on an option like checkPadding or ignorePadding? What should the default be?

The actual code in question to be strict on padding would look like if (input.length % 8) throw new RangeError(...). We have other code that slices off padding, if any exists.