[rfc][icedtea-web] fix for RH816592

[Thomas Meyer]

Am Donnerstag, den 24.05.2012, 15:41 +0200 schrieb Jiri Vanek:
> On 05/23/2012 05:45 PM, Jiri Vanek wrote:
> > On 05/23/2012 05:36 PM, Omair Majid wrote:
> >> On 05/23/2012 10:22 AM, Deepak Bhole wrote:
> >>> * Jiri Vanek<jvanek at redhat.com> [2012-05-03 08:21]:
> >>>> This patch is fixing
> >>>> https://bugzilla.redhat.com/show_bug.cgi?id=816592 reproduced in
> >>>> [rfc][icedtea-web] reproducer for RH816592
> >>>> (http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-May/018357.html)
> >>>>
> >>>> This patch have small (one output message) overleap with [rfc]
> >>>> [icedtea-web] providing little bit more debug outputs for few
> >>>> methods (http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-April/018332.html)
> >>>>
> >>>
> >>> This patch tries to manually add an entry to the security map. However it should not
> >>> be needed. Whatever is adding the jar should add an entry to the map --
> >>> the bug should be fixed there IMO.
> >
> > Hmmm. I Believe that there is reflection used to inject the jar into classlaoder. So if I will
> > overwrite addUrl method (which is the best place to do this) this can be still walked around. Thats
> > why I have chosen this place..
> >
> > But I admit my originalpatch must be improved for not searching again for already searched resources.
> >>
> 
> I elaborated little bit above sources of jmol (http://jmol.sourceforge.net/demo/atoms/)  and I have 
> NOT FOUND where they are injecting theirs jars :-/
> 
> So I have prepared testing fix (the WRONG one) which was checkigg if somebody is using addURL by 
> reflection (which I consider as best way to do and I have used in my reproducer - 
> (http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-May/018357.html). However it appeared 
> that not jmol nor geogebra are using this approach.
> 
> Today I have traversed through jmol code and have not find how tehy are getting the sources in:-/
> They are using for preloading Class.forName in few first lines of app, but in thsi time there IS 
> already requested jar which is not declared on classpath of applet (well.. object generated 
> byjavascript :-/)  tag.
> But it can be anything. Even direct reflection to field holding urls in UrlClassLaoder or some JS as 
> it looks like in jmol.... In this case everything hook upon any method is in vain. But My original 
> solution WILL work for all this cases O:)
> 
> 
> J.
> 
> The improved patch is fixing possible exception thrown and repeated reloading of resources in case 
> of failure.
> 
> 2012-05-24  Jiri Vanek  <jvanek at redhat.com>
> 
> 	Fix for RH816592
> 	* netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java:
> 	(getCodeSourceSecurity): will now try to download and verify resource
> 	which was downloaded outside of netx.
> 	(alreadyTried) set for memory of once tried resources to not try again
> 
> >> This is an implementation-specific behaviour of the proprietary javaws
> >> that some programs seem to rely on. We have other bugs caused by the
> >> same issue too: PR568 [1] and PR839.
> >
> > Yap. As I already wrote it is brutal:)
> >>
> >> Cheers,
> >> Omair
> >>
> >> [1] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=568
> >> [2] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=839
> >
> 

Hi,

is this the same as PR858?

I mailed this patch to fix it:
http://old.nabble.com/Re%3A--RFC--PR858-p33525848.html

with kind regards
thomas