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.
toggle quoted messageShow quoted text
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!
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.....
On 8 Dec 2020, at 5:39 pm, Jack Brindle via groups.io <email@example.com> 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.
On Dec 8, 2020, at 9:05 AM, Jon Gotow <firstname.lastname@example.org> wrote:
On Dec 8, 2020, at 7:51 AM, Mark Allan <email@example.com> wrote: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.
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.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?