Upgraded to Big Sur and now my codesigning fails on 10.11 and earlier

Upgraded to Big Sur and now my codesigning fails on 10.11 and earlier. Anybody else seeing this?

On 10.11 I see:

App_1.2.6.pkg can't be installed because its digital signature is invalid.

The package may have been corrupted or tampered with. Get a new copy of the package and try again.

Any ideas?

JUCE and macOS 11 / ARM is this relevant?

This seems like what I was referring to in the other thread, Chris from Audio Damage has talked about this on his Twitter too


I’d love to know if the runtime exceptions library validation would make stuff work pre 10.12. Sadly I don’t have a machine to test that, just big sur and catalina here.

productsign in Big Sur isn’t adding SHA1 hashes: https://developer.apple.com/forums/thread/664842

Don’t be a dumbass like me and upgrade your build machines to Big Sur.


I already did upgrade :rofl:

That is why I have two mac minis: one upgraded and one with the previous system or XCode. Now I will have three after Apple switched to ARM.

The tool someone wrote in the link posted by g-mon unfortunately does not solve this annoying issue. Maybe it could be extended? The pkgresign tool adds RSA signatures to an already signed package… but now we’d also need SHA1 as stated. Does anyone know the xar/xar.h library enough to patch the tool?

I already tried to copy the old productsign to Big Sur, but of course it does not run.

Any workaround would be very welcome. I do still have an non-updated dev machine, but needing two machines for release builds is terrible and means I cannot fully automate my builds :frowning: .

Update: I was able to make the 10.13 productsign run on Big Sur under Rosetta2. It failed because … wait for it … its signature was invalid. So I resigned the 10.13 productsign using my own signature on Big Sur and now it executes. Unfortunately the resulting signed package still doesn’t run on older systems :s. The difference is probably not inside productsign, but in some library.

maybe this will help us:

maybe we can use the same steps to sign without productsign.

I find it hard to believe myself, but I got the method in the link to work and have now successfully signed a .pkg on Big Sur using my Installer certificate which launches on both Big Sur and 10.7.

A big problem was that the xar utility shipped with OS X is the basic version and does not have the commands needed for cert extraction and injection. I tried building the extended mackyle/xar 1.6.1 myself on arm64, but ran into issues quickly. I realized MacPorts is already working on arm64, has mackyle/xar included and luckily all the required libs are arm64 compatible already.

So I installed MacPorts and installed xar from that using sudo port install xar. Using this version I was able to do the exact steps listed in the link in the previous post, I just needed to adjust the path of xar to /opt/local/bin/xar to use the macports one.

The only thing that remains to be checked it whether the .pkg still passes Notarization.

Yep works… now I just need to write a script from this that works like productsign.

I ended up with this modified version of the script posted and called it xarsign.sh .

Update: WARNING! This method has been shown to not fully work. See later posts!


# Original script from http://users.wfu.edu/cottrell/productsign/productsign_linux.html
# Written by Allin Cottrell, with help from MacKyle who added signing capabilities to xar.
# Requires a mackyle/xar install using MacPorts (sudo port install xar).
# The xar included in macOS cannot modify pkg signatures.
# Instructions on how to extract certs from a working foo.pkg and a .p12 file exported from
    # Keychain Access.app are on the homepage:
# mkdir certs
# xar -f foo.pkg --extract-certs certs
# openssl pkcs12 -in "Dev ID Installer.p12" -nodes | openssl rsa -out "Dev ID Installer.pem"

DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null 2>&1 && pwd )"
SIGFILE="$DIR/Dev ID Installer.pem"

echo "determine signature length"
SIGLEN="$(: | openssl dgst -sign "$SIGFILE" -binary | wc -c)"

echo $SIGLEN

echo "prepare singing data digest & add certs to pkg"
# may have to adjust depending
# on the contents of the certs subdir in your case
$XARCMD --sign -f $PKG --digestinfo-to-sign digestinfo.dat \
  --sig-size $SIGLEN \
  --cert-loc "$DIR/certs/cert00" \
  --cert-loc "$DIR/certs/cert01" \
  --cert-loc "$DIR/certs/cert02"

echo "create signature"
openssl rsautl -sign -inkey "$SIGFILE" -in digestinfo.dat -out signature.dat
echo "inject signature into package"
$XARCMD --inject-sig signature.dat -f $PKG

# clean up
rm -f signature.dat digestinfo.dat

WARNING! This method has been shown to not fully work. See later posts!

I created the “foo.pkg” on my 10.13 system and also exported the Developer ID Installer .p12 file on the 10.13 machine … just to be sure.

I put everything inside a directory like this:


Now I can just call xarsign.sh from anywhere with the pkg to sign as the argument.


I’ve had similar problems trying to produce a properly signed binary on macOS 11.0.1 / Xcode 12.2 (running on actual Apple silicon hardware) that would check out on macOS 10.11 to 10.9. Wasted a day trying just about everything.

Simply building with the exact same recipe and same OS / Xcode versions on an Intel machine made the problem go away for me.

YMMV, maybe it helps someone else not to waste a(nother) day on Apple signotarization shenanigans.

Can you confirm your Xcode version is Version 12.2 (12B45b)?

btw. on the apple forum thread there was an “official” answer to the productsign problem:

“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.”

So it looks like they won’t fix productsign to work on 10.7 - 10.11. Very annoying… first Apple forced us to sign the installers to pass Notarization and now they break backwards compatibility in an extremely unnecessary way.
At least I found the xar workaround.

Luckily I am not seeing the issues @hexler mentionned with my builds on arm. I use codesign from the command line and they even load on 10.7. If a fix is to run on an intel machine… maybe we could also just run xcodebuild using rosetta2 on the M1 machines.

Yes, “Version 12.2 (12B45b)”

@hexler, do you codesign inside XCode?

No, these are scripted command line builds in a VM using xcodebuild

So you are running Big Sur arm64 in a vm? You wrote when singing problems happened you built on Apple Silicon Hardware. I am not aware of any vm that could run arm on arm yet.

I just would like to figure out what circumstances to avoid in order not to get the signing problems. I build using XCode 12.2 on Big Sur on a DTK and the resulting plugins load fine on 10.7, 10.9, 10.13 and Big Sur intel and arm.

No, I was running into problems similar to the op’s when trying to produce a properly signed executable on a genuine Apple silicon machine using the build scripts from our build machine.

Tried to solve that for a day, gave up and set up a build VM on our (Intel) build server anyway planning to probably raise the system requirements if no solution magically appears.

Then it turned out the build coming from there (exact same versions of OS and Xcode, but running on Intel) signed and checked out fine on all versions of macOS we support.

End of story. Thought I’d share that as it might save somone else some time.

In the meantime I realized that Keychain Access.app can also create the .pem file directly, so the initial openssl step might not be needed, but as it’s working fine for me I haven’t tested this.

What is important to remember for the future is that the whole thing needs a machine with a system that can create installers working on all target OSes. At some point your installer certificate is going to time out and will need to be renewed and then another run of the setup steps is needed and cannot be done on a Big Sur machine.

Thanks a lot for doing this tedious work @pflugshaupt , it took me some time but I finally managed to get it to work.

Now I can build my pkg on a Big Sur dtk, and the pkg is still compatible with macos 10.7, and the x86_64/arm64 universal binaries also work fine on 10.7.

Not sure how long this will work, but for now I am quite satisfied :slight_smile:

1 Like