Topics

Installer pkg built with Xcode 12.2 won't open in macOS 10.10 and 10.11


Mark Allan
 

Hi all,

I have a script which Xcode runs as a post-action during the archive phase which takes my compiled app, and generates a signed .pkg installer file along with all the other elements of the app.

For the last few years this has worked fine, but for some reason I'm now unable to open the resulting pkg file on macOS 10.10 and 10.11. When I try to open the installer on the older OSes, I'm presented with the following error message:

Installer_signed.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.

The signature is valid and I can see this in macOS 11 and 10.15 when clicking the certificate icon in the upper right corner of the window, so I'm not sure what's going on.

Is anyone aware of any changes to pkgbuild and productbuild which might have caused this? The man pages don't reference anything new that might be relevant, so I'm stuck.

Thanks
Mark


Ben Kennedy
 

Hey Mark,

I can't speak to what might be the problem, but I've been reading about code signing and notarization recently in an effort to better understand how it all works at a lower level, so I'm interested in what you find out.

TN2206 (https://developer.apple.com/library/archive/technotes/tn2206/_index.html) makes reference to using the `check-signature` tool (https://developer.apple.com/download/more/?=SignatureCheck) to validate package signatures. Have you tried that? Does it report anything useful?

-ben

On 7 Dec 2020, at 8:57 am, Mark Allan <markjallan@gmail.com> wrote:

Hi all,

I have a script which Xcode runs as a post-action during the archive phase which takes my compiled app, and generates a signed .pkg installer file along with all the other elements of the app.

For the last few years this has worked fine, but for some reason I'm now unable to open the resulting pkg file on macOS 10.10 and 10.11. When I try to open the installer on the older OSes, I'm presented with the following error message:

Installer_signed.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.

The signature is valid and I can see this in macOS 11 and 10.15 when clicking the certificate icon in the upper right corner of the window, so I'm not sure what's going on.

Is anyone aware of any changes to pkgbuild and productbuild which might have caused this? The man pages don't reference anything new that might be relevant, so I'm stuck.

Thanks
Mark





Mark Allan
 

Hey Ben,

Thanks for the suggestion. No I hadn't checked that tool...but I have now, and it says "YES" ie it's signed correctly, so unfortunately I'm no further forward.

Mark

On 7 Dec 2020, at 6:53 pm, Ben Kennedy <ben-groups@zygoat.ca> wrote:

Hey Mark,

I can't speak to what might be the problem, but I've been reading about code signing and notarization recently in an effort to better understand how it all works at a lower level, so I'm interested in what you find out.

TN2206 (https://developer.apple.com/library/archive/technotes/tn2206/_index.html) makes reference to using the `check-signature` tool (https://developer.apple.com/download/more/?=SignatureCheck) to validate package signatures. Have you tried that? Does it report anything useful?

-ben


On 7 Dec 2020, at 8:57 am, Mark Allan <markjallan@gmail.com> wrote:

Hi all,

I have a script which Xcode runs as a post-action during the archive phase which takes my compiled app, and generates a signed .pkg installer file along with all the other elements of the app.

For the last few years this has worked fine, but for some reason I'm now unable to open the resulting pkg file on macOS 10.10 and 10.11. When I try to open the installer on the older OSes, I'm presented with the following error message:

Installer_signed.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.

The signature is valid and I can see this in macOS 11 and 10.15 when clicking the certificate icon in the upper right corner of the window, so I'm not sure what's going on.

Is anyone aware of any changes to pkgbuild and productbuild which might have caused this? The man pages don't reference anything new that might be relevant, so I'm stuck.

Thanks
Mark









Jack Brindle
 

Which OS are you building on? There are reports of Big Sur builds having issues on early versions of the OS (pre Mojave, I believe).

Jack

On Dec 7, 2020, at 1:21 PM, Mark Allan <markjallan@gmail.com> wrote:

Hey Ben,

Thanks for the suggestion. No I hadn't checked that tool...but I have now, and it says "YES" ie it's signed correctly, so unfortunately I'm no further forward.

Mark

On 7 Dec 2020, at 6:53 pm, Ben Kennedy <ben-groups@zygoat.ca> wrote:

Hey Mark,

I can't speak to what might be the problem, but I've been reading about code signing and notarization recently in an effort to better understand how it all works at a lower level, so I'm interested in what you find out.

TN2206 (https://developer.apple.com/library/archive/technotes/tn2206/_index.html) makes reference to using the `check-signature` tool (https://developer.apple.com/download/more/?=SignatureCheck) to validate package signatures. Have you tried that? Does it report anything useful?

-ben


On 7 Dec 2020, at 8:57 am, Mark Allan <markjallan@gmail.com> wrote:

Hi all,

I have a script which Xcode runs as a post-action during the archive phase which takes my compiled app, and generates a signed .pkg installer file along with all the other elements of the app.

For the last few years this has worked fine, but for some reason I'm now unable to open the resulting pkg file on macOS 10.10 and 10.11. When I try to open the installer on the older OSes, I'm presented with the following error message:

Installer_signed.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.

The signature is valid and I can see this in macOS 11 and 10.15 when clicking the certificate icon in the upper right corner of the window, so I'm not sure what's going on.

Is anyone aware of any changes to pkgbuild and productbuild which might have caused this? The man pages don't reference anything new that might be relevant, so I'm stuck.

Thanks
Mark













Alex Zavatone
 

Out of curiosity, do you have an older copy of the installer that works on those platforms?

You may be able to open it up and view the entitlements/config files and see the differences.

One option is to create a VM with one of those operating systems on it and install a version of Xcode that works on 10.10 and 10.11, then deliver these special case installers or create installers that work on that OS and see what the difference is.

I keep around old 50 GB VMWare images and old Xcode installers just in case.

Alex Zavatone

On Dec 7, 2020, at 3:21 PM, Mark Allan <markjallan@gmail.com> wrote:

Hey Ben,

Thanks for the suggestion. No I hadn't checked that tool...but I have now, and it says "YES" ie it's signed correctly, so unfortunately I'm no further forward.

Mark

On 7 Dec 2020, at 6:53 pm, Ben Kennedy <ben-groups@zygoat.ca> wrote:

Hey Mark,

I can't speak to what might be the problem, but I've been reading about code signing and notarization recently in an effort to better understand how it all works at a lower level, so I'm interested in what you find out.

TN2206 (https://developer.apple.com/library/archive/technotes/tn2206/_index.html) makes reference to using the `check-signature` tool (https://developer.apple.com/download/more/?=SignatureCheck) to validate package signatures. Have you tried that? Does it report anything useful?

-ben


On 7 Dec 2020, at 8:57 am, Mark Allan <markjallan@gmail.com> wrote:

Hi all,

I have a script which Xcode runs as a post-action during the archive phase which takes my compiled app, and generates a signed .pkg installer file along with all the other elements of the app.

For the last few years this has worked fine, but for some reason I'm now unable to open the resulting pkg file on macOS 10.10 and 10.11. When I try to open the installer on the older OSes, I'm presented with the following error message:

Installer_signed.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.

The signature is valid and I can see this in macOS 11 and 10.15 when clicking the certificate icon in the upper right corner of the window, so I'm not sure what's going on.

Is anyone aware of any changes to pkgbuild and productbuild which might have caused this? The man pages don't reference anything new that might be relevant, so I'm stuck.

Thanks
Mark













Jon Gotow
 

I've had similar problems when code-signing and notarizing an app using Xcode 12.2 on Big Sur.

On my DTK (Apple Silicon) machine running macOS 11.1 beta and Xcode 12.2, if I go through a standard build and notarization using the Xcode GUI, everything appears to be fine. The codesign and spctl commands report everything is fine when I run them on macOS 11 or 10.15 and the app launches as expected. However, on macOS 10.10, I get the error "the sealed resource directory is invalid" when I run spctl and the system refuses to launch the app, saying it's damaged.

However, if I build on my MacBook Pro running macOS 11.1 beta and Xcode 12 beta, the resulting app doesn't have any problems. I'll boot back into Big Sur and find out which Xcode 12 beta I'm running. In any case, I'm hesitant to update to Xcode 12.2 for fear my builds will no longer work on 10.10.

- Jon

On Dec 7, 2020, at 9:57 AM, Mark Allan <markjallan@gmail.com> wrote:

I have a script which Xcode runs as a post-action during the archive phase which takes my compiled app, and generates a signed .pkg installer file along with all the other elements of the app.

For the last few years this has worked fine, but for some reason I'm now unable to open the resulting pkg file on macOS 10.10 and 10.11. When I try to open the installer on the older OSes, I'm presented with the following error message:

Installer_signed.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.

The signature is valid and I can see this in macOS 11 and 10.15 when clicking the certificate icon in the upper right corner of the window, so I'm not sure what's going on.

Is anyone aware of any changes to pkgbuild and productbuild which might have caused this? The man pages don't reference anything new that might be relevant, so I'm stuck.


Alex Zavatone
 

On Dec 7, 2020, at 4:19 PM, Jon Gotow <gotow@stclairsoft.com> wrote:

I've had similar problems when code-signing and notarizing an app using Xcode 12.2 on Big Sur.

On my DTK (Apple Silicon) machine running macOS 11.1 beta and Xcode 12.2, if I go through a standard build and notarization using the Xcode GUI, everything appears to be fine. The codesign and spctl commands report everything is fine when I run them on macOS 11 or 10.15 and the app launches as expected. However, on macOS 10.10, I get the error "the sealed resource directory is invalid" when I run spctl and the system refuses to launch the app, saying it's damaged.

However, if I build on my MacBook Pro running macOS 11.1 beta and Xcode 12 beta, the resulting app doesn't have any problems. I'll boot back into Big Sur and find out which Xcode 12 beta I'm running. In any case, I'm hesitant to update to Xcode 12.2 for fear my builds will no longer work on 10.10.

- Jon
Jon, have you been able to isolate the difference between the two executables?


On Dec 7, 2020, at 9:57 AM, Mark Allan <markjallan@gmail.com> wrote:

I have a script which Xcode runs as a post-action during the archive phase which takes my compiled app, and generates a signed .pkg installer file along with all the other elements of the app.

For the last few years this has worked fine, but for some reason I'm now unable to open the resulting pkg file on macOS 10.10 and 10.11. When I try to open the installer on the older OSes, I'm presented with the following error message:

Installer_signed.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.

The signature is valid and I can see this in macOS 11 and 10.15 when clicking the certificate icon in the upper right corner of the window, so I'm not sure what's going on.

Is anyone aware of any changes to pkgbuild and productbuild which might have caused this? The man pages don't reference anything new that might be relevant, so I'm stuck.





Jon Gotow
 

On Dec 7, 2020, at 3:58 PM, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

Jon, have you been able to isolate the difference between the two executables?
OK - so I went back and re-signed a known-working build of the app on both machines, just to make sure there weren't any inadvertent build differences caused by building the app with two different versions of Xcode (12.2 on the DTK machine, 12.2 beta 3 on the MacBook Pro). After re-signing them, I zipped both copies of the app and uploaded them to a server, then downloaded them onto an old MacBook Pro running macOS 10.10 Yosemite.

As before, the copy of the app that was code-signed on the DTK machine is reported as damaged when I double-click it to run it on Yosemite, while the copy that was code-signed on my 15" MacBook Pro launches correctly on Yosemite. Both machines where I did the code signing were running macOS 11.1 beta (20C5061b). I checksummed /usr/bin/codesign and the executables on both machines are the same, though they're presumably running different code since codesign is a universal binary.

Using 'codesign -dvvv --deep <appname>.app' (full output below) reveals that the working copy of the app includes both sha1 and sha256 hashes, while the non-working one only includes a sha256 hash. So does Yosemite not like sha256?

- Jon



For completeness, here are the commands I used to sign the code:

codesign -f -s "Developer ID Application: St. Clair Software (7HK42V8R9D)" --timestamp -o runtime Go64.app/Contents/Frameworks/Sparkle.framework/Resources/Autoupdate.app
codesign -f -s "Developer ID Application: St. Clair Software (7HK42V8R9D)" --timestamp -o runtime Go64.app/Contents/Frameworks/Sparkle.framework
codesign -f -s "Developer ID Application: St. Clair Software (7HK42V8R9D)" --entitlements Go64.entitlements --timestamp -o runtime Go64.app

And here are the results of displaying the results with codesign:

----- Copy of Go64 that works on Yosemite -----
Executable=/Volumes/StClairSW/Downloads/codesign test/Go64-Good.app/Contents/MacOS/Go64
Identifier=com.stclairsoft.Go64
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=2560 flags=0x10000(runtime) hashes=69+7 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=128f8fc1408c76dabe1875e3898c8c5b15c05746
CandidateCDHash sha256=11ce01c6847639cee4bd45b20f3aec69cc367f82
Hash choices=sha1,sha256
CDHash=11ce01c6847639cee4bd45b20f3aec69cc367f82
Signature size=9067
Authority=Developer ID Application: St. Clair Software (7HK42V8R9D)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Dec 7, 2020 at 6:31:38 PM
Info.plist entries=27
TeamIdentifier=7HK42V8R9D
Runtime Version=11.0.0
Sealed Resources version=2 rules=13 files=48
Nested=Frameworks/Sparkle.framework
Nested=MacOS/Go64Search
Internal requirements count=1 size=180


----- Copy of Go64 that does not work on Yosemite -----
Executable=/Volumes/StClairSW/Downloads/codesign test/Go64-Bad.app/Contents/MacOS/Go64
Identifier=com.stclairsoft.Go64
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=2560 flags=0x10000(runtime) hashes=69+7 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha256=3e39c465a06ea00880ac5b0d3c4aba523b70e49a
Hash choices=sha256
CDHash=3e39c465a06ea00880ac5b0d3c4aba523b70e49a
Signature size=8987
Authority=Developer ID Application: St. Clair Software (7HK42V8R9D)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Dec 7, 2020 at 5:13:14 PM
Info.plist entries=27
TeamIdentifier=7HK42V8R9D
Runtime Version=11.0.0
Sealed Resources version=2 rules=13 files=48
Nested=Frameworks/Sparkle.framework
Nested=MacOS/Go64Search
Internal requirements count=1 size=180


Jack Brindle
 

That is the issue! Your post jogged my memory. The older versions of macOS need SHA1, but the Apple Silicon version of macOS doesn’t do SHA-1. Apple switched over to SHA-256 several years ago, maintaining both in the system. But, it looks like they didn’t maintain the SHA-1 for Apple Silicon systems. It may be very important to keep an Intel Mac around to handle builds for the foreseeable future.

Jack.

On Dec 7, 2020, at 5:52 PM, Jon Gotow <gotow@stclairsoft.com> wrote:

On Dec 7, 2020, at 3:58 PM, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

Jon, have you been able to isolate the difference between the two executables?
OK - so I went back and re-signed a known-working build of the app on both machines, just to make sure there weren't any inadvertent build differences caused by building the app with two different versions of Xcode (12.2 on the DTK machine, 12.2 beta 3 on the MacBook Pro). After re-signing them, I zipped both copies of the app and uploaded them to a server, then downloaded them onto an old MacBook Pro running macOS 10.10 Yosemite.

As before, the copy of the app that was code-signed on the DTK machine is reported as damaged when I double-click it to run it on Yosemite, while the copy that was code-signed on my 15" MacBook Pro launches correctly on Yosemite. Both machines where I did the code signing were running macOS 11.1 beta (20C5061b). I checksummed /usr/bin/codesign and the executables on both machines are the same, though they're presumably running different code since codesign is a universal binary.

Using 'codesign -dvvv --deep <appname>.app' (full output below) reveals that the working copy of the app includes both sha1 and sha256 hashes, while the non-working one only includes a sha256 hash. So does Yosemite not like sha256?

- Jon



For completeness, here are the commands I used to sign the code:

codesign -f -s "Developer ID Application: St. Clair Software (7HK42V8R9D)" --timestamp -o runtime Go64.app/Contents/Frameworks/Sparkle.framework/Resources/Autoupdate.app
codesign -f -s "Developer ID Application: St. Clair Software (7HK42V8R9D)" --timestamp -o runtime Go64.app/Contents/Frameworks/Sparkle.framework
codesign -f -s "Developer ID Application: St. Clair Software (7HK42V8R9D)" --entitlements Go64.entitlements --timestamp -o runtime Go64.app

And here are the results of displaying the results with codesign:

----- Copy of Go64 that works on Yosemite -----
Executable=/Volumes/StClairSW/Downloads/codesign test/Go64-Good.app/Contents/MacOS/Go64
Identifier=com.stclairsoft.Go64
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=2560 flags=0x10000(runtime) hashes=69+7 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=128f8fc1408c76dabe1875e3898c8c5b15c05746
CandidateCDHash sha256=11ce01c6847639cee4bd45b20f3aec69cc367f82
Hash choices=sha1,sha256
CDHash=11ce01c6847639cee4bd45b20f3aec69cc367f82
Signature size=9067
Authority=Developer ID Application: St. Clair Software (7HK42V8R9D)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Dec 7, 2020 at 6:31:38 PM
Info.plist entries=27
TeamIdentifier=7HK42V8R9D
Runtime Version=11.0.0
Sealed Resources version=2 rules=13 files=48
Nested=Frameworks/Sparkle.framework
Nested=MacOS/Go64Search
Internal requirements count=1 size=180


----- Copy of Go64 that does not work on Yosemite -----
Executable=/Volumes/StClairSW/Downloads/codesign test/Go64-Bad.app/Contents/MacOS/Go64
Identifier=com.stclairsoft.Go64
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=2560 flags=0x10000(runtime) hashes=69+7 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha256=3e39c465a06ea00880ac5b0d3c4aba523b70e49a
Hash choices=sha256
CDHash=3e39c465a06ea00880ac5b0d3c4aba523b70e49a
Signature size=8987
Authority=Developer ID Application: St. Clair Software (7HK42V8R9D)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Dec 7, 2020 at 5:13:14 PM
Info.plist entries=27
TeamIdentifier=7HK42V8R9D
Runtime Version=11.0.0
Sealed Resources version=2 rules=13 files=48
Nested=Frameworks/Sparkle.framework
Nested=MacOS/Go64Search
Internal requirements count=1 size=180






Jon Gotow
 

Seriously? I have to keep an Intel machine around just to do release builds that will run on older macOS versions? Is there any chance of getting SHA-1 checksums added in the Apple Silicon version of codesign if we file bugs?

- Jon

On Dec 7, 2020, at 7:20 PM, Jack Brindle via groups.io <jackbrindle=me.com@groups.io> wrote:

That is the issue! Your post jogged my memory. The older versions of macOS need SHA1, but the Apple Silicon version of macOS doesn’t do SHA-1. Apple switched over to SHA-256 several years ago, maintaining both in the system. But, it looks like they didn’t maintain the SHA-1 for Apple Silicon systems. It may be very important to keep an Intel Mac around to handle builds for the foreseeable future.


Keary Suska
 

Supported encryption algorithms have nothing to do with hardware architecture. They are purely software. There is no reason that an M1 machine can’t generate a SHA-1 hash. Perhaps it was removed from the newer Xcode version? Or support for it was removed from underlying system support for the newer system? In any case, that would definitely call for an entry in the release notes. Searching them might tell you what OS/Xcode versions will generate a supported hash.

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"

On Dec 7, 2020, at 8:26 PM, Jon Gotow <gotow@stclairsoft.com> wrote:

Seriously? I have to keep an Intel machine around just to do release builds that will run on older macOS versions? Is there any chance of getting SHA-1 checksums added in the Apple Silicon version of codesign if we file bugs?

- Jon


On Dec 7, 2020, at 7:20 PM, Jack Brindle via groups.io <jackbrindle=me.com@groups.io> wrote:

That is the issue! Your post jogged my memory. The older versions of macOS need SHA1, but the Apple Silicon version of macOS doesn’t do SHA-1. Apple switched over to SHA-256 several years ago, maintaining both in the system. But, it looks like they didn’t maintain the SHA-1 for Apple Silicon systems. It may be very important to keep an Intel Mac around to handle builds for the foreseeable future.





Marco S Hyman
 

Supported encryption algorithms have nothing to do with hardware architecture. They are purely software. There is no reason that an M1 machine can’t generate a SHA-1 hash.
Except that SHA-1 is “fully and practically broken for use in digital signatures”.

https://eprint.iacr.org/2020/014.pdf

I don’t see Apple or anyone else add SHA-1 to anything at this late date.


Mark Allan
 

On 8 Dec 2020, at 2:20 am, Jack Brindle via groups.io <jackbrindle@...> wrote:

That is the issue! Your post jogged my memory. The older versions of macOS need SHA1, but the Apple Silicon version of macOS doesn’t do SHA-1. Apple switched over to SHA-256 several years ago, maintaining both in the system. But, it looks like they didn’t maintain the SHA-1 for Apple Silicon systems. It may be very important to keep an Intel Mac around to handle builds for the foreseeable future.

Jack.

That doesn't explain my issue with installer packages though. When I take the last known working pkg (built using Xcode 12.0 under macOS 10.15.7) and open it on 10.10, if I click the certificate icon in the upper-right corner, I can see that it says 
Signature Algorithm: SHA-256 with RSA Encryption ( 1.2.840.113549.1.1.11 )

Surely that means 10.10 is able to handle SHA 256.

Also, last night I installed Xcode 12.2 on my iMac (which I haven't upgraded to macOS 11 yet), and if I build the installer package there, it works fine on 10.10. So the only difference between the two build machines (both Intel) is that my MBP is running macOS 11 and the iMac is running 10.15.7.  The iMac produces a perfectly usable installer package for 10.10 all the way up to macOS 11 including Apple Silicon, but the MBP seems to produce something which is only valid for most OSes, but not 10.10 or 10.11


On 7 Dec 2020, at 9:48 pm, Alex Zavatone via groups.io <zav@...> wrote:

Out of curiosity, do you have an older copy of the installer that works on those platforms?

You may be able to open it up and view the entitlements/config files and see the differences.

What's the best way to do that? Using `pkgutil --expand` just gives me the payload, distribution.xml and resources. None of which show any appreciable differences.

Using `pkgutil --verbose --check-signature` just reports
Status: invalid signature
For the one built under macOS 11.

One option is to create a VM with one of those operating systems on it and install a version of Xcode that works on 10.10 and 10.11, then deliver these special case installers or create installers that work on that OS and see what the difference is.

I keep around old 50 GB VMWare images and old Xcode installers just in case.

Yeah, I do that too. I already have a bunch of VMs for testing (going all the way back to 10.6.8!) and an additional one running macOS 10.13 for building a version that runs on 10.6.8 - 10.9.5. I don't desperately want to introduce yet another non-scriptable step to my build process for something that really feels like a bug in the OS or build tools.

Cheers
Mark


Mark Allan
 

Sorry, just to clarify...
On 8 Dec 2020, at 10:49 am, Mark Allan via groups.io <markjallan@...> wrote:

Using `pkgutil --verbose --check-signature` on macOS 10.10 or 10.11 just reports
Status: invalid signature
for the one built under macOS 11.

When using any other version of the OS, it says Status: signed by a developer certificate issued by Apple for distribution and shows the certificate chain.


Mark Allan
 

I'm beginning to think there's something wrong with the 'codesign' tool on macOS 11. One of my other build scripts for the same app iterates through a directory of additional binaries and libraries to codesign them prior to being archived. (find .... exec /usr/bin/codesign ...  )

The codesign tool reports no error whilst signing, but the resulting archive fails notarisation because of a number of unsigned embedded files. Sometimes they all get signed correctly, sometimes one or more files are missed and don't end up getting signed.

Again, this worked 100% of the time over the last few years until I upgraded to macOS 11.

On 8 Dec 2020, at 10:52 am, Mark Allan via groups.io <markjallan@...> wrote:

Sorry, just to clarify...
On 8 Dec 2020, at 10:49 am, Mark Allan via groups.io <markjallan@...> wrote:

Using `pkgutil --verbose --check-signature` on macOS 10.10 or 10.11 just reports
Status: invalid signature
for the one built under macOS 11.

When using any other version of the OS, it says Status: signed by a developer certificate issued by Apple for distribution and shows the certificate chain.



Jon Gotow
 

On Dec 8, 2020, at 7:51 AM, Mark Allan <markjallan@gmail.com> wrote:

I'm beginning to think there's something wrong with the 'codesign' tool on macOS 11. One of my other build scripts for the same app iterates through a directory of additional binaries and libraries to codesign them prior to being archived. (find .... exec /usr/bin/codesign ... )
Yes, that was my point in my (overly long) reply earlier. The _only_ thing different about the two builds was in codesign. The apps were exactly the same otherwise. The failing copy of my app was signed with macOS 11.1's codesign on Apple Silicon, while the successful one was signed on an Intel machine running 11.1. So codesign has changed.

The codesign tool reports no error whilst signing, but the resulting archive fails notarisation because of a number of unsigned embedded files. Sometimes they all get signed correctly, sometimes one or more files are missed and don't end up getting signed.
In Quinn's unofficial post on the do's and don'ts of code signing, he says not to use the --deep argument, but instead create a script that signs all necessary executables from the inside out (see https://developer.apple.com/forums/thread/128166). Are you signing individual embedded files of your .pkg as necessary, or relying on --deep to do it for you?

- Jon


Jack Brindle
 

I would definitely file a bug report. At the least you may learn why they didn’t use SHA-1 in the Apple Silicon version of codesign.

The big surprise to me is that the Intel version does allow SHA-1. My initial understanding was that it didn’t, but you have shown their inconsistency in the implementation.
We know that SHA-1 is broken and no longer secure, which pretty much now makes codesigning with it useless.

Please let us know what Apple says in response to your ticket.

Jack

On Dec 7, 2020, at 7:26 PM, Jon Gotow <gotow@stclairsoft.com> wrote:

Seriously? I have to keep an Intel machine around just to do release builds that will run on older macOS versions? Is there any chance of getting SHA-1 checksums added in the Apple Silicon version of codesign if we file bugs?

- Jon


On Dec 7, 2020, at 7:20 PM, Jack Brindle via groups.io <jackbrindle=me.com@groups.io> wrote:

That is the issue! Your post jogged my memory. The older versions of macOS need SHA1, but the Apple Silicon version of macOS doesn’t do SHA-1. Apple switched over to SHA-256 several years ago, maintaining both in the system. But, it looks like they didn’t maintain the SHA-1 for Apple Silicon systems. It may be very important to keep an Intel Mac around to handle builds for the foreseeable future.





Jack Brindle
 

I agree with Quinn on this one. If you bring in any libraries, especially any that are previously codesigned, —deep WILL break their signing. With the addition of system extensions and imported libraries, it becomes very important to not modify or replace any of the previously-signed bundles/libraries, or your app will simply not work under Big Sur. Figuring out why Gatekeeper didn’t allow your app to launch can waste considerable time and sanity. Don’t ask how I know this…
I now make sure that we do not use —deep in our code signing, but instead walk the tree of all bundles/libraries and make sure they are signed, or if they are known to be previously signed, don’t re-sign them.

One other thing I have learned recently - for the first time, provisioning profiles are important on the Mac. All the things the iOS devs have gone through in learning how to handle them we will be going through over time. Gatekeeper has changed our world, and is much more stringent on Big Sur. Properly codesigning is the only way to tackle it.

Jack

On Dec 8, 2020, at 9:05 AM, Jon Gotow <gotow@stclairsoft.com> wrote:

On Dec 8, 2020, at 7:51 AM, Mark Allan <markjallan@gmail.com> wrote:

I'm beginning to think there's something wrong with the 'codesign' tool on macOS 11. One of my other build scripts for the same app iterates through a directory of additional binaries and libraries to codesign them prior to being archived. (find .... exec /usr/bin/codesign ... )
Yes, that was my point in my (overly long) reply earlier. The _only_ thing different about the two builds was in codesign. The apps were exactly the same otherwise. The failing copy of my app was signed with macOS 11.1's codesign on Apple Silicon, while the successful one was signed on an Intel machine running 11.1. So codesign has changed.

The codesign tool reports no error whilst signing, but the resulting archive fails notarisation because of a number of unsigned embedded files. Sometimes they all get signed correctly, sometimes one or more files are missed and don't end up getting signed.
In Quinn's unofficial post on the do's and don'ts of code signing, he says not to use the --deep argument, but instead create a script that signs all necessary executables from the inside out (see https://developer.apple.com/forums/thread/128166). Are you signing individual embedded files of your .pkg as necessary, or relying on --deep to do it for you?

- Jon






Alex Zavatone
 

On Dec 8, 2020, at 11:39 AM, Jack Brindle via groups.io <jackbrindle=me.com@groups.io> wrote:


One other thing I have learned recently - for the first time, provisioning profiles are important on the Mac. All the things the iOS devs have gone through in learning how to handle them we will be going through over time. Gatekeeper has changed our world, and is much more stringent on Big Sur. Properly codesigning is the only way to tackle it.

Jack
It’s now time to remind everyone why I like this tool so much.

https://github.com/chockenberry/Provisioning

It lets you select a provisioning profile in the Finder and press the space bar to preview its contents. It also works on certs.

There are some newer forks of the repo which may be more useful, but this has been a godsend for me in the past.

Cheers,
Alex Zavatone


Sak Wathanasin
 



On 8 Dec 2020, at 10:49, Mark Allan <markjallan@...> wrote:

Surely that means 10.10 is able to handle SHA 256.



Not necessarily: I think the 10.15 codesign generates both SHA1 & SHA256 sigs, and the macOS 11 codesign on the TDK at least only generates SHA256.

I've been follwoing this thread with great interest since pur apps have pretty similar requirements. At the moment none of our build boxes are running macOs 11.x, but we may have to update at least 1 to support iOS builds.

So, this afternoon, I tried building our (macOS) app on the DTK box (running 11.0.1). So far, I'd only been using it for testing, so had to install Xcode 12.2, the certs etc etc. Our app also has embedded dylibs, Finder sync extension, privileged helper tool etc all of which is signed from the inside-out by a build script written in python. The script also (optionally) notarizes the built packages.

The good news is that it all still works: the resulting package is notarized and stapled; the bad news is that, as expected, the package will not open in 10.11 (and presumably earlier).

I'm not sure why your script has trouble with the signing - some difference in behaviour between zsh & bash possibly? Does signing the recalcitrant dylibs in the Terminal work?

 Regards
Sak Wathanasin
Network Analysis Limited           http://www.network-analysis.ltd.uk