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

471–480 of 569 posts

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

#471

Post by exyi »

postalcoder wrote: post #453

FYI, npm/bun/pnpm/uv now all support setting a minimum release age for packages. I updated my global configs to set min release age to 7 days: ~/.config/uv/uv.toml exclude-newer = "7 days" ~/.npmrc min-release-age=7 # days ~/Library/Preferences/pnpm/rc minimum-release-age=10080 # minutes ~/.bunfig.toml [install] minimumReleaseAge = 604800 # seconds

Do you know if there is override this specifically when I want to install a security patch? UV just claims that package doesn't exist if I ask for new version

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

#472

Post by wasmitnetzen »

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`

Take this as an argument to rethink your engineering decision to base your workflows entirely on the availability of an external dependency.

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

#473

Post by encomiast »

hannahoppla wrote: post #461
ting0 wrote: post #315

Earlier quoted context omitted.

What we need is accountability and ties to real-world identity. If you're compromised, you're burned forever in the ledger. It's the only way a trust model can work. The threat of being forever tainted is enough to make people more cautious, and attackers will have no way to pull off attacks unless they steal identities of powerful nodes. Like, it shouldn't be a thing that some large open-source project has some 4th…

Accountability is on the people using a billion third party dependencies, you need to take responsibility for every line of code you use in your project.

If you are really talking about dependencies, I’m not sure you’ve really thought this all the way through. Are you inspecting every line of the Python interpreter and its dependencies before running? Are you reading the compiler that built the Python interpreter?

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

#474

Post by davidatbu »

what wrote: post #442
ting0 wrote: post #306

I've been waiting for something like this to happen. It's just too easy to pull off. I've been hard-pinning all of my versions of dependencies and using older versions in any new projects I set up for a little while, because they've generally at least been around long enough to vet. But even that has its own set of risks (for example, what if I accidently pin a vulnerable version). Either that, or I fork everything,…

Pinning doesn’t help you. They can replace the package and you’ll get the new one. You have to vendor the dependencies.

I don't think pypi or npm allow replacing existing packages?

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

#475

Post by postalcoder »

exyi wrote: post #471
postalcoder wrote: post #453

FYI, npm/bun/pnpm/uv now all support setting a minimum release age for packages. I updated my global configs to set min release age to 7 days: ~/.config/uv/uv.toml exclude-newer = "7 days" ~/.npmrc min-release-age=7 # days ~/Library/Preferences/pnpm/rc minimum-release-age=10080 # minutes ~/.bunfig.toml [install] minimumReleaseAge = 604800 # seconds

Do you know if there is override this specifically when I want to install a security patch? UV just claims that package doesn't exist if I ask for new version

Yes there is. You can use those configs as flags in the CLI to override the global config.

eg:

  npm install  --min-release-age 0
  
  pnpm add  --minimum-release-age 0
  
  uv add  --exclude-newer "0 days"
  
  bun add  --minimum-release-age 0

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

#476

Post by kreelman »

driftnode wrote: post #446
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 chain here is wild. trivy gets compromised, that gives access to your ci, ci has the pypi publish token, now 97 million monthly downloads are poisoned. was the pypi token scoped to publishing only or did it have broader access? because the github account takeover suggests something wider leaked than just the publish credential

I wonder if there are a few things here....

It would be great if Linux was able to do simple chroot jails and run tests inside of them before releasing software. In this case, it looks like the whole build process would need to be done in the jail. Tools like lxroot might do enough of what chroot on BSD does.

It seems like software tests need to have a class of test that checks whether any of the components of an application have been compromised in some way. This in itself may be somewhat complex...

We are in a world where we can't assume secure operation of components anymore. This is kinda sad, but here we are....

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

#477

Post by tinix »

jbkkd wrote: post #83
cpburns2009 wrote: post #9

You can see it for yourself here: https://inspector.pypi.io/project/litellm/1.82.8/packages/fd...

Two URLs found in the exploit: https://checkmarx.zone/raw https://models.litellm.cloud/

these links trigger prefetch in chrome (doesn't respect nofollow rel).

I got popped by our security team, they were convinced I had this malware because my machine attempted to connect to the checkmarx domain.

clearly a false positive but I still had to roll credentials and wipe my machine.

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

#478

Post by pjc50 »

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…

The trouble with sandboxing is that eventually everything you want to access ends up inside the sandbox. Otherwise the friction is infuriating.

I see people going in the opposite direction with "dump everything in front of my army of LLMs" setups. Horribly insecure, but gotta go fast, right?

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

#479

Post by [deleted] »

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…

[deleted]

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

#480

Post by claud_ia »

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…

[dead]
Post reply on HN