base_library.zip should be in the Contents/Resources not Contents/MacOS folder else codesigning is fragile [includes workaround]

[mshunshin]

When using pyinstaller to make a MacOS application which will then be signed and distributed, having base_library.zip in the Contents/MacOS folder can cause problems.

When signing applications, files in Contents/MacOS that are Mach-O get modified with a signitures. Files in Resources have their signature added to Contents/_CodeSignature/CodeResources

The base_library.zip file in Contents/MacOS ends up with its signature as an extended attribute.

If the application during distribution transitions via a distribution mechanism that strips extended attributes then verificaiton at the other end will fail.

codesign --deep --force --verify --sign "Developer ID Application: Joe Bloggs (##########)" "My App.app"

This works
codesign --verify --verbose=4 MyApp.app

Simulate transitioning via a filesystem that does not preserve extended attributes
xattr -cr ./MyApp.app

This now fails
codesign --verify --verbose=4 MyApp.app

MagiQuant.app: code object is not signed at all
In subcomponent: /##/##/##/###/MyApp.app/Contents/MacOS/base_library.zip

[Solution]
If you move base_library.zip to Contents/Resources
Then provide a soft link:
cd Contents/MacOS
ln -s ./../Resources/base_library.zip base_library.zip

It will now be signed without requiring extended attributes and will be much more robust in distribution.

In patricular, using Disk Utility to create a new DMG with default options then copying out the App causes these attributes to be lost.

[htgoebel]

Some of the OS X people needs to verify this. @mshunshin: We'd appreciate a pull-request for a sulution.

[mshunshin]

In PyInstaller/building/osx.py there is a specific line to exclude base_library.zip from being symlinked. The comment specifies is for a Python 3 reason - but cant see the specific issue. The patch would be just removing this check (so delete this one line) - but I am loath to do it without understanding why it was specifically put there in the first place. @springermac made this commit. There is even a comment about codesigning above it - so clearly somone has been down this path before.

[cbenhagen]

Maybe @springermac can remember why he excluded base_library.zip from symlinking in Python 3? Symlinking it does work for us in Python 3 and fixes our notarization issues.

[Legorooj]

@mshunshin is this still valid now?

[mshunshin]

Sorry - haven’t used pyinstaller since my first comment, fixing it, and distributing the software - so can’t comment if any changes.

…

On 26 Feb 2020, at 05:03, Legorooj ***@***.***> wrote: @mshunshin is this still valid now? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[Legorooj]

Ok then. I'll close now, but reopen if someone produces the problem with py3 and PyInstaller dev

[cbenhagen]

@Legorooj please reopen. I can reproduce the issue and fix it by linking like explained in the issue.

Guess we can remove base_library.zip from

pyinstaller/PyInstaller/building/osx.py

Line 177 in 555c5e8

if typ == 'DATA' and base_path not in ('base_library.zip', 'PySide2', 'PyQt5'):

unless someone has a good reason not to link it.

[Legorooj]

@cbenhagen ok. Please submit a PR!