www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: Summary
Date Tue, 07 Mar 2006 19:03:47 GMT
On Mar 4, 2006, at 2:04 PM, Steve Loughran wrote:

> On 3/4/06, Henri Yandell <flamefew@gmail.com> wrote:
>> On 3/3/06, Dain Sundstrom <dain@iq80.com> wrote:
>>>
>>> BTW it would be nice if we could just use standard Java Jar signing.
>>> That way the ultimate user of the code, the JVM, can verify the Jar.
>>
>> Hearing this idea a lot; Steve Loughran had some emails saying that
>> signing wouldn't work - Steve?
>>
>> Hen
>>
>
> It would be nice, cos then java webstart could run from the
> repository. But once a jar is signed, only jars signed by the same
> person can declare classes/resources in the same package (I think the
> root package is special, as in META-INF)
>
> As a consequence
>  -hibernate breaks; it cannot add new proxy classes for your code  
> on the fly
>  -nobody would be allowed to add new classes to the package in any  
> other JAR

Package Sealing is an optional flag in the Jar manifest (http:// 
java.sun.com/j2se/1.4.2/docs/guide/extensions/spec.html).  If you  
simply don't include include the "Sealed: true" entry in the manifest  
or specifically set it to "Sealed: false" and you won't get sealing.   
Further, sealing is implemented by the classloader itself.  The  
UrlClassLoader respects the entry, but others may or may not.  For  
example, webstart below always turns on Sealing when dealing with a  
signed application.

> problem #2 kind of goes against your right of an OSS user, the easy
> ability to add new stuff to a JAR. So, say I wanted to patch
> ant-junit.jar, which declares stuff in org.apache.tools.ant.optional,
> I'd need to rebuild the whole of ant or strip out the signatures, just
> to get my signal jar to work. Which complicates redist too.
>
> Now, if you design an app with signing in from the outset, maybe this
> would be a feature not a problem. So, say maven could always only
> download and run signed plugins; it would be signed itself from the
> outset, so as long as that original bootstrapper got to you securely,
> and all instructions it received were authenticated,  you would have a
> local chain of trust.

I agree, so if it isn't possible to turn off Sealing then this will  
not work.

> And returning to webstart, Its flawed, horribly, I just havent sat
> down to prove it yet. When you run a webstart app an HTML doc is
> downloaded that lists the JARs to run, the JRE pulls them down and
> runs them, starting at the main entry point listed in the descriptor.
> If a signed JAR has any other entry point in, then it is at risk of
> being called. Does anyone audit their JARs for entry points? Exactly.
> If you sign a JAR you are saying "safe to use in a java web start
> triggered by an untrusted HTML descriptor", which is not something we
> are prepared to say.

Signing is supposed to only assure that you know who signed the file  
and that the file hasn't been tapered with.  Signing the file doesn't  
say that the file is usable for any purpose.  Further java webstart  
has a very very restrictive set of signing rules:


An application launched by a JNLP Client is considered to be signed,  
if and only if:

o All the JAR files are signed (both for jar and nativelib elements)  
and can be verified. A JAR file is signed if all the entries  
(excluding manifest entries, the signature iteself, and empty  
directories) are signed by a single signature.
o If a signed version of the JNLP file exists, then it must be  
verified, and it must match the JNLP file used to launch the  
application. This is described in the following subsection.
o The same certificate is used to sign all JAR files (jar and  
nativelib elements) that are part of a single JNLP file. This  
simplifies user management since only one certificate needs to be  
presented to the user during a launch per JNLP file (and hardly  
restricts the signing process in practice).
o The certificate used for signing the JAR files and JNLP file (if  
signed) must be verified against a set of trusted root certificates.


Further for an application to be run in a trusted environment  
(normally webstart application run in an applet like environemnt),  
the spec states:

The following requirements must be satisfied before a JNLP Client can  
grant an application these access rights:
o The application is signed.
o The user and/or the JNLP Client trusts the certificate that is used  
to sign the application.


Anyway, I think webstart is cool, but not really important to this  
discussion.

-dain


Mime
View raw message