Onefile on macOS with signing and notarization

[MarshalX]

Hi! I viewed a lot of historical issues and discussions, even on Google Groups from 2012, but I still can't get the answer to how to fix the gap in startup time when macOS tries to verify the executable file.

I use the same .spec file for macOS, Linux, and Windows. They are all using the same GitHub Actions pipeline. Each pipeline runs the result executable file with time and what I get:

Linux:

real	0m0.423s
user	0m0.378s
sys	0m0.045s

Windows (after signing):

real	0m0.714s
user	0m0.000s
sys	0m0.015s

macOS (after signing and notarizing):

real	0m3.418s
user	0m0.519s
sys	0m0.247s

I'm completely fine with onefile and time on Linux/Windows, but this is unbelievably slow on macOS. It easily could take up to 11 seconds to start. I started researching it and figured out that Apple send request each run. Blocking this request locally gives me a 1.5s startup. And that's how I found all related issues and discussions later.

This perfectly describes my issue (context: sign every binary file instead of only the main one):

I think that approach would solve a lot of problems for both this and app startup times (Catalina + single-file executable makes the startup time on Catalina take MINUTES -- because it has to phone home for virus check or some nonsense!!).
by @cculianu in #3991 (comment)

The Recipe OSX Code Signing wiki pages refer to the GitHub Gist I used to initially set my signing and notarizing flow. It uses codesign --deep --force. The results of the startup are above.

So I started thinking that --deep doesn't work well with onefile and tried --codesign-identity that has been added in #5581 by @rokm. It signs successfully (at least it doesn't throw errors), so I don't expect legacy problems with LINKEDIT from 2012 (ref)

Additionally, I signed the resulting onefile executable manually and notarized it after that. It passes checks via codesign -dv --verbose=4 file for signing and spctl -a -vvv -t install file for notarizing.

Unfortunately, the startup time doesn't change. Using the sniffing tool I can confirm that macOS still sends a request to Apple each run instead of caching in somehow or something.

The latest what I want to quote before asking a question is

PyInstaller has codesiging capabilities now (although macOS isn't generally suited to onefile mode - signed or otherwise)
by @bwoodsend in #4934 (comment)

I'll be happy to know the reason for the problems on macOS and onefile mode. So what is the reason and how we can deal with it? Is there a right way to sign and notarize executable files in onefile mode? Thanks!

upd. summoning @jiayouzl from #6801. Looks exactly what I have now but without details how to fix.

[rokm]

I'll be happy to know the reason for the problems on macOS and onefile mode. So what is the reason and how we can deal with it?

Even if you sign and notarize your onefile executable, the shared libs collected in the onefile executable are not notarized (even if you did sign them during collection using --codesign-identity). (And yes, --deep has effect only on macOS .app bundles - it recursively signs its contents; the codesign tool naturally knows nothing about PyInstaller and its onefile builds).

Is there a right way to sign and notarize executable files in onefile mode?

There is not. Like one of the quotes said, "macOS isn't generally suited to onefile mode".

[MarshalX]

but it will be not possible to staple a ticket to binaries :( and probably it will keep going to Apple servers to find the ticket on the launch

[rokm]

Yeah, if I were Apple, I would disallow such partial notarization of components, as the complete application might be more than the sum of its components.

[MarshalX]

so, did I understand correctly that every unpacking from onefile mode macOS gatekeeper thinks this is a brand new installation, and does verifications? and that costs time

[rokm]

so, did I understand correctly that every unpacking from onefile mode macOS gatekeeper thinks this is a brand new installation, and does verifications? and that costs time

Yes.

[MarshalX]

@rokm hi, sorry for bumping this thread again, but isn't feature like --onefile-tempdir-spec="%CACHE_DIR%/%COMPANY%/%PRODUCT%/%VERSION%" (from Nuitka) will help to deal with it? It will reuse the extracted and already verified files by Apple instead of extracting them again (and passing Apple verification one more time).

[rokm]

No, the temporary directory in onefile builds is never reused by design (even if you use --runtime-tmpdir, a different directory _MEIxxxxxx directory is created in there on each run), and that's not going to change. So if you want files to undergo Apple verification only once, use a onedir build.