The commons-coded BaseXX classes we wrap in our BaseXXSupport classes have changed in recent releases to start throwing IllegalArgumentException on certain invalid input strings.
The IdP test failure triggered by the first of those (in commons-codec 1.13) was addressed by making the sealer code more robust in java-support commit 2c34093672b57c8726ffbacc7a07f58701895595.
The second (in commons-codec 1.14) triggers another IdP test failure. Reviewing our code here, Scott and I are of the opinion that we could improve the BaseXXSupport decoder APIs.
Specifically, throwing a new checked exception analogous to commons-codec's DecoderException would be an improvement over the current situation, as it would force us to catch it and handle it close to each call site; we're clearly not successfully doing this with IllegalArgumentException just now.
This would require catching IllegalArgumentException on each call to the underlying classes, and rethrowing. It's probably also worth looking at our classes' use of an (again, unchecked) ConstraintViolationException when the underlying classes return null. It's not clear that's the right thing to be doing in general.
Doing something like this would obviously require reviewing every call site. In some cases it will be fairly straightforward to address the new exception because there's already a try block around.
I've marked this as a blocker for 8.0.0 and therefore IdP 4.0.0 because unless sorted out one way or another before then we'll be stuck on commons-codec 1.13 and unable to upgrade to 1.14.