loadJOGLLibraryFromURL -this is also good idea, maybe you could try to implement it by yourself and post it to KEN Dzzd?
yes I also like that idea ;D.
but using to be a hacker long time ago 
, there will be a big security hole, maybe it is already the case with the current joglappletlaucher? because you can simple unassemble the jogl (native as the .dll files ) library, patch it with a malicious code like patching the glvertex3f function in the library this way
glvertex3f(…)
{
…
my malicious code
…
old glvertex3f code
return
}
and re-assemble it and deploy your applet using this new library, so a crc or something like that must be computed by the library loader and only allow validated library to ensure the user a good security.
I dont think sun would appreciate his sign to be used as a virus dispatcher
i do not know how certificate works in java (on jre side) but i think that changing any *.jar which was earlier deployed and certified after adding new class or anytning else (by non sun programeer - hacker or someone else) certificate will not work, so even new pathched jogl.jar will not be asociated with that certificate becouse they are two diffrent files (old jogl.jar and new jogl.jar). Well i do not know but i think that it works in that way.
and you have right about joglAppletLancher code ido not know but it is intresting if JoglASppletLancher from certified jogl.jar will run applet from not certified jar (for example your DzzD) , but that not certified jar if could run some special functions for example file func will it cause security issus, better it should be checked or someone could make an applet with untrusted code that will be run as trusted, you know what i mean, so someone could acces client system data download native lib etc, but i think that Ken and c_lilian has thought about it…
I am talking about the native library, not the jogl.jar the jogl.jar is not modified on my previous explanation only the library as .dll for windows and those library are not signed… so you can patch any function in those native library with a malicious code
ah yes now i understand you have right, have Ken thought about it? This patched lib could make whatever it want to and if some hacker will patch all os’s libs it will make crossplatform virus
i have one question to you Dzzd asociated to your website which is really intresting, have you earned anything from those google ads? Is it enough for handle a server and maybe for some candies ;)? I have hard about other adds programs like amazon etc but do not know much more about it…
c_lilian gave the security issue quite a bit of thought during the development of the JOGLAppletLauncher. It requires that the jogl.jar and jogl-natives-*.jar files all be signed by the same entity. Therefore if the security dialog claims that Sun Microsystems, Inc. is the trusted entity, you can’t substitute in native code not signed by Sun.
I exchanged email with a member of the deployment team here at Sun and they indicated that the name and URL of the applet is coming from the AppContext, not the certificate. That’s why your applet claimed to be signed by Sun. I don’t know if there’s a good workaround for this but I think it’s definitely a sub-optimal situation.
Ok, I better understand now the certificat popup bug.
what about a static function to load native library ?
if both native library and jar must be signed they will not be security problem, so is it a possible solution that can be added to JOGL as a static method ?
Maybe, but again you or someone else in the community will have to prototype this. I’m sorry, but we don’t have the development resources to support every kind of possible installation mechanism.
Great, I am sure user will love this new functionality.
today someone told me that he can do this job, so we will try to feedback the source code as polish as we can.
Ok we finished a first version of a new class to allow remote loading of native library from applet, need to polish it before to post its source code.
the new class is called NativeLibRemoteLoader and have two static methods NativeLibRemoteLoader.loadFrom(URL) & NativeLibRemoteLoader.loadFrom(String) where the parameter is the url of the remote server to download native library from.
we tested a self signed version of the jogl.jar including this new class, and it works fine and it is really simple to use in applet or others.
To use it in an applet just do the following :
NativeLibRemoteLoader.loadFrom(this.getCodeBase()),
libraries will be downloaded if needed in the same way as JoglAppletLauncher do ( jogl_ext dir in user home) and than loading into system.
your applet tag should look like : <Applet archive=“yourjar.jar,jogl.jar” …
should be ready in few days
i have tried to make it on my own, but only made theoretical load code, even not check it, anyway good that you have make it with succes, and i have a question:
-
how have you implemented loading of jogl.jar ?, using url.openConnection and downloading by hand or just simple Class.forName (so the whole process is made by jvm plugin) . Becouse i was thinking to make it possible applet control of loading of jogl and required natives. Why? Becouse jogl.jar is quite huge so it can freeze applet for long time if that librarys will be downloaded by jvm. The problem is in this aproach to make downloaded jar in bytes to make it work for jvm , well theoretically special classLoader could be made so it will work. This approach could be useful if we would to control the process of downloading on our own applet , so for example during loading jogl.jar user will be able to play game etc and after jogl download+natives game will switch to opengl version. Have you fought about it Dzzd?
-
is loadFrom working in its own thread like in JoglAppletLancher refreshJogl , if yes how an applet will know that jogl install has ended (will for examlpe NativeLibRemoteLoader invoke some applet func to notify it using reflection )
again its great news
a1:
the loading implementation of jogl.jar is up to the user of jogl.jar, jogl.jar cannot contain a function to load itself, for our test we just use <applet archive=“jogl.jar,other.jar” … .
I think it is also possible to load jogl.jar in background using a separate thread while doing something else on screen : play animation or start game in software mode, at least It is how it should be implemented in 3DzzD.
native libraries will be only loaded if needed : loader test for version diff between already downloaded natives and server version
a2:
no, for now native libraries loading is not done in another thread : loading 60ko take only about 8-16 secondes with a 56 kbits modem.
Also I think that the remote loader is not really specific to applet , no ? and if it is not performing an asynchronous loading there is no need of applet notification.
what do you think about it?
i think that you could add some special methods for this NativeLibRemoteLoader so applet creator will have better control what is happening, especialy downloading natives on its own not in your installer, well it should be some choice for applet creator
functions:
-
getNativeJarName() - that function is already in JoglAppletLancher, so it should be made public, and rewritten again so even before initalization of
NativeLibRemoteLoader.loadFrom use my applet will know what native.jar download and i will be able for example to provide user some progressbar or something, so getNativeJarName function should check client os system and check all native jar names and return String of native jar for this os and applet from itself will have to download that jar on its own -
NativeLibRemoteLoader.loadFrom( byte nativeJar[] ) - when my applet will download native jar on its own it should have a posibility to give it to your loader, implementation of this function can be very simple, the whole array of bytes could be just saved like this:
private void saveNativeJarLocallyFromByteArray(File localJarFile, byte array[]) throws IOException{
FileOutputStream out = null;
try{
out = new FileOutputStream(localJarFile);
out.write(array);
out.close();
}finally {
if (out != null) {
try {
out.close();
} catch (IOException ignore) {
}
}
}
}
so loadFrom function will save that bytes as a jar (this is the same situation like in JoglAppletLancher.saveNativesJarLocally func but of course will be much faster) and
next process of extracting native libs from that jar will be the same like in refreshJOGL function (where JarFile jf = new JarFile(localJarFile); is used) but that long freeze will be avoided. I think that it should be made good and with maximum flexibility, that two functions in future could make our live simpler in coding belive me.
so that were my two cents…
what do you think?
oh and maybe some two additional functions should be added which are very important:
public boolean isJOGLInitalized(); // false - instalation has not started, true - instalation was complited without any error
public boolean isJOGLInstalationTerminated(); // true - jogl can not be used due to some instalation problem
so applets will be able to know if jogl works so all steps of initalization like : creating directory for native.jar, getting native libs, loading them to jvm
IT IS VERY IMPORTANT, note that JOGLApppletLancher checks may times for errors and give the user information through displayMessgae what went wrong, for example during functions operations etc, so applet will know if the procees has ended with success
of course those functions names you can cheange as you wish, you should change them to names that will fit better to your loader class
Making getNativeJarName public could be useful.
doing NativeLibRemoteLoader.loadFrom( byte nativeJar[] ) will cause the applet unavailable to download natives libraries from another location than the codebase of itself due to browser applet security that do not allow to open connection to other server than the applet provider ?
what about doing :
NativeLibRemoteLoader.getNativeJarName();
NativeLibRemoteLoader.loadFrom(serverURL) //synchronous loading with natives name auto detection
NativeLibRemoteLoader.loadFrom(serverURL,nativeName) //Synchronous loading
NativeLibRemoteLoader.loadFrom(serverURL,nativeName,NativeLibRemoteLoader.interfaceProgressor) //asynchronous loading in another thread
another thing is that NativeLibRemoteLoader.loadFrom(URL) is able to test natives jar version before downloading and applet wont be able to do because they will not be able to read current natives libraries version.
so maybe we can do:
NativeLibRemoteLoader.getNativeJarName(); //for utility purpose
NativeLibRemoteLoader.getNativeLibLocalVersion() //Get local version
NativeLibRemoteLoader.getNativeRemoteVersion(URL) //Get remote version
NativeLibRemoteLoader.loadLocal() //Load local natives version
NativeLibRemoteLoader.loadFrom(serverURL) //synchronous loading with natives name and version diff auto detection
NativeLibRemoteLoader.loadFrom(serverURL,nativeName) //Synchronous loading and version diff auto detection
NativeLibRemoteLoader.loadFrom(serverURL,nativeName,NativeLibRemoteLoader.interfaceProgressor) //asynchronous loading and version diff auto detection
will be good to have Ken opinion about it ?
EDIT:
Yes knowing what is the current status of jogl native is a good thing
may be isJOGLInstalationTerminated and isJOGLInitalized() can be replaced by NativeLibRemoteLoaderException throwed by all NativeLibRemoteLoader public methods?
code evrything as you wish for error handling etc, it is not a problem
my idea to mek load form byte array is not to replave your idea of downloading from any location even another then codebase.
BOTH ideas can be useful and BOTH ideas can be implemented - it is not a problem from where applet creator would like to download it - from codebase or any athor location he will decide, so you could make it like this:
loadFrom( byte array[], long date) - applet will give date of native jar which is required for checking date version (like in JoglAppletLancher.getTimestamp func)
eh … anyway interfaceProgressor can also be used, well i thought that applet should have much more control but you decide
you have right Ken should take a look at it …
thanx again for your work DzzD, good night and good luck untill tomorow
i would not like to interupt your job DzzD but would like to ask one question: have you finished that jogl loader?
it is working but can get enought time to polish/finish it since last time I worked on it , source code is for now still very dirty/bad,
I have to finish an other job and than I ll finish this one, I think it will be fully finished and I will post it in one week and maybe before at the begining of next week.
I have the same problem as everybody wich is a lack of time, sorry for the late…
?
if you DzzD do not have time i can clean up that code, what do you think?
That’s a great idea, because I am really busy for now.
Thijs(on this forum) and me have only worked on it few hours including time necessary to instal Ant and other tools requiered to compile JOGL, we cannot found any free time to finish this work before a cupple of weeks, so I will send to you our tests source code wich include a new class NativeLibRemoteLoader and a working sample applet that use it.
What need to be done is cleaning the code(for now it is only bunch of code mixed…), improve security by adding a control of the certificat of the downloaded native libraries, adding other necessary method as we told about in that thread, better implement the security acces control block.
It will be really great if you could finish it , thanks for that proposal !
let me know how can I sent it to you