There are a few issues with how jpackage signs bundles:
1. It signs additional launchers and all executables in the runtime: "Contents/Home/bin/java", "Contents/Home/bin/keytool", "Contents/Home/lib/libnet.dylib" (all dll-s in "Contents/Home/lib" folder). Why is that? These executables are supposed to be signed by a JDK vendor and should not be signed with the user's certificate.
2. jpackage runs codesign command on the bundle directory without entitlements. The default JDK's entitlements (see [1]) are:
```
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.security.cs.allow-dyld-environment-variables</key>
<true/>
<key>com.apple.security.cs.allow-jit</key>
<true/>
<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
<true/>
<key>com.apple.security.cs.debugger</key>
<true/>
<key>com.apple.security.cs.disable-library-validation</key>
<true/>
<key>com.apple.security.device.audio-input</key>
<true/>
</dict>
</plist>
```
The "com.apple.security.cs.disable-library-validation" key is critical for allowing the app launcher to load the "Contents/Home/lib/libjli.dylib" DLL from the runtime directory. However, it is not applied to the bundle, and thus, it is not applied to the main launcher. It is only applied to additional launchers. This has quite an unexpected outcome in the signing tests. Can run the additional launcher:
```
alexeysemenyuk-mac:jpackage-tests alexeysemenyuk$ ./SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/MacOS/testAL
jpackage test application
args.length: 0
hello: Output file: [jpackage-tests/appOutput.txt]
```
, but can not run the main launcher:
```
alexeysemenyuk-mac:jpackage-tests alexeysemenyuk$ ./SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/MacOS/SigningAppImageTest
dlopen(SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/runtime/Contents/Home/lib/libjli.dylib) failed. Error: dlopen(SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/runtime/Contents/Home/lib/libjli.dylib, 0x0001): tried: 'SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/runtime/Contents/Home/lib/libjli.dylib' (code signature in <D54A5AB8-88A5-32C5-BBDF-C9B3BF8F75E3> 'SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/runtime/Contents/Home/lib/libjli.dylib' not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs), '/System/Volumes/Preboot/Cryptexes/OSSigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/runtime/Contents/Home/lib/libjli.dylib' (no such file), 'SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/runtime/Contents/Home/lib/libjli.dylib' (code signature in <D54A5AB8-88A5-32C5-BBDF-C9B3BF8F75E3> 'SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/runtime/Contents/Home/lib/libjli.dylib' not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs)
```
"Contents/MacOS/SigningAppImageTest", "Contents/MacOS/testAL", and "Contents/runtime/Contents/Home/lib/libjli.dylib" are signed with the same ad-hoc certificate but they don't have a Team ID:
```
alexeysemenyuk-mac:jpackage-tests alexeysemenyuk$ codesign -dvv ./SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/MacOS/SigningAppImageTest
Executable=SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/MacOS/SigningAppImageTest
Identifier=Hello.Hello
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20500 size=1804 flags=0x10000(runtime) hashes=50+3 location=embedded
Signature size=6115
Authority=Developer ID Application: jpackage.openjdk.java.net (ö)
Timestamp=Jun 5, 2025 at 1:35:34 PM
Info.plist entries=16
TeamIdentifier=not set
Runtime Version=13.3.0
Sealed Resources version=2 rules=13 files=98
Internal requirements count=1 size=88
alexeysemenyuk-mac:jpackage-tests alexeysemenyuk$ codesign -dvv ./SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/MacOS/testAL
Executable=SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/MacOS/testAL
Identifier=Hello.testAL
Format=Mach-O thin (x86_64)
CodeDirectory v=20500 size=1933 flags=0x10000(runtime) hashes=50+7 location=embedded
Signature size=6114
Authority=Developer ID Application: jpackage.openjdk.java.net (ö)
Timestamp=Jun 5, 2025 at 1:35:28 PM
Info.plist=not bound
TeamIdentifier=not set
Runtime Version=13.3.0
Sealed Resources=none
Internal requirements count=1 size=88
alexeysemenyuk-mac:jpackage-tests alexeysemenyuk$ codesign -dvv ./SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/runtime/Contents/Home/lib/libjli.dylib
Executable=SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/runtime/Contents/Home/lib/libjli.dylib
Identifier=Hello.libjli
Format=Mach-O thin (x86_64)
CodeDirectory v=20500 size=941 flags=0x10000(runtime) hashes=24+2 location=embedded
Signature size=6115
Authority=Developer ID Application: jpackage.openjdk.java.net (ö)
Timestamp=Jun 5, 2025 at 1:35:29 PM
Info.plist=not bound
TeamIdentifier=not set
Runtime Version=13.3.0
Sealed Resources=none
Internal requirements count=1 size=88
```
Missing Team ID in the signatures causes the system to complain for the main launcher because it lacks the "com.apple.security.cs.disable-library-validation" key in the entitlements (entitlements are completely missing):
```
alexeysemenyuk-mac:jpackage-tests alexeysemenyuk$ codesign -d --entitlements - ./SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/MacOS/SigningAppImageTest
Executable=SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/MacOS/SigningAppImageTest
```
, while the system allows the additional launcher to run because it has this key:
```
alexeysemenyuk-mac:jpackage-tests alexeysemenyuk$ codesign -d --entitlements - ./SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/MacOS/testAL
Executable=SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/MacOS/testAL
[Dict]
[Key] com.apple.security.cs.allow-dyld-environment-variables
[Value]
[Bool] true
[Key] com.apple.security.cs.allow-jit
[Value]
[Bool] true
[Key] com.apple.security.cs.allow-unsigned-executable-memory
[Value]
[Bool] true
[Key] com.apple.security.cs.debugger
[Value]
[Bool] true
[Key] com.apple.security.cs.disable-library-validation
[Value]
[Bool] true
[Key] com.apple.security.device.audio-input
[Value]
[Bool] true
```
Missing the "Team ID" should not be an issue for the users, because they are likely to have it set in certificates issued by Apple. This issue only occurs with self-signed certificates used in jpackage tests.
Anyways, I believe app bundle should be signed with the entitlements so that they get applied to the main launcher. jpackage app launcher should have the same entitlements as the standard Java launcher [1] by default. This is not currently the case.
Data collected from running the "SigningAppImageTest.test(true, true, UNICODE_INDEX)" test.
The observed behavior is not a regression; jpackage has been like this for a long time.
[1] https://github.com/openjdk/jdk/blob/fe3be498b83e70a9f4739ddad6642c3aa04a97d3/make/data/macosxsigning/default.plist
1. It signs additional launchers and all executables in the runtime: "Contents/Home/bin/java", "Contents/Home/bin/keytool", "Contents/Home/lib/libnet.dylib" (all dll-s in "Contents/Home/lib" folder). Why is that? These executables are supposed to be signed by a JDK vendor and should not be signed with the user's certificate.
2. jpackage runs codesign command on the bundle directory without entitlements. The default JDK's entitlements (see [1]) are:
```
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.security.cs.allow-dyld-environment-variables</key>
<true/>
<key>com.apple.security.cs.allow-jit</key>
<true/>
<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
<true/>
<key>com.apple.security.cs.debugger</key>
<true/>
<key>com.apple.security.cs.disable-library-validation</key>
<true/>
<key>com.apple.security.device.audio-input</key>
<true/>
</dict>
</plist>
```
The "com.apple.security.cs.disable-library-validation" key is critical for allowing the app launcher to load the "Contents/Home/lib/libjli.dylib" DLL from the runtime directory. However, it is not applied to the bundle, and thus, it is not applied to the main launcher. It is only applied to additional launchers. This has quite an unexpected outcome in the signing tests. Can run the additional launcher:
```
alexeysemenyuk-mac:jpackage-tests alexeysemenyuk$ ./SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/MacOS/testAL
jpackage test application
args.length: 0
hello: Output file: [jpackage-tests/appOutput.txt]
```
, but can not run the main launcher:
```
alexeysemenyuk-mac:jpackage-tests alexeysemenyuk$ ./SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/MacOS/SigningAppImageTest
dlopen(SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/runtime/Contents/Home/lib/libjli.dylib) failed. Error: dlopen(SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/runtime/Contents/Home/lib/libjli.dylib, 0x0001): tried: 'SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/runtime/Contents/Home/lib/libjli.dylib' (code signature in <D54A5AB8-88A5-32C5-BBDF-C9B3BF8F75E3> 'SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/runtime/Contents/Home/lib/libjli.dylib' not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs), '/System/Volumes/Preboot/Cryptexes/OSSigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/runtime/Contents/Home/lib/libjli.dylib' (no such file), 'SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/runtime/Contents/Home/lib/libjli.dylib' (code signature in <D54A5AB8-88A5-32C5-BBDF-C9B3BF8F75E3> 'SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/runtime/Contents/Home/lib/libjli.dylib' not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs)
```
"Contents/MacOS/SigningAppImageTest", "Contents/MacOS/testAL", and "Contents/runtime/Contents/Home/lib/libjli.dylib" are signed with the same ad-hoc certificate but they don't have a Team ID:
```
alexeysemenyuk-mac:jpackage-tests alexeysemenyuk$ codesign -dvv ./SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/MacOS/SigningAppImageTest
Executable=SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/MacOS/SigningAppImageTest
Identifier=Hello.Hello
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20500 size=1804 flags=0x10000(runtime) hashes=50+3 location=embedded
Signature size=6115
Authority=Developer ID Application: jpackage.openjdk.java.net (ö)
Timestamp=Jun 5, 2025 at 1:35:34 PM
Info.plist entries=16
TeamIdentifier=not set
Runtime Version=13.3.0
Sealed Resources version=2 rules=13 files=98
Internal requirements count=1 size=88
alexeysemenyuk-mac:jpackage-tests alexeysemenyuk$ codesign -dvv ./SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/MacOS/testAL
Executable=SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/MacOS/testAL
Identifier=Hello.testAL
Format=Mach-O thin (x86_64)
CodeDirectory v=20500 size=1933 flags=0x10000(runtime) hashes=50+7 location=embedded
Signature size=6114
Authority=Developer ID Application: jpackage.openjdk.java.net (ö)
Timestamp=Jun 5, 2025 at 1:35:28 PM
Info.plist=not bound
TeamIdentifier=not set
Runtime Version=13.3.0
Sealed Resources=none
Internal requirements count=1 size=88
alexeysemenyuk-mac:jpackage-tests alexeysemenyuk$ codesign -dvv ./SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/runtime/Contents/Home/lib/libjli.dylib
Executable=SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/runtime/Contents/Home/lib/libjli.dylib
Identifier=Hello.libjli
Format=Mach-O thin (x86_64)
CodeDirectory v=20500 size=941 flags=0x10000(runtime) hashes=24+2 location=embedded
Signature size=6115
Authority=Developer ID Application: jpackage.openjdk.java.net (ö)
Timestamp=Jun 5, 2025 at 1:35:29 PM
Info.plist=not bound
TeamIdentifier=not set
Runtime Version=13.3.0
Sealed Resources=none
Internal requirements count=1 size=88
```
Missing Team ID in the signatures causes the system to complain for the main launcher because it lacks the "com.apple.security.cs.disable-library-validation" key in the entitlements (entitlements are completely missing):
```
alexeysemenyuk-mac:jpackage-tests alexeysemenyuk$ codesign -d --entitlements - ./SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/MacOS/SigningAppImageTest
Executable=SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/MacOS/SigningAppImageTest
```
, while the system allows the additional launcher to run because it has this key:
```
alexeysemenyuk-mac:jpackage-tests alexeysemenyuk$ codesign -d --entitlements - ./SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/MacOS/testAL
Executable=SigningAppImageTest/test.e1103956/output/SigningAppImageTest.app/Contents/MacOS/testAL
[Dict]
[Key] com.apple.security.cs.allow-dyld-environment-variables
[Value]
[Bool] true
[Key] com.apple.security.cs.allow-jit
[Value]
[Bool] true
[Key] com.apple.security.cs.allow-unsigned-executable-memory
[Value]
[Bool] true
[Key] com.apple.security.cs.debugger
[Value]
[Bool] true
[Key] com.apple.security.cs.disable-library-validation
[Value]
[Bool] true
[Key] com.apple.security.device.audio-input
[Value]
[Bool] true
```
Missing the "Team ID" should not be an issue for the users, because they are likely to have it set in certificates issued by Apple. This issue only occurs with self-signed certificates used in jpackage tests.
Anyways, I believe app bundle should be signed with the entitlements so that they get applied to the main launcher. jpackage app launcher should have the same entitlements as the standard Java launcher [1] by default. This is not currently the case.
Data collected from running the "SigningAppImageTest.test(true, true, UNICODE_INDEX)" test.
The observed behavior is not a regression; jpackage has been like this for a long time.
[1] https://github.com/openjdk/jdk/blob/fe3be498b83e70a9f4739ddad6642c3aa04a97d3/make/data/macosxsigning/default.plist
- duplicates
-
JDK-8361225 [macos] SigningAppImageTest fails to verify main launcher
-
- Closed
-
- relates to
-
JDK-8360507 JPKG002-006: SigningPackageTest: appOutput.txt cannot be found in user home directory and output doesn't contain: origin=Developer ID Application: jpackage.openjdk.java.net
-
- Resolved
-