PyInstaller 4.5.1 "codesign failure!" on macos #6167
Comments
Can you figure out where the offending
I suppose if you don't care about binaries not being code signed (even ad-hoc), you could comment the raise of |
|
I have no idea what is this file, I have searched for it in the machine and this is what I have found I really don't want to start editing the code to disable the codesign, why in 4.3 everything is working? |
Because in 4.3, we do not (re-)sign the binaries we collect. |
Can you attach the Also, what macOS version are you using? |
|
My build passes on my MacOS 11.5.2 machine but fails on my OSX 10.13.6 VM: And the same failure but for Swapping from ad-hoc signing to self-signed passed as expected. |
|
@lachyc How can I use "self-signed" instead of "ad-hoc" ? |
|
This does look like an issue with
Does the self-signed app work correctly, though? If signing identity is provided, we turn on hardened runtime, and according to my tests, that did not work with self-signed certificate... |
Running pyinstaller 4.5.1 with a self-signed certificate on 10.13 generates an app that runs on both 10.13 and 11.5.2 for me. Edit: Building on 11.5.2 with a self-signed cert works too. I am generating a single binary rather than a .app bundle in case that makes any difference! |
|
Hmm, interesting. Thanks for the input. On my test High Sierra system, ad-hoc or self-signed makes no difference; the re-signing fails in both cases. Actually, I suspect that it is the removal of the signature (which we perform prior to other modifications) that somehow corrupts the file with that version of
On my test Big Sur system, a onedir console application, signed with self-signed certificate, fails to launch. But I remember that I initially overlooked the problem as well, because I had previously disabled gatekeeper via |
|
But back to the original issue, if it is the signature removal that We definitely need to remove signature (if present) from the bootloader due to the way we "hide" the appended archive inside the executable. But for collected binaries, perhaps just forcing a re-sign after modifying headers, without prior removal of signature, might do the trick as well. @arossert and @lachyc, can you try patching your pyinstaller installations on High Sierra to comment out this line: pyinstaller/PyInstaller/building/utils.py Line 389 in 5a02f55 It seems to fix the codesign errors on my test system (with ad-hoc signing), and the resulting signatures on collected binaries as well as the whole frozen application seem to be OK. |
|
@rokm After commenting out the line from my env this is what I'm getting: |
|
Hmmm, odd. Disabling signature removal for collected binaries should not have any effect on the generated frozen executable itself... Unless, is this a onefile build? In that case, binaries would have been processed before the executable, which means that this is an additional error... Can you try the following:
Do either of the two attempts generate the sanity check error? |
|
I'm using onedir and not onefile This is the first command output: And the second one: |
|
This looks like the
Then upload both But you could probably work around this issue by not having a signed bootloader in the first place. I.e, by downloading the sdist (or creating a git checkout for 4.5.1 tag), rebuilding the bootloader locally ( |
|
Here are the files: |
|
Thanks for the files. The sanity check fails because after |
|
Can you check if fixes in these branches (the first is based on https://github.com/rokm/pyinstaller/tree/robustify-macos-assembly-pipeline |
|
@rokm I have tried the first branch |
|
I've tested the 5.0.dev0 version of PyInstaller on a Mac Mini running macOS 10.13.6 with Python3.9.7 installed. The resulting single folder version is over 2.05GB. This is primary because of this file: binascii.cpython-39-darwin.so which is 2.03GB. It runs reasonably fast. The single file form is only 12.3MB but runs very, very slowly e.g. 35 seconds to get version on the Python app. Is that normal ? Is it due to Python3.9 or some other factor ? |
Can you compare the sizes of binary extensions (e.g., It could be that such corrupted files end up compressing very well, and that's where the difference between onedir and onefile is coming from. |
In the Python framework "lib-dynload" folder, that file is 53KB. In the onedir list it's 2.03GB. I've checked 7 other library files – two had different files sizes: _lzma.cpython-39-darwin.so which is 258,096 bytes in the installed framework and 257,264 bytes in the onedir libs. "_ssl.cpython-39-darwin.so" is 187,504 bytes and 186,672 bytes respectively. Without the binascci file, the entire folder in the onedir lib-dynload is 6,764,064 bytes. The installed framework lib-dynload folder is 8,063,344 bytes. BTW,
The singlefile build on Catalina is only 7.7MB. Cheers. |
I'm trying to build my application on macOS and I'm getting this error with the latest PyInstaller 4.5.1, it is working on PyInstaller 4.3
Is there a way to work around it?
PyInstaller: 4.5.1
Python: 3.7.9
OS: macOS
The text was updated successfully, but these errors were encountered: