Bug ID: JDK-7191662 JCE providers should be located via ServiceLoader

JDK-7191662 : JCE providers should be located via ServiceLoader

Type: Enhancement
Component: security-libs
Sub-Component: java.security
Affected Version: 9

Priority: P2
Status: Closed
Resolution: Fixed
OS: generic
CPU: generic

Submitted: 2012-08-15
Updated: 2019-09-12
Resolved: 2015-06-26

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 9
9 b71Fixed

Related Reports

Relates :	JDK-8157881 - security.provider property description needs to be updated for modules
Relates :	JDK-8075902 - Update security provider docs for changes under 8038084 and 7191662
Relates :	JDK-8130648 - JCK test api/java_security/AuthProvider/ProviderTests_login starts failing after JDK-7191662
Relates :	JDK-7191104 - (sl) ServiceLoader shortcomings when moving from JCE provider mechanism
Relates :	JDK-8230923 - SunJSSE is not properly initialized in FIPS mode from a configuration file
Relates :	JDK-8130360 - Add tests to verify 3rd party security providers if they are in modular JARs

Sub Tasks

JDK-8173226 :

Release Note: Security providers are now loaded through ServiceLoader and registered by name - Closed

Description

As part of the work to load JCE providers using ServiceLoader in Project Jigsaw, some changes and restructuring were made to the provider loading code to enable it to better support modular providers. The changes that are not specifically dependent on modules/jigsaw should be merged into JDK 8 to ease potential future merges. Here is the changeset:

Changeset: bf6c3ddca9f9
Author:    mullan
Date:      2012-08-14 17:09 -0400
URL:       http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/bf6c3ddca9f9

Load JCE Providers in module mode using ServiceLoader
Reviewed-by: alanb, mchung, psandoz

! make/modules/jdk.depconfig
! make/modules/modules.group
! src/share/classes/com/sun/crypto/provider/AESKeyGenerator.java
! src/share/classes/com/sun/crypto/provider/BlowfishKeyGenerator.java
! src/share/classes/com/sun/crypto/provider/CipherCore.java
! src/share/classes/com/sun/crypto/provider/DESKeyGenerator.java
! src/share/classes/com/sun/crypto/provider/DESedeKeyGenerator.java
! src/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java
! src/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java
! src/share/classes/com/sun/crypto/provider/DHParameterGenerator.java
! src/share/classes/com/sun/crypto/provider/HmacMD5KeyGenerator.java
! src/share/classes/com/sun/crypto/provider/HmacPKCS12PBESHA1.java
! src/share/classes/com/sun/crypto/provider/HmacSHA1KeyGenerator.java
! src/share/classes/com/sun/crypto/provider/ISO10126Padding.java
! src/share/classes/com/sun/crypto/provider/KeyGeneratorCore.java
! src/share/classes/com/sun/crypto/provider/KeyProtector.java
! src/share/classes/com/sun/crypto/provider/PBECipherCore.java
! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java
! src/share/classes/com/sun/crypto/provider/SunJCE.java
! src/share/classes/org/openjdk/jigsaw/cli/Packager.java
! src/share/classes/sun/security/jca/ProviderConfig.java
! src/share/classes/sun/security/jca/ProviderList.java
! src/share/classes/sun/security/jca/Providers.java
! src/share/classes/sun/security/pkcs11/SunPKCS11.java
+ test/org/openjdk/jigsaw/services/jce.sh

Comments

Re-adjusted the due date to end of June because of the dependency on https://bugs.openjdk.java.net/browse/JDK-8066492
09-06-2015
SaslClient/ServerFactory class does not have public getInstance APIs which takes a provider object or name. So, having a separate provider for holding the GSSAPI SaslClient/ServerFactory impl classes will not impact existing applications. The only external exposure is the additional provider entry added to java.security file.
18-03-2015
Well, I tried moving SunJGSS provider out of "java.security.jgss" module but run into dependency issues from the public API org.ietf.jgss classes. The SaslClient/ServerFactory impl classes depends on the extended JDK classes in the "jdk.security.jgss" module. So, it's difficult to merge them into the current SunJGSS provider which is in "java.security.jgss" module. So, maybe we will go with a new provider for the SaslClient/ServerFactory impl classes for now until we can find a way to separate these classes out from these 2 modules, move them into one or the other.
07-03-2015
Currently, SunJGSS provider is in "java.security.jgss" module instead of the "jdk.security.jgss" module which GSSAPI SaslClient/ServerFactory impl classes are in. So, if we want to merge the GSSAPI SaslClient/ServerFactory impl classes into the SunJGSS provider, then we would have to move SunJGSS provider from "java.security.jgss" module to the "jdk.security.jgss" module. If conceptually this is ok, then I will give it a try. Actually, it seems to me that it makes sense for the providers to be in their individual module (instead of bundled in a module which contains public standard API?) such as SunEC, SunPKCS11 providers are in their own modules. Are we trying to limit the numbers of modules?
06-03-2015
We had a lot of problems with circular dependencies JNDI depends SASL and JGSS depends SASL and JNDI. To eliminate the circular dependencies, it results in the current module graph: module java.naming requires java.security.sasl module java.security.jgss (Kerberos) requires module java.naming module jdk.security.jgss requires module java.security.jgss and java.security.sasl. jdk.security.jgss is JDK-specific module that exports com.sun.security.jgss. As Alan noted earlier, if we could eliminate JGSS to JNDI, it could open up other options to organize this. jdk.security.jgss requires java.security.jgss. I think it seems reasonable to move GSSAPI SaslClient/ServerFactory mechanism from SunSASL to SunJGSS. One will get SunJGSS if java.security.jgss is present. jdk.security.jgss can register GSSAPI SaslClient/ServerFactory mechanism to SunJGSS provider - I assume via Provider.Service?
06-03-2015
Well, it is doable, but again comes with the cost of backward compatibility, i.e. callers who specify SunSASL provider for GSSAPI SaslClient/ServerFactory will encounter error. Instead of yet another new provider which only supports 1 single algorithm, can we explore the possibility of moving this to existing provider, e.g "SunJGSS" provider. The "SunJGSS" provider is in "java.security.jgss" module though but the GSSAPI SaslClient/ServerFactory depends on classes in the "jdk.security.jgss" module. Anyone know the distinction between the "java.security.jgss" and "jdk.security.jgss" module and whether it's ok to move "SunJGSS" provider from former to latter?
05-03-2015
I think a security provider (java.security.sasl in this case) should only register its own services/mechanisms rather than something from another module (jdk.security.jgss module). Should jdk.security.jgss be its own provider?
04-03-2015
This may impact existing 3rd party providers as ServiceLoader mechanism requires META-INF/services/ entry in order to be able to found the declared service.
28-01-2015
It would be good to re-visit this early in JDK 9. In our early modules builds then we can't currently use crypto when we enable the Core Reflection changes, here's an example: java.lang.IllegalAccessException: Class sun.security.jca.ProviderConfig$2 (module java.base) can not access a member of class sun.security.ec.SunEC (module jdk.crypto.ec) with modifiers "public" at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:142) at java.lang.Class.newInstance(Class.java:429) at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:221) at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:206) at java.security.AccessController.doPrivileged(Native Method) at sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:206) at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:187) at sun.security.jca.ProviderList.loadAll(ProviderList.java:282) at sun.security.jca.ProviderList.removeInvalid(ProviderList.java:299) at sun.security.jca.Providers.getFullProviderList(Providers.java:173) at java.security.Security.insertProviderAt(Security.java:360) at java.security.Security.addProvider(Security.java:403) at ProviderTest.main(ProviderTest.java:45) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:484) at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) at java.lang.Thread.run(Thread.java:744)
25-03-2014