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


Mark Allan
 

Sorry to dredge up an old thread, but I'm still having issues with this.

I've worked out that I can do the Archive build on my main dev machine (running Xcode 12.x on macOS 11.1) and then copy the resulting .pkg file over to my iMac (still on 10.15) and run the `productsign` tool over there. Doing that allows the pkg installer to run correctly on macOS 10.10 all the way up to 11.1

I'd rather not have to rely on two separate machines in my build process though.

Does anyone else have any other suggestions?

Best regards,
Mark

On 9 Dec 2020, at 3:30 pm, Mark Allan via groups.io <markjallan=gmail.com@groups.io> wrote:

Yeah, I've seen --deep causing problems in the past. I'm using `find` to traverse the directory structure and calling codesign on each file in turn.

I've worked out why the notarisation bit no longer works though - in another part of my script, it strips off extended attributes just before tar'ing up the directory. This is something that was necessary in the past because xattrs used to cause problems with Installer.app on OS X 10.6.8. Removing the line that strips them off allows the notarisation to succeed.

Sure enough, running `ls -la@` on the directory gives the following extended attributes on some files...curiously not on all files, even though all files are signed!
com.apple.cs.CodeDirectory 136
com.apple.cs.CodeRequirements 220
com.apple.cs.CodeRequirements-1 172
com.apple.cs.CodeSignature 9001

This must be new behaviour with Xcode 12.2 rather than macOS 11 specific, as it does the same thing on 10.15.

Sadly, it doesn't get me any closer to being able to create an Installer .pkg file which opens in 10.10 and 10.11 though.....

Mark

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

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














Mark Allan
 

Yeah, I've seen --deep causing problems in the past. I'm using `find` to traverse the directory structure and calling codesign on each file in turn.

I've worked out why the notarisation bit no longer works though - in another part of my script, it strips off extended attributes just before tar'ing up the directory. This is something that was necessary in the past because xattrs used to cause problems with Installer.app on OS X 10.6.8. Removing the line that strips them off allows the notarisation to succeed.

Sure enough, running `ls -la@` on the directory gives the following extended attributes on some files...curiously not on all files, even though all files are signed!
com.apple.cs.CodeDirectory 136
com.apple.cs.CodeRequirements 220
com.apple.cs.CodeRequirements-1 172
com.apple.cs.CodeSignature 9001

This must be new behaviour with Xcode 12.2 rather than macOS 11 specific, as it does the same thing on 10.15.

Sadly, it doesn't get me any closer to being able to create an Installer .pkg file which opens in 10.10 and 10.11 though.....

Mark

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

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










Ben Kennedy
 

On 8 Dec 2020, at 9:55 am, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

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

https://github.com/chockenberry/Provisioning
FYI: this plugin no longer necessary; the functionality is now built in to MacOS.

(I don't know when it became standard, but I have no custom QL plugins any more on my 10.15 system and I get provisioning profile previews just fine.)

-ben


Jack Brindle
 

We are developing for non-App Store distribution. The app has a kext, which is being moved to a dext for Big Sur. The last big hurdle was getting the provisioning profile and entitlements right for Big Sur. The surprise was the need to add com.apple.application-identifier and com.apple.developer.team-identifier attributes to the entitlements file. These are automatically added by Xcode, but since we codesign externally, they were not in the file. They are now.

So, I am seeing it for pretty much all apps that need things that must be specified in a provisioning profile on the Mac. Primarily these are system extensions at the moment.

Jack


On Dec 8, 2020, at 11:58 AM, Sak Wathanasin <sw@...> wrote:



On 8 Dec 2020, at 17:39, Jack Brindle via groups.io <jackbrindle@...> 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.

Does this apply generally or just for AppStore apps?

Sak



Alex Zavatone
 

Sak, it might be worthwhile to make a clone of your working OS to an external and try updating that to 11. Or install VMWareFusion, and run the OS in a VM so that you can have the same OSes on your CI machine and just fire it up when needed.

Cheers,
Alex Zavatone

On Dec 8, 2020, at 1:57 PM, Sak Wathanasin <sw@...> wrote:



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



Sak Wathanasin
 



On 8 Dec 2020, at 17:39, Jack Brindle via groups.io <jackbrindle@...> 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.

Does this apply generally or just for AppStore apps?

Sak


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


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


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






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.





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


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.



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
 

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


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.


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.





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.


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
 

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


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.