Closed 05nelsonm closed 1 year ago
In terms of fixing the issue in the new, yet unreleased version. Will need to remove the config option acceptLowercase
as that will be the default henceforth. What matters in terms of case sensitivity is the encoded output, which is already configurable.
Currently published code does not allow for decoding of lowercase in either the
Base16
, or all variants of theBase32
implementation.With the refactor to
EncoderDecoder
andFeed
s, a configuration option was added;acceptLowercase
. This is incorrect as per RFC 4648. The decoding process should be case insensitive by default and accept both upper and lower case letters.Regarding the refactor and pointing the old extension functions to use the new
EncoderDecoder
implementations, anyone currently using those will be doing something likeencodedData.uppercase().decodeBase16ToArray()
, so modifying it to also accept lowercase should not be an issue at all in terms of decoding failures.If someone were to downgrade the dependency to an older version (
1.1.5
or lower), while still using the old extension functions, while not callingencodedData.uppercase()
, it would fail to decode. So, super rare edge case.Binary compatibility is still be preserved, but the functionality will now include automatically accepting lowercase letters.
This issue serves as documentation to point to if any issues may arise from consumers that fall into the aforementioned category of downgrading dependency versions and encountering decoding failures.