Question (or bug) about PKCS11 keystore type

[commi]

I'm submitting a…

• bug report
• feature request
• other

Short description of the issue/suggestion:

I'm setting up singing with an eToken, and sumbled about his line:
https://github.com/fvarrui/JavaPackager/blob/f01e4f0d5e89e70c3a31181cc1a9aeee445a0919/src/main/java/io/github/fvarrui/javapackager/utils/SignerHelper.java#L248

I put 'SunPKCS11' as Keystore, and this is listed in java.security. But this lines checks if the provider/keystore starts with 'SunPKCS11-' (min the dash). There fore it is not accepted.

Is this intentional? I expected from the documentation that SunPKCS11 is the correct value there.

Sidenote: an upgrade to jsign 6 would be helpful, because it supports more option for etokens, to that a specified provider is not even needed anymore.

Steps to reproduce the issue/enhancement:

Attach eToken

pom:

<signing>
    <storetype>PKCS11</storetype>
    <keystore>SunPKCS11</keystore>
    <storepass></storepass>
</signing>

What is the expected behavior?

signing without error

What is the current behavior?

Exception: io.github.fvarrui.javapackager.utils.SignerException: keystore should either refer to the SunPKCS11 configuration file or to the name of the provider configured in jre/lib/security/java.security

Please tell us about your environment:

• JavaPackager version: 1.6
• OS version: Windows 10
• JDK version: 17
• Build tool:
  • Maven
  • Gradle

[fvarrui]

Hi @commi!
I'm not really sure if it's feature or a bug 😄 as far as I remember, I had to patch SignerHelper class in order to fix some bug with JP. But you are right, maybe it would be a good idea to upgrade jsign-core library and try with its own SignerHelper.

[fvarrui]

Hi @commi!
I've just fixed this "bug" and released a new snapshot version: 1.7.6-20240602.222910-9. Now JP directly uses net.jsing.SignerHelper class from the jsing-core library.
Please, try it and give me some feedback.
Thanks!!

[fvarrui]

Oh! I almost forgot ... now, if the problem persists, we should ask the jsign developer

[commi]

Branch issue-413 seems to work. I pass storetype 'ETOKEN' to JavaPackager (keystore and password blank) and Jsing uses it. It needs some DLL still, and aborts, but it identified it correctly. I will report as soon as I find the driver DLL for my eToken:)

[commi]

Update: Signing worked with branch issue-413!

<signing>
    <storetype>ETOKEN</storetype>
    <keystore></keystore>
    <storepass>${windows.codesign.password}</storepass>
</signing>

I had to supply the following JVM options to maven so jsign-core could use Java APIs:

--add-exports jdk.crypto.cryptoki/sun.security.pkcs11=ALL-UNNAMED
--add-exports jdk.crypto.cryptoki/sun.security.pkcs11.wrapper=ALL-UNNAMED
--add-exports java.base/sun.security.action=ALL-UNNAMED
--add-exports java.base/sun.security.rsa=ALL-UNNAMED
--add-opens java.base/java.security=ALL-UNNAMED
--add-opens java.base/sun.security.util=ALL-UNNAMED
-Djava.security.debug=sunpkcs11

The java.security.debug option is also crucial because it triggers the driver to scan all 'ports' for a token. Otherwise, the correct port has to be supplied by a config file. That would be doable (supply a .cfg file instead of ETOKEN), but I don't like to hardcode stuff in the config file if not needed.

[commi]

Related: i found that jsign needs commons-io:2.16 when signing MSI files. with 2.11 i get a NoSuchMethod error. So this dependency has to be updated too in this branch.

[commi]

with implementation 'commons-io:commons-io:2.16.1' MSI gets also signed correctly with jsign 6.0 and ETOKEN. i updated my fork.

[fvarrui]

Hi @commi!
Just upgraded commons-io to 2.16.1 and released 1.7.6-20240623.184401-10.
Please, test it and give me some feedback!
Thanks

[commi]

Yes, this fixes it! To build the MSI correctly i also needed f9276f9 for issue #370

[fvarrui]

Yes, this fixes it! To build the MSI correctly i also needed f9276f9 for issue #370

Ok, I've just added your patch to issue-413 branch and released a new snapshot version: 1.7.6-20240625.080404-12.
Please, try it again and give me feedback. If all works fine, I'll release 1.7.6 to Maven Central with all pending patches.
Thanks!