如何为OSX和Gatekeeper签署（动态）JNLP文件

Question

My company produces Java Applications for Servers and delivers JNLP files to start local Applications. Since OSX 10.8.4 it is required to sign JNLP files with a Developer ID to keep Gatekeeper happy (it's actually in the release notes at the very bottom).

The question is: how to accomplish this? AFAIK you can sign Apps (we have some Java Apps signed with Developer IDs) - but JNLP - Files are just that: files.

Next: how to do this with generated JNLP files. We have to modify them as they come from a server - eg properties, base URL and so forth.

AFAIK Java has a certain mechanism to say JNLP files are signed via their respective JAR file (the one that holds the main class) - but: Jar files are signed with a different certificate they will not satisfy Gatekeeper as well.

I did find one reference on how to sign tools and stuff , but it does not apply the scenario of dynamic files.

What I do not want as answers: Right-Click and Open to override the Gatekeeper or change the System- or Java settings. This is not an option.

[UPDATE] Since OSX 10.9.5 you also have to sign using OSX 10.9+ and have valid version 2 signatures. How will this be done?

Answer 1

I think I found a solution. The only one I can currently think up. We basically need to wrap the JNLP with a custom app launcher, sign the app, make sure we can modify the JNLP on the fly on a server and then have it run.

As you may be aware, there is an app bundler project which can wrap up any JAR files into an OSX executable. This can be signed, delivered and will not fail Gatekeeper. I made a custom fork (which is up for a pull int o the main fork) that can take an JNLP file, wrap it up and you have a custom application doing just all the stuff a JNLP should do.

A Requirement is, however, that you do have a valid "Developer ID Application" certificate

1. Head over to bitbucket.org and download the current version
2. Run the ant task and build the appbundler package.
3. Have a look at the documentation for an example build script that will create the app container.
   • The example does not include the JNLP into the application right now.
   • The applications signature is created in a way so that the JNLP file can be modified later.
   • The application is being put into a zip file. This is important for downloading an application since they are only directories
4. Create your server code. Load the ZIP file, put the JNLP File into the directory <yourapp>.app/Contents/Java/
5. Deliver the zip file.

Now, if everything went fine, the zip file should automatically be unpacked in the Download folder and you should see your application icon. If you really made no mistake, you can execute the application as if it was a normal one.

I hope this will help a lot of developers fixing the broken JNLP behavior with OSX.

[UPDATE for modifiable JNLPs] Since OSX 10.9.5 it is required to have valid version 2 signatures on your app. This means that it the trick that was previously used by the app bundler (set a resource list file) does not work anymore. Everything and anything has to be signed now and it is virtually impossible to change the signed app afterwards.

I did however find a way: Use the app bundler. Set the JNLP to a file inside the Contents/_CodeSignature directory. Do not yet copy your modifiable JNLP in there but do this eg using Java later on when patching the zip (you'll need some code here anyway).

Please note: this should really only be needed if you have to put another JNLP file dynamically into the app container (thats is what the questions was about)

UPDATE (08-2017)

Oracle will be releasing Java 9 by the end of September. The appbundler does not handle the java9 vm correctly. They changed a whole lot of the API and the way that javaws works. For I need to say: stick with java8 if you want to use wrapped JNLP apps.

Answer 2

We've been able to determine that you can sign a jnlp file with codesign, using the "Developer ID Application" Certificate, like this:

codesign -f -s "Developer ID Application: " foo.jnlp

The result from this operation seems to pass Gatekeeper on the local machine. However, it seems like the signature gets stored as extended HFS attributes, and as a result, it is not transmitted if a user fetches the file from a HTTP transaction.

It might work if you took the .jnlp file, and packaged it in some kind of container, like a .dmg or maybe a .tar.gz, however, that's both a lot of work, and it provides a fairly challenging user experience.

Answer 3

From an email thread with Apple tech support, it seems the official word is to use the xip tool to work around the reliance on HFS extended attributes with codesign :

Instead of codesign, use xip (pronounced "chip") to create a signed archive of your JNLP file. Provide your Developer ID Installer identity as the argument to the --sign option, not your Developer ID Application identity.

A xip archive is essentially a signed zip archive so it can be served over the Internet in the same way as a zip archive. It will be unarchived automatically on the client Mac.

https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/xip.1.html

From my experimentation the xip tool always generates an archive with the jnlp contained in a folder when unxip'd.

Answer 4

Just to summarise the discussion; currently there is no existing solution on how to come around this.

This means that end users cannot launch an application via JNLP easily. Basically one needs to tell the user to Right-Click and Open to override the Gatekeeper.

The other solution would be to make an signed Mac application and have users install that via disk image.

Answer 5

Would it work to bundle a simple executable shell script called something like "myapp" in a signed .dmg which looks like this:

javaws http://path/to/my/app.jnlp

that way you can change the .jnlp however you like without changing your .dmg . I don't have an Apple Developer ID, so I can't try it myself right now.