ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs
Date Wed, 30 Mar 2005 09:34:05 GMT
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 

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 "" 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:
For additional commands, e-mail:

View raw message