[Gcjwebplugin-devel] Re: NSAPI/ OJI/ Applet plugin

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Jun 12, 2006, at 9:33 PM, Philippe Laporte wrote:

>>> What are these really missing features and how essential are they?
>>
>> The main missing feature in gcjwebplugin is support for signed jars.
>> Like security, we're missing infrastructure in this area but Casey
>> Marshall is actively filling it in.  I don't have a timeline for this
>> work.
>
> I've reviewed the outstanding PRs on this.
>
> There was lots of activity in April/Eraly May around the WebPlugin,  
> but
> as far as Security is concerned, the class lib seems not to have been
> touched, and so I guess none of these PRs have been updated.
>
> Appearances apart, what is the current situation on signed jars,  
> missing
> security implementation here and there and the security audit? Has a
> timeline been worked out in the mean-time? Is someone in particular
> interested?
>

java.util.jar.JarFile should have sufficient support for reading  
signatures and certificates from signed Jar files. What's missing  
(AFAIK) is using that info to load classes as trusted, and managing  
trust and policy settings.

I don't think anyone has gone through Classpath to see what  
permission checks are missing, and nor has anyone audited the code  
paths that implement these permissions. So the answer is that we  
can't say for sure if Classpath is secure or not.

> Is Security seen as vital for running Applets, in the usage contexts
> currently being addressed?
>

Yes, security is definitely vital for running applets. And too, the  
second point I mention above (denying access) is much more important  
than signed applets (granting access to trusted code).

Doing this is important, but I guess we just don't have enough people  
who have the time or experience to do it properly. I've never audited  
code for such a thorough security review as Classpath needs, so even  
if I had the time to do it, I can't guarantee that I'll do a good  
enough job.

We may be able to throw some static checking at the problem; I  
suggested, for example, using annotations to better document  
permissions that are needed for certain methods, but that would only  
work for the generics branch. Some tests for permission checks, maybe  
in Mauve or perhaps elsewhere, would help.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 478 bytes
Desc: This is a digitally signed message part
Url : http://developer.classpath.org/pipermail/classpath/attachments/20060614/86ddc5d7/PGP.pgp

[Index of Archives]     [Linux Kernel]     [Linux Cryptography]     [Fedora]     [Fedora Directory]     [Red Hat Development]

  Powered by Linux