[very much RFC][icedtea-web] fix for [Bug 564] NetX depends on sun.misc.BASE64Encoder
dbhole at redhat.com
Tue Oct 11 10:15:35 PDT 2011
* Jiri Vanek <jvanek at redhat.com> [2011-10-10 11:31]:
> On 10/07/2011 07:01 PM, Omair Majid wrote:
> >On 10/07/2011 12:09 PM, Jiri Vanek wrote:
> >>Only drawback of copypasting this explicit code is that we lost possible
> >>updates from third party (where is it much more used then in icedtea-web)
> >Actually, I am against copying code into icedtea-web. Not only do we lose the benefit from updates, if any security issues are discovered in the code (not that sun.misc.BASE64Encoder is likely to have many), we will have to update the code in icedtea-web as well. To be safe, that would mean that we look every security update for openjdk and double check that the code we copied into icedtea-web is not affected by the fix.
> >I think https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Why_no_Bundled_Libraries gives many more reasons why copying code ("bundling") into icedtea-web may be a bad idea.
> >Still, if others think it is fine to copy a small (and rather safe) piece of code into icedtea-web, then please don't let me stop you.
> Well, according to this issue I'm still hesitating :(
> I agree that replacement of base64 encoder is quite safe and minor issue. Also I admit, that my fix is really huge for just a simple thing.
> Are there any plans to fix another similar compiler-infos issues? If yes, will they be probably fixed by calling 3rd party libraries or will be written by us? (or copied from openjdk??!!)
> Based on this i would like to decide this base64 patch.
Some of them (like sun.applet.*) would be a lot harder to remove (if at
all possible) than the rest. Furthermore, there are also some
sun.net.www.protocol.jar.URLJarFile) that should _not_ be removed.
The fact of the matter is, we need to use some private apis to hook into
the jre cleanly because the plug-in is not just a "standard
application". It needs to do things that sometimes go beyond -- so I
don't think that the metabug (562) will ever be resolved.
Then the question is, if we are already using 5-10 hooks via private API,
do a couple of more (that may be removable) really matter?
> Best regards
> 564 nor P2 All unassigned at icedtea.classpat... ASSI NetX depends on sun.misc.BASE64Encoder
> 571 nor P2 Linu unassigned at icedtea.classpat... NEW NetX depends on com.sun.net.ssl.internal.ssl.X509ExtendedTrustManager.java
> 575 nor P2 Linu dbhole at redhat.com NEW Plugin depends on com.sun/jndi.toolkit.url.UrlUtil
> 605 nor P2 Linu omajid at redhat.com NEW NetX depends on sun.misc.HexDumpEncoder
> 562 nor P2 Linu dbhole at redhat.com NEW [METABUG] NetX code contains reference to non-standard sun.* classes
> 576 nor P2 Linu dbhole at redhat.com NEW Plugin depends on sun.applet.AppletImageRef
> 563 nor P2 All dbhole at redhat.com NEW NetX uses sun.security code
> 570 nor P2 Linu unassigned at icedtea.classpat... NEW NetX depends on sun.applet.AppletViewPanel
> 574 nor P2 Linu dbhole at redhat.com NEW Plugin depends on sun.misc.Ref
> 762 nor P5 Linu omajid at redhat.com NEW Netx depends on sun.net.www.protocol.jar.URLJarFileCallBack
> 657 nor P5 Linu dbhole at redhat.com NEW IcedTea-Web depends on sun.misc.JarIndex
> 761 nor P5 Linu omajid at redhat.com NEW Netx depends on sun.net.www.protocol.jar.URLJarFile
More information about the distro-pkg-dev