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


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


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



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



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


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










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