Adding Info.plist to an executable

[SachaGoldman]

I'm using pyinstaller to create subroutines for a macOS application I'm making. I'm compiling using --onefile I'm wondering theres a way to include an Info.plist in the binary? I'm asking this to try to get around the issue described here.

I've tried a couple of tools that try to let you inject an Info.plist directly into the compilled binary with no luck (I'm still open to suggestions though).

Been stuck on this problem for quite some time and haven't found a solution so any help would be appricated.

[rokm]

I've tried a couple of tools that try to let you inject an Info.plist directly into the compilled binary with no luck (I'm still open to suggestions though)

Are you sure it is Info.plist (or lack thereof) that is the problem, then? The linked SO discussion seems to be about entitlements (or lack thereof), which you can set by passing entitlements file to codesign when signing your executable or app bundle.

Because PyInstaller onefile executables may present additional issues (more on that in next paragraph), I would strongly suggest you to first try with a simple C-compiled hello-world executable, to figure out what you really need to get it working.

In PyInstaller's onefile mode, the collected binaries (e.g., shared libraries) are collected into executable-embedded archive and extracted to temporary directory when executable is being run. I imagine macOS requires these binaries to be signed and entitled as well. And unlike onedir builds, you cannot do this post-hoc, because you have no access to these embedded files. PyInstaller develop branch has new command-line options, --codesign-identity and --osx-entitlements-file that allows you to sign the collected binaries. Perhaps that will help.

[rokm]

If I understand you correctly those options are compatible with --one-file and don't require the --windowed option?

Yes, those options are independent of --windowed.

What windowed does on macOS is, it adds additional clause to the .spec file so that after a "regular" build (onefile or onedir) is made, the resulting frozen program (single binary in onefile mode, whole dist dir in onedir mode) is also used to create an .app bundle. So the end result are both dist/program and dist/program.app.

[SachaGoldman]

An update:

The app does in fact pass app review with the extra flags! Thank you very much for your help.

[SachaGoldman]

It appears the app passing App Review was a fluke. It seems theres an error:

It does seem like the binaries (including those created dynamically at runtime) are getting signed correctly with the correct entitlements. I suspect that I'm missing an entitlement or using the wrong code sign identity.

Code sign identity:
Developer ID Application: John Doe (1111111111)

Entitlements:
entitlements.txt

I'm again somewhat lost...

[rokm]

Hmm, it did seem a bit too easy to be true...

Below are some guesses on my part (disclaimer: I'm not an Apple developer, and have no practical experience with Apple store and related verification, notarization, etc. procedures).

I guess Python here refers to the python shared library that's part of the frozen helper application, and that was extracted to temporary directory when the helper was launched. Does "Show in Finder" open this temporary directory? If it does, try opening the same location in terminal, and check whether the libraries inside (Python in particular) have correct signature and entitlements (using codesign utility). If you cannot access the temporary directory, then you can use pyi-archive_viewer utiity to extract Python from the frozen helper's executable, and do the same checks. This is to ensure that the onefile-embedded libraries actually do have proper signature in entitlements (whatever the "proper" entitlements in this case may be?).

Another thing to consider is, does sandboxed app bundle even allow a helper process to load shared libraries from temporary directory? It kind of seems to me that this could be used to cheat the whole Apple store verification process; they can directly analyze your bundle and the helper executable itself, but unless they run it and do some run-time analysis on the files that the helper extracts when launched, one could smuggle practically anything past the verification...

Does submission to app store modify the bundle and its executables in any way (i.e., add an attribute, or additional signature, or something along those lines)? Because if it does, then onefile helper won't work, as the embedded libraries are definitely missing that modification.

At any rate, google search for "X can't be opened because Apple cannot check it for malicious software." seem to indicate that this is either a problem with signature, or with the quarantine xattr flag (`com.apple.quarantine˙) being set on the file (which could be the case for onefile-embedded stuff extracted to temporary directory).

[SachaGoldman]

I was able to make it pass app review by not using one --onefile. This way the binaries were not created dynamiaclly and the com.apple.quarantine flag was avoided. This solution is still somewhat flawed because it means there are many binaries in the package, but it does work.

If I find a way to get things working with --onefile I'll update this thread.