Live data from Hacker News

PyPI halted new users and projects while it fended off supply-chain attack

arstechnica.com

11–20 of 47 posts

Re: PyPI halted new users and projects while it fended off supply-chain attack

#11
post #2

Am I the only one who is scared by the entire ecosystem of "drag random crap and dependencies off the Internet from who the hell knows"? I've had a couple of minor incidents with NodeJS dependencies over the last few years on this front which sort of opened my eyes to running untrusted code. I tend to err on the side of distribution packages since, with the restrictions that imposes on what I do.

Some packaging ecosystems are more risky than others, primarily because they allow running arbitrary code at some point during the install cycle. Node and Python being two notable ones, especially considering how commonly they are used[1]. Others do it more safely where, at a minimum, no code can run until the library is imported and run with application code. Depending on how and where you deploy, you can mitigate s…

I'm not convinced of the additional danger in letting packages run code during installation. You install them because you want to use them, so the code they ship will get run anyway. Are there really common environments where the final product only gets run with less permissions than the package manager?

Re: PyPI halted new users and projects while it fended off supply-chain attack

#12
post #2

Am I the only one who is scared by the entire ecosystem of "drag random crap and dependencies off the Internet from who the hell knows"? I've had a couple of minor incidents with NodeJS dependencies over the last few years on this front which sort of opened my eyes to running untrusted code. I tend to err on the side of distribution packages since, with the restrictions that imposes on what I do.

You're not the only one. I have become hesitant to use applications developed in certain languages and ecosystems (like Python) because they encourage the prolific use of unvetted code not under the control of the developer, although there is no real safe space anymore. It's a cultural shift that has affected almost everything.

Re: PyPI halted new users and projects while it fended off supply-chain attack

#13

Earlier quoted context omitted.

Some packaging ecosystems are more risky than others, primarily because they allow running arbitrary code at some point during the install cycle. Node and Python being two notable ones, especially considering how commonly they are used[1]. Others do it more safely where, at a minimum, no code can run until the library is imported and run with application code. Depending on how and where you deploy, you can mitigate s…

I'm not convinced of the additional danger in letting packages run code during installation. You install them because you want to use them, so the code they ship will get run anyway. Are there really common environments where the final product only gets run with less permissions than the package manager?

Most any deployment based setup will have a separation between the code that is executed on the developer's machine and the code that is run on a built application?

Yes, it is common for developers to have some unit/build testing setup available so that they can run the code locally, but even that should be done by a system that makes sure anything actually running during the test is declared as part of the project workspace.

More directly, it is common for many package managers to try and do a global install of some things. If not global for the computer, for the current user. Thankfully, this is changing a lot. (At least, I think it is?)

Re: PyPI halted new users and projects while it fended off supply-chain attack

#14

I think people should stop using PyPI altogether. It's full of abandoned garbage and malware because there's really no filter on who can upload what. I don't even use it to search for packages anymore. If Linux distro packaging worked the same way, Linux would be a hellscape of malware and weird random broken apps. I'd rather use old software than constantly worry about fat fingering a package name and ending up with…

> I think people should stop using PyPI altogether

Sorry if this is a naive question, but what would the alternative be?

Re: PyPI halted new users and projects while it fended off supply-chain attack

#15
post #13

Earlier quoted context omitted.

I'm not convinced of the additional danger in letting packages run code during installation. You install them because you want to use them, so the code they ship will get run anyway. Are there really common environments where the final product only gets run with less permissions than the package manager?

Most any deployment based setup will have a separation between the code that is executed on the developer's machine and the code that is run on a built application? Yes, it is common for developers to have some unit/build testing setup available so that they can run the code locally, but even that should be done by a system that makes sure anything actually running during the test is declared as part of the project w…

How does that add any danger? You're pulling in code because you want to use it. If the package is malicious and your package manager doesn't have post-install scripts, the malicious code is just going to run 5 seconds later when you import it and start working with it.

In the case of NPM with post-install scripts disabled, you'll simply get pwned when you `npm start` rather than `npm install`.

Re: PyPI halted new users and projects while it fended off supply-chain attack

#16
post #2

Am I the only one who is scared by the entire ecosystem of "drag random crap and dependencies off the Internet from who the hell knows"? I've had a couple of minor incidents with NodeJS dependencies over the last few years on this front which sort of opened my eyes to running untrusted code. I tend to err on the side of distribution packages since, with the restrictions that imposes on what I do.

Looks absolutely insane to me too. Recently I had to deal with a NPM-based theme for a minor website. It downloaded 140 dependencies. Most of them were trivial like "string-width", which finds the visual width of a character (some Unicode characters may appear as double-width). The package consists of a rather simple 25-line function that tests a character against several if-s in a loop. A function that trivial does not justify adding +1 to the potential sources of supply-chain attacks.

Re: PyPI halted new users and projects while it fended off supply-chain attack

#17

Earlier quoted context omitted.

Some packaging ecosystems are more risky than others, primarily because they allow running arbitrary code at some point during the install cycle. Node and Python being two notable ones, especially considering how commonly they are used[1]. Others do it more safely where, at a minimum, no code can run until the library is imported and run with application code. Depending on how and where you deploy, you can mitigate s…

I'm not convinced of the additional danger in letting packages run code during installation. You install them because you want to use them, so the code they ship will get run anyway. Are there really common environments where the final product only gets run with less permissions than the package manager?

> Are there really common environments where the final product only gets run with less permissions than the package manager?

Yes, only running the final product in a VM/container is pretty common.

Re: PyPI halted new users and projects while it fended off supply-chain attack

#18
post #13

Earlier quoted context omitted.

I'm not convinced of the additional danger in letting packages run code during installation. You install them because you want to use them, so the code they ship will get run anyway. Are there really common environments where the final product only gets run with less permissions than the package manager?

Most any deployment based setup will have a separation between the code that is executed on the developer's machine and the code that is run on a built application? Yes, it is common for developers to have some unit/build testing setup available so that they can run the code locally, but even that should be done by a system that makes sure anything actually running during the test is declared as part of the project w…

Deployments are irrelevant for this conversation; libraries get to run code there anyway. For code execution during installation to be an attack vector, you'd need an environment where npm install gets run with _more_ permissions than npm start (or the equivalent for other package managers). I can't really think of an environment where that is the case. Usually the build and package manager is more restricted than the application, not the other way around.

Re: PyPI halted new users and projects while it fended off supply-chain attack

#19

I think people should stop using PyPI altogether. It's full of abandoned garbage and malware because there's really no filter on who can upload what. I don't even use it to search for packages anymore. If Linux distro packaging worked the same way, Linux would be a hellscape of malware and weird random broken apps. I'd rather use old software than constantly worry about fat fingering a package name and ending up with…

Isn't this the case for most programming languages' package indices? crates.io for Rust, the NPM registry for Javascript, etc. They are all public in the sense that anyone can just create an account and upload a package.

Maven Central is notoriously fiddly to get an account for - it require a manual registration step and you have to GPG-sign all your packages. Seems like that barrier to entry may have been useful.

Re: PyPI halted new users and projects while it fended off supply-chain attack

#20
post #13

Earlier quoted context omitted.

Most any deployment based setup will have a separation between the code that is executed on the developer's machine and the code that is run on a built application? Yes, it is common for developers to have some unit/build testing setup available so that they can run the code locally, but even that should be done by a system that makes sure anything actually running during the test is declared as part of the project w…

Deployments are irrelevant for this conversation; libraries get to run code there anyway. For code execution during installation to be an attack vector, you'd need an environment where npm install gets run with _more_ permissions than npm start (or the equivalent for other package managers). I can't really think of an environment where that is the case. Usually the build and package manager is more restricted than th…

Right, my understanding is that this was not too uncommon for some older packages? Especially in early python, it was not too uncommon to accidentally install to the whole system, no?
Post reply on HN