Hello Adarsh: Please see my reply in the ticket.
Gary On Fri, Oct 23, 2026 at 6:17 AM Adarsh Kumaromrey <[email protected]> wrote: > > Hi, > > I reproduced CODEC-348 on current master (JDK 21). With > new Base64(76, new byte[]{'\n'}, false, CodecPolicy.STRICT), decoding the > encoder's own output works, but the same bytes with the trailing '\n' > trimmed, as a single line, or with CRLF separators throw > IllegalArgumentException (via BaseNCodec.validateCanonicalEnd and > validateCanonicalByte). > > LENIENT decodes all three, but it also accepts non-canonical trailing bits > (for example "AB=="), which STRICT rejects. So switching to LENIENT gives up > a guarantee that callers chose STRICT for. > > I wrote a JUnit test with four cases (20 and 256 bytes), three of which > currently fail: > https://github.com/adarshomrey/commons-codec/blob/CODEC-348-strict-line-length/src/test/java/org/apache/commons/codec/binary/Base64StrictLineLengthTest.java > > Before I write a fix, which direction would you prefer? > (1) an opt-in builder option for line-structure validation, keeping the > 1.22.1 STRICT semantics as the default, > (2) relaxing the final-separator requirement, or > (3) keeping the 1.23.0 behavior and documenting it. > > I'm happy to prepare a PR for whichever you choose. > > Thanks, > Adarsh > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
