productsign in Big Sur backwards compatibility problem

Great, it is always a pleasure to spend hours fixing this kind of issues, I felt I did not lose enough time with notarization stuff already.

Hello,

I found another workaround that you may find easier to use, but it will also require a computer running an older system (I tried with Big Sur and Mojave, but I guess it will work with Big Sur and Catalina too).

In my case, I was preparing JOGL libraries (see forum.jogamp.org/JOGL-for-Mac-ARM-Silicon-td4040887.html ) to make Sweet Home 3D run under Big Sur ARM. I compiled the libraries for x86_64 then for arm64, prepared universal libraries with lipo command and signed them with codesign. But when I tried the application under macOS X 10.10, I encountered the "code signature invalid" error reported here.
Then, I tried to reverse lipo and codesign processes, wondering if a universal library built from signed sublibraries would work, and this seems to be the case. I'm not 100% sure about it because I experimented this way of doing only on libraries and not on a .app bundle which includes such libraries.

So, if you have already some universal libraries try this:

• under Big Sur, go to the folder where your libraries are stored and extract x86_64 libraries to a x86_64 folder with a command similar to:

Code Block 
  find . -name "*.dylib" -exec lipo -extract x86_64 -output path/to/x86_64/'{}' '{}' ';'

• extract arm64 libraries to an arm64 folder with a command similar to:

Code Block 
find . -name "*.dylib" -exec lipo -extract arm64 -output path/to/arm64/'{}' '{}' ';'

• under an older system, go to x86_64 folder and change the signature of x86_64 libraries with a command like:

Code Block 
find . -name "*.dylib" -exec codesign -v -f -s "Developer ID Application" --options=runtime {} --entitlements path/to/entitlements.plist ';'

• finally under Big Sur, go to x86_64 folder and rebuild universal libraries with a command similar to:

Code Block 
find . -name "*.dylib" -exec lipo '{}' path/to/arm64/'{}' -output path/to/yourApplication/'{}' -create ';'

To apply the same procedure to an executable, just replace *.dylib by the name of your executable or read "find" man page.
Of course, it's more than advised to backup everything before doing this.

One last detail, be sure to compile your libraries and executable with -mmacosx-version-min=10.9 option as suggested at https://stackoverflow.com/questions/41865537/how-does-apples-codesign-utility-decide-which-sha-algorithms-to-sign-a-shared otherwise it still won't work.

I've got the following answer in my ticket:

This is expected behavior, you will need to produce two different packages that are signed with different hashes if you want to support older OSs.

that's pretty crazy. apple really loves its developers

Fortunately things have improved on this front, at least according to the Xcode 12.5 Release Notes:

Fixed an issue that caused OS X 10.11 and earlier to reject packages
signed in macOS 11 or later. (71695608, 75599040)

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

this issue was just reported from a user, which is how i ended up here! i'll see if i can get more details, as i was fully prepped to ship two separate installers. thanks btw!

This really is another annoying problem. We launched our software and keep getting complaints due to this. Looks like Apple doesn't really care about a solution though...

This really is another annoying problem.

So, with reference to my earlier post, are you saying that Xcode 12.5 has not fixed this issue for you?

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