-
-
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
PyOpenSSL / CFFI freezes when running codesigned x64 binary on M1/Rosetta. #8099
Comments
Doesn't CFFI compile stuff on the fly? In that case, the resulting on-the-fly-compiled binary it generates is very likely not signed (with your codesign identity), and I would expect it to cause issues? But if it works on the corresponding native platform (i.e., signed x86_64 build running on x86_64 Mac and signed arm64 build running on Apple Silicon Mac), then perhaps that's a Rosetta issue? |
Yeah – as you said, x86_64 on x86_64 and arm64 on arm64 both work. x86_64 python on arm64 (without pyinstaller) also works, despite Rosetta. |
Are you sure x86_64 works on x86_64, though? On my test x86_64 system, it also seems to get stuck until I remove the signature from the executable... |
Yes, both locally and in CI. The GitHub Actions run linked above is one example. |
That's largely irrelevant, though, because you don't have signing in python (nor hardened run-time that comes with it, when you use PyInstaller's --codesign-identity). |
Also as a side note, .zip file fails to preserve symbolic links in the generated frozen application bundle. This might not have been issue with older PyInstaller versions that had no notion of symbolic links, but it is with PyInstaller >= 6.0. |
Well, like I said, it gets stuck on my x86_64 test system as well, and I can see the system log spamming the following:
So I'm still leaning towards this being an issue with CFFI-generated binary not being signed. I'm actually surprised it works on arm64, although perhaps the catch is that on arm64 CFFI at least ad-hoc codesigns the binary (since on arm64, a valid signature, even if an ad-hoc one, has been a hard requirement since its introduction), but apparently on x86_64, it does not. Can you check if you get similar errors in the system log with Rosetta as well? |
Perhaps you need to look into adding proper entitlements when signing the application? E.g., Or maybe omit |
Yes!
And Yes! This fixes it, wonderful. I didn't expect the lack of entitlements to manifest in a hang, but I'll take it. 🎉 Thank you so much for the super super speedy and helpful replies, this has been fantastic! 🍰 ✨ 😃 |
@mhils I've been struggling with the same sort of issue for a few weeks. Can you please give any other details on your use case? For instance: Is the reason you (presumably) aren't using inheritance-based entitlements, because the binary is the main executable of your app, and so is implementing its own entitlements? When I test the PyInstaller-bundled app directly, using its own entitlements rather attempting to inherit (i.e. as required when launching a helper process from the Xcode-built parent app, but fails), it passes library validation and doesn't hang. If you have any insight into possible causes or solutions for this issue, they would be much appreciated (even if to help rule something out). |
@petiatil: We're not using inheritance-based entitlements because we don't have an [Xcode-built] parent app. It's the main app. Sorry, that's probably not too helpful for your case. 😶 |
Description of the issue
PyInstaller's codesigning causes hangs with PyOpenSSL/cffi code when running macOS x86_64 binaries on Apple Silicon (M1) using Rosetta.
Context information (for bug reports)
pyinstaller --version
:pyinstaller 6.2.0
A minimal example program which shows the error
Here is a full reproducers for arm-based Macs:
Additional observations:
venv-x64/bin/python repro.py
works flawlessly.--codesign-identity
, the binary works locally (but cannot be distributed).chmod +x repro/repro && /usr/bin/xattr -dr com.apple.quarantine repro && repro/repro
)Stacktrace / full error message
None. The program just hangs with high CPU utilisation.
The text was updated successfully, but these errors were encountered: