There's a big difference from a person downloading a package from a random site and running it, and a person adding a known internal package name to requirements.txt. The first is usually a bad idea (unless you know what you're doing and ready for the consequences) and every SWE worth Google money knows that. The second is a standard practice and everybody does that. You can't make stupid behavior impossible - but you can make common behavior safe, and that's the basis of good security.

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.

> 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

True enough. The problem is that a) it is a common misconfiguration and b) it appears to be also affecting Google, which is a big juicy target for any computer criminal. We're not talking about solving a theoretical problem in 100% of theoretical cases. We're talking about having a very practical vulnerability - which can be practically fixed. Yes, that doesn't fix all other theoretically possible vulnerabilities - so what? That's like arguing that since halting problem is unsolvable having debuggers and static analyzers is useless - we can't solve 100% of the problem, so why even bother to solve even 1%?

> Last: this class of error affects almost all programming language package managers out there.

Again, you're replacing a specific issue with a "class". Yes, you can't fix all the problems in the whole class. But you can very well fix this particular one, in many ways.

You could work with a whitelist or a build environment that is sandboxed somehow.

As I understand the article, the problem is that an employee machine is misconfigured and uses the public package repo for a private package. The package in question seems to be explicitly pinned in the requirements.txt - that’s essentially a whitelist. Whitelisting also suffers from the issue that a good public packages could at any time turn into a malicious package - so you’d need to pin the version. A task that seems infeasible for developer machines at googles scale.

Sandboxing the development environment could be done, but would only help against this attack if the sandbox cannot connect to the public internet- which again would be painful.

Googles strategy of accepting that this kind of breach will happen and rather focus on mitigation of the resulting damage seems like the better way.