Question (or bug) about PKCS11 keystore type about javapackager HOT 13 CLOSED

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:)

from javapackager.

Singing works!

from javapackager.

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.

from javapackager.

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!!

from javapackager.

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

from javapackager.

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.

from javapackager.

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.

from javapackager.

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

from javapackager.

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

from javapackager.

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

from javapackager.

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!

from javapackager.

Branch issue-413 merged into devel, ready to be released in 1.7.6

from javapackager.

v1.7.6 released to Maven Central

from javapackager.