On Fri, 31 Jul 2026 06:56:40 GMT, Andreas Chmielewski <[email protected]> wrote:
>> I want to propose this enhancement. Please see the CSR. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Andreas Chmielewski has updated the pull request incrementally with one > additional commit since the last revision: > > Review I am preparing an updated version of the test. Before pushing a new revision of this PR, I did some cleanup and unfortunately introduced a bug that was later discovered by @haimaychao. The surprising part is that the test still passed, which showed that my test was not actually verifying the EMS code path as strictly as I thought. I have not yet found a good way to prove that P11TlsExtendedMasterSecretGenerator and the EMS derivation mechanism are actually being used during the handshake. At the moment I am considering two approaches: 1. Add a temporary trace point to P11TlsExtendedMasterSecretGenerator protected SecretKey engineGenerateKey() { if (debug != null) { System.out.println( "P11TlsExtendedMasterSecretGenerator.engineGenerateKey()"); } ... } 2. Using method tracing [JEP-520](https://openjdk.org/jeps/520) JEP 520 seems like it should provide a cleaner way to verify that the method was actually invoked. I have not experimented with this approach yet. My concern is that it is only available in JDK 25 and later. Since I expect to backport the EMS support to earlier JDK releases, I would prefer to avoid introducing a test dependency that is unavailable in those releases. Does anyone have suggestions for a better way to verify that the EMS PKCS#11 derivation path was actually exercised during the handshake? ------------- PR Comment: https://git.openjdk.org/jdk/pull/32081#issuecomment-5314727854
