codesign stubbornly failing

I have a few resources to share with you:

• Placing content in a bundle explains how bundles should be structured.
• Creating distribution-signed code for macOS and Packaging Mac software for distribution explain how to manually sign code.
• Embedding nonstandard code structures in a bundle offers advice on how to deal with non-Apple code structures, like the ones used by Python.

You have a couple of choices here:

• You can strictly follow the rules in Placing content in a bundle, which is a bunch of extra work right now but will likely work better in the long term.
• You can bend those rules by simply signing your code as it’s currently structured.

Based on the script you included, it looks like you’re attempting the second approach. It’s likely you’ll be able to make that work, but that script will need significant enhancement. For example, Creating distribution-signed code for macOS explains that you need to sign code from the inside out from a dependency perspective, and your script is doing it from a file system hierarchy perspective.

Can you share a copy of your app here? I’m talking about the .app bundle prior to you running your script over it. I’d like to get a better handle on what py2app is doing these days.

If not, that’s cool. At some point I’ll find the time to play around with py2app myself.

If so, you’ll need to upload it to a file sharing service and post a link. Post that link in the clear, per tip 14 of Quinn’s Top Ten DevForums Tips.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks for the provided links! Makes sense that the signing needs to be from the dependencies backwards. Regarding placing of the content, I think py2app does a good job with that. Especially the log states there is some signing happening already. Of course I can provide you with a copy, the project is open source anyway. Here is the zipped .app: http://dreisicht.net/share/renderrob.zip

the project is open source anyway.

Yeah, but if you send me a binary then I don’t have to mess around with build systems (-:

Here is the zipped .app

Thank you!

This layout is much what I’d expected:

Note I’m using the FindMachO.sh script from here.

Or, as a hierarchy:

That is, you have a vast array of code embedded within the Contents/Resources directory. It’s feasible to sign and distribute this. It doesn’t follow the rules in Placing content in a bundle, but this particular structure is tolerable, at least for the moment [1].

So, to sign this you need to generate a list of these code items, sort them in dependency order, and sign each one in that order. This is pretty much the process described in Creating distribution-signed code for macOS.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] The other way around, placing data is locations reserved for code, is much more problematic.

Thank you for your answer. I tried signing the files in ascending order, meaning so sign all files first, and the directory above it. Unfortunately no change in the result though. Is there a way to get more information about why the "Developer ID Certificate" is invalid?

If you run "codesign" on your executable, it tells you exactly what the problem is:

/tmp $ codesign -vv -R="anchor apple generic" renderrob.app
renderrob.app: unsealed contents present in the root directory of an embedded framework
In subcomponent: /private/tmp/renderrob.app/Contents/Frameworks/Python.framework

If you explore that framework using Terminal, you'll see what it's complaining about:

/tmp $ find /private/tmp/renderrob.app/Contents/Frameworks/Python.framework
...
/private/tmp/renderrob.app/Contents/Frameworks/Python.framework/Versions/._Current
/private/tmp/renderrob.app/Contents/Frameworks/Python.framework/._Resources
/private/tmp/renderrob.app/Contents/Frameworks/Python.framework/._Python

Remove those files and try again:

/tmp $ rm /private/tmp/renderrob.app/Contents/Frameworks/Python.framework/Versions/._Current
/tmp $ rm /private/tmp/renderrob.app/Contents/Frameworks/Python.framework/._Resources
/tmp $ rm /private/tmp/renderrob.app/Contents/Frameworks/Python.framework/._Python
/tmp $ codesign -vv -R="anchor apple generic" renderrob.app                                 
renderrob.app: a sealed resource is missing or invalid
file added: /private/tmp/renderrob.app/Contents/Resources/lib/python3.11/._site.pyc
file added: /private/tmp/renderrob.app/Contents/Frameworks/._libmpdec.4.dylib

Almost there. Keep removing those dot files...

/tmp $ rm /private/tmp/renderrob.app/Contents/Resources/lib/python3.11/._site.pyc
/tmp $ rm /private/tmp/renderrob.app/Contents/Frameworks/._libmpdec.4.dylib
/tmp $ codesign -vv -R="anchor apple generic" renderrob.app                      
renderrob.app: valid on disk
renderrob.app: satisfies its Designated Requirement
renderrob.app: explicit requirement satisfied

Now you're good to go. Or at least, ready to notarize.

Something in your toolchain is trying to create resource forks inside a zip file incorrectly. Are you building some of this on a non-Mac platform? I made a point to double-click your zip file to unzip using the expected procedure. I think you can use "ditto" on the command line to achieve the same result, but not "unzip". When using Finder, I shouldn't ever get those kind of dot files. (And for the record, they aren't even correctly structured dot files.)

I understand a lot of internet folks don't like Xcode. I've got a long list of Xcode complaints myself. But I still use it because, even at its worst, it's better than anything else. I have a very complex project under development that was designed to use some of the most gnarly Linux/open-source build platforms ever known. It's bit the bullet and took the time to port it all to Xcode. It just insane how much better Xcode is at this. Those poor Linux masochists have no idea.

Thanks for your answer. I removed the files you mentioned and get the same positive output from codesign -vv, but it doesn't make any difference regarding the notarization process. I tried using Xcode for the signing, but it seems like it's not compatible with what Qt offers.