The peril of unquoted Python strings, and how they caused CVE-2024-9287

This is not about "unquoted Python strings".

It is about unquoted shell arguments, in the context of invoking the shell using Python's `subprocess` standard library. The title is grossly misrepresentative, and the substance is missing the point. There is nothing special about Python here; causing a string to contain quotes works much the same way as in other popular languages. Besides, `subprocess.run` et. al. make use of the shell opt-in; the default behaviour is to pass arguments to a named executable directly. Typically, correct function requires those arguments not to have quotes (for the shell to remove them, among other processing, when the shell is used). The article then spends way too long, and too much formatting, on explaining what is really a very simple concept. We don't need a "part" for every few sentences and code example.

The "koan" presentation also strikes me as very strange for a simple warning about a practical security risk. There is no need for deep philosophical thinking here. Just recognize the problem and follow the associated best practices.

Regarding the CVE, it's hard to imagine a circumstance in which an "attacker-controlled virtual environment" isn't already game over. In fact, the exploit relies on the attacker being able to create a virtual environment, which in any normal situation already implies full shell access. An exploit like this is basically only relevant to a situation in which party A exposes an interface to party B for creating virtual environments, then expects party C to run code in the resulting environment. So, basically, people providing third-party CI systems, which are already fraught with trust and supply-chain issues. And even then, using virtual environments doesn't generally require the activation script at all, and well-written automation probably shouldn't use it, because it needlessly introduces a state dependency.