[icedtea-web] (PR1513) Signed JAR with external main-class

[Andrew Azores]

On 10/21/2013 05:43 PM, Omair Majid wrote:
> * Andrew Azores <aazores at redhat.com> [2013-10-21 16:24]:
>> On 10/18/2013 04:06 PM, Omair Majid wrote:
>>> * Andrew Azores <aazores at redhat.com> [2013-10-18 14:04]:
>>>> Hi,
>>>>
>>>> The applet in the PR1513 report fails to launch due to the following
>>>> check in JNLPClassLoader#initializeResources():
>>>>
>>>> // If jar with main class was not found and there are no more
>>>> // available jars, throw a LaunchException
>>>> if (file.getLaunchInfo() != null) {
>>>>      if (!foundMainJar // && (available == null || available.size() == 0))
>>>>          throw new LaunchException(file, null, R("LSFatal"),
>>>>                  R("LCClient"), R("LCantDetermineMainClass"),
>>>>                  R("LCantDetermineMainClassInfo"));
>>>> }
>>> /me grumbles about comments that reiterate what the code is doing
>>> without explaining why.
>> Yep. Sometimes I find comments that I really just want to remove...
>>
>> // initialize extensions
>> initializeExtensions();
> Feel free to remove them.
>
>> I'm not sure what you mean but I think my last email might've been a
>> little confusing about this. To be clear, the loading/execution of
>> the arbitrary class files while also displaying a "fully trusted"
>> message only happens when taking the naive approach to making the
>> PR1513 applet run, which is just removing that LaunchException
>> completely and doing nothing else. This lets the applet run (since
>> other than the signing issue, we do generally support applets having
>> the main-class external to the JARs) but leaves the ClassLoader and
>> JarCertVerifier and whatever else still thinking that the applet is
>> fully trusted, which is wrong. What we currently do never involves
>> loading any unverified classes while claiming everything is
>> verified, as far as I can tell.
> I am curious about the current state. Can it ever be that we load
> classes from the codebase URL _and_ claim that the applet is fully
> signed?

I don't think so, but I'll look into it further to be sure.

>
>> So what I think we need to do is not throw the LaunchException from
>> the code hunk I referenced, but instead treat the applet as if it's
>> unsigned when given the same conditions. This will not affect signed
>> applets where the main-class is within a JAR. It also won't affect
>> unsigned applets at all. Applets with signed JARs but with the
>> main-class not found will then be treated as if they are unsigned,
>> until either the main-class is found externally in the codebase (at
>> which point we run the applet as if it's unsigned), or the
>> main-class is just not found at all, in which case a LaunchException
>> should occur elsewhere anyway (I'll need to verify that this
>> actually happens however, we might end up with some other less
>> informative error). Does this seem right?
> Yes, this sounds like the correct fix. I don't know if it will be a
> simple one (code-wise), though.
>
> Cheers,
> Omair

Fix and reproducer patches attached. The fix is a little bit of an ugly 
workaround I guess, but I think a nicer solution would involve rewriting 
a lot of other things. Maybe that can come later on down the road.

What happens here is that if the JNLPFile's main-class is marked as 
external by the JNLPClassLoader, then the AppVerifiers will never use 
AccessType.VERIFIED. Instead, either SIGNING_ERROR or UNVERIFIED will be 
used. Which one depends on CertInformation#isRootInCaCerts(). If this 
returns true then you get the "signing error" dialog box, else you get 
the "unverified" message. The classloader still considers the applet to 
be signed, however. I figured it was better to tell the user there's a 
signing trust issue and ask for confirmation to run with full 
permissions, rather than restricting the applet to sandbox permissions, 
since the signed portion of the applet could very well require more 
permissions than that.

I guess now this mail has become an [rfc]...

ChangeLog:

Fix bug where signed applets with main-class located outside of JAR(s) 
would not be able to launch (PR1513)
* netx/net/sourceforge/jnlp/JNLPFile.java: (externalMainClass, 
setMainClassIsExternal, isMainClassExternal) new field and methods for 
marking or checking that an applet's main-class is external to its JAR(s)
* netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java: 
(initializeResources) mark JNLPFile with external main-class as 
appropriate. Do not throw LaunchExceptions for signed applets with 
external main-class
* netx/net/sourceforge/jnlp/security/JNLPAppVerifier.java: 
(checkTrustWithUser) if main-class is external, do not claim applet is 
verified
* netx/net/sourceforge/jnlp/security/PluginAppVerifier.java: 
(checkTrustWithUser) if main-class is external, do not claim applet is 
verified

* 
tests/reproducers/custom/SignedAppletExternalMainClass/resources/SignedAppletExternalMainClass.html: 
new test to ensure signed applets with external main classes can launch
* tests/reproducers/custom/SignedAppletExternalMainClass/srcs/Makefile: same
* 
tests/reproducers/custom/SignedAppletExternalMainClass/srcs/SignedAppletExternalMainClass.java: 
same
* 
tests/reproducers/custom/SignedAppletExternalMainClass/srcs/SignedAppletExternalMainClassHelper.java: 
same
* 
tests/reproducers/custom/SignedAppletExternalMainClass/testcases/SignedAppletExternalMainClassTest.java: 
same


Thanks,

-- 
Andrew A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signed-applet-external-main-class.patch
Type: text/x-patch
Size: 5905 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20131023/9354262e/signed-applet-external-main-class.patch 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signed-applet-external-main-class-reproducer.patch
Type: text/x-patch
Size: 11684 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20131023/9354262e/signed-applet-external-main-class-reproducer.patch