-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base_library.zip should be in the Contents/Resources not Contents/MacOS folder else codesigning is fragile [includes workaround] #3550
Comments
Some of the OS X people needs to verify this. @mshunshin: We'd appreciate a pull-request for a sulution. |
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. |
Maybe @springermac can remember why he excluded |
@mshunshin is this still valid now? |
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.
|
Ok then. I'll close now, but reopen if someone produces the problem with py3 and PyInstaller dev |
@Legorooj please reopen. I can reproduce the issue and fix it by linking like explained in the issue. Guess we can remove pyinstaller/PyInstaller/building/osx.py Line 177 in 555c5e8
|
@cbenhagen ok. Please submit a PR! |
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.
The text was updated successfully, but these errors were encountered: