8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions

[sashamatveev]

• It is not clear on which macOS versions codesign fails if application bundle contains additional content.
• As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
• This change is for macOS only.
• Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions (Bug - P3)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/21698/head:pull/21698
$ git checkout pull/21698

Update a local copy of the PR:
$ git checkout pull/21698
$ git pull https://git.openjdk.org/jdk.git pull/21698/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 21698

View PR using the GUI difftool:
$ git pr show -t 21698

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/21698.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back almatvee! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@sashamatveev The following label will be automatically applied to this pull request:

• core-libs

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.

[mlbridge]

Webrevs

• 00: Full (d964968c)

[alexeysemenyukoracle]

The test does nothing on OSX, right? We just run jpackage and don't verify the output. What is the point then?

How come this test does signing on OSX? I don't see how --mac-sign argument is configured.

[sashamatveev]

Test used to do nothing before this fix on macOS. Before we forced exit code to 1, jpackage failed and we did not verify anything. With new approach we will generate application image with additional content and test will verify that additional content exists in application image. Generating PKG and DMG is not possible due to potential failure of codesign. Also, it is unlikely that something can go wrong with PKG and DMG generation with additional content, since PKG and DMG does not really care about content of application image.

We always do code sign on macOS since sometime already. If --mac-sign is not specified we will do ad-hoc signing. If --mac-sign is specified we will do signing using certificates. ad-hoc signing does not use any identity, but it is required on latest macOS versions, otherwise application cannot be run.

[sashamatveev]

Another possible solution to codesign failure is to add additional CLI command to jpackage --mac-unsigned and if such option is specified we will not run ad-hoc codesign at all. It will produce completely unsigned image which is not very useful, but will avoid any such problems during testing.

[mlbridge]

Mailing list message from Michael Hall on core-libs-dev:

On Oct 25, 2024, at 4:36?PM, Alexander Matveev <almatvee at openjdk.org> wrote:

Generating PKG and DMG is not possible due to potential failure of codesign.

So these both still return the failing error code?

Are these changes only related to the test or do they apply somehow to normal usage?

I?m not sure what the additional files are. Extra files that go into the app directory? Or where do they go?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241025/18abb1ed/attachment.htm>

[sashamatveev]

So these both still return the failing error code?
Yes, jpackage will return failing error case.

Are these changes only related to the test or do they apply somehow to normal usage?
Change is for test only. Test will ignore jpackage error code. jpackage itself will work as before.

I?m not sure what the additional files are. Extra files that go into the app directory? Or where do they go?
Extra files will go to TestAppName.app/Contents.

[mlbridge]

Mailing list message from Michael Hall on core-libs-dev:

On Oct 25, 2024, at 7:31?PM, Alexander Matveev <almatvee at openjdk.org> wrote:

On Fri, 25 Oct 2024 21:55:58 GMT, Michael Hall <mik3hall at gmail.com> wrote:

So these both still return the failing error code?
Yes, jpackage will return failing error case.

Are these changes only related to the test or do they apply somehow to normal usage?
Change is for test only. Test will ignore jpackage error code. jpackage itself will work as before.

Thanks

I?m not sure what the additional files are. Extra files that go into the app directory? Or where do they go?
Extra files will go to TestAppName.app/Contents.

OK. I?m not sure how applications are accessing files here. Being able to have everything that?s in the input directory end up in the app directory I think would be able to serve the same purpose without needing an additional cli arg that requires special handling. Java apps can locate files there with a java option of something like, -Dapp.path=$APPDIR. Or figure it out from something in java.class.path. They could directly resource load from here if the app directory itself was in class path? I don?t remember if I enhancement requested that or not.

They would also, files in the app directory, all be automatically code signed I think wouldn?t they?

[sashamatveev]

Closing this PR. This issue will be fixed under new PR #21741.

[mlbridge]

Mailing list message from Alexander Matveev on core-libs-dev:

Hi Michael,

They would also, files in the app directory, all be automatically code signed I think wouldn?t they?

Yes, files under app directory will be signed as well.

Thanks,
Alexander

From: Michael Hall <mik3hall at gmail.com>
Date: Friday, October 25, 2024 at 5:52?PM
To: Alexander Matveev <almatvee at openjdk.org>
Cc: core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: RFR: 8342576: [macos] AppContentTest still fails after JDK-8341443 for same reason on older macOS versions

On Oct 25, 2024, at 7:31?PM, Alexander Matveev <almatvee at openjdk.org> wrote:

On Fri, 25 Oct 2024 21:55:58 GMT, Michael Hall <mik3hall at gmail.com> wrote:

So these both still return the failing error code?
Yes, jpackage will return failing error case.

Are these changes only related to the test or do they apply somehow to normal usage?
Change is for test only. Test will ignore jpackage error code. jpackage itself will work as before.

Thanks

I?m not sure what the additional files are. Extra files that go into the app directory? Or where do they go?
Extra files will go to TestAppName.app/Contents.

OK. I?m not sure how applications are accessing files here. Being able to have everything that?s in the input directory end up in the app directory I think would be able to serve the same purpose without needing an additional cli arg that requires special handling. Java apps can locate files there with a java option of something like, -Dapp.path=$APPDIR. Or figure it out from something in java.class.path. They could directly resource load from here if the app directory itself was in class path? I don?t remember if I enhancement requested that or not.

They would also, files in the app directory, all be automatically code signed I think wouldn?t they?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241028/c2d4e9e8/attachment.htm>

[mlbridge]

Mailing list message from Michael Hall on core-libs-dev:

On Oct 28, 2024, at 5:40?PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:

Hi Michael,

They would also, files in the app directory, all be automatically code signed I think wouldn?t they?
Yes, files under app directory will be signed as well.

Thanks,
Alexander

Sorry, I was going to leave it at this but did a little more googling out of curiosity.

https://bugs.openjdk.org/browse/JDK-8274717

https://bugs.openjdk.org/browse/JDK-8274346

I am sort of gathering that this might make more sense on other platforms?

Putting files in an application Contents directory doesn?t seem like a sound practice to me.

Are you aware of any actual use cases of this? Maybe someone has a situation where this makes sense on MacOS but I am still not thinking of any.

The app directory provides a way to do usual java resource loading. There is no such normal provision for accessing something off of an Application's Contents directory that I am aware of.

--mac-dmg-content makes perfect sense for dmg?s.

I am not really familiar with package installs maybe it works better there?

For an application ?app-image if you wanted to allow additional files I think they would be better off extermal to the application.

Maybe someplace like the ~/Library/Application\ Support directory.

Again maybe I?m missing something and this is commonly used functionality. If so, feel free to ignore this.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241028/43159d28/attachment-0001.htm>

[koppor]

Google directed me here. We updated from JDK23 to JDK24

We have

--app-content buildres/mac/jabrefHost.py

JDK23: Without any issue

JDK24:

"codesign" failed and additional application content was supplied via the "--app-content" parameter. Probably the additional content broke the integrity of the application bundle and caused the failure. Ensure content supplied via the "--app-content" parameter does not break the integrity of the application bundle, or add it in the post-processing step.
[10:08:52.963] Running /usr/bin/xcrun
[10:08:52.973] Command [PID: 9939]:
    /usr/bin/xcrun --help
[10:08:52.973] Output:
    Usage: xcrun [options] <tool name> ... arguments ...
    
    Find and execute the named command line tool from the active developer
    directory.
    
    The active developer directory can be set using `xcode-select`, or via the
    DEVELOPER_DIR environment variable. See the xcrun and xcode-select manual
    pages for more information.
    
    Options:
      -h, --help                  show this help message and exit
      --version                   show the xcrun version
      -v, --verbose               show verbose logging output
      --sdk <sdk name>            find the tool for the given SDK name
      --toolchain <name>          find the tool for the given toolchain
      -l, --log                   show commands to be executed (with --run)
      -f, --find                  only find and print the tool path
      -r, --run                   find and execute the tool (the default behavior)
      -n, --no-cache              do not use the lookup cache
      -k, --kill-cache            invalidate all existing cache entries
      --show-sdk-path             show selected SDK install path
      --show-sdk-version          show selected SDK version
      --show-sdk-build-version    show selected SDK build version
      --show-sdk-platform-path    show selected SDK platform path
      --show-sdk-platform-version show selected SDK platform version
[10:08:52.974] Returned: 0

Error: "codesign" failed with following output:
/var/folders/gn/rldh9pd93qg48089gvgb1gb80000gn/T/jdk.jpackage3854937683320166432/images/image-16322408788641963111/JabRef.app: replacing existing signature
/var/folders/gn/rldh9pd93qg48089gvgb1gb80000gn/T/jdk.jpackage3854937683320166432/images/image-16322408788641963111/JabRef.app: code object is not signed at all
In subcomponent: /private/var/folders/gn/rldh9pd93qg48089gvgb1gb80000gn/T/jdk.jpackage3854937683320166432/images/image-16322408788641963111/JabRef.app/Contents/***Host.py

Full example: at JabRef/jabref#13032

[alexeysemenyukoracle]

@koppor,

We had a very similar issue in one of jpackage tests when we tried to copy random files in the "Contents" directory. See a comment at AppContentTest.java#L62.

It turned out that you can have only "Info.plist" file in the "Contents" directory. Any other files should be placed in the "Contents/Resources" directory instead.

This aligns with Apple's recommendations for bundle directory structure - https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW19

jpackage is not quite compliant with these recommendations, as it places the Java runtime in the "Contents/runtime" directory and the application jar files in the "Contents/app" directory. The justification is that this is legacy behavior originating from the JFX's jpackager. Fortunately, this hasn't caused problems so far.

Bottom line: don't copy files or directories with periods (.) in their names to the "Contents" directory. Copy them to the "Contents/Resources" directory instead. Otherwise, codesign will fail.

[Siedlerchr]

This is unfortunate. However, then how do I add content to the app image before?
Our current workaround is to build an app-image only and then manually pack it but this misses the dmg background images and install instructions etc

https://github.com/JabRef/jabref/blob/97aaab58e3ab543a0f50097ee59e52504d99c786/.github/workflows/deployment.yml#L167-L178

[alexeysemenyukoracle]

This is unfortunate. However, then how do I add content to the app image before?

You can add custom app content to the app image, but be sure to copy it to the correct location.
You can have "Contents/Resources/jabrefHost.py", but you can not have "Contents/jabrefHost.py".

[alexeysemenyukoracle]

The workaround at workflows/deployment.yml doesn't look right, I'm surprised "codesign" works in the script. Maybe it runs on older macos with a permissive codesign version?

If you want to build app image and create pkg and dmg packages from it in separate steps, you can leverage jpackage's --app-image option for this.

1. Build unsigned app image:

jpackage --type app-image ... --dest build/distribution

2. Copy additional content to the app image:

cp buildres/mac/jabrefHost.py build/distribution/JabRef.app/Contents/Resources
cp -R buildres/mac/native-messaging-host build/distribution/JabRef.app/Contents/Resources

3. Create a signed PKG package:

jpackage --type pkg --mac-sign --app-image build/distribution/JabRef.app ...

4. Create a signed DMG package:

jpackage --type dmg --mac-sign --app-image build/distribution/JabRef.app ...

No explicit codesign, hdiutil, and productbuild invocations.
You can have "the dmg background images and install instructions etc".

[Siedlerchr]

Followed the stepa and built an unsigned image first and then signed the jpackage build and created the pkg/dmg files. However, notarization fails as it says it's not signed at all:

e.g.:

  "path": "JabRef-6.0_arm64.dmg/JabRef.app/Contents/MacOS/JabRef",

  "message": "The binary is not signed with a valid Developer ID certificate.", 

notarylog.log

Testing now with a presigned image.

[Siedlerchr]

When supplying mac sign to building the image, it does not work either and then applying.
The current branch is here in this PR JabRef/jabref#13032

And now I remember that probably this was the initial reason for using the original approach mentioned earlier with specifcying the app content

  "severity": "error",
      "code": null,
      "path": "JabRef-6.0_arm64.dmg/JabRef.app/Contents/MacOS/JabRef",
      "message": "The signature of the binary is invalid.",
      "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087735",
      "architecture": "arm64"
    }

[alexeysemenyukoracle]

And now I remember that probably this was the initial reason for using the original approach mentioned earlier with specifcying the app content

This means the two-stage packaging with signing is completely broken in jpackage. The output can not be notarized. I suspect the same applies to one-stage packaging also. Not good. Can you share jpackage logs?

[Siedlerchr]

From the GitHub actions run with double signing: (mac os 14 runner)
jpackage Log starts at Creating app package: JabRef.app

signed_image_signed_dmg_macOS (ARM64) installer and portable version.txt

Run with only signing the pkg/dmg:
only signing dmg_macOS (ARM64) installer and portable version.txt

[alexeysemenyukoracle]

It looks like jpackage sign bundles in a way that they can not be notarized.

[alexeysemenyukoracle]

@sashamatveev can you comment?

[sashamatveev]

Not sure what is going on. I tried generating app-image with signing modifying it and then generating DMG with --mac-sign and application image is signed correctly. I did not tried to notarize it.

When DMG is mounted what is output of codesign --display -vvvv /Volumes/JabRef-6.0_arm64.dmg/JabRef.app?

Also from provided logs:

2025-05-02T17:19:25.6911920Z     /usr/bin/codesign -s Developer ID Application: JabRef e.V. (6792V39SK3) -vvvv --timestamp --options runtime --prefix org.*** --entitlements buildres/mac/***.entitlements --force build/distribution/JabRef.app/Contents/runtime

buildres/mac/***.entitlements -> "***" does not look right.

[alexeysemenyukoracle]

"***" does not look right.

This is just a mask to hide the real value.

I did not tried to notarize it.

Well, the problem is with notarization. Signing in jpackage passed. But looks like it produces a bundle that can not be notarized.

[mlbridge]

Mailing list message from Michael Hall on core-libs-dev:

I had successfully notarized a jpackage app sometime back. As I remember it was a rather involved process where you had to be online to an Apple server?
I still have it in the build for one application but offline it does always fail.

This might be from when I did that
https://developer.apple.com/forums/thread/124614
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250502/3dfd4081/attachment.htm>

[sashamatveev]

It might be possible that "codesign --display -vvvv" does not check signature well enough as notarization. If I am reading issue correctly signed app-image is being generated, then it will be post-process and then it is used to generate DMG. See JabRef/jabref#13032. In this case we will package app-image as is since we will assume it is signed. See JDK-8293462. My suggestion is to generate unsigned image if post-processing is required or sign application image separately after it was modified. See JDK-8286850.

[Siedlerchr]

I managed to get it working now.

1. Build a signed app image with --mac-sign
2. Add the addtional content
3. re-sign the content manually with

          # Sign the final artifact
          codesign --force --deep --sign "Developer ID Application: JabRef e.V. (6792V39SK3)" \
            --entitlements buildres/mac/jabref.entitlements \
            --options runtime --timestamp build/distribution/JabRef.app

4. build a signed dmg/pkg
5. Notarization works now but only for macOS 14 arm

[mlbridge]

Mailing list message from Michael Hall on core-libs-dev:

3. re-sign the content manually with

     \# Sign the final artifact
     codesign \-\-force \-\-deep \-\-sign \"Developer ID Application\: JabRef e\.V\. \(6792V39SK3\)\" \\
       \-\-entitlements buildres\/mac\/jabref\.entitlements \\
       \-\-options runtime \-\-timestamp build\/distribution\/JabRef\.app

Possibly I missed something if this was the fix.

I don?t remember any issues with the existing signing when I tried notarization.

I do see?

--deep (DEPRECATED for signing as of macOS 13.0)

When I man codesign.

I?m also a little curious how you came up with the ?options runtime. I?m not familiar and even after looking at the man I?m not quite sure what it's purpose is. Make the requirements extra strict exempted by entitlements maybe?

Also why you decided to use ?timestamp?

I looked to see if jpackage uses any options like this but verbose output only shows codesign being invoked, many times, and not with what parameters.

If this is sufficient, or required, for a valid, notarizable application, maybe jpackage could be simplified to just do an invocation like yours at the end rather than the numerous invocations it appears to do.

[Siedlerchr]

Jpackage does include the options as well from the logs:

2025-05-02T17:19:25.6907840Z [17:19:12.379] Preparing Info.plist: /Users/runner/work/***/***/jabgui/build/distribution/JabRef.app/Contents/Info.plist.
2025-05-02T17:19:25.6908750Z [17:19:12.383] Using custom package resource [Application Info.plist] (loaded from Info.plist).
2025-05-02T17:19:25.6909590Z [17:19:12.388] Using custom package resource [Java Runtime Info.plist] (loaded from Runtime-Info.plist).
2025-05-02T17:19:25.6910240Z [17:19:23.350] Running /usr/bin/codesign
2025-05-02T17:19:25.6910740Z [17:19:24.530] Command [PID: 6752]:
2025-05-02T17:19:25.6911920Z     /usr/bin/codesign -s Developer ID Application: JabRef e.V. (6792V39SK3) -vvvv --timestamp --options runtime --prefix org.*** --entitlements buildres/mac/***.entitlements --force build/distribution/JabRef.app/Contents/runtime
2025-05-02T17:19:25.6912950Z [17:19:24.530] Output:
2025-05-02T17:19:25.6914200Z     build/distribution/JabRef.app/Contents/runtime: replacing existing signature
2025-05-02T17:19:25.6915140Z     build/distribution/JabRef.app/Contents/runtime: signed bundle with Mach-O thin (arm64) [com.oracle.java.JabRef]
2025-05-02T17:19:25.6915990Z [17:19:24.530] Returned: 0
2025-05-02T17:19:25.6916510Z [17:19:24.530] Running /usr/bin/codesign
2025-05-02T17:19:25.6917100Z [17:19:25.655] Command [PID: 6759]:
2025-05-02T17:19:25.6918000Z     /usr/bin/codesign -s Developer ID Application: JabRef e.V. (6792V39SK3) -vvvv --timestamp --options runtime --prefix org.*** --entitlements buildres/mac/***.entitlements --force build/distribution/JabRef.app
2025-05-02T17:19:25.6918880Z [17:19:25.656] Output:
2025-05-02T17:19:25.6919430Z     build/distribution/JabRef.app: replacing existing signature
2025-05-02T17:19:25.6920230Z     build/distribution/JabRef.app: signed app bundle with Mach-O thin (arm64) [org.***JabRef]
2025-05-02T17:19:25.6920880Z [17:19:25.656] Returned: 0
2025-05-02T17:19:25.6921160Z 
2025-05-02T17:19:25.6921510Z [17:19:25.656] Succeeded in building Mac Application Image package
2025-05-02T17:19:36.0557030Z Warning: Support for per-user configuration of the installed application will not be supported due to missing "build/distribution/JabRef.app/Contents/app/.package" in predefined signed application image.

After creating the app image we put additional content in it under Resources. That probably affects the integrity? of the whole stuff

Runtime options is for Hardened Runtime https://developer.apple.com/documentation/security/hardened-runtime
which allows specifying exclusions like jit in the entitlements

Timestamp is also required https://developer.apple.com/documentation/security/resolving-common-notarization-issues#Include-a-secure-timestamp

Otherwise, notarization fails with no timestamp or invalid timestamp.

Deep is like going recursively through the files. But should be avoided. I will try without as well

To upload a macOS app to be notarized, you must enable the Hardened Runtime capability. For more information about notarization, see Notarizing macOS software before distribution.

[mlbridge]

Mailing list message from Michael Hall on core-libs-dev:

On May 3, 2025, at 10:33?AM, Christoph <duke at openjdk.org> wrote:

On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

- It is not clear on which macOS versions codesign fails if application bundle contains additional content.
- As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
- This change is for macOS only.
- Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.

Jpackage does include the options as well from the logs:

Not for me with

${PACKAGER} \
--verbose \
--jlink-options '--strip-debug --no-man-pages --no-header-files' \
--input input \
--icon GenericApp.icns \
--resource-dir resources \
--name HalfPipe \
--type "dmg" \
--main-jar halfpipe.jar \
--main-class us.hall.hp.common.LoaderLaunchStub \
--module-path '/Users/mjh/Documents/javafx-jmods-21.0.1:mods' \
--add-modules javafx.swing,javafx.graphics,javafx.controls,us.hall.eio,org.openjdk.nashorn,java.compiler,java.desktop,java.logging,java.management,jdk.management.agent,java.prefs,java.se,java.rmi,java.scripting,java.sql,java.xml,jdk.attach,jdk.jshell,jdk.crypto.ec,jdk.jdeps,jdk.jcmd,jdk.zipfs,jdk.jfr \
--java-options '-Xmx1024m -XX:+UnlockDiagnosticVMOptions --add-opens java.desktop/javax.swing.text=ALL-UNNAMED --enable-preview -Djdk.attach.allowAttachSelf=true -XX:+UseG1GC -XX:MaxGCPauseMillis=50 --enable-native-access=ALL-UNNAMED -Djava.nio.file.spi.DefaultFileSystemProvider=us.hall.trz.osx.MacFileSystemProvider --add-opens=java.base/java.lang=ALL-UNNAMED --add-exports java.base/java.lang=ALL-UNNAMED --add-exports org.openjdk.nashorn/org.openjdk.nashorn.tools=ALL-UNNAMED -Dapp.path=$APPDIR -Djava.security.policy=$APPDIR/all.policy -Dapple.laf.useScreenMenuBar=true -Dapple.awt.application.name=HalfPipe -Dconsole=pane' \
--mac-package-identifier "us.hall.HalfPipe" \
--mac-sign \
--mac-signing-key-user-name "$SIGNING_CERT" \
--mac-entitlements "entitlements.xml" \
--mac-dmg-content additional/src.zip,additional/Half-Pipe.pdf

All I see are the

[10:05:03.044] Running /usr/bin/codesign

After creating the app image we put additional content in it under Resources. That probably affects the integrity? of the whole stuff

**Runtime** options is for Hardened Runtime https://developer.apple.com/documentation/security/hardened-runtime
which allows specifying exclusions like jit in the entitlements

**Timestamp** is also required https://developer.apple.com/documentation/security/resolving-common-notarization-issues#Include-a-secure-timestamp

Otherwise, notarization fails with no timestamp or invalid timestamp.

**Deep** is like going recursively through the files. But should be avoided. I will try without as well

To upload a macOS app to be notarized, you must enable the Hardened Runtime capability. For more information about notarization, see [Notarizing macOS software before distribution](https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution).

Hardened runtime sounds sort of familiar, it?s been a while. Other requirements might of changed.

[mlbridge]

Mailing list message from Michael Hall on core-libs-dev:

On May 3, 2025, at 10:49?AM, Michael Hall <mik3hall at gmail.com> wrote:

On May 3, 2025, at 10:33?AM, Christoph <duke at openjdk.org> wrote:

On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

- It is not clear on which macOS versions codesign fails if application bundle contains additional content.
- As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
- This change is for macOS only.
- Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.

Jpackage does include the options as well from the logs:

Not for me with

Sorry missed it.

/usr/bin/codesign -s Developer ID Application: Michael Hall (5X6BXQB3Q7) -vvvv --timestamp --options runtime --prefix us.hall.hp.common. --entitlements entitlements.xml --force /var/folders/mp/64527rf1501726r7t53qpx0w0000gn/T/jdk.jpackage8582845157994500039/images/image-17727033358038913514/HalfPipe.app

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250503/c021f2fe/attachment.htm>

[mlbridge]

Mailing list message from Michael Hall on core-libs-dev:

On May 3, 2025, at 10:49?AM, Michael Hall <mik3hall at gmail.com> wrote:

**Deep** is like going recursively through the files. But should be avoided. I will try without as well

There was something in the man about behavior when using deep in combination with force. I?m not sure what eliminating one will do.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250503/036eb9d2/attachment.htm>

[alexeysemenyukoracle]

After creating the app image we put additional content in it under Resources. That probably affects the integrity? of the whole stuff

Right, if you modify the app image, you need to resign it. I'm glad you figured out a workaround. But ideally, you should be able to pass additional content to jpackage with --app-content, and it should produce a notarizable signed app image without extra steps on the user's side. Unfortunately, it doesn't.

[alexeysemenyukoracle]

So the takeaway from this fruitful discussion is:

• jpackage doesn't produce helpful verbose signing output. Filed JDK-8356116
• jpackage doesn't produce a notarizable app image if --app-content is used. Filed JDK-8356117

[Siedlerchr]

jpackage doesn't produce a notarizable app image if --app-content is used. Filed JDK-8356117

Actually, this is a regression as it worked in JDK23 where we just used it recently
https://github.com/JabRef/jabref/blob/6d0d78716893cc09577a957d111d62ba2dfbefd0/.github/workflows/deployment-arm64.yml#L115-L126

Just changing from 23 to 24 led to this error as reported by @koppor earlier in this thread
#21698 (comment)

The binaries of the release were successfully notarized both on macOS13 and macOS14 (About dialog of JabRef shows the jdk version used as well, 23.0.1)
https://github.com/JabRef/jabref/releases/tag/v6.0-alpha2

[mlbridge]

Mailing list message from Michael Hall on core-libs-dev:

On May 3, 2025, at 3:58?PM, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

On Fri, 25 Oct 2024 01:49:01 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

- It is not clear on which macOS versions codesign fails if application bundle contains additional content.
- As a result test was modified to generate only application image, since PKG or DMG cannot be generated if signing fails. Exit code of jpackage is ignored, but generated application image will be checked for additional content.
- This change is for macOS only.
- Previous implementation of test (forcing expected exist code to 1) was not doing anything useful, since we never checked if additional content was copied or not.

So the takeaway from this fruitful discussion is:
- jpackage doesn't produce helpful verbose signing output. Filed [JDK-8356116](https://bugs.openjdk.org/browse/JDK-8356116)

I was mistaken on this. The codesign parameters appear to be shown once. Then there are many messages indicating just that codesign is being run.
If the same parameters are always used indicating the parameters for each message probably isn?t needed.

I may of missed this as well. I thought the original poster indicated that changing the signing parameters somehow gave them a fix.
If so, and doing it only once works, all the additional codesign?s that jpackage seems to do might not be necessary?
Although if his fix depended on using ?deep that currently shows as deprecated in the man page.

I would think that only executable content would need signing? ?app-content I don?t think adds anything for that.
If it doesn?t break signing, and I see there is a SigningOptionsTest that appears to include it, I wouldn?t think it would break notarization either.

But I don?t know. Other than testing some time back I don?t notarize.

[alexeysemenyukoracle]

Just changing from 23 to 24 led to this error as reported by @koppor earlier in this thread
#21698 (comment)

This looks like a regression, but it is not. You use --app-content buildres/mac/jabrefHost.py, which will add the "jabrefHost.py" file to the "Contents" directory of the app image. "jabrefHost.py" file should not be at this location, regardless of the version of jpackage. Explanation - #21698 (comment). It should be in the "Contents/Resources" directory instead, so the app content arguments should be --app-content buildres/mac/Resources/jabrefHost.py. Can you please try it?

[alexeysemenyukoracle]

If the same parameters are always used indicating the parameters for each message probably isn?t needed.

The same parameters don't need to be logged, but having the complete list of files signed by jpackage in the log would be good. We don't have it now.

I see there is a SigningOptionsTest that appears to include it

This is a negative test; it configures jpackage to exit with an error. Not very helpful in the context of this discussion

[Siedlerchr]

Just tried it with putting the additional files into the Resources folder. Same error as originally reported.

Run: https://github.com/JabRef/jabref/actions/runs/14823769155/job/41614205909

Changes from PR: https://github.com/JabRef/jabref/pull/13032/files#diff-5a17873aec4eae6b52b00959d8f9e17672912858f63181d39de8c3a713e90018R135-R144

"codesign" failed and additional application content was supplied via the "--app-content" parameter. Probably the additional content broke the integrity of the application bundle and caused the failure. Ensure content supplied via the "--app-content" parameter does not break the integrity of the application bundle, or add it in the post-processing step.


Error: "codesign" failed with following output:
/var/folders/hn/k7g0_sh57112t0xtjxcjcm5r0000gn/T/jdk.jpackage2295206181121069675/images/image-11269735772913219400/JabRef.app: replacing existing signature
/var/folders/hn/k7g0_sh57112t0xtjxcjcm5r0000gn/T/jdk.jpackage2295206181121069675/images/image-11269735772913219400/JabRef.app: code object is not signed at all
In subcomponent: /private/var/folders/hn/k7g0_sh57112t0xtjxcjcm5r0000gn/T/jdk.jpackage2295206181121069675/images/image-11269735772913219400/JabRef.app/Contents/***Host.py
[17:58:51.622] java.io.IOException: Command [/usr/bin/codesign, -s, Developer ID Application: JabRef e.V. (6792V39SK3), -vvvv, --timestamp, --options, runtime, --prefix, org.***, --entitlements, buildres/mac/***.entitlements, --force, /var/folders/hn/k7g0_sh57112t0xtjxcjcm5r0000gn/T/jdk.jpackage2295206181121069675/images/image-11269735772913219400/JabRef.app] exited with 1 code
	at jdk.jpackage/jdk.jpackage.internal.Executor.executeExpectSuccess(Executor.java:90)
	at jdk.jpackage/jdk.jpackage.internal.IOUtils.exec(IOUtils.java:125)
	at jdk.jpackage/jdk.jpackage.internal.MacAppImageBuilder.runCodesign(MacAppImageBuilder.java:740)
	at jdk.jpackage/jdk.jpackage.internal.MacAppImageBuilder.signAppBundle(MacAppImageBuilder.java:907)
	at jdk.jpackage/jdk.jpackage.internal.MacAppImageBuilder.doSigning(MacAppImageBuilder.java:414)
	at jdk.jpackage/jdk.jpackage.internal.MacAppImageBuilder.prepareApplicationFiles(MacAppImageBuilder.java:365)
	at jdk.jpackage/jdk.jpackage.internal.AppImageBundler.createAppBundle(AppImageBundler.java:189)
	at jdk.jpackage/jdk.jpackage.internal.AppImageBundler.execute(AppImageBundler.java:93)
	at jdk.jpackage/jdk.jpackage.internal.MacBaseInstallerBundler.prepareAppBundle(MacBaseInstallerBundler.java:201)
	at jdk.jpackage/jdk.jpackage.internal.MacDmgBundler.bundle(MacDmgBundler.java:83)
	at jdk.jpackage/jdk.jpackage.internal.MacDmgBundler.execute(MacDmgBundler.java:579)
	at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:707)
	at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:554)
	at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:92)
	at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:53)

[mlbridge]

Mailing list message from Michael Hall on core-libs-dev:

On May 4, 2025, at 1:12?PM, Christoph <duke at openjdk.org> wrote:

In subcomponent: /private/var/folders/hn/k7g0_sh57112t0xtjxcjcm5r0000gn/T/jdk.jpackage2295206181121069675/images/image-11269735772913219400/JabRef.app/Contents/***Host.py

If this is the current error log the file ***Host.py (? Strange file name.) doesn?t seem to be in the resource directory but the Contents directory still?

But I?ve been off on this a couple times already.

Still curious do all the codesign running messages in verbose output indicate multiple invocations or are they the status for a single running process?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250504/0fb54e02/attachment.htm>

[alexeysemenyukoracle]

In the log:

In subcomponent: /private/var/folders/hn/k7g0_sh57112t0xtjxcjcm5r0000gn/T/jdk.jpackage2295206181121069675/images/image-11269735772913219400/JabRef.app/Contents/***Host.py

The command line:

jpackage \
  ...
  --app-content buildres/mac/Resources/***Host.py \
  --app-content buildres/mac/Resources/native-messaging-host \

--app-content values are wrong. My bad, I gave you incorrect instructions. It should be a single "--app-content buildres/mac" option. This way, jpackage will copy both the "jabrefHost.py" file and the "native-messaging-host" directory into the "Contents/Resources" directory in the app bundle. This should make codesign work.

You can have multiple --app-content on the jpackage command line, but on macOS, the value should be a directory with the "Resources" subdirectory (or any other directory that is valid in the "Contents" directory of the app bundle). Otherwise, codesign will keep failing.

[Siedlerchr]

Thanks all for your support, with a single app-content parameter and the resource directory this worked with codesign and even notarization worked on both macOS13 and macOS14 (arm)
It would be great if you document this in the manual/help

[alexeysemenyukoracle]

Filed JDK-8356218 to follow up with the documentation