Issues while signing macOS app

In the first approach, do you see your imported certificate and private key under "My Certificates" in Keychain Access? Do you see your imported certificate in Xcode's Settings > Accounts when you click "Manage Certificates"?

I try to generate new certs for this m1 machine

It sounds like you’re trying to create a new Developer ID certificate. That’s not a good way forward. I talk about this in depth in The Care and Feeding of Developer ID.

I export the cert with the private key from my intel to the m1 machine

Moving a Developer ID signing identity via a .p12 file should work. I do that regularly.

but when I try to sign, I get: Invalid signature.

Can you elaborate on that? Is it failing in Xcode? Or are you signing with codesign? Does it fail with all programs? Or just with your main product? And are you signing from Terminal? Or in some other context, like SSH or in a CI environment?

For context, here’s a simple way to test your codesign setup:

% cp /usr/bin/true MyTrue
% codesign -s "Developer ID Application" -f "./MyTrue" 
./MyTrue: replacing existing signature

If you run that from Terminal, what do you see?

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

It sounds like you’re trying to create a new Developer ID certificate

Yes, it is not the best approach as you highlight here and in the other thread, but was a desperate approach as we had tight time before releasing 😅

Can you elaborate on that? Is it failing in Xcode? Or are you signing with codesign? Does it fail with all programs? Or just with your main product? And are you signing from Terminal? Or in some other context, like SSH or in a CI environment?

We ship an application as a pkg. This PKG includes a progressive web app coded in Electron.js. Inside this Electron app we add two binaries plus some dependencies to run. One of it is an executable binary and the other one is a dynamic library. For all of them, we signed and notarized (Works well on the intel machine). Also, important to mention we ship outside AppStore that is why we follow a process outside Xcode.

We run: codesign --sign "Developer ID Application:TTT" --deep --force --options runtime --entitlements entitlements.mac.plist <file>, where file are all the binaries (the ones we code and the third-party libraries. Also, the ones we code are in c++).

This is the output of the error when we try to sign an external library or our executables:

<name>.dylib: invalid or unsupported format for signature

Something important to mention is this libraries comes from each native architecture. We downloaded through brew. The ones owned by use, are built for each native architecture as well.

Also, try your suggestion for testing codesign. It kind of work, but I get an extra line:

MyTrue: replacing existing signature
Warning: unable to build chain to self-signed root for signer "Developer ID Application: TTT"
/MyTrue: errSecInternalComponent

I check Keychain to make sure I can see the cert + private key. Everything looks well on Keychain. We are not using Xcode for it, the code is written in another language. (Electron.js)

try your suggestion for testing codesign. It kind of work, but I get an extra line:

Getting that working is a first step. See Resolving errSecInternalComponent errors during code signing.

We run: codesign … --deep …

Don’t signed code with --deep. See --deep Considered Harmful.

Rather, sign your code and installer package using the processes described in:

• Creating distribution-signed code for macOS

• Packaging Mac software for distribution

That’ll either fix the problem or it won’t. If it doesn’t, it’ll at least show you which code item is failing, and you can debug from there.

This is the output of the error when we try to sign an external library or our executables:

… invalid or unsupported format for signature

Hmmm, that’s a new one on me. If you put that .dylib in a directory by itself and run the equivalent of my MyTrue example, do you see the same problem?

If so, what does file report?

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

errSecInternalComponent

I was able to fix this issue by noticing in keychain the cert were checked to Always Trust. As soon as I change it to "Use System Defaults", the extra warning was gone.

Hmmm, that’s a new one on me. If you put that .dylib in a directory by itself and run the equivalent of my MyTrue example, do you see the same problem?

I try to sign a third-party lib with the same command as MyTest codesign -s "Developer ID Application" -f "./libapr.dylib" and it gives the same output: libapr.dylib: invalid or unsupported format for signature

I can attach the dylib, or you can downloaded from internet. The name is libapr. (I get it from brew as a dependency of liblog4cxx)

I was able to fix this issue

Yay!

As to the libapr.dylib, I can’t seem to find a binary to download (and I don’t have time to build it from source). Can you post the binary to a file sharing service and then reply here with the link?

Post the link in the clear, per Quinn’s Top Ten DevForums Tips.

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

HI @DTS Engineer! I think my reply on your suggestion where miss under comment section.

Here is the link for libapr for arm architecture. https://we.tl/t-49G2iDOINJ And this is for intel architecture https://we.tl/t-i1sw6BTwEI Something I try, and works in terms of signing is to create a universal binary with lipo command. But in this case, we need to shipped them for the native architecture

I think my reply on your suggestion where miss under comment section.

Yeah, don’t do that )-: See Quinn’s Top Ten DevForums Tips for this and other tips.

Here is the link for libapr for arm architecture.

Thanks for that.

Just to recap, the issue is that you can replace the signature of the Intel dynamic library but not the Apple silicon one:

% codesign -s - -f libapr-1.0.intel.dylib
libapr-1.0.intel.dylib: replacing existing signature
% codesign -s - -f libapr-1.0.m1.dylib   
libapr-1.0.m1.dylib: invalid or unsupported format for signature

Do you know what tools generated this library? Because its code signature seems to be very weirdly constructed. Consider this [1]:

% codesign -d -vvvv libapr-1.0.m1.dylib   
libapr-1.0.m1.dylib: code object is not signed at all
% codesign -s - libapr-1.0.m1.dylib  
libapr-1.0.m1.dylib: invalid or unsupported format for signature

It’s Schrödinger’s code signature, being both there and not there!

For a quick workaround, you can do this:

% codesign --remove-signature libapr-1.0.m1.dylib 
% codesign -s - libapr-1.0.m1.dylib             

However, my proper answer is that you need to look back through the supply chain to figure out where this library came from. Because whatever tools that generated it are doing something weird.

And if those tools are Apple tools, I’d love to hear about it.

Just before finishing this reply I thought I’d have a look inside the dynamic library to see if it offers any clues as to its provenance [1]. I tripped at the first hurdle:

% dyld_info -exports libapr-1.0.m1.dylib 
dyld_info: 'libapr-1.0.m1.dylib' rebase opcodes terminated early at offset 1 of 40

Yikes! So this library has a broken code signature and a broken Mach-O structure. That’s quite bad.

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

[1] To be clear, this is the original library as I downloaded it, not the version that I re-signed earlier in this post.