JDK-8287190 : [macos] Add support for signing user provided app image
  • Type: CSR
  • Component: tools
  • Sub-Component: jpackage
  • Priority: P3
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 19
  • Submitted: 2022-05-24
  • Updated: 2022-06-03
  • Resolved: 2022-06-02
Related Reports
CSR :  
JDK-8286850 - [macos] Add support for signing user provided app image
Description
Summary
-------

Add support for signing predefined application image.

Problem
-------

In some cases user might want to do post processing on application image after it got generated and any changes to application image will invalidate signature. Signing process is complex and requires multiple steps: un-sign all content in app bundle if signed, sign executables, sign runtime and finally sign app bundle itself. Doing it manually by user is possible, but will require some effort, thus jpackage should provide ability to sign predefined application image.

Solution
--------

There will be no additional command line options introduced and current set of options will be used. Following command line options will be used to indicate that predefine application image needs to be sign:

    jpackage --type app-image --app-image Test.app --mac-sign [additional signing options]

Following options will be allowed if user specified "app-image" type, provided predefined application image and requested signing:

    --mac-package-signing-prefix
    --mac-signing-keychain
    --mac-signing-key-user-name
    --mac-entitlements
    --verbose

Specifying any other options not mentioned above when signing predefined application image is requested will result in unsupported option error thrown. Signing will happen in place and jpackage will not validate application image during or after signing to make sure that it is still valid and runnable image. It will be user responsibility to make sure that post processing did not broke application image. Already signed or partially signed application images will be supported and old signature will be completely removed before signing it with requested parameters. Signing predefine application image will be done in exactly same way as signing application image when it is generated. Generating DMG or PKG from predefined application image with signing enabled will not sign application image as it currently do. Windows and Linux are not affected by this change and they will still throw error if user attempts to specify "app-image" type and --app-image at same time.

Specification
-------------

Help text will add sample usage example:

    Sign the predefined application image:
        jpackage --type app-image --app-image <app-image> \
            --mac-sign [<additional signing options>...]
        Note: the only additional options that are permitted in this mode are:
              the set of additional mac signing options and --verbose

Description of --app-image option will change to:

    --app-image <directory path>
          Location of the predefined application image that is used
          to build an installable package or to sign the predefined
          application image
          (absolute path or relative to the current directory)

Description of --mac-sign option will change to:

    --mac-sign
          Request that the package or the predefined application image be
          signed.
Comments
Moving updated request to Approved.
02-06-2022
[~darcy] I added compatibility risk description. It solves listed problem by providing ability to jpackage to sign predefined application images after they were post processed by user. Doing any post processing on an application image will invalidate signature and make application invalid for Mac App Store or notarization.
01-06-2022
Moving to Provisional, not Approved. [~almatvee], please update the compatibility discussion to describe what is changed, including if any existing command line combinations are invalidated (doesn't sound like they are). How does the proposed change address the listed problems?
01-06-2022
So the use of `-t app-image --app-image <app-image>` is for the special case of "signing in place", and it A) requires `--mac-sign` and B) only permits the set of options specified in the Solution section. This seems fine then. Can you add the updated documentation that will inform the user of the valid options when using this mode to the Specification section? Unless there is a more natural place to describe the restriction, I recommend adding a note to the sample usage example shown by `jpackage --help`, something like this: ``` Sign the predefined application image: jpackage --type app-image --app-image <app-image> \ --mac-sign [<additional signing options>...] Note: the only additional options that are permitted in this mode are: the set of additional mac signing options and --verbose ```
26-05-2022
No, it will throw error that "-d" option is not supported. Only options listed in "Solution" section can be specified. I can add support for "-d" option as you describing it, but user can always make a copy of original app image if needed. No, it will not work without --mac-sign. On macOS it will throw error that --mac-sign is required if type is "app-image" and the predefined app image is provided. On Linux and Windows behavior stays same and following error is thrown: "Error: Option [--app-image] is not valid with type [app-image]".
24-05-2022
This seems like a useful feature. The new behaviors, including any limitations, should be documented in the command line options and examples, and maybe the man pages and packaging guide. Question: what happens in the following case? `jpackage -t app-image --mac-sign --app-image <app-image> -d <dest>` Does it create a new app-image in the destination, leaving the original untouched? That's what I would expect, meaning that only in the case where the dest is unspecified (or is the parent dir of the `<app-image>`) would it sign in place. Somewhat related to that, will the above work without the `--mac-sign` option? It doesn't seem very useful, but is there a reason to preclude it?
24-05-2022
1) Behavior will stay same. Currently in this case we will take app image as is (without doing any signing) and we will sign PKG. There is no need to sign DMG. I have following in solution section: "Generating DMG or PKG from predefined application image with signing enabled will not sign application image as it currently do." 2) Behavior will stay same. I assume you mean if --app-image is not specified, then user provides options to generate app image. In this case we will generate app image and sign it. After that we will generate PKG or DMG and sign PKG as well. There is no behavioral changes to any currently supported signing combinations. This enhancement adds new options combination "--type app-image and --app-image" which used to throw error as unsupported options combination before.
24-05-2022
It is unclear how jpackage will behave when building dmg/pkg with `--mac-sign` option. In particular, what will it do if 1) both `--mac-sign` and `--app-image` are specified 2) `--mac-sign` is specified and `--app-image` is not specified.
24-05-2022