Not sure if you've seen this or not:

http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/deployment_rules.html
https://blogs.oracle.com/java-platform-group/entry/introducing_deployment_rule_sets

So it appears that there will be a way for "enterprises" to whitelist RIAs via deployment rulesets.  I'll have to implement this for my customer since we're deploying via JNLP so I'll let you know how it goes.

It's still unclear to me whether self-signed applets will be blocked entirely or if that the end-user will be prompted to accept the signing certificate as trusted?

-brian


---------- Forwarded message ----------
From: DRC <dcommander@users.sourceforge.net>
Date: Fri, Oct 18, 2013 at 9:06 PM
Subject: [VirtualGL-Devel] Rethinking the built-in web server (was "Best practices for signing open source JARs?")
To: VirtualGL Developers <virtualgl-devel@lists.sourceforge.net>


In thinking about the JAR signing issue, it occurs to me that the main
reason I'm stuck on that issue in the context of The VirtualGL Project
is the fact that the TurboVNC Server includes a built-in web server that
serves up the Java viewer as an applet.  Thus, if we kept that feature,
I'd have to sign the JAR in our project binaries somehow.

But it begs the question-- does it makes sense to even keep the built-in
web server feature?  Does anyone really use it?  It seems like kind of a
legacy feature that may have outlived its usefulness, particularly when
considering that you can't really run a modern VNC viewer in an applet
sandbox (the most recent TurboVNC and TigerVNC Java viewers can't run
sandboxxed at all, and even if they could, they would be very crippled.)
  It just seems like the main reason why the built-in web server feature
was invented was so people could start a VNC server on their workstation
and then go down the hall to another machine and connect back to their
workstation without having to install anything.  That may still be a
valid thing that people do for collaboration.  I'm not sure-- that's why
I'm thinking out loud here.  I don't know of anyone using the feature in
an actual TurboVNC deployment (and, in fact I know of many who disable
it), but correct me if I'm wrong.

One thing I had considered for 1.3 is keeping the built-in web server
but having it serve up a JNLP file instead of a web page, and I could
provide instructions along with that regarding how to add the
libjpeg-turbo JNI JARs and sign everything using an "official
certificate."  I'm not a big fan of shipping something that doesn't work
out of the box, though.


On 10/18/13 7:39 PM, DRC wrote:
> I'm a little stumped on this one.  It appears that, as of January 2014,
> Oracle's JRE (and maybe others) will simply stop allowing self-signed
> JARs to be run as applets or JWS apps.  I'm not sure why they want to
> make life difficult for open source developers, but it definitely seems
> like they did not have us in mind when they dreamed this up, and I'm not
> sure of a good way around it.  The CA model just does not really fit
> well with open source.  Open source binaries are supposed to be
> reproducible by anyone, not tied to a particular developer, and I
> consider it a point of pride that anyone can check out my build scripts
> from SVN and, assuming they are using the same type of build machine,
> produce identical binaries to the ones I release.  We are a project, not
> a company, and the JARs we produce are intended to be re-signed by a
> company before being deployed in any official capacity.  But for testing
> purposes, there is nothing wrong with a self-signed certificate.  This
> seems like a sweetheart deal for the certificate authorities, at the
> expense of allowing open source code to be easily tested.
>
> There is a certificate authority (Certrum) that is offering free code
> signing certificates for use by open source developers, but those are
> unfortunately generated based on individual credentials.  Thus, if I
> signed TurboVNC with one of those certificates, it would pop up my full
> name and address and other vital information every time someone ran the
> TurboVNC Viewer.  Not acceptable.  For starters, it's an invasion of my
> privacy, but it also goes against the principles of open source code
> being a community effort.  What if someone else wanted to generate
> binaries for the project instead of me?  What if anyone who didn't have
> a CSC wanted to build TurboVNC binaries for their own internal testing?
>   Further, an individual certificate like that would imply that I was
> legally responsible for the behavior of the app, which is in fact not
> true (the open source licenses explicitly disclaim any warranty.)  It
> just seems like lawsuit bait to sign an app with one's personal name,
> particularly if the app is not yet released and is being provided solely
> for testing.
>
> Any advice?
>
> DRC

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
_______________________________________________
VirtualGL-Devel mailing list
VirtualGL-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtualgl-devel