How to sign (dynamic) JNLP files for OSX and Gatekeeper

纵然是瞬间 提交于 2019-11-27 20:07:16

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 e.g. 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.

Steve Kann

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.

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.

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.

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.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!