I agree with your general thrust, but I don’t see how your point refutes mine. First, it’s not required to actually run the package. Installing it is sufficien

I agree with your general thrust, but I don’t see how your point refutes mine. First, it’s not required to actually run the package. Installing it is sufficient. All package managers that I worked with so far can run code at install time. Second, the issue here seems to be a misconfiguration that makes pip look up a private package that should be retrieved from a private repository on the public repository. The attacker then just registers a malicious package on the public repo with the same name. Preventing this attack requires that python is correctly configured on each an every developer machine - something that I’d never rely on as cornerstone of my security. Third: This is one example of smuggling a malicious package on a developers machine. Another vector is that a good package turns into a malicious package with an update. That’s even harder to defend against - pulling in the update with the programming languages standard tooling may run malicious code. You can certainly first download the package, unpack and inspect it and then pull the update - but would you rely on thousands of developers diligently doing that? Last: this class of error affects almost all programming language package managers out there. So it’s better to assume that this will happen, take a local compromise of a developers machine as a matter of when, and mitigate what the attacker can do with the capabilities they gain from this compromise.