ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vincent Ryan <Vincent.R...@Sun.COM>
Subject Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs
Date Fri, 01 Apr 2005 14:49:48 GMT
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:

[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
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

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