Bug 27596 - no way to verify JAR files as validly signed in Ant. (was: signjar should support the -verify and -certs options)
Summary: no way to verify JAR files as validly signed in Ant. (was: signjar should sup...
Status: NEW
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: unspecified
Hardware: Other other
: P3 enhancement with 1 vote (vote)
Target Milestone: ---
Assignee: Ant Notifications List
Depends on:
Reported: 2004-03-11 10:25 UTC by Stuart Wigley
Modified: 2009-07-31 04:10 UTC (History)
2 users (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Stuart Wigley 2004-03-11 10:25:04 UTC
There doesn't appear to be anyway to verify an existing signed jar file using 

At the command line I could use:
jarsigner -verfiy -verbose -certs myfile.jar

This would verify the signed file, and with the additional -certs option would 
also display details of the certificates used to sign the jar.

I know this could be acheived with exec, but for completeness it would be nice 
if signjar supported these options.
Comment 1 Steve Loughran 2005-03-17 18:04:11 UTC
Will be needed as part of library signing policy; will be achieved by
refactoring out a base class of <signjar> and then having a separate <verifyjar>
task to verify signatures.
Comment 2 Steve Loughran 2005-03-23 17:49:43 UTC
Stuart, how do you propose we actually verify that the jarsigner verification
Comment 3 Steve Loughran 2005-03-24 23:47:34 UTC
Having implemented this, I am not going to expose the task. The problem is that
jarsigner -verify is so broken, the presence of a <verifyjar> task would mislead
people into thinking it worked.

1. it doesnt return any exit code for failure to verify. You need to parse the
output. This is too brittle. 

2. it still prints "jar verified." when the certificates used to sign the jar
are unknown. This is fundamentally insane, from a security perspective. 

jarsigner -verify is no good for verifying JARs. We add it, and unless the task
prints "warning, this is a toy verification, no better than a CRC check",
someone will download something, run <verifyjar /> over it, trust it and then be
surprised when it turns out to be malicious. The ant team would get the blame
for propagating a broken app.

I'm changing the title of the bugrep to show the underlying problem, not the
solution that doesnt work. 

Java1.5 does appear to expose enough of the certification chain (with the
Certificates class) to maybe make this an optional feature in future. This is
the sole reason I am leaving this bug open. Using jarsigner -verify is not the
solution, nor, probably , is loading it in a secure classloader, for reasons I
wont explain here, but which are equally tragic. 

Comment 4 Emmanuel Bourg 2009-05-18 10:11:53 UTC
It may be worth documenting somewhere that the verifyjar task is actually implemented and available since Ant 1.7. It works fine to verify a set of jar files, otherwise jarsigner has to be called through the <exec> task for every jar to check:

<exec executable="jarsigner" dir="dist/lib" failonerror="true">
  <arg value="-verify"/>
  <arg value="foo.jar"/>
<exec executable="jarsigner" dir="dist/lib" failonerror="true">
  <arg value="-verify"/>
  <arg value="bar.jar"/>

What is missing from the task to make it official?
Comment 5 Steve Loughran 2009-05-19 02:33:32 UTC
Emmanuel, read the comment above. Jarsigner -verify does not verify that the JAR is signed by anyone you trust. That it does not look at your list of valid certifications and say "are the artifacts in the JAR signed by a trusted entity". All it does is check that there is a signature.

As I said before "verify is so broken, the presence of a <verifyjar> task would mislead people into thinking it worked."

That is why <verifyjar> isn't written up. People might use it and think that it is checking that JARs are valid. It isnt -and neither is jarsigner.
Comment 6 Emmanuel Bourg 2009-05-19 04:01:00 UTC
I understand it's not perfect, the task is 'as bad' as the jarsigner tool, but it's still useful. For example when you sign and pack your own jar files (with pack200), running 'jarsigner -verify' is a must to ensure that the repack+sign+pack process was done properly.

I use <verifyjar> to check the jars produced by my build and signed with my certificate. The fact that the validity of the certificate is not checked is irrelevant in this case. It doesn't tell if the jar can be trusted, it tells if the jar is corrupted and will break when loaded by the Java Plugin.