[3.14] gh-151544: Fixes CVE-2026-12003 by removing the fallback to %VPATH%/Modules/Setup.local for discovering sources in getpath.py (GH-151545)#151565
Conversation
…ATH%/Modules/Setup.local for discovering sources in getpath.py (pythonGH-151545) (cherry picked from commit 9e863fa) Co-authored-by: Steve Dower <steve.dower@python.org>
|
I'm looking into the WASI failure. Best hint so far (thanks Brett!) is that the --argv0 option was added to the 3.15 build but isn't in earlier versions. That seems likely, as it would affect the |
| pybuilddir_txt = working_dir / "pybuilddir.txt" | ||
| if not pybuilddir_txt.exists(): | ||
| os.symlink(CHECKOUT / "pybuilddir.txt", pybuilddir_txt) | ||
| log("📝", f"Symlinked {pybuilddir_txt} to normal location") |
There was a problem hiding this comment.
@savannahostrowski @brettcannon Without the ../../Modules/Setup.local fallback (the security risk I'm fixing here) and without the --argv0 argument to fix up the path (not available in this version of wasmtime), this seems to be the best way to help it find pybuilddir.txt. Any thoughts/comments?
There was a problem hiding this comment.
not available in this version of wasmtime
The wasmtime version isn't locked, so you should be able to update it (might need CLI updates because there was a change to the format at some point).
| pybuilddir_txt = working_dir / "pybuilddir.txt" | ||
| if not pybuilddir_txt.exists(): | ||
| os.symlink(CHECKOUT / "pybuilddir.txt", pybuilddir_txt) | ||
| log("📝", f"Symlinked {pybuilddir_txt} to normal location") |
There was a problem hiding this comment.
not available in this version of wasmtime
The wasmtime version isn't locked, so you should be able to update it (might need CLI updates because there was a change to the format at some point).
| $(LINKCC) $(PY_LDFLAGS_NOLTO) -o $@ $(LIBRARY_OBJS_OMIT_FROZEN) \ | ||
| Programs/_bootstrap_python.o Modules/getpath.o $(LIBS) $(MODLIBS) $(SYSLIBS) | ||
| # Dummy pybuilddir.txt is needed for _bootstrap_python to be runnable | ||
| @echo "none" > ./pybuilddir.txt |
There was a problem hiding this comment.
If you're automatically doing this, then why the change to the build script?
There was a problem hiding this comment.
This is needed for all the other platforms, WASI needs extra work because it's apparently not "properly" changing the output location. I admit I haven't traced it all the way through, but the Makefile assumes the output is going to be in the root of the checkout, and it looks like the WASI build is putting the output binary deeper into the tree, when the way that's supported is to build out of tree with a reference back to the checkout.
But it ultimately is only an issue when argv[0] isn't valid, because that's how Python finds its way back to the rest of its files. I'll try updating wasmtime and fixing that, which ought to make the symlink redundant.
3 participants
(cherry picked from commit 9e863fa)
Co-authored-by: Steve Dower steve.dower@python.org