PEP 832: Go back to a .venv redirect file

[brettcannon]

• Change is either:
  • To a Draft PEP
  • To an Accepted or Final PEP, with Steering Council approval
  • To fix an editorial issue (markup, typo, link, header, etc)
• PR title prefixed with PEP number (e.g. PEP 123: Summary of changes)

[read-the-docs-community]

Documentation build overview

📚 pep-previews | 🛠️ Build #34439875 | 📁 Comparing e7563aa against latest (24419b9)

  🔍 Preview build  

1 file changed

± pep-0832/index.html

[westurner]

This (.venv redirects) would not be safe if it were to default to being on by default?

I've used virtualenvwrapper and my custom (pre- venv stdlib module) venv module (now venvw, I guess) for years and this is just now an issue because I want to use uv and uv uses .venv by default; but I've always suspected that that isn't best, so here's this:

• Relevant issues:
  • How to manage two uv environments under one project? astral-sh/uv#15672
  • How to manage two uv environments under one project? astral-sh/uv#15672 (comment)
    • uv-virtualenvwrapper
    • uv-workon
• Better interoperability with pipenv python-virtualenvwrapper/virtualenvwrapper#114
• always sourcing .env files is a dangerous workflow pattern
  • though it's true that an evil user could just modify the source of appname,
    it is still best to not always source .env files that can contain code.
    (This is also why declarative pyproject.toml is at least supposedly more safe than procedural setup.py)
  • virtualenvwrapper exists basically in order to not always source (user-writeable) .env files?
    virtualenvwrapper exists basically in order to not always source (user-writeable) .env files that are user-modifiable or remote-repo-determined?
    • virtualenvwrapper sources $VIRTUAL_ENV/bin/postactivate on workon venvname
      • WORKON_HOME=$HOME/.virtualenvenvs workon venvname
VIRTUAL_ENV=WORKON_HOME/venvname
• Given:
  • _SRC=${VIRTUAL_ENV}/src
    • $VIRTUAL_ENV/bin/pip install -e https://github.com/psf/requests#egg=requests or
      $VIRTUAL_ENV/bin/python -m pip install -e https://github.com/psf/requests#egg=requests
      installs into $VIRTUAL_ENV/src
  • a _WRD (working directory)
    _WRD=${_SRC}/appname
_WRD=${VIRTUAL_ENV}/src/appname
• It is very common for developers to chmod -R u+rw "${_WRD}" and run the app as the same user.
• chmod -R u+rw

From the PEP https://peps.python.org/pep-0832/#security-implications :

Security Implications

If tools blindly overwrite .venv, that could be a denial of service attack if a user happened to use that directory for something else. The expectation, though, is that would occur very rarely due to the convention of .venv being used for virtual environments. If tools are concerned about this issue then they can prompt the user before creating an environment at a location that already exists.

Normally this is solved by the installer determining where files are placed, not each package. But this is a development workflow, so

Another concern would be using a relative path in a .venv redirect file that is checked into version control. That could result in escaping the project and somehow using a virtual environment elsewhere on the machine. But that would require the user to implicitly trust the files in the repository which is already a security risk.

Still this:

though it's true that an evil user could just modify the source of appname,
it is still best to not always source .env files that can contain code.

Tools need to treat the contents of a .venv redirect file as path data rather than command-line syntax. Interpolating those contents into a shell command could allow a malicious redirect file to execute arbitrary commands.

This file format might as well not be Python-specific? So, CFG (INI?), JSON, YAML, TOML; what's fastest and most portable?

It would be best to indicate which tool was used to build the venv, but there again that inversion of control is a risk that is normally solved with review at packaging time?

[westurner]

IIRC I had a similar discussion with @kennethreitz about why autoenv is dangerous compared to virtualenvwrapper, but in practice $VIRTUAL_ENV/bin is also user-writeable (for example even in devcontainers with rootless podman)

[westurner]

Isn't this the same issue, too?

• PEP 796: Relative Virtual Environments #4476
• https://github.com/python/peps/pull/4476/changes

[brettcannon]

@westurner please provide feedback on discuss.python.org so others can participate.