Codesign -- force not signing 3rd Pty binaries

Question

Created Jul ’25

Replies 9

Boosts 0

Participants 2

This math-educational 3D-graphics courseware utilizes Java3D, which sits on top of hardware-dependent JOGAMP binaries (which instruct at the GPU-level).

This code signing command applied to the installer .dmg:

codesign -s "myName" --force --options runtime ~/DFG2D_MacOS_Manufacturing/MacOSInstallers/DFG2D_Mac_J1602_x86/DataflowGeometry2D-1.0.300.dmg

is supposed to force signing of all the embedded binaries, BUT the notary tool finds about 25 jogamp-fat dynamic libraries (/ *.dylib) UNSIGNED.

Processing complete id: 23d81a99-4087-48d2-a567-8072dd2820fe status: Invalid pierrebierre@Pierres-iMac ~ % xcrun notarytool log 17d2fe94-f38a-47d4-9568-cf4dc65f24c9 --apple-id "xxxxxxxxxxx" --team-id "XXXXXXXXX" --password pwpwpwpwpw { "logFormatVersion": 1, "jobId": "17d2fe94-f38a-47d4-9568-cf4dc65f24c9", "status": "Invalid", "statusSummary": "Archive contains critical validation errors", "statusCode": 4000, "archiveFilename": "DataflowGeometry2D-1.0.300.dmg", "uploadDate": "2025-07-13T21:28:21.147Z", "sha256": "57320c4ad4a07f144336084152bf7e3328f8c5694dd568d2cfd23a596b5b3b13", "ticketContents": null, "issues": [ { "severity": "error", "code": null, "path": "DataflowGeometry2D-1.0.300.dmg/DataflowGeometry2D.app/Contents/app/DFG2D_Mac_x86_300.jar/lib/jogamp-fat/jogamp-fat.jar/natives/macosx-universal/libnativewindow_awt.dylib", "message": "The binary is not signed.", "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087721", "architecture": "x86_64" }, { "severity": "error", "code": null, "path": "DataflowGeometry2D-1.0.300.dmg/DataflowGeometry2D.app/Contents/app/DFG2D_Mac_x86_300.jar/lib/jogamp-fat/jogamp-fat.jar/natives/macosx-universal/libnativewindow_awt.dylib", "message": "The signature does not include a secure timestamp.", "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087733", "architecture": "x86_64" },

What is your advice on how to get these binaries signed?

Answered by DTS Engineer in 848906022

This code signing command applied to the installer .dmg … is supposed to force signing of all the embedded binaries

No it’s not. I’m not sure where you got that idea from, but signing a disk image just signs the disk image, it does not change the content on the disk image. That’s true even if you apply --deep [1].

If you want to re-sign the contents of a disk image, you have to extract the contents, re-sign that, and then re-create the disk image with the new contents.

Oh, I guess there’s another option here, which is to convert the disk image to read/write, mount it, re-sign the items in place, unmount it, and then convert it back to read-only. That’d work too.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Which, of course, you shouldn’t be doing. See --deep Considered Harmful.

Boost

Answer 1

DTS Engineer OP

Apple

Jul ’25

Recommended

This code signing command applied to the installer .dmg … is supposed to force signing of all the embedded binaries

No it’s not. I’m not sure where you got that idea from, but signing a disk image just signs the disk image, it does not change the content on the disk image. That’s true even if you apply --deep [1].

If you want to re-sign the contents of a disk image, you have to extract the contents, re-sign that, and then re-create the disk image with the new contents.

Oh, I guess there’s another option here, which is to convert the disk image to read/write, mount it, re-sign the items in place, unmount it, and then convert it back to read-only. That’d work too.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Which, of course, you shouldn’t be doing. See --deep Considered Harmful.

0

Answer 2

pbierre OP

Aug ’25

My latest process is still failing Notarization, saying 10 .dylib files (located in the jog amp MacosX Universal Binaries folder) are unsigned. My process:

Unarchive jogamp-fat.jar (command line too "jar xf")
codesign --timestamp all 10 .dylib files
confirm all signed
reJar the jog amp-fat.jar
codesign the jar, and confirm signed
add signed jar back into Eclipse Java project as an external library
Export app jar
use jpackage tool to sign app jar , build .dmg, and sign that
test run install and launch
submit .dmg to Notarization

Will try to email the .dmg to Quinn

0

Answer 3

pbierre OP

Aug ’25

Link to DropBox where I put the .dmg installer that won't pass Notarization even after signing the errant binaries:https://www.dropbox.com/scl/fi/axj79k0jzwwzwxjimgpg4/DataflowGeometry2D-1.0.313.dmg.cpgz?rlkey=zsan46qo6gdjk6y4dy1utgay6&st=uo9ujuo8&dl=0

0

Answer 4

DTS Engineer OP

Apple

Aug ’25

The immediate cause of your problem is you have code that’s not signed:

% file /Volumes/DataflowGeometry2D/DataflowGeometry2D.app/Contents/app/DFG2D_Mac_x86_313.jar
/Volumes/DataflowGeometry2D/DataflowGeometry2D.app/Contents/app/DFG2D_Mac_x86_313.jar: Java archive data (JAR)
% mkdir DFG2D_Mac_x86_313
% cd DFG2D_Mac_x86_313
% unzip /Volumes/DataflowGeometry2D/DataflowGeometry2D.app/Contents/app/DFG2D_Mac_x86_313.jar
Archive:  /Volumes/DataflowGeometry2D/DataflowGeometry2D.app/Contents/app/DFG2D_Mac_x86_313.jar
  …
  inflating: lib/jogamp-fat/jogamp-fat.jar
  …
% mkdir jogamp-fat
% cd jogamp-fat
% unzip ../lib/jogamp-fat/jogamp-fat.jar
Archive:  ../lib/jogamp-fat/jogamp-fat.jar
  …
  inflating: natives/macosx-universal/libjocl.dylib
  …
% file natives/macosx-universal/libjocl.dylib
natives/macosx-universal/libjocl.dylib: Mach-O universal binary with 2 architectures…
…
% codesign -d -vvv natives/macosx-universal/libjocl.dylib
…
CodeDirectory v=20400 size=1606 flags=0x20002(adhoc,linker-signed) …
…

The notary service requires that all of the code in your app be signed with a valid Developer ID code-signing identity. You have code that’s not signed, like that shown above [1], and thus you get these complaints.

IMPORTANT It’s actually good that notary picks this up. If it didn’t, you’d run into weird runtime problems with Gatekeeper, and those are much harder to debug.

Looking through your earlier post it’s clear that you tried to sign these files. I’m not sure why that’s failing, but I’m hardly an expert on Java tooling. I recommend that you re-examine those steps to see how your app got in to this state.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Technically that code is ad hoc signed, but that’s not enough to satisfy notary.

0

Answer 5

pbierre OP

Aug ’25

I have a valid Developer ID certificate and key. When I codesign, I'm prompted to enter my system pw. codesign gives absolutely ZERO feedback that it isn't using the Developer ID I reference in the codesign command line. It just says it's signed in response to --verify.

You haven't told me anything specifically actionable, like how would I verify during code signing that it's using my Developer ID vs. adhoc.

Is there a way to tell, short of the long, exasperating feedback loop leading to Notarization testing?

0

Answer 6

pbierre OP

Aug ’25

Would you agree to a screen-sharing session to help resolve this?

0

Answer 7

pbierre OP

Aug ’25

POSSIBLE CLUE:

This feedback from: codesign --display --verbose=2 indicates a valid Developer ID signature is attached, (not an adhoc signature)

pierrebierre@Pierres-iMac ~ % codesign --display --verbose=2 ~/DFG2D_MacOS_Manufacturing/JogAmpSignedJar/jogamp-fat/natives/macosx-universal/libnewt_head.dylib

Executable=/Users/pierrebierre/DFG2D_MacOS_Manufacturing/JogAmpSignedJar/jogamp-fat/natives/macosx-universal/libnewt_head.dylib Identifier=libnewt_head Format=Mach-O universal (x86_64 arm64) CodeDirectory v=20400 size=912 flags=0x0(none) hashes=23+2 location=embedded Signature size=9047 Authority=Developer ID Application: Pierre Bierre (SL7L4YU8GT) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=Aug 4, 2025 at 11:36:17 AM Info.plist=not bound TeamIdentifier=SL7L4YU8GT Sealed Resources=none Internal requirements count=1 size=172

The codesign --verify --verbose command gives:

pierrebierre@Pierres-iMac ~ % codesign --verify --verbose ~/DFG2D_MacOS_Manufacturing/JogAmpSignedJar/jogamp-fat/natives/macosx-universal/libnewt_head.dylib /Users/pierrebierre/DFG2D_MacOS_Manufacturing/JogAmpSignedJar/jogamp-fat/natives/macosx-universal/libnewt_head.dylib: valid on disk /Users/pierrebierre/DFG2D_MacOS_Manufacturing/JogAmpSignedJar/jogamp-fat/natives/macosx-universal/libnewt_head.dylib: satisfies its Designated Requirement

Is this not the feedback indicating I (a valid Apple Developer) have signed my code?

What possibly could explain why Notarization is calling out this file as unsigned?

0

Answer 8

pbierre OP

Aug ’25

I just found some evidence that Eclipse is linking in the unsigned "jogamdp-fat" jar. I can tell because I noted the file size increase after code signing, and the one being linked in the smaller file.

0

Answer 9

pbierre OP

Aug ’25

Accepted Answer

WOOHOO!!!!! It's been 3 months trying to crack this, going back to a problem that occurred when originally installing my Developer ID Certificates into KeyChainAccess.

Thank you for your help.

Successfully uploaded file id: e7b2c2a0-24e4-48e3-8c0e-baa7b5a33f07 path: /Users/pierrebierre/DFG2D_MacOS_Manufacturing/MacOSInstallers/DFG2D_Mac_J1602_x86/DataflowGeometry2D-1.0.313.dmg Waiting for processing to complete. Current status: Accepted..................... Processing complete id: e7b2c2a0-24e4-48e3-8c0e-baa7b5a33f07 status: Accepted

0