Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

arstechnica.com

Post reply on HN
Print view View original

41–47 of 47 posts

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

#41

Post by maxerickson »

TZubiri wrote: post #23
seabrookmx wrote: post #7

Earlier quoted context omitted.

You're not the only one! This is why I strongly prefer languages with a comprehensive standard library. I trust my Python/golang/dotnet/whatever install, so the number of third party packages I need to pull in is much smaller and more easily audited.

I build python servers. I've replaced most of the dependencies with just standard library code. Removed Flask for http.server Removed requests for urllib Removed requirements.txt Removed pip Life is good

I use urllib.request to avoid having a dependency in little scripts, but I can't say I think that requests is a big supply chain risk.

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

#42

Post by benglish11 »

maxerickson wrote: post #41
TZubiri wrote: post #23

Earlier quoted context omitted.

I build python servers. I've replaced most of the dependencies with just standard library code. Removed Flask for http.server Removed requests for urllib Removed requirements.txt Removed pip Life is good

I use urllib.request to avoid having a dependency in little scripts, but I can't say I think that requests is a big supply chain risk.

It may not be the request package itself but a sub dependency. It only has a few from looking at the repo but something like flask can have a lot (especially with the plugins) and that’s a mainstream and well supported library

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

#43

Post by PuercoPop »

louislang wrote: post #10
nerdwaller wrote: post #5

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…

this is still true of node/npm. It's also true of Cargo (Rust), Nuget (C#), and a handful of others. I'd say it's probably the _norm_ for most ecosystems to allow some form of pre/post-install execution.

For what is worth in nix after the code is downloaded the code is built in a sandbox without network access. So one does have a viable alternative for Rust.

And is true that most package managers for popular language allow arbitrary code execution during the install process. That is how husky adds git hooks to the developers machines.

For example in Ruby I need to patch the Kafka gem, karafka because it downloads, builds and stores librdkafa.so in the gem's directory.

I understand that this as well as the husky example comes from a desire to make developer lifes easier but I'd rather we erred on the side of caution. Making sure that software builds without access to the network and without being able to modify your system (ej. Adding files to $HOME)

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

#44

Post by nerdwaller »

Denvercoder9 wrote: post #11
nerdwaller wrote: post #5

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?

The issue isn't when you get what you're wanting. The issue is when either you accidentally get something you didn't want (such as type-o squatting - a not too distant issue on PyPi) or a package was published maliciously (imagine bumping a patch version and it being compromised) - a few fairly recent issues on npm.

I agree that the happy path is ideal and hopefully the common case. Regardless, anything with access to production secrets for my team is run on the most minimal image possible (and none of those secrets are available during dependency installation and compilation).

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

#45

Post by JohnFen »

cqqxo4zV46cp wrote: post #35
JohnFen wrote: post #12

Earlier quoted context omitted.

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.

From your perspective, the application itself is untrusted un-vetted third-party code until you yourself have vetted it, no? The fact that you also have to vet dependencies is meaningless implementation detail. You’ve got a bucket of code, you want to run it on your machine, and you decide that you want to vet it first. How does a package boundary change that? You’re describing security theatre.

> The fact that you also have to vet dependencies is meaningless implementation detail.

I disagree. minimizing dependencies means reducing the risk exposure. That's not meaningless.

What I'm really talking about is a cultural change where package managers have made it so easy to just throw a package at a problem that devs tend to do this too much. People using packages to do simple things, people using packages without understanding what the packages do, etc.

Every time an application uses a library or package of any sort, that decreases the security of the application. So it's a tradeoff, and I think that too many devs ignore or forget that there's a tradeoff here and just go for "install a package/library to do it" as if it were cost-free.

Minimizing the use of external code is not security theater at all. It's good practice. I think avoiding applications that use languages and platforms where lots of external code is common and expected is a reasonable thing. It's absolutely not a complete security solution, but it does reduce the risk.

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

#46

Post by mensfeld »

PuercoPop wrote: post #43
louislang wrote: post #10

Earlier quoted context omitted.

this is still true of node/npm. It's also true of Cargo (Rust), Nuget (C#), and a handful of others. I'd say it's probably the _norm_ for most ecosystems to allow some form of pre/post-install execution.

For what is worth in nix after the code is downloaded the code is built in a sandbox without network access. So one does have a viable alternative for Rust. And is true that most package managers for popular language allow arbitrary code execution during the install process. That is how husky adds git hooks to the developers machines. For example in Ruby I need to patch the Kafka gem, karafka because it downloads, bu…

Hey, you have to patch nothing. Nix support was merged to karafka two months ago.

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

#47

Post by nerdwaller »

g_p wrote: post #37
lmm wrote: post #17

Earlier quoted context omitted.

> 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.

And this is a very sensible precaution where developer environments have SSH keys and other privileged credentials available and exposed in predictable locations, ready for exfiltration over the unfiltered internet connection that developers insist on having available. Hopefully the VM/container run environment is also in a network-isolated environment too, so it can only be accessed and invoked through the expected…

The types of secrets ought to be a bit different and less consequential on a developer's machine. If they're not, that's a pretty big red flag. It's one thing to gain access to clone some repositories (e.g. ~/.ssh) but an entirely different thing to get production aws credentials. Not to mention all the other protections that should be in place that mitigate the fallout (for example: no pushes to main/master/prod branches, requiring status checks and reviews before merges, etc).
Post reply on HN