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

[Andrew Azores]

On 10/23/2013 04:36 PM, Andrew Azores wrote:
> 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,
>

Ping?

-- 
Andrew A