Security update breaks A LOT OF STUFF!

General Discussions
#1

So creating the LWJGL 2.4 release.

We already added the needed Trusted-Library and stuff. Applets all good.

Then I updated the webstart…

nothing worked…

Issue 1:
Proper signed jar, proper manifest - just wouldn’t load. Cause: A Trusted-Only jar cannot be run from “sandbox” mode.
Solution: Add even though I DONT NEED it

Issue 2:
Proper signed jar, proper manifest, excess security rights. Error: java.lang.NullPointerException at com.sun.deploy.cache.CachedJarFile.findMatchingSignerIndices(Unknown Source)
Solution: Don’t use resource only jars. You must add code to jars. :persecutioncomplex:

Issue 3:
Proper signed jar, proper manifest, excess security rights, messy resources into jar where I dont want it. Error: NullPointerException when accessing said resources.
Cause: My lwjgl_test.jar (in Trusted-Only: true mode) with all my resources could not use the LWJGL util class for loading wave files because that was implemented like this:

	public static WaveData create(String path) {
		return create(WaveData.class.getClassLoader().getResource(path));
	}

and since update 19, the extension and the application jar are no longer running in the same classloader - so there is no resource to be found.
Only about everybody is using a syntax similar to the above - including the java tutorials.

Now, security aside - why the HELL did anyone approve this piece of shit update??? Pardon my language but this has got to be the most f* up EVER point release in the history of software updates.

* Matzon shakes fist

EDIT: hang on to issue 3 - may be cause by something else … investigating … nope, its valid :frowning: - fix: switch to context classloader, as per comments

#2

damn, so basically issue 3 means you can no longer use classloaders to fetch resources due to different JRE’s now putting jars in random classloaders depending on how you sign/don’t sign your jars!

Now that breaks a hell lot of code.

They should fire someone for this, maybe Gosling oh wait :slight_smile:

#3

is there any official way to raise concern about the changes to oracle, as a community?

#4

issue 3 also breaks code using things like Class.ForName(String) if the jars get loaded in separate classloaders.

Also what’s strange is that under Sun almost every release of Java6N Update had an alpha/beta before a final release, Java6u19 being the first release under Oracle didn’t have a public alpha/beta. The update was also pushed straight to the masses via the java auto updater and didn’t even get released to developers for a small period so that they could test their apps.

#5

Wow. That can’t be right, can it?

#6 

Thread.currentThread().getContextClassLoader().getResource()

Should work if they’ve implemented it as expected. There should be a delegating class loader across all the resource/code JARs that can be used to see all of them. In a JEE world you’d expect to see this classloader being passed around on the thread.

Kev

#7

nice, could you explain a little more plz ?

#8

should and if being the key words :wink:

#9

Classloaders don’t have to be one big lump. Quite often is useful and more flexibile to be able to load seperate application artifacts in different class loaders to support isolation between artifacts and co-hosting of applications. Seems like this is the case here, each artifact is being loaded in a seperate classloader.

In these cases the context class loader of the thread is normally set to a class loader that gives you the complete context of the application as viewed by the current piece of code. In this case it means that before the webstart client calls main the context class loader “should” (as hackboy rightly points out) be set to a class loader than spans all the others.

Has anyone tried it yet? Until then it’s just speculation.

Kev

#10

Thanks kapta for pointing me in the right direction in the other thread.

When I first started my battle with u19 (from HELL!), my applets didn’t start anymore AT ALL. Not even the initial messages in the console appeared, I am talking about the messages from the java plugin! That made it quite difficult debug, since nothing started. I managed to figure out that the boot loader that Dzzd had made, would actually bring up the mixed mode warning pop-up. I found out that I all along had copied and pasted a resource jar (menu sounds and stuff) that was signed to all my project. Removing sign got rid of mixed mode warning and the applet started, using boot loader.

Without the boot loader, the applet still didn’t start. I use a script for all my builds, and in this particular instance, I used all software rendered resources, so I had one empty jar (just containing the manifest) that I didn’t use, that wasn’t signed, and that wasn’t referenced from the applet tag, but was in the executed jar´s manifest. Not only does it not start, but the console buttons don’t work, including the close and the windows [ x ] close button! Removing this empty jar made everything work just fine, but leaving it in, will completely lock everything up before the console menu even appears!!! :o

I do use “Class.forName(getParameter(“game”)).newInstance();” in my framework code to be able to separate applet, standalone specific code from my game code. Not sure if that is affecting things.

I have not been bashing Sun or Java in the past, but I have to say very well put, and I could not agree more!

#11

:slight_smile: ok dont want to give to much hopes (but first try seems to work, just need to do some more tests) expecially if it finally dont solve it, but seems that I have find a really nice solution, will post some more informations tonight.

PS: the not so good thing is that it will probably be considered as a security hole and then will be patched…

#12

seems to work pretty well… unfortunatly it for now dont solve my problem (popup & load security at runtime) but it enable something new in Applet world that give the Applet Booter all its power :

here it what it offer : delay all the jar loading (even on unsigned Applet :)),applet tag do not requiere any archive tag, all jar are loaded after the applet have started this enable imediate applet start and custom loading, tested & working I ll post last details and sources code tonight.

It also enable mixing signed / unsigned without mixed warning and enable cross jar class access as long as you put the boot class in a signed jar and I suppose this one will help some of JGOs here ?

#13

here is what I got for now, not really as neat as I was thinking…

http://demo.dzzd.net/Test619/

below is the HTML code, as you can see there is no archive attribute on the Applet tag all Jars loading are delayed (and it does not requiere to be signed), but I am still facing a problem :

need to put Boot.class in a signed boot.jar to enable signed/unsigned mixing Jars, because if not each Jar are considered as being unsigned, I dont like it because I would like to be able to popup the security dialog at runtime as it was running before 1.6u19 (not at startup).

how/when this dialog is poped up ? I suppose it is related to Certificat / SourceCode / ProtectionDomain or some other classe like those, but how exacly, any ideas ? for now I can load those signed Jars but the signeds one act exactly the same as unsigned : the ClassLoader load them and seems to not see / ignore (I suppose because my classloader is stamped unsigned …) the certificat of the signed Jar/classes…

<APPLET
	    code	= "Boot.class"
	    width	= "600"
	    height	= "338"
	    MAYSCRIPT>
<PARAM NAME="IMAGE" VALUE="BLANK.GIF">	
<PARAM NAME="BOOTJARS" VALUE="LIB/dzzd.jar;LIB/timer.jar;LIB/extension.jar;game.jar">	
<PARAM NAME="BOOTBGCOLOR" VALUE="eeeeee">
<PARAM NAME="BOOTCLASS" VALUE="game.spiderExperiment.FPSSample">		
</APPLET>
#14

rather than doing our own plugin… we should all investigate in a trusted certificate and sign a generic Applet booter ( one like this ) and implements our own security manager …

I know it look a bit security hole but… that what happen when security become too restrictive : people uninstall FireWall / Antivirus / Disable vista security center / click “yes” on any security dialog they are asked for / write there password on paper sheet / and so on… that’s why once again I would say that Oracle have no idea of what is security or they have some commercial plan in mind

#15

Or they will give up and say your application/game/x “doesn’t work”, I don’t know which option is worse >:(

#16

u19 does look like one fucked up puppy.

#17

Seriously, thanks for sharing your opinion. At least now we know somebody with some influence in Oracle realizes what a serious regression this is.

#18

@tremobvetski - any idea about how quickly this might get sorted out satisfactorily? (First step - pull u19 and downgrade everyone back to u18 if possible using autoupdate?)

Cas :slight_smile:

#19

If 6u20 == 6u18, that would fix it, without any effort.

#20

Except that u19 fixed a security issue - a gaping hole.
Imo they should have done a “patch” for now and then change the stuff in java 7.

but apparently the issue was more important than screwing devs over - which I dont disagree with …