-
Notifications
You must be signed in to change notification settings - Fork 777
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
⚠️ PyO3 0.23.0, 0.23.1, 0.23.2 have soundness bug in compile configuration #4757
Comments
fat finger submit, details incoming... |
This "only" impacts the situation where you're doing multiple builds in the same dir (or caching it), is that right? |
I don't think this is the root cause of issues in 0.23, but anyone who tries to set up free-threaded wheels may run into Quansight-Labs/setup-python#5 on Windows, which also affects CI environments setting up multiple python versions simultaneously. Just sharing here since others might be experimenting with building free-threaded wheels using Maturin. |
Yes, typically this would be due to using |
can this issue be closed now that 0.23.3 is live on crates.io ref #4745 (comment)? |
Yes, GitHub release now pushed and advisory PR up. I'll yank the affected versions and close this. rustsec/advisory-db#2159 |
Previous builds were corrupt when done with multiple interpreters at the same time (meaning while sharing cross-build state). This resolves segfaults seen with the latest rpds.py release, which we will yank, following PyO3 itself (which is yanking these versions). We should also generally reconsider doing these builds separately (using separate jobs for each interpreter). Closes: #112 Refs: PyO3/pyo3#4757 Refs: rustsec/advisory-db#2159
Details: PyO3/pyo3#4757 Signed-off-by: Panos Vagenas <[email protected]>
I've seen recent segmentation faults from builds shipped in watchfiles and jiter, as well as unexpected errors in pydantic-core's test suite.
My current hypothesis is that the root cause is #4497, which mistakenly changed reading of
PYO3_CONFIG_FILE
env var such that we don't emitcargo:rerun-if-changed
block for it.As such, wheels built in bulk for many interpreters with
maturin
are not rebuilt properly and all contain codecfg
-d for the first interpreter built for.I will continue to verify that this is the cause, and work on a patch ASAP.
I think we will need to yank 0.23.0 through 0.23.2 and file a security advisory, as wheels built with these versions are likely highly unstable and will fail in unpredictable ways.
The text was updated successfully, but these errors were encountered: