RFR: 8341927: Replace hardcoded security providers with new test.provider.name system property [v7]

Lutz Schmidt lucy at openjdk.org
Wed Nov 20 15:53:26 UTC 2024


On Wed, 30 Oct 2024 18:12:30 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR, I removed hard-coded security providers and replaced them with a system property, test.provider.name. If the property is not specified, the provider originally used in the test is used:
>> 
>> Cipher c = Cipher.getInstance("AES/GCM/NoPadding", System.getProperty("test.provider.name", "SunJCE"));
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   included additional services in testing.md

While reviewing the backport PR to jdk17, I stumbled across a potential functional incompleteness. There are a few tests which use more than one security provider. This works well when only the default providers are used. One example of such a test is `test/jdk/java/security/Signature/TestCloneable.java`. There are three providers by default:

        String dsaProviderName = System.getProperty("test.provider.name", "SUN");
        String ecProviderName  = System.getProperty("test.provider.name", "SunEC");
        String rsaProviderName = System.getProperty("test.provider.name", "SunRsaSign");

If the `test.provider.name` property is specified for a test run, all three name strings are set to the same provider name. The test will only succeed if the specified provider can handle the combined set of algorithms of all three default providers. 

These are the tests I found to be affected. The list is **not** believed to be complete.

test/jdk/java/security/Signature/TestCloneable.java
test/jdk/java/security/SignedObject/Chain.java
test/jdk/java/security/KexGenerator/TestGetInstance.java
test/jdk/java/security/Mac/TestGetInstance.java
test/jdk/java/security/auth/login/Configuration/GetInstance.java
test/jdk/java/security/X509/X509CertImpl/Verify.java

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21551#issuecomment-2488947679


More information about the serviceability-dev mailing list