-
Notifications
You must be signed in to change notification settings - Fork 6.1k
8271868: Warn user when using mac-sign option with unsigned app-image. #5004
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
👋 Welcome back herrick! A progress list of the required criteria for merging this PR into |
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
--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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitpicking: typo "allready" -> "already"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will fix this spelling error
@andyherrick This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. 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. ➡️ To integrate this PR with the above commit message to the |
/integrate |
Going to push as commit 0aca4f7.
Your commit was automatically rebased without conflicts. |
@andyherrick Pushed as commit 0aca4f7. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/5004/head:pull/5004
$ git checkout pull/5004
Update a local copy of the PR:
$ git checkout pull/5004
$ git pull https://git.openjdk.java.net/jdk pull/5004/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 5004
View PR using the GUI difftool:
$ git pr show -t 5004
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/5004.diff