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

[Omair Majid]

* 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?

> 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