Live data from Hacker News

Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

github.com

451–460 of 569 posts

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

#451

Earlier quoted context omitted.

> real-world identity This bit sounds like dystopian governance, antithetical to most open source philosophies.

Would you drive on bridges or ride in elevators "inspected" by anons? Why are our standards for digital infrastructure and software "engineering" so low? I don't blame the anons but the people blindly pulling in anon dependencies. The anons don't owe us anything.

A business or government can (should) separately package, review, and audit code without involving upstream developers or maintainers at all.

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

#452
I maintain that GitHub does a piss poor job of hardening CI so that one step getting compromised doesn’t compromise all possible secrets. There’s absolutely no need for the GitHub publishing workflow to run some third party scanner and the third party scanner doesn’t need access to your pypi publishing tokens.

This stupidity is squarely on GitHub CI. Trivy is also bad here but the blast radius should have been more limited.

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

#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

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

#454
post #135

Earlier quoted context omitted.

They don't have access to the host filesystem nor environment variables and this attack wouldn't work.

Just because this attack example did not contain container escape exploits does not mean this is safe. Its better than nothing but nothing that will save us.

Those supply chain attacks we are seeing are bad, but if someone burns a 0day container escape for it, it would probably be a net positive effect on security overall. Just saying this is FUD.

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

#455

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…

Good work! Sorry to hear you're in this situation, good luck and godspeed!

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

#456

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

I don't think syntax is correct for pnpm

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

#457

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…

[dead]

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

#458

Earlier quoted context omitted.

I've been thinking the same thing. And it's somewhat parallel to what happened to meditation vs. drugs. In the old world the dangerous insights required so many years of discipline that you could sort of trust that the person getting the insight would be ok. But then any idiot can get the insight by just eating some shrooms and oops, that's a problem. Mostly self-harm problem in that case. But the dynamic is somewhat…

In the old world the dangerous insights required so many years of discipline that you could sort of trust that the person getting the insight would be ok. But then any idiot can get the insight by just eating some shrooms and oops, that's a problem. I would think humans have been using psychedelics since before we figured out meditation. Likely even before we were humans.

Ah yes the stoned ape hypothesis. I don't know if there is or will ever be evidence to support the hypothesis.

I also like the drunk monkey hypothesis.

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

#459

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

I don't think syntax is correct for pnpm

Works for me?

  $ pnpm add -D typescript@6.0.2
   ERR_PNPM_NO_MATURE_MATCHING_VERSION  No matching version found for typescript@6.0.2 published by Wed Mar 18 2026..
You could also set the config this way:

  pnpm config set minimumReleaseAge 10080 --global
You may be thinking about the project-specific config, which uses YAML.

https://pnpm.io/cli/config

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

#460

Earlier quoted context omitted.

For now. They're about to get hit by the AI wave as bad as us software devs. Who knows what's on the other side of this.

Sorry that I have to be the one to tell you this, but lawyers are fine. Sure, AI will have an impact, but nothing like the once hyped idea that it would replace lawyers. It has actually been amusing to watch the hype cycle play out around AI when it comes to lawyers.

Lawyership in the sense of the profession may survive and adapt. Individual lawyers, not so much. I strongly doubt the new equilibrium (if we ever reach one) will need so many lawyers.

Same logic for software developers.

Post reply on HN