JTREG test javax/crypto/Cipher/GetMaxAllowed.java fails

[bmathiske]

If you run the JTREG test suite "jdk_security" against bundled ACCP, built from its current source code tip, this one test fails: "javax/crypto/Cipher/GetMaxAllowed.java". This applies to OpenJDK 11, 17, 21, and 24.

  make run-test-prebuilt TEST="jdk_security"

((When running the above, be careful to use the exact same JDK version for TEST_IMAGE_DIR , BOOT_JDK , and JDK_IMAGE_DIR . Otherwise a lot more tests may fail, but not for the right reasons.))

Alternatively, you can reproduce the test failure without bundling with a locally built JDK (which must not already have ACCP bundled):

make run-test TEST=javax/crypto/Cipher/GetMaxAllowed.java "JTREG=VERBOSE=all;TEST_MODE=othervm;OPTIONS=-cpa:<path>/AmazonCorrettoCryptoProvider.jar;VM_OPTIONS=-Djava.security.properties=<path>/amazon-corretto-crypto-provider-jdk15.security"

Note that setting TEST_MODE=othervm is critical. Without it, ACCP will not be loaded as a security provider by the JVM that runs the test.

Why does the test fail? Let's examine this at the example of JDK 17.0.15:

ACCP now registers cipher transformations differently than in version 2.4, resulting in transformation "AES/CBC" without a third component that would be the padding part, making the assumption that "NoPadding" is understood by default. This seems to be OK, except in a check during string tokenization (line 328) in "Cipher.java", which is not actually guarding against anything that follows after any of the two calls of that method.

The first call contains a permission check (line 2627) that only considers the first token, and not the missing third one and not even the present second one.

In the second call, after "AES/CBC" has been passed to Cipher.getTransforms(), this method (line 438) will return a transformation list with null as padding, but when this eventually flows back to ACCP, once applied, the latter will then fill in its default "NoPadding". So, AFAICT this should be OK.

Here are some ways to address the test failure:

1. Tolerate it and remember every time you see it what it means.
2. Skip the test entirely when running JTREG regression testing with ACCP on board.
3. Patch the test in question to not check "AES/CBC" but keep all other checks intact.
4. Change how ACCP registers "AES/CBC", to not produce any transformation entries with only two parts.
5. Patch your JDK in "Cipher.java", allowing transformations with only two tokenization parts (algorithm and mode, omitting padding).

Which one would you prefer and why? Alternatives?