Hello Brad, thanks for the answer. Yes I was talking about the security.provider properties.
It is good to know that it wont work with jlink/jmod. The JCA/JCE documentation Looks quite good to follow. A text similiar to this would complete the picture: Note when changing the list of Providers in Java.security file, that this requires the signed Provider JAR to be present on the class- or module path of the JVM. When the Provider class cannot be loaded, it will be skipped. The extensions mechanism/library was deprecated in Java 8 and removed in Java 9. It can no longer be used to store your custom JCE Provider JAR. Storing JCE providers in custom runtime Images (JMOD files bundled with the JLink tool) is only possible if the provider does not provide Ciphers, Key Agreements or MACs (because there is no codesigning feature for jmod files). Gruss Bernd -- http://bernd.eckenfels.net Von: Brad Wetmore Gesendet: Freitag, 2. März 2018 01:01 An: Bernd; OpenJDK Dev list Betreff: Re: provider registration 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
