jpackage codesign exit code 1 already signed

Question

This months macos java app build failed saying codesign returned 1 signing libnet.dylib Taking a copy of libnet.dylib and attempting the same codesign command as jpackage it says Already Signed.

This is one of those apparent "worked fine last month and changed nothing" scenarios. Yes the app java source code has changed, but the build script hasn't, nor has the jdk version.

Any clues where to start looking next much appreciated.

Here's the redacted jpackage command

$JAVA_HOME/bin/jpackage --verbose \
  --dest bundles \
  --input build \
  --name DrumScoreEditor \
  --main-class org.whiteware.DrumScoreEditor \
  --main-jar DrumScoreEditor_$VERSION.jar \
  --add-modules java.base,java.desktop,java.datatransfer,java.prefs,java.xml,java.logging \
  --java-options "--add-opens java.desktop/com.apple.eawt.event=ALL-UNNAMED" \
  --app-version $VERSION \
  --copyright "Copyright (c) 2023 Alan R. White" \
  --vendor "drumscore.scot" \
  --file-associations autobuild/filetypes.txt \
  --mac-sign \
  --mac-package-signing-prefix org.whiteware.DrumScoreEditor \
  --mac-signing-key-user-name "Alan White (REDACTED)" \
  --mac-package-name "Drum Score Editor" \
  --mac-entitlements autobuild/entitlements.txt \
  --resource-dir package/macosx

The error ...

[17:50:24.874] Running /usr/bin/codesign
[17:50:25.526] java.io.IOException: Command [/usr/bin/codesign, -s, Developer ID Application: Alan White (REDACTED), -vvvv, --timestamp, --options, runtime, --prefix, org.whiteware.DrumScoreEditor, /var/folders/70/dxx7_3xn7kq1wl8bq0sfnch40000gn/T/jdk.jpackage10506364833728775098/images/image-10320893665944302794/DrumScoreEditor.app/Contents/runtime/Contents/Home/lib/libnet.dylib] 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:215)

Running codesign manually as above ...

➜  autobuild git:(modelrip) ✗ cp /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/lib/libnet.dylib .
➜  autobuild git:(modelrip) ✗ /usr/bin/codesign -s "Developer ID Application: Alan White (REDACTED)" -vvvv --timestamp --options runtime --prefix org.whiteware.DrumScoreEditor libnet.dylib
libnet.dylib: is already signed

EDIT to show verbose log entries at failure

[08:40:50.007] Using default package resource Runtime-Info.plist.template [Java Runtime Info.plist] (add Runtime-Info.plist to the resource-dir to customize).
[08:40:50.016] Running /usr/bin/codesign
[08:40:50.342] Running /usr/bin/codesign
[08:40:51.454] java.io.IOException: Command [/usr/bin/codesign, -s, Developer ID Application: Alan White (REDACTED), -vvvv, --timestamp, --options, runtime, --prefix, org.whiteware.DrumScoreEditor, /var/folders/70/dxx7_3xn7kq1wl8bq0sfnch40000gn/T/jdk.jpackage2766942816810615066/images/image-16726125713601794084/DrumScoreEditor.app/Contents/runtime/Contents/Home/lib/libnet.dylib] 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:215)

The message at 50.016 appears to be the call to codesign to un-sign the libs, then the next is the failing attempt to sign. If there was some way to surface the actual text message from the failing codesign rather than just there retcode of 1 it would be useful.

So, the JDK version hasn't changed, but is it possible that the JDK was re-installed? (or maybe the build script downloads the JDK on demand). — Jorn Vernee, Apr 21 '23 at 16:43
Thanks for the pointer, no updates there, I worked temurin and openjdk 17 LTS and now the latest 20, and consistently the same problem. security find_identity is showing the Developer ID as valid, cert expires next year. Lost count the number of times I've been here between Apple and Oracle with packaging mysteriously stopping working! — Hamish258, Apr 21 '23 at 21:46
I'm not sure, but I think jpackage is supposed to unsign all the libraries and then re-sign them when creating the package. Maybe the unsign is silently failing. How you tried running with `--verbose`? — Jorn Vernee, Apr 21 '23 at 22:01
https://github.com/openjdk/jdk/blob/dfacda488bfbe2e11e8d607a6d08527710286982/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java#L701 shows that yes, it is supposed to unsigned all dylibs first. Verbose is showing no error on unsign, will add in the detailed log extract to show. — Hamish258, Apr 22 '23 at 07:00

score 2 · Accepted Answer · answered Apr 22 '23 at 07:52

Hopefully this will help others in the future.

When jpackage spawns the codesign command it only surfaces that it received a return code of 1 if something went wrong signing your app. Verbose mode doesn't tell you any more.

To find the real error requires reproducing it. I'd made a flawed attempt at doing so, by copying the named dylib that was failing, trying to sign it, and getting a 'Already signed' message (and return code of 1).

What I needed to do was unsign libnet.dylib and then try and sign it again, and this time got the real error.

➜  autobuild git:(modelrip) ✗ /usr/bin/codesign --remove-signature libnet.dylib
➜  autobuild git:(modelrip) ✗ /usr/bin/codesign -s "Developer ID Application: Alan White (REDACTED)" -vvvv --timestamp --options runtime --prefix org.whiteware.DrumScoreEditor libnet.dylib
libnet.dylib: signed Mach-O thin (x86_64) [org.whiteware.DrumScoreEditorlibnet]
libnet.dylib: timestamps differ by 190 seconds - check your system clock

As for the cause of the clock errors, who knows, I rebooted and then it worked ... reminds me of jokes about "have you tried switching it on and off yet" .. facepalm

Nice find! I'm also reminded of the jpackage `--temp ` flag that will put all the temporary files it creates in `` instead. That could make it easier to re-run the command that failed, using the exact same input file(s). (It's too late to help you, but hopefully it can help future readers) — Jorn Vernee, Apr 22 '23 at 15:46
As far as I remember `codesign` has the argument `--force` which overwrites existing signatures. — Robert, Apr 23 '23 at 12:31
Which, if it was indeed due to an Already Signed error would have worked I guess. It would be really useful if codesign returned different error codes for different errors, or jpackage surfaced the stdout/err from spawning codesign. — Hamish258, Apr 23 '23 at 19:41

jpackage codesign exit code 1 already signed

1 Answers1