provider registration

Brad Wetmore bradford.wetmore at oracle.com
Fri Mar 2 00:01:09 UTC 2018



On 2/28/2018 8:36 AM, Bernd wrote:
> Hello,
> 
> there was a thread on BouncyCastle's crypto-dev mailing list how to use 
> a custom JCA provider with Java 9+. Since there is no alternative for 
> the lib/ext extension mechanism this is a bit tricky (if you do want to 
> make the extension in the java.security file permanent).
> 
> There are multiple alternatives (adding to module path, to classpath, 
> using service loader or programmatic registration). Those are described 
> in the actual documentation.

Hopefully it's clear.  There was a lot of moving parts and sharp edges 
as JDK 9 came to a close.  Comments welcome of course.

> However expanding the java.security list

To be clear, when you say "expanding the java.security list", you mean 
adding an entry like:

     security.provider.14=MyProvider

> does not mention explicitely 
> that without the extension mechanism this produces a java home which 
> wont start without modifying the module path.

The JDK should still start, but it wouldn't be able to find MyProvider 
if it's not in either the class or module path.

> Not sure if there is actually a default way to storesuch a "security 
> provider module" 

Not aware of anything for JDK 9+, short of putting your provider into 
the module/classpath directory.  As you note, the extension 
mechanism/directory was removed in the JDK 9 (see JEP 220).

> without using for example jlink to build a new image 
> (or add the -mp argument).

Please note from the Provider documentation:

     You can link a provider in a custom runtime image with the jlink
     command as long as it doesn't have a Cipher, KeyAgreement, or MAC
     implementation.

Providers that don't have Cipher/KeyAgreement/MAC implementation can be 
jlinked.

However, providers providing Cipher/KeyAgreement/MAC implementations 
must be signed using a valid certificate to pass the export tests in 
implementations like Oracle JDK.  We only support signed modular jars 
(module-path) and signed jars (classpath).  There is not a signed JMOD 
feature, and thus jlink can't be used to create an image that will pass 
the export tests.

> Maybe this should be stated explicite?
> 
> "Starting with Java 9 there is no extension mechanism where you could 
> install the provider JAR permanently. Therefore expanding the 
> java.security leaves typically a incomplete java home and should be 
> avoided. Permanently installing an additional module could be done with 
> a custom jlink image."
> 
> (I havent tested if JLink works, BCProv is not yet modularized or 
> service loader enabled. Classpath and programmatic registration works fine).
> 
> Is that correct?

We could add some wording here to talk about the removal of the 
extension mechanism.

Hope that helps.

Brad




More information about the security-dev mailing list