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]



Reply via email to