In general I don’t find the idea that generating docs involves running arbitrary code surprising,

I misunderstood this originally. The problem is not that it runs arbitrary code to generate the docs (if you’re importing a package, you’re letting the author of the that package [and, by extension, the docs for that package] run arbitrary code anyway, because Python does not have a capability model). The problem is that the docs tool reads files matching a specific name in the current directory and executes them. If someone manages a drive-by download exploit on your browser (I think Safari is still the only mainstream browser that requires you to confirm per site that you want to allow it to download files) then they can drop a file like this in your downloads directory, and if you run the docs command in your downloads directory then you’re owned. Fortunately, it only checks the current directory and not arbitrary parents (as the git vulnerability a month or two ago did), so dropping a file like this in ~/Downloads doesn’t exploit you if you look at docs in ~/Downloads/SomePythonPackage-1.2.3.4/)

It works for me on Debian 11 and Ubuntu 22. And it also works for “python3 -m http.server”.

Which OS do you use? Can you try running it in a Debian container?

When I do, it also works for me:

docker run --rm -it debian:11-slim
apt update -y && apt upgrade -y
apt install -y python3
echo 'print("P0wned");exit()' > collections.py
python3 -m http.server
P0wned

I also cannot reproduce—not on macOS 12.6.1 with python 3.10.8 and not on Debian 11 with python 3.10.5. (My shell is bash on both systems, though I doubt that matters.)

I wonder what other variables are at play.

Yes, if you write the python command by hand and are aware of the issue, you can probably mitigate it.

The tricky thing is that the python call might be somewhere in a shellscript you use.

The issue actually came up when an irc user reported his computer goes bananas when he cds into a certain dir. Turned out he was using a tool that executes some Python onevery cd. In that dir, there was a “types.py”. And the shellscript ran some Python that imported “types”.

If using an older version of Python (I still run py36-py38), an alternative solution is to add an extra import hook (via sys.meta_path, but an extra FileFinder in sys.path_hooks might also be enough) before the defaults to avoid this behavior.

I’ve stubbed my toe on this “feature” of Python’s import system enough times to write a custom import hook: https://github.com/ahgamut/cosmopolitan/blob/importer-cosmo/third_party/python/Lib/importlib/_bootstrap.py#L1089

Why does this happen? When running “import foo”, what python (approximately) does is the following:

• Python looks through its sys.meta_path entries to see if any of them can handle importing foo (example if foo involves a dynamic shared object, you’d need an entry that calls dlopen).
• how does the entry check if it can handle the import? It does a few checks (is foo compiled within the default libpython.so or is it frozen bytecode?) or sometimes just attempts the import outright with a try-except fallback
• the last sys.meta_path entry is usually the one that walks through the files and folders on your filesystem and this is where the whole PYTHONPATH/PYTHONSAFEPATH gimmick comes into play: Python checks the entries of sys.path (which is influenced by the env vars) one-by-one for foo.py, and the first entry in sys.path is usually "." i.e. the current directory. this is why when you have a types.py in your current directory and a script does import types, you get the local file instead of the types module from the stdlib.

Therefore to avoid this mistake we can add an entry at the start of sys.meta_path or sys.path_hooks that checks the “safe” locations first, before punting to the latter entries that use the local directory

To avoid the inverse of this mistake (ie I want to import my local foo.py but name clashes with stdlib), I try to import .foo or from . import foo but usually I just rename the local file :P

The older -I flag is a bit more comprehensive and was updated to imply -P.