Windows: convertenviron() doesn't parse environment variables properly

[vstinner]

BPO	39420
Nosy	@vstinner, @eryksun

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2020-01-24.08:57:53.147>
created_at = <Date 2020-01-22.15:10:19.368>
labels = ['invalid', 'library', '3.9']
title = "Windows: convertenviron() doesn't parse environment variables properly"
updated_at = <Date 2020-01-24.08:57:53.145>
user = 'https://github.com/vstinner'

bugs.python.org fields:

activity = <Date 2020-01-24.08:57:53.145>
actor = 'vstinner'
assignee = 'none'
closed = True
closed_date = <Date 2020-01-24.08:57:53.147>
closer = 'vstinner'
components = ['Library (Lib)']
creation = <Date 2020-01-22.15:10:19.368>
creator = 'vstinner'
dependencies = []
files = []
hgrepos = []
issue_num = 39420
keywords = []
message_count = 3.0
messages = ['360473', '360490', '360597']
nosy_count = 2.0
nosy_names = ['vstinner', 'eryksun']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue39420'
versions = ['Python 3.9']

[vstinner]

os.environ is created by convertenviron() of posixmodule.c. The Windows implementation calls _wgetenv(L"") to initialize _wenviron, and then parses the _wenviron string.

The _wenviron string is parsed by search for the first "=" character to split between the variable name and the variable value. For example, "USER=vstinner" is parsed as name="USER" and value="vstinner".

The problem is that the _wputenv() function allows to insert variable names containing the "=" character (but reject names starting with "=" character). Python can inherit an environment with a name containing "=".

One solution can be to use GetEnvironmentStringsW() which uses null characters to separate variable name and variable value. It returns a string like "name1\0value1\0name2\0value2\0\0": the string ends with a null character as well, to mark the end of the list.

https://docs.microsoft.com/en-us/windows/win32/api/processenv/nf-processenv-getenvironmentstrings?redirectedfrom=MSDN

Python 3.8 *explicitly* rejects variable names containing "=", at least on Windows, likely to workaround this issue. But another program can inject such variable in the environment.

Example with a Python modified to not reject explicitly "=" in the varaible name:
---

import subprocess, os, sys
os.putenv("victor=", "secret")
code = """import os; print(f"victor: {os.getenv('victor')!r}"); print(f"victor=: {os.getenv('victor=')!r}")"""
subprocess.run([sys.executable, "-c", code])

---

Output:
---
victor: '=secret'
victor=: None
---

Expected output:
---
victor: None
victor=: '=secret'
---

[eryksun]

The problem is that the _wputenv() function allows to insert variable
names containing the "=" character

No, it does not. Your experiments uncovered bugs elsewhere with the implementations of _wgetenv and WINAPI GetEnvironmentVariableW, but this isn't one of them. _wputenv(L"victor==secret") updates the OS environment by calling SetEnvironmentVariableW(L"victor", L"=secret"). That is the only correct result. A variable name is only allowed to contain "=" as the first character, where it is unambiguous. The first "=" beyond the first character must be the value delimiter.

[vstinner]

You're right, Windows works as expected. I close the issue.

See #18115 for more information.