I’d like to thank everyone who helped spread the word on the new Code Signing requirements and guidelines starting with 7u21. In particular, Markus Eisele did a fantastic job with his blog, and also an article in Heise Developer (in German) – thanks @myfear!
We’ve just added two new FAQ questions to the OTN article on Code Signing in response to a two particularly frequent questions. The first is in response to questions around applet signing, and in particular the fact that prior to 7u21 signed apps were assumed to want full permissions, and unsigned were assumed to want to be sand-boxed. See the FAQ “How has this changed the underlying security model of Java applications in the browser?” for more information.
Both questions contain links to the product documentation with additional information for developers and admins.
I am looking for java upgrade from 1/6 to 1.7 for my client(vm leader) and trying to know what are the major performance improvements in 7? Can you point to the right information.
pls share your email as i cant see it here.
Of course the best way to know for sure is to give it a try and see!
You should be able to set this in the jar as well. The support for applet parameters is for legacy reasons. There’s some corner cases I’d have to test out or ping engineering, but it should work either way. Also, proving the data under https should help minimize any concerns.
In what way does HTTPS prevent a rogue attacker from downloading my (signed) applet, upload it to his webserver and present it as his on his website and configures it to run outside the sandbox? If I tested my applet only to work fine inside the sandbox (much less testing required, as an exploit for a programming error will probably be still blocked by the sandbox!) and later my applet is abused by someone else who runs it outside the sandbox, it casts a danming light on me, the signer of the applet – which is a reason I’d rather not sign my applets if I cannot be sure it will not be used in such a context.
@mihi, sorry – I misunderstood. https is obviously a red herring if this is your core concern. Like you say, I’m not sure how that could be abused but definitely sounds like a case to be considered. I’ll have to do some digging on that one.