-
Notifications
You must be signed in to change notification settings - Fork 722
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
jdk21 com/sun/crypto/provider/Cipher/ChaCha20/ChaCha20NoReuse Must use either a different key or iv #17632
jdk21 com/sun/crypto/provider/Cipher/ChaCha20/ChaCha20NoReuse Must use either a different key or iv #17632
Comments
@jasonkatonica fyi |
Issues eclipse-openj9/openj9#17630 eclipse-openj9/openj9#17632 eclipse-openj9/openj9#17633 eclipse-openj9/openj9#17634 Signed-off-by: Peter Shipton <Peter_Shipton@ca.ibm.com>
Issues eclipse-openj9/openj9#17630 eclipse-openj9/openj9#17632 eclipse-openj9/openj9#17633 eclipse-openj9/openj9#17634 Signed-off-by: Peter Shipton <Peter_Shipton@ca.ibm.com>
Issue eclipse-openj9/openj9#17632 Signed-off-by: Peter Shipton <Peter_Shipton@ca.ibm.com>
Still fails on the latest jdk21 OpenJ9. Passes on OpenJ9 with |
Tentatively setting as a blocker, unless we can explain why this failure doesn't matter. |
The tests that are failing are part of a specific scenario. The scenario involves the reuse of the
According to the specification and original implementation in OpenJDK21, all of those are allowed. To accommodate this expected behaviour, I created a fix: https://github.com/KostasTsiounis/openj9-openjdk-jdk21/tree/chacha20_reuse The failing test now succeeds: https://hyc-runtimes-jenkins.swg-devops.com/view/Test_grinder/job/Grinder/34861/ Only problem is that this particular behaviour is only expected in later versions of Java. More specifically, the equivalent test in Java 17 expects to get an Exception in all of the use cases:
The equivalent test in Java 11 doesn't even check for the first use case and also expects an Exception for each of the other two:
|
Hi Kostas, Reading above it seems like we could do one of the following:
Id vote for option 1 above to maintain behavior as close to Sun providers as possible there is a good reason otherwise. @pshipton Do you have an opinion here one way or another? |
@pshipton : fyi, your opinion was requested above. Kostas (@KostasTsiounis ), could you post a current status update on this blocking JDK 21 issue please? Thanks. |
Option 1 works for me. Matching the OpenJDK behavior is what users expect. |
A PR has already been put in for OpenJDKnext: ibmruntimes/openj9-openjdk-jdk#661 Once this is merged, I will back port to 21, and this issue will be resolved. |
Reopening since the test is still excluded. The below lines need to be removed in order to re-enable the test: |
JDK-next (JDK22) fix: ibmruntimes/openj9-openjdk-jdk#661 JDK21 fix: ibmruntimes/openj9-openjdk-jdk21#50 Closes: eclipse-openj9/openj9#17632 Signed-off-by: Babneet Singh <sbabneet@ca.ibm.com>
JDK-next (JDK22) fix: ibmruntimes/openj9-openjdk-jdk#661 JDK21 fix: ibmruntimes/openj9-openjdk-jdk21#50 Closes: eclipse-openj9/openj9#17632 Signed-off-by: Babneet Singh <sbabneet@ca.ibm.com>
Opened adoptium/aqa-tests#4817 to re-enable the |
JDK-next (JDK22) fix: ibmruntimes/openj9-openjdk-jdk#661 JDK21 fix: ibmruntimes/openj9-openjdk-jdk21#50 Closes: eclipse-openj9/openj9#17632 Signed-off-by: Babneet Singh <sbabneet@ca.ibm.com>
JDK-next (JDK22) fix: ibmruntimes/openj9-openjdk-jdk#661 JDK21 fix: ibmruntimes/openj9-openjdk-jdk21#50 Closes: eclipse-openj9/openj9#17632 Signed-off-by: Babneet Singh <sbabneet@ca.ibm.com>
JDK-next (JDK22) fix: ibmruntimes/openj9-openjdk-jdk#661 JDK21 fix: ibmruntimes/openj9-openjdk-jdk21#50 Closes: eclipse-openj9/openj9#17632 Signed-off-by: Babneet Singh <sbabneet@ca.ibm.com>
JDK-next (JDK22) fix: ibmruntimes/openj9-openjdk-jdk#661 JDK21 fix: ibmruntimes/openj9-openjdk-jdk21#50 Closes: eclipse-openj9/openj9#17632 Signed-off-by: Babneet Singh <sbabneet@ca.ibm.com>
https://openj9-jenkins.osuosl.org/job/Grinder_testList_2/46/ - amac jdk21
com/sun/crypto/provider/Cipher/ChaCha20/ChaCha20NoReuse.java
The text was updated successfully, but these errors were encountered: