Insight manifest changes for webstart #11772

[manics]

Add Permissions tag (required for webstart) and a couple others to the insight manifest.

Testing: not easy, you'll either need to create your own root CA, or use an existing one (the latter is probably better since it more closely reflects the situation if we obtain an official code-signing cert)... instructions below. At the very least non-webstart Insight should build and work normally.

./build.py

./build.py release-webstart \
    -Djarsign.keystore=/Volumes/ome/team/simon/code-signing/store.jks \
    -Djarsign.alias=testcodesign \
    -Djarsign.storepassfile=/Volumes/ome/team/simon/code-signing/store.passwd

Import the root CA certificate into the Java certificate store:
Open the Java Control Panel (via System Preferences on OS X), Security, Manage Certificates. Select Signer CA, User, Import, Select /Volumes/ome/team/simon/code-signing/ca.p12

Now start the server and web, and attempt to launch Insight webstart. You should get one or more dialogs, they should show OMERO.Insight instead of an unfriendly classname and the Publisher should not be Unknown.

Note the code-signing certificate should not be imported, if the root CA has been imported and the jar signing succeeded there should be a certificate chain leading up to the root.

Timestamping uses http://time.certum.pl by default. It involves one request per signed jar, http://www.certum.eu/certum/cert,offer_time_stamp.xml (non-qualified) doesn't say anything about limits.

This of course assumes you haven't already added a workaround/exception for Java, if you're unsure try running webstart without this PR and/or without signing the jars and/or without importing the root CA, and compare the dialogs. On the latest Java (1.7.0_51) with default security settings you should not be allowed to run webstart at all without this PR and signing, on older versions you should get a warning.

This will not work if the Java security settings have been changed to the highest level as there isn't an OCSP responder for checking whether the certificate has been revoked.

It's also worth seeing whether this can be built on one server and deployed on another. Codebase=* which in theory means it can run anywhere.

/cc @stick

[manics]

Example dialog:

[joshmoore]

Two questions to think about while deploying this:

• If we put the properties in etc/local.properties, will they show up anywhere in the CI logs?
• Are there any situations in which we'd want to reduce the permissions from all?

[manics]

Are there any situations in which we'd want to reduce the permissions from all?

The only other option is sandbox which would prevent uploading of local files, which I guess could be useful for a read-only system.

[manics]

I've changed build.xml and local.properties.example to use a password from a file, and added timestamping. PR description updated.

[bpindelski]

In general this works as expected. In particular, I do miss some output from the build.py invocations that delegate to jarsigner. At the moment I have to wait without seeing any output in the console and guess if Ant is stuck or doing something...

[bpindelski]

Also - this only works with jarsigner bundled with JDK 7. Something to watch out for if we decide to use it on the CI nodes.

[manics]

I get a jar signed. message for each jar, what output are you missing?

$ ./build.py release-webstart -Djarsign.keystore=/Volumes/ome/team/simon/code-signing/store.jks -Djarsign.alias=testcodesign -Djarsign.storepassfile=/Volumes/ome/team/simon/code-signing/store.passwd

...

webstart-sign:
jar signed.
jar signed.
jar signed.
jar signed.
...

this only works with jarsigner bundled with JDK 7.

I thought all our nodes use JDK7?

[bpindelski]

I get a jar signed. message for each jar, what output are you missing?

$ ./build.py release-webstart -Djarsign.keystore=/Volumes/ome/team/simon/code-signing/store.jks -Djarsign.alias=testcodesign -Djarsign.storepassfile=/Volumes/ome/team/simon/code-signing/store.passwd

...

webstart-sign:
jar signed.
jar signed.
jar signed.
jar signed.
...

I am not getting that output (Java 7u45). What's your JDK? Maybe I need to update to u51?

this only works with jarsigner bundled with JDK 7.

I thought all our nodes use JDK7?

I think so too, but that would be a question to Kenny.

[joshmoore]

Is there any use in keeping the old-style, ant-based commands for non-JDK7 users?

[manics]

$ java -version
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

I think the problem is that the -storepass:file option is a recent addition to jarsigner, so to support JDK6 I'd have to store the password in two places (as a string in local.properties.example and in a file), and add a conditional to detect the JDK version.

[sbesson]

Excluding. See http://ci.openmicroscopy.org/job/OMERO-5.0-merge-daily/570/

[manics]

Gretzky is still running java version "1.6.0_20"

[manics]

@sbesson @bpindelski
I've added the old signjar task back in, and made the new/old tasks dependent on whether the jarsign.storepassfile property is defined or not. Default is not set, so jarsign.storepass from local.properties.example will be used. Also added an echo task in the new task to output the name of the jar as it's signed.

This means a standard ./build.py release-webstart should be the same as before except that timestamping is enabled, for the new behaviour run the build commands in the PR description.

[sbesson]

👍 unexcluding

[bpindelski]

@manics Tested on Ubuntu with Oracle JDK 7u51. The release-webstart target works fine (although signing took 20 minutes - might be Linux weirdness). Now at least I got the output in the terminal.

[joshmoore]

Merging. If any performance issues are seen in the CI jobs we can come back to this.

For all the jobs on the JDK6 nodes, we'll likely need to configure explicit use of the XXXX fake password (/cc @sbesson)

[manics]

--rebased-to #2121

[manics]

Partial
--rebased-to #2238