Earlier quoted context omitted.
They absolutely do. In this case litellm 1.82.8 had been out for at least a week (can’t recall the exact date offhand). The compromised version was a replacement.
Ah, my mistake! Thanks for the correction. But I believe you can replace versions on both, nonetheless. It’s a multi step process, unpublish then publish again. But the net effect is the same.
Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
551–560 of 569 posts
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#552Does the Python ecosystem have anything like pnpm’s minimumReleaseAge setting? Maybe I’m being overly paranoid, but it feels like every internet-facing ecosystem should have something like this.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#553Earlier quoted context omitted.
Thank you for sharing this! I always wanted to mess with building virtual filesystems but was unwilling to venture outside the standard library (i.e. libfuse) for reasons wonderfully illustrated in this thread and elsewhere. Somehow the idea of implementing a networked fs protocol and leaving system integration to the system never crossed my mind. I'm glad more people are taking this stance. Large centralized standar…
hi, glad you like it and that it encourages you to try some things you've always wanted to do :-) I was thinking for the license I'd do GPLv3. Would that work for you?
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#554Earlier quoted context omitted.
hi, glad you like it and that it encourages you to try some things you've always wanted to do :-) I was thinking for the license I'd do GPLv3. Would that work for you?
Depends on what you want to achieve with your licensing, but I personally think GPLv3 is a really good fit for a project like yours.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#555I'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.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#556FYI, 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 understand that this is a good idea but it does feel really weird. Add a min-release-age to see if anyone who doesn't gets bitten. Next up, we're going to advise a minimum-release-age of 14 days, cause most other projects use 7 days.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#557Earlier quoted context omitted.
I understand that this is a good idea but it does feel really weird. Add a min-release-age to see if anyone who doesn't gets bitten. Next up, we're going to advise a minimum-release-age of 14 days, cause most other projects use 7 days.
You don't have to outrun the bear, just the other guy.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#558Maintainers need to keep a wall between the package publishing and public repos. Currently what people are doing is configuring the public repo as a Trusted Publisher directly. This means you can trigger the package publication from the repo itself, and the public repo is a huge surface area. Configure the CI to make a release with the artefacts attached. Then have an entirely private repo that can't be triggered aut…
The point of trusted publishing is supposed to be that the public can verifiably audit the exact source from which the published artifacts were generated. Breaking that chain via a private repo is a step backwards. https://docs.npmjs.com/generating-provenance-statements https://packaging.python.org/en/latest/specifications/index-...
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#559Earlier quoted context omitted.
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.
My parents had a weird green card and paperwork issue that was becoming a big problem. Everyone in their social circle recommended an immigration type lawyer. Everyone. My dad was confident he could figure it out based on his perplexity Pro account. He attacked the problem from several angles and used it for help with what to do, how to do it, what to ask for when visiting offices, how to press them to move forward,…
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#560LiteLLM 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