8271868: Warn user when using mac-sign option with unsigned app-image. #5004
Conversation
|
|
openjdk
bot
changed the title
|
@andyherrick The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
| // if signing bundle with app-image, warn user if app-image | ||
| // is not allready signed. | ||
| Path launcher = applicationImage.resolve("Contents/MacOS") | ||
| .resolve(APP_NAME.fetchFrom(params)); |
There was a problem hiding this comment.
As far as I remember launcher can be signed, but entire app image might not be signed. So, in this case check will pass, but notarization will fail. I think we should run check on app image itself.
There was a problem hiding this comment.
jpackage will either copy the launcher from resource unmodified and unsigned, or sign all the sign-able elements in the app-image (including the launcher).
| public static boolean isFileSigned(Path file) { | ||
| try { | ||
| IOUtils.exec(new ProcessBuilder("/usr/bin/codesign", | ||
| "--verify", file.toString())); |
There was a problem hiding this comment.
--deep should be added, so check is run on nested frameworks and helpers.
|
What if we save "signed/not signed" flag in ".jpackage.xml" when building app image and read its value instead of guessing if they signed app image or not using |
|
I think it will not work. User might modify app image after it was created and it will invalidate signature. |
|
What options exist for building a package from app image with invalid signature? |
|
The purpose of this change is to catch the case (and emit a warning) when user creates an app-image w/o using --mac-sign, and then uses that app image to build a pkg or dmg bundle using --mac-sign. For this purpose, checking if the main launcher is signed is sufficient. There is no reason to check all the executables, libraries, and/or Frameworks in the app image., and there is no such thing as signing the app-image itself, also using --deep arg to codesigner is specifically recommended against in all codesigner documentation I have read. The alternative of recording if the app-image was created with --app-sign in the AppImageFile is a reasonable alternative to verifying the signing of the main launchers |
|
First of all why we only want to cover case when app-image was produced without --mac-sign? If we want to cover such case only, then we need to use approach suggested by Alexey and record signing flag in .jpackage.xml. Otherwise, user will receive false warning if unsigned app-image is provided which was generated without using jpackage or in case if app-image was modified after it was generated and signed. |
|
My understanding of this enhancement is to warn user when app image created without --mac-sign is used in building a signed package. I.e. to warn user they misused --mac-sign option. We don't want to check the quality of app image and its suitability for packaging in signed package as a part of this enhancement. For this limited scope checking the value of signing flag recorded in .jpackage.xml seems reasonable approach. |
|
now recording in AppImageFile if signing used to create the app-image, and showing warning only if signing an app using an app-image that is not so recorded as signed. |
| if (Optional.ofNullable( | ||
| SIGN_BUNDLE.fetchFrom(params)).orElse(Boolean.FALSE)) { | ||
| // if signing bundle with app-image, warn user if app-image | ||
| // is not allready signed. |
There was a problem hiding this comment.
nitpicking: typo "allready" -> "already"
There was a problem hiding this comment.
will fix this spelling error
|
@andyherrick This change now passes all automated pre-integration checks. After integration, the commit message for the final commit will be: You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 29 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.
|
|
/integrate |
|
Going to push as commit 0aca4f7.
Your commit was automatically rebased without conflicts. |
|
@andyherrick Pushed as commit 0aca4f7. |
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/5004/head:pull/5004$ git checkout pull/5004Update a local copy of the PR:
$ git checkout pull/5004$ git pull https://git.openjdk.java.net/jdk pull/5004/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 5004View PR using the GUI difftool:
$ git pr show -t 5004Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/5004.diff
The text was updated successfully, but these errors were encountered: