758 2013-06-20 04:25:40 +0200 Build all and test JogAmp Modules w/ Java7 targeting Java6 bytecode for security reasons. Apply JAR Manifest tags: Sealed, Permissions and Codebase 2015-09-27 03:14:58 +0200 1 1 3 JogAmp General infrastructure unspecified All all RESOLVED FIXED P1 major --- 1 sgothel sgothel FEATURE jogamp-scripting 909a1bed99fa5f07fc3f4ec6564ffde529a5162b gluegen 6704fab767307b89fa21250c20f1dab56323ffac joal 55b5449ce106164e7f47b827cbe03a7831de9942 jogl dc6b3b50f83bf8ed114f509a3d88855f1ff9e54a jocl 6704fab767307b89fa21250c20f1dab56323ffac --- oldest_to_newest 2693 0 sgothel 2013-06-20 04:25:40 +0200 Build all and test JogAmp Modules w/ Java7 targeting Java6 bytecode for security reasons. - Read http://www.kb.cert.org/vuls/id/225657 - No more Java6 security updates - No more java6 toolchain available (but Red Hat's openjdk6 ..) - Building w/ Java7 will produce Java6 bytecode using source and target levels 1.6, as well as using a java6 rt.jar. Apply JAR Manifest tags: Sealed, Permissions and Codebase Note: The Manifest file is included in the signed JAR file .. and signed. - Read http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/no_redeploy.html - Using 'Sealed' on jogamp.* classes impl. / direct acessing the JNI code - so there will be no 'derivation' - 'Codebase: *.jogamp.org' will prevent copying the signed jar files and survive a vulnerability deletion, i.e. if we delete our copy from the server it .. it's of no use anymore. Users would need to signed the jars to be used on their servers. Yes, this is more like snake oil .. not real security. Better: A policy how to mark determine a valid location of signed content allowing us to control it's lifecycle. Sealed, also allows us to forbid non intentional use, i.e. derivation / override. .. in process.