productsign in Big Sur backwards compatibility problem

Yes, I am seeing the same problem and it's causing me a few headaches. I tried running the Catalina version of productsign on Big Sur and it ran OK, but the resulting signed package still would not install on El Capitan.

Is it something to do with the format of the certificates? I got new ones when I moved my development environment to Big Sur, so that's another variable. Perhaps El Capitan doesn't support SHA256 hashes.

Big Sur hasn't been released yet so you shouldn't be using it to sign and release software. Notarized apps and packages from Catalina should support any operating system since 10.9. You can try notarizing in Big Sur if you want and see if it works on 10.9 and later.

I am using the old certificated like on Catalina, so I guess this isn't a problem.
Just installed a 11.0.1 and the bug is still there. So far the workaround is to sign installer on earlier version of macOS and to notarize and do the rest on the Big Sur.

I have tried and notarizing in Big Sur doesn't work in El Capitan or earlier. So, definitely there is some problem with using productsign in Big Sur.

Did you ever find a solution for this? Big Sur is released now and signing is still broken.

Any luck? Big Sur does not correctly sign pkg files using SHA1 which is required by El Capitan (10.11) and earlier.

Sierra (10.12) and later correctly pickup the SHA256 signature.

Big Sur does not correctly sign pkg files using SHA1 which is required
by El Capitan (10.11) and earlier.

Yeah, that’s my suspicion too. I took a look at the macOS 11 version of productsign to see if it had an option to control this but, AFAICT, it does not.

Have you filed a bug about this? If not, please do so. Once you have a bug on file, post the bug number here.

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

Ok, I submitted feedback - FB8907482

Thanks.

Looking at the bug it’s landed in the right place, which is good. However, I don’t see any attachments. At a minimum you should attach:

• An example package that reproduces the problem

• A sysdiagnose log from the Mac taken immediately after it refuses to install the package

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

Ok, I've added those two files.

Do we have an update on this? Same issue here. Users on 10.11 cannot install our app. Moreover, Big Sur users are getting other weird errors such as "This app cannot be opened".

Bug ID: FB8914737

This is a serious problem. We released an installer signed on a development computer running Big Sur, and we were flooded with complaints from users running macOS 10.9 through 10.11, all receiving the error that the installer's signature was invalid. We had to use a separate computer running Catalina to sign the installer, in order to make it compatible with these older operating systems.

We'd like to know what Apple's plans are to fix this problem, and when we can expect this fix to be released. This has greatly complicated our build process, as well as our QA process.

Thanks.

We'd like to know what Apple's plans are to fix this problem, and when we can expect this fix to be released.

Apple never tells anyone their plans, for good reason.

You can "expect" this will never be fixed. If you are really lucky, it "might" be fixed in a couple of months. This would be an absolute, best-case scenario. But you really shouldn't expect that. If you want to support older operating systems, you will need to build, or at least sign, with an older system.

Today I found a workaround for this annoying issue. Unfortunately I cannot place a link to the relevant webpage here, but using a search engine a document can be found called "Signing a Mac package on Linux". on the wfu.edu homepage. The same steps work on OSX if you build the xar utility using MacPorts on Big Sur and the call that version using /opt/local/bin/xar. Additional requirements are a working .pkg to extract the certificates and a .p12 file of your certificate. Basically xar can be used to do the same thing as productsign but with backwards compatibility. This way we don't need to wait for a fix from Apple. It seems this problem in slightly different form was already present on 10.14 when targetting 10.6.8, but now it is affecting everything up to 10.11.

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.

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"