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

Shai-Hulud Themed Malware Found in the PyTorch Lightning AI Training Library

semgrep.dev

Post reply on HN
Print view View original

181–190 of 196 posts

Re: Shai-Hulud Themed Malware Found in the PyTorch Lightning AI Training Library

#181

Post by BigTTYGothGF »

SupLockDef wrote: post #73
fnoef wrote: post #55

Looks like coding is in a downward spiral towards complete chaos

When I was a kid, we've been told to be cautious with third party dependencies, that code can do anything and it's a risk to evaluate. With the new generation of yolo NPM scripters, they simply don't evaluate the risks. They will even fight back telling you that it's the way of doing things. In reality, it's the warning we learnt back then, that's the result of be mindlessly importing third dependencies without think…

> When I was a kid ... With the new generation

Let's be real tho, there's a whole lot of people who have been around enough to know better that do this too.

Re: Shai-Hulud Themed Malware Found in the PyTorch Lightning AI Training Library

#182

Post by BigTTYGothGF »

12_throw_away wrote: post #7
spate141 wrote: post #4

ah shit, here we go again

this is fine, we are definitely a perfectly normal industry that knows what it is doing

"No way to prevent this,' says only industry where this regularly happens.

Re: Shai-Hulud Themed Malware Found in the PyTorch Lightning AI Training Library

#184

Post by pxc »

imtringued wrote: post #141
crabbone wrote: post #64

Earlier quoted context omitted.

> Looking back ten years to `left-pad`, are there more successful attacks now than ever? I can't vouch for the number of attacks, but, and since we are talking about Python, nothing substantially changed since the time of `left-pad`. The same bad things that enabled supply chain attacks in Python ten years ago are in place today. However, it looks like there are more projects and they are more interconnected than bef…

virtualenv isn't relocatable out of the box, so how else would you deploy a python project? You can call it laziness, but it's not like the python ecosystem has ever developed an answer for this problem. The only reasonable answer has been to use docker, which is basically admitting that the python community did nothing.

> virtualenv isn't relocatable out of the box, so how else would you deploy a python project?

My team has a handful of Python projects. Here's how they work:

devenv.nix provides a Python runtime and all native dependencies, git hooks for linters and things like this. It integrates with direnv and the Python package manager (currently Poetry 1.x for older projects and uv for newer ones) so that when you cd in you get a virtualenv with everything you need, scripts in the project (or stubs for them) magically appear on your PATH so you don't need to use `uv run` or whatever it is for anything.

flake.nix provides a publishable artifact for projects that we run on workstations or servers. It autogenerates a Nix package from pyproject.toml and friends. You can reproducibly build it across platforms without virtualization, you can push it up to a binary cache and avoid source builds, whatever. It's great.

For projects that we run in cloud-native containers (for us AWS Fargate and AWS Lambda), we don't currently ship our own container images. We just publish zip files that we generate with a Poetry plugin that runs builds inside containers that have the same images as are used by AWS in its default runtime environments and push them up with the AWS CLI. The exact steps are stored as a Devenv script so the CI can be a one liner and you can run everything locally just like you would in CI.

> the python community did nothing

Python sucks.

But you can still represent your Python project as a proper Python package and get reproducible-ish build artifacts that are local-first and embrace Python-native tooling and ship it up to prod in a portable format with or without Docker. It only takes one engineer spending a day or two to work it out once for the whole team or maybe the whole company. You just need someone to be willing to RTFM on a package manager or two. The Python community seems to be largely lacking such people but your team doesn't have to be.

Re: Shai-Hulud Themed Malware Found in the PyTorch Lightning AI Training Library

#185

Post by hombre_fatal »

solid_fuel wrote: post #49
jackdoe wrote: post #22

I cant wait to have no dependencies. An extreme example is now when I make interactive educational apps for my daughter, I just make Opus use plain js and html; from double pendulums to fluid simulations, works one shot. Before I had hundreds of dependencies. Luckily with MIT licensed code I can just tell Opus to extract exactly the pieces I need and embed them, and tweaked for my usecase. So far works great for hobb…

And of course, you will go over every line of code that Opus produces with the same scrutiny we expect of open source maintainers, right? Right? I'm going to go publish some MIT-licensed remote access code and get that into Opus's training data.

Yes, I trust my LLM codegen and review process far more than the code I was never going to read from all of my transitive deps and every sequential update to them forever.

This is a trivial bargain for most libraries we were using not long ago out of convenience. Like a library just for setting ansi colors for your TUI.

Ideally you have minimal deps scoped to the truly hard things: libghostty, btrfs, luks, postgres, etc. Then you focus on the application and generate the mechanical glue code on demand with a solid harness that keeps the important stuff well-tested.

Though you’ll need to figure out how to build that harness/process before it really delivers.

Re: Shai-Hulud Themed Malware Found in the PyTorch Lightning AI Training Library

#186

Post by hombre_fatal »

kblissett wrote: post #28
Aperocky wrote: post #27

Earlier quoted context omitted.

I am torn because I like rust over go, and rust is better from an LLM perspective. But the dependency philosophy on rust is basically a security blackhole whereas go is much better.

I have found Go is an amazing language for LLMs. What do you prefer about Rust?

You can encode so much design and intent in the Rust type system. It’s one of the best things about Rust.

I prefer to write Go if I were doing everything by hand. But now everything is Rust. And a quick scroll through my Rust types, the discriminated union types, the discriminated error types, the high level application types, it’s just so much better for spec’ing out a system and leaving no question about what some bit of code is trying to do and the states it’s trying to prohibit.

And with an LLM, the hard things about Rust that would’ve had me asking questions on IRC are not hurdles anymore.

Granted, it has its own cultural NPM/RubyGem dep spam problem when you watch cargo install’s output.

Re: Shai-Hulud Themed Malware Found in the PyTorch Lightning AI Training Library

#187

Post by dragonwriter »

godelski wrote: post #127
jefftk wrote: post #113

Earlier quoted context omitted.

>This might just be the frequency illusion at play, but there seem to have been a number of high-profile supply chain attacks of late in major packages. It's real. As of the beginning of April we'd had 7 in the past 12 months vs 9 in the two decades before that: https://www.jefftk.com/p/more-and-more-extensive-supply-chai...

I think the real question is "are we just hearing about it more now or has the actual rate of attack increased?"

I think it is a real increase in the rate of detected attacks, not just awareness, but whether that’s an increase in vigilance or an increase in attacks is hard to know. I suspect both, of nothing else because awareness drives both vigilance and attackers inspired by the earlier attacks.

Re: Shai-Hulud Themed Malware Found in the PyTorch Lightning AI Training Library

#188

Post by srcreigh »

BigTTYGothGF wrote: post #179
jackdoe wrote: post #22

I cant wait to have no dependencies. An extreme example is now when I make interactive educational apps for my daughter, I just make Opus use plain js and html; from double pendulums to fluid simulations, works one shot. Before I had hundreds of dependencies. Luckily with MIT licensed code I can just tell Opus to extract exactly the pieces I need and embed them, and tweaked for my usecase. So far works great for hobb…

Now you're exposed to the real dependency, the browser.

Not to mention Claude

Re: Shai-Hulud Themed Malware Found in the PyTorch Lightning AI Training Library

#189

Post by SoftTalker »

CoastalCoder wrote: post #152
woodson wrote: post #119

Earlier quoted context omitted.

Not if one is running it in a non-privileged vm/container with restricted network access. But everything is YOLO these days.

Forgive the tangent, but I'm just starting to learn about using AI for coding, and getting a safe sandbox is one of my next steps. Any suggestions for a vm/container setup that works on a Linux host, provides the safety net you describe, and is still capable enough to try out all these things that people are talking about?

Easiest thing is to run your AI under a separate user identity, with its own home directory, and no sudo permission. Then it can't screw up your system or your own files.

Re: Shai-Hulud Themed Malware Found in the PyTorch Lightning AI Training Library

#190

Post by crabbone »

ifwinterco wrote: post #134
pxc wrote: post #110

Earlier quoted context omitted.

> It's not just common, it's almost universal to run `pip install` on production machines as a means of deploying a Python program. Maybe a Python culture problem; maybe a hallmark of Python's status as an "easy to hire for", manager-friendly, least common denominator blub language; maybe a risk that stems from the conveniences of interpreter languages... but this is such a shame in this day and age. It's seriously n…

"Almost universal" is a bit of a stretch, most of the time these days Python apps are deployed as Docker containers, and if you're using k8s this becomes effectively mandatory. However a lot of the time especially for older codebases the docker build will just run pip install from public pypi without a proper lockfile. So at least install code isn't being executed on your production machine, but still significant sur…

Well, the install code can leave some code behind that will be executed on the production machine... It doesn't really help being in a container. While a separate problem from Python ecosystem, people really put a lot more faith in isolation offered by containers than they should. Also, it's often very tempting to poke holes in that isolation because it's difficult and up to impossible sometimes to get things done otherwise.
Post reply on HN