`jdk_security3_0` and `jdk_security1_0` have problems on Windows systems.

[sxa]

Please set the title to indicate the test name and machine name where known.

To make it easy for the infrastructure team to repeat and diagnose, please
answer the following questions:

• test suite/name (e.g, BUILD_LIST, TARGET, CUSTOM_TARGET)? jdk_security3_0 and jdk_security1_0
• a link into recent Test_ job on https://ci.adoptium.net which showed the failure: https://ci.adoptium.net/job/Test_openjdk21_hs_sanity.openjdk_x86-64_windows/211/tapTestReport/ or https://ci.adoptium.net/job/Grinder/12170/testReport/
• Hyperlink to re-run in Grinder: jdk_security3_0 on test-4
• Is there an existing issue elsewhere covering this?
• Which machine(s) does it work on? test-azure-win2022-x64-1 doesn't seem to have the math failures
• Which machine(s) does it fail on? test-azure-win20220-x64-4

Any other details:
This is a full dump of links etc. so may have more information not directly relevant to this, especially since some of it covers the wsl issue covered in another issue in this repostitory:
:
Noticed during some experimentation I've been doing on Windows. I initially thought that this was restricted to the new -4 machine (which is currently offline) but it has also been seen on -1:

Original failures on -1 in jdk_security1 and jdk_security4 (Some covered by #3853)

 - sun/security/krb5/runNameEquals.sh.runNameEqualsjava/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh.ClassLoaderDeadlock 94 ms 1

• java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh.ClassLoaderDeadlock 0.17 sec 1
• java/security/Security/ClassLoaderDeadlock/Deadlock.sh.Deadlock 0.17 sec 1
• java/security/Security/ClassLoaderDeadlock/Deadlock.sh.Deadlock 0.13 sec 1
• java/security/cert/CertificateFactory/slowstream.sh.slowstream 0.44 sec 1
• java/security/cert/CertificateFactory/slowstream.sh.slowstream 0.11 sec 1
• sun/security/krb5/runNameEquals.sh.runNameEquals 0.22 sec 1
• sun/security/krb5/runNameEquals.sh.runNameEquals

jdk_security3 and jdk_imageio failed in two tests on -1 (checked after seeing jdk_security3 failures on -4) :

- sun/security/ssl/X509TrustManagerImpl/distrust/Symantec.java.Symantecjavax/imageio/plugins/jpeg/JPEGsNotAcceleratedTest.java.JPEGsNotAcceleratedTest 2.8 sec 1

• sun/security/ssl/X509TrustManagerImpl/distrust/Symantec.java.Symantec 0.92 sec 39
• sun/security/ssl/X509TrustManagerImpl/distrust/Symantec.java.Symantec

For the above, the first failure is sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target and the second is java.awt.HeadlessException: The application does not have desktop access, but this program performed an operation which requires it. which should have been fixed by running the agent via a terminal on the logged in machine instead of as a service but doesn't seem to have been fully resolved for some reason...

The full list of jdk_security3 failures on -4 were as follows (The math ones seem to be Agent error: java.lang.Exception: Agent 38 timed out with a timeout of 960 seconds; check console log for any additional details:

- sun/security/ssl/X509TrustManagerImpl/distrust/Symantec.java.Symantecjavax/net/ssl/SSLSocket/Tls13PacketSize.java.Tls13PacketSize 2.7 sec 1

• sun/security/util/math/TestIntegerModuloP.java#Curve448OrderField.TestIntegerModuloP_Curve448OrderField 17 min 1
• sun/security/util/math/TestIntegerModuloP.java#IntegerPolynomial448.TestIntegerModuloP_IntegerPolynomial448 17 min 1
• sun/security/util/math/TestIntegerModuloP.java#IntegerPolynomialP384.TestIntegerModuloP_IntegerPolynomialP384 17 min 1
• sun/security/util/math/TestIntegerModuloP.java#IntegerPolynomialP521.TestIntegerModuloP_IntegerPolynomialP521 18 min 1
• sun/security/util/math/TestIntegerModuloP.java#P384OrderField.TestIntegerModuloP_P384OrderField 18 min 1
• sun/security/ssl/X509TrustManagerImpl/distrust/Symantec.java.Symantec

[sxa]

Noting that from https://ci.adoptium.net/job/Grinder/12174/testReport/ (jdk_security3) the distrust test fails on -3 as well, so this might be a potential "real" problem that is showing up and not something specific to the machines.

[Haroon-Khel]

According to the openj9 team, the failing sun/security/ssl/X509TrustManagerImpl/distrust/Symantec.java test was renamed from sun/security/ssl/X509TrustManagerImpl/Symantec/Distrust.java which we have excluded for many jdk versions and platforms
https://github.com/search?q=repo%3Aadoptium%2Faqa-tests+sun%2Fsecurity%2Fssl%2FX509TrustManagerImpl%2FSymantec%2Fdistrust&type=code

[sxa]

It doesn't look like it's just a straight rename - the new one is about 30% smaller (changes occurred between 21.0.6+0 and 21.0.6+1:

Symantec-Distrust.java.gz
distrust-Symantec.java.gz

Having said that - since the OpenJ9 team concluded that this was a result of using the Mozilla cacerts bundle, which adoptium also uses, I suspect this is a valid candidate for exclusion for us too.

[Haroon-Khel]

I suspect this is a valid candidate for exclusion for us too.

I agree

[Haroon-Khel]

test-azure-win2022-x64-4 is back in the test pool for the dryrun (Jan 2025 release)

[sxa]

Exclusion of Distrust/Symantec is being done under adoptium/aqa-tests#5862