Update to Code Signing Note on OTN

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.

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.

- Don

About these ads

About DonaldOJDK

This blog is for both personal and professional topics. Nothing here should be considered official for any past, present or future employer (or my wife and kids)!
This entry was posted in Uncategorized. Bookmark the permalink.

7 Responses to Update to Code Signing Note on OTN

  1. Hi Donald,

    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.

    thank you
    pradeep kamasani

  2. mihi42 says:

    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…

    • DonaldOJDK says:

      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.

      • mihi42 says:

        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.

  3. DonaldOJDK says:

    @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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s