#7 Merged at 97eb6c1
Repository
gammaproduction
Branch
default
Repository
infinitekind
Branch
default
Author
  1. Gerry Weißbach
Reviewers
Description

Documentation for the 'privileged' option.

Added an option to use JNLP files instead of the mainclassname. This circumvents problems with gatekeeper which does not allow direct execution of JNLP files - which can not be signed properly at the moment. But you have to sign the application. (see http://stackoverflow.com/questions/16958130/how-to-sign-dynamic-jnlp-files-for-osx-10-8-4-and-gatekeeper)

Comments (5)

  1. Sean Reilly

    Hi Gerry, there was another pull request recently that conflicted with yours. Would you mind pulling again to get your code up to date, merging, and re-submitting the pull request?

    Also, are you sure that it will be safe to launch code based on a JNLP file if that JNLP file isn't signed itself? It seems a bit like routing around the security system and losing its benefit.

    Thanks, Sean

  2. Gerry Weißbach author

    Ok, I merged the changes into my branch und updated the pull request.

    The problem I wanted to solve is that JNLP can not be signed (and then be modified). Modifying JNLP files is crucial to dynamic WebStart apps, such as several products of my company. Both Apple and Oracle have open rdars/tickets on the issue which is being discussed on SO and other platforms (see this stackoverflow question).

    Using appbundler you can now create an .app container that launches the JNLP file (first copies it to a temporary location) - it will also load updates of the JNLP automatically.

    As for security: You are right. Even if a a developer properly signs the .app with an Apple issued certificate. It's more like a workaround to have an app start instantly without bugging the user (every time he downloads the potentially same JNLP) - who is not a developer in most cases - that the JNLP can't be launched and the thing is not signed and so on. I personally think this is safe until Oracle or Apple come up with a better solution.

    Despite the security issues: I think for an end-user on a Mac this might be the most convenient solution. They simply download an app which they can permanently store in their Applications. If the app is signed properly (and the servers run on subsequent starts of the app ;) ) everything runs fine right out of the box.

  3. Sean Reilly

    I'm sorry it has taken so long to respond here. I'd like to merge your PR now but unfortunately I've left it so long that there are now conflicts. Would you mind resolving them and then update the PR and I'll merge it before taking any other action?

  4. Gerry Weißbach author

    Phu. No change in so many years.

    I once again merged with the original repository. This is due to a change in Java9 that will require a modification on the base code as well: Java changes the version schema and skips several numbers ahead: Java 9 has version "9", not "1.9" so the parsing will have to be modified.