Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8358723

jpackage signing issues: redundant codesign invocations; the main launcher doesn't have entitlements

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: P3 P3
    • 26
    • 17, 21, 24, 25
    • tools
    • generic
    • os_x

      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

            asemenyuk Alexey Semenyuk
            asemenyuk Alexey Semenyuk
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: