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

Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

github.com

Post reply on HN
Print view View original

181–190 of 569 posts

Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

#181

Post by kleton »

detente18 wrote: post #99

LiteLLM maintainer here, this is still an evolving situation, but here's what we know so far: 1. Looks like this originated from the trivvy used in our ci/cd - https://github.com/search?q=repo%3ABerriAI%2Flitellm%20trivy... https://ramimac.me/trivy-teampcp/#phase-09 2. If you're on the proxy docker, you were not impacted. We pin our versions in the requirements.txt 3. The package is in quarantine on pypi - this block…

There are hundreds of PRs fixing valid issues to your github repo seemingly in limbo for weeks. What is the maintainer state over there?

Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

#182

Post by binsquare »

vladvasiliu wrote: post #128
binsquare wrote: post #109

Earlier quoted context omitted.

So... I'm working on an open source technology to make a literal virtual machine shippable i.e. freezing everything inside it, isolated due to vm/hypervisor for sandboxing, with support for containers too since it's a real linux vm. The problems you mentioned resonated a lot with me and why I'm building it, any interest in working to solve that together?: https://github.com/smol-machines/smolvm

What would the advantage of this be compared to using something like a Firecracker backend for containerd?

Run locally on macs, much easier to install/use, and designed to be "portable" meaning you can package a VM to preserve statefulness and run it somewhere else.

worked in AWS and specifically with firecracker in the container space for 4 years - we had a very long onboarding doc to dev on firecracker for containers... So I made sure to focus on ease of use here.

Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

#183

Post by jerf »

amelius wrote: post #113
jFriedensreich wrote: post #86

We just can't trust dependencies and dev setups. I wanted to say "anymore" but we never could. Dev containers were never good enough, too clumsy and too little isolation. We need to start working in full sandboxes with defence in depth that have real guardrails and UIs like vm isolation + container primitives and allow lists, egress filters, seccomp, gvisor and more but with much better usability. Its the same requir…

We need programming languages where every imported module is in its own sandbox by default.

Now is probably a pretty good time to start a capabilities-based language if someone is able to do that. I wish I had the time.

Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

#184

Post by zparky »

kleton wrote: post #181
detente18 wrote: post #99

LiteLLM maintainer here, this is still an evolving situation, but here's what we know so far: 1. Looks like this originated from the trivvy used in our ci/cd - https://github.com/search?q=repo%3ABerriAI%2Flitellm%20trivy... https://ramimac.me/trivy-teampcp/#phase-09 2. If you're on the proxy docker, you were not impacted. We pin our versions in the requirements.txt 3. The package is in quarantine on pypi - this block…

There are hundreds of PRs fixing valid issues to your github repo seemingly in limbo for weeks. What is the maintainer state over there?

Not really the time for that. There's also PRs being merged every hour of the day.

Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

#185

Post by amelius »

jFriedensreich wrote: post #131
amelius wrote: post #113

Earlier quoted context omitted.

We need programming languages where every imported module is in its own sandbox by default.

We have one where thats possible: workerd (apache 2.0) no new language needed just a new runtime

I mean, the sandboxing aspect of a language is just one thing.

We should have sandboxing in Rust, Python, and every language in between.

Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

#186

Post by GrayShade »

Imustaskforhelp wrote: post #115
outside2344 wrote: post #112

Earlier quoted context omitted.

Is it just in 1.82.8 or are previous versions impacted?

1.82.7 is also impacted if I remember correctly.

1.82.7 doesn't have litellm_init.pth in the archive. You can download them from pypi to check.

EDIT: no, it's compromised, see proxy/proxy_server.py.

Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

#187

Post by cpburns2009 »

GrayShade wrote: post #186
Imustaskforhelp wrote: post #115

Earlier quoted context omitted.

1.82.7 is also impacted if I remember correctly.

1.82.7 doesn't have litellm_init.pth in the archive. You can download them from pypi to check. EDIT: no, it's compromised, see proxy/proxy_server.py.

1.82.7 has the payload in `litellm/proxy/proxy_server.py` which executes on import.

Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

#188

Post by binsquare »

jFriedensreich wrote: post #162
binsquare wrote: post #109

Earlier quoted context omitted.

So... I'm working on an open source technology to make a literal virtual machine shippable i.e. freezing everything inside it, isolated due to vm/hypervisor for sandboxing, with support for containers too since it's a real linux vm. The problems you mentioned resonated a lot with me and why I'm building it, any interest in working to solve that together?: https://github.com/smol-machines/smolvm

Thanks for the pointer! Love the premise project. Just a few notes: - a security focused project should NOT default to train people installing by piping to bash. If i try previewing the install script in the browser it forces download instead of showing as plain text. The first thing i see is an argument # --prefix DIR Install to DIR (default: ~/.smolvm) that later in the script is rm -rf deleting a lib folder. So if…

Love this feedback, agree with you completely on all of it - I'll be making those changes.

1. In comparison with colima with krunkit, I ship smolvm with custom built kernel + rootfs, with a focus on the virtual machine as opposed to running containers (though I enable running containers inside it).

The customizations are also opensource here: https://github.com/smol-machines/libkrunfw

2. Good call on that description!

I've reached out to you on linkedin

Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

#189

Post by saidnooneever »

bognition wrote: post #155
detente18 wrote: post #99

LiteLLM maintainer here, this is still an evolving situation, but here's what we know so far: 1. Looks like this originated from the trivvy used in our ci/cd - https://github.com/search?q=repo%3ABerriAI%2Flitellm%20trivy... https://ramimac.me/trivy-teampcp/#phase-09 2. If you're on the proxy docker, you were not impacted. We pin our versions in the requirements.txt 3. The package is in quarantine on pypi - this block…

The decision to block all downloads is pretty disruptive, especially for people on pinned known good versions. Its breaking a bunch of my systems that are all launched with `uv run`

known good versions and which are those exactly??????

Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

#190

Post by michh »

kleton wrote: post #181
detente18 wrote: post #99

LiteLLM maintainer here, this is still an evolving situation, but here's what we know so far: 1. Looks like this originated from the trivvy used in our ci/cd - https://github.com/search?q=repo%3ABerriAI%2Flitellm%20trivy... https://ramimac.me/trivy-teampcp/#phase-09 2. If you're on the proxy docker, you were not impacted. We pin our versions in the requirements.txt 3. The package is in quarantine on pypi - this block…

There are hundreds of PRs fixing valid issues to your github repo seemingly in limbo for weeks. What is the maintainer state over there?

increasing the (social) pressure on maintainers to get PRs merged seems like the last thing you should be doing in light of preventing malicious code ending up in dependencies like this

i'd much rather see a million open PRs than a single malicious PR sneak through due to lack of thorough review.

Post reply on HN