Cannot package signed Java security providers with JMOD

I'm reading this documentation about implementing a provider in the Java cryptography architecture and it states that

> You cannot package signed providers in JMOD files

The article also states:

> Only providers that supply instances of Cipher, KeyAgreement, KeyGenerator, Mac, or SecretKFactory must be signed. If your provider only supplies instances of SecureRandom, MessageDigest, Signature, KeyStore, etc., the provider does not need to be signed.

I am trying to develop this provider using the JDK 11 version, which makes use of .jmod files in replacement of .jar files.

And I was looking at the functions used by the standard security policies
and many of them use Cipher, KeyAgreement, KeyGenerator, Mac, or SecretKeyFactory, but are somehow packaged into .jmod format in the JDK 11 I'm using.

Can anyone explain this further?

The providers in the jmod files packaged in the JDK are not 'signed', because jmods don't support signing. If you inspect the .jmod files with jmod list you will not find any .SF signature files for instance.

> I am trying to develop this provider using the JDK 11 version, which makes use of .jmod files in replacement of .jar files.

Note that .jmod files are not full replacements for jar files. jmod files are link-only artifacts. From the jmod doc:

> The JMOD file format lets you aggregate files other than .class files, metadata, and resources. This format is transportable but not executable, which means that you can use it during compile time or link time but not at run time.

In other words, the jmod files bundled with the JDK are not loaded directly for execution, but are instead meant to be fed to tools such as jlink, which pull them apart and re-package them. This re-packaging would invalidate any signature hashes any ways, so there is less reason why jmod files need to support signing.

If you want to distribute custom providers, you will have to distribute them using jar files, and then sign those jar files. Whether the signing is required when loading the providers depends on the JDK distribution.

Note that the JDK's own providers are not loaded from the bundled jmod files, but from an implementation specific archive whose validity is verified using another mechanism.

Using jmod files is only necessary if you want to package native libraries into an archive, and then distribute that archive. In that case, your users would have to re-package and then re-sign whatever artifact they end up generating based the jmod files.

If you don't need to distribute native libraries, my advice would be to distribute .jar files instead, which can be signed with jarsigner and then used for execution directly. As also stated in the jmod doc:

> Note: For most development tasks, including deploying modules on the module path or publishing them to a Maven repository, continue to package modules in modular JAR files. The jmod tool is intended for modules that have native libraries or other configuration files or for modules that you intend to link, with the jlink tool, to a runtime image.