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

[Andrew Azores]

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();


>
>> What I'm wondering however, is if this is actually safe. How do we
>> really want to be handling this situation? The JarCertVerified
>> reports "fully signed", but then we are going to go ahead and
>> execute an arbitrary unverified class file from outside the JAR(s).
>> To me this seems a little bit questionable - definitely we shouldn't
>> just fail to launch altogether, but what should be done about the
>> permissions for this applet? Right now with the exception removed,
>> the user is still prompted with a dialog claiming that the applet's
>> signature has been validated by a trusted source, but can we really
>> say that now?
> I don't think saying "fully signed" is valid even if the main class is
> found in the jar. As long as there is a URL which will be used to search
> for additional classes, we can not claim we have verified all classes.
> We probably should not claim that everything is signed and/or trusted.
>
> Do all applets get a codebase URL for fallback unconditionally?
>
> Thanks,
> Omair

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.

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?

Thanks,

-- 
Andrew A