Hello Steve, It's certainly true that the jarsigner tool has not kept pace with recent PKI developments in the J2SE platform. For example, J2SE 1.4 introduced an API for cert path validation and J2SE 1.5 introduced support for cert revocation checking using OCSP and enhancements to the existing CRL support. Using these APIs it is possible to perform comprehensive verification of signed JAR files in Java.
Given that the underlying platform has improved, it's now true that the "-verify" option to jarsigner could easily be expected to perform a more elaborate verification. However, as you remarked, its verification ability is quite limited: http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/jarsigner.html#Verifying [Although you phrased it a little more harshly ;-) ] We will investigate correcting this problem for a future release of J2SE. A first step will be to define an API to support complete JAR file verification. That should include the ability to perform a PKIX-compliant cert path validation on each signer and to react correctly to the presence of timestamped signatures. Then we can enhance jarsigner with a new option that makes use of this new API. >From an Ant development perspective this activity will not solve the JAR file verification issue for current and prior J2SE releases. However, if you're interested, we are certainly willing to provide support for developing a verify task for signed JAR files that better meets the needs of Ant users. Bye for now. -------- Original Message -------- List: ant-dev Subject: Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs SignJarTest.java From: Steve Loughran <stevel () apache ! org> Date: 2005-03-30 9:34:05 Message-ID: <424A728D.7040707 () apache ! org> Kev Jackson wrote: > >> Well, a bit of hackery and you can verify that JAR is signed. But >> there is *nothing* to verify that the signature itself is trusted. >> Essentially "jarsigner -verify" is a worthless piece of junk from the >> security perspective. >> >> > Who'd have thought that a commit message would have me ROFL! "Worthless > piece of junk" - priceless, now I hope that someone at Sun takes this > comment and really wakes up to the fact that they can't keep banging the > "more secure than .Net" if they don't fix basic things like this. Its an interesting problem. Which is more secure: a bike that is unlocked, or one that has a heavy (kryptonite) lock that turns out to be trivial to open? I'd argue at least the unlocked one is, because knowing its vulnerability, you keep more of an eye on it. jarsign -verify is the lock that you think work, but doesnt. I had a long chat with our team security expert, and am now enlightened. The only way to reliably verify a class across all java versions is to load it in a secure classloader; that is where the JRE really checks the certs. But here is the best bit: 1. callers dont have an easy way of checking. That is, if I do classloader.load(jar) I dont get some UntrustedJARException or anything. The JRE knows that the untrusted code gets different rights, depending upon the security manager, but you cant really introspect to find out what they are. 2. Untrusted data is still accessible . An unsigned jar can contain stuff "defaults.properties" that is loadable by trusted classes, and these classes can't tell that it came from something unsigned. To be secure, you can only trust data from sealed packages; unsealed packages may have content coming from untrusted sources Java1.5 has some API for examining certificates; that is mostly moot for us. Here are my current plans -pull the declaration of <verifyjar>, tests, etc. -I'd leave the code over in optional, always excluded, with a "here is why this is broken" comment. Its aim is to warn off others. -Not attempt to use jar signing as a way of verifying JAR downloads in <libraries>; this was my plan. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
