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
