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