| Summary: | no way to verify JAR files as validly signed in Ant. (was: signjar should support the -verify and -certs options) | ||
|---|---|---|---|
| Product: | Ant | Reporter: | Stuart Wigley <sw> |
| Component: | Core tasks | Assignee: | Ant Notifications List <notifications> |
| Status: | NEW --- | ||
| Severity: | enhancement | CC: | ebourg, notifications |
| Priority: | P3 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | other | ||
|
Description
Stuart Wigley
2004-03-11 10:25:04 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. Stuart, how do you propose we actually verify that the jarsigner verification worked? 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. 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> <exec executable="jarsigner" dir="dist/lib" failonerror="true"> <arg value="-verify"/> <arg value="bar.jar"/> </exec> What is missing from the task to make it official? 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. 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. |