ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Edwards <>
Subject <verifyjar> apparently not passing keystore password along
Date Fri, 16 Mar 2018 20:25:00 GMT
We're using 1.10.1 to build and sign an executable JAR file.  All of
that has been working fine for a while now.

Out of paranoia, we've been asked to run the <verifyjar> task to our
post-build "quick check that this isn't gratuitously broken" target.  (Other
targets do more extensive testing including, you know, running the thing
in a paranoid launcher.)  We mentioned the concerns that had also been
raised way
back when bug #27596 was opened, in that it's not meant to check complete
chain of validity, merely that the JAR isn't going to crash and burn when
loaded.  We figured fine, go ahead and run <verifyjar>, as long as we
continue to do the rest of the testing, more can't hurt.

The task is always concluding with
   [verifyjar] jar verified, with signer errors.
   [verifyjar] Error:
   [verifyjar] This jar contains signed entries that are not signed by
alias in this keystore.
   the\path\to\the\build.xml:444: jarsigner returned: 32
        ...dozen more lines of

which doesn't make sense given the rest of the setup.  Namely:

1)  The JAR is being signed with the same arguments to its task:

    <signjar jar="the_jar_file.jar"
      keystore="the_keystore.p12" storetype="pkcs12"
      sigfile="..." sigalg="..." digestalg="..." tsaurl="..."/>

works fine.

2)  We can run the_jar_file.jar and it's properly verified and loaded.
And we can run

    jarsigner -verify -storetype pkcs12 -keystore the_keystore.p12   \
      -storepass yup_its_in_the_build_file -strict -certs -verbose   \
      the_jar_file.jar signing_alias

and everything is fine, along with seeing 'smk' flags printed for each
file in the JAR

3)  But running

    <verifyjar jar="the_jar_file.jar"
      keystore="the_keystore.p12" storetype="pkcs12"
      certificates="true" strict="true" verbose="true"/>

only prints 'sm' flags for each file before giving the error above.

4)  Running ant with -d, we're seeing

   [verifyjar] Verifying JAR: the_jar_file.jar
   [verifyjar] Current OS is Windows 7
   [verifyjar] Using input string
   [verifyjar] Executing 'C:\Java\x64\jdk-9.0.4\bin\jarsigner.exe'
with arguments:
   [verifyjar] '-strict'
   [verifyjar] '-keystore'
   [verifyjar] 'full\path\to\the_keystore.p12'
   [verifyjar] '-storetype'
   [verifyjar] 'pkcs12'
   [verifyjar] '-verify'
   [verifyjar] '-certs'
   [verifyjar] 'path\to\the_jar_file.jar'
   [verifyjar] The ' characters around the executable and arguments are
   [verifyjar] not part of the command.
   Execute:Java13CommandLauncher: Executing
'C:\Java\x64\jdk-9.0.4\bin\jarsigner.exe' with arguments:

Note that the "storepass" and "alias" attributes have not been passed along.
Taking the successful command-line invocation of jarsigner from (2) and
removing those two arguments causes the same error.

And finally, just to be certain that the output from -d is actually what's
happening (yah, they're very paranoid about tools here; fifty times bitten,
twice shy), I checked the current Git tree, and the command sequences built
up in
confirm all this.  First, that the "alias" attribute is not being included in
the command for the <verifyjar> task.  It's not required to check that the
JAR is signed, but it's required to test whether the JAR has been signed by
the cert we "think" (know) has been used.

Second, the storepass is a little tricker.  Ant doesn't give "-storepass
your_password" on its command line for security reasons, but instead sets
up a redirection and feeds the password on jarsigner's stdin.  However, that
only helps when jarsigner actually reads a password from stdin, and from
looking at the source of the OpenJDK reference implementation
it's clear that -verify turns off keystore password prompting.  (See its
loadKeyStore() arguments and how they're passed.)

Granted that the usefulness of jarsigner and the <verifyjar> task is
debatable, it should still actually do what it claims to do.  :-)   I feel
not passing these two arguments is clearly a bug, but that's something the
maintainers can decide.  In the meantime, I'd like to find a workaround.
I had been hoping we could sneak the "-storepass" argument through somehow,
perhaps using the task's <sysproperty>, but looking at the jarsigner/
source it doesn't look for any system properties at all, let alone for the
keystore password.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message