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!

The second question relates to warnings when running applets in mixed (signed and unsigned) environments (particularly as it relates to JavaScript). 7u21 expanded the scope of when these warning would be presented, and we have addressed how developer can manage these situations in the FAQ “Does the code signing requirement impact “mixed code” environments?“.

Both questions contain links to the product documentation with additional information for developers and admins.

7 Responses to Update to Code Signing Note on OTN

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.

Any specific reasons why the switch to run signed applets in the sandbox is part of the (unsigned) applet parameters and not the (signed) Jar manifest? I cannot think of an easy way to abuse this, but it seems pretty risky to put such an important piece of information at a place where the signing company has no control over…

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.