I reviewed the LiteLLM source a while back. Without wanting to be mean, it was a mess. Steered well clear.
Terrible code quality and terrible docs
Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
151–160 of 569 posts
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#152We 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 just can't trust dependencies and dev setups.
Also, I typically only update dependencies when either an exploit is known in the current version or I need a feature present in a later version - and even then not to the absolute latest version if possible. I do this for all my projects under the many eyes principal. Finding exploits takes time, new updates are riskier than slightly-stale versions.
Though, if I'm filing a bug with a project, I do test and file against the latest version.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#153We 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…
That's no solution. If you can't trust and/or verify dependencies, and they are malicious, then you have bigger problems than what a sandbox will protect against. Even if it's sandboxed and your host machine is safe, you're presumably still going to use that malicious code in production.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#154A question from a non-python-security-expert: is committing uv.lock files for specific versions, and only infrequently updating versions a reasonable practice?
(I am not a security expert either)
But, one of the arguments that I saw online from this was that when a security researcher finds a bug and reports it to the OSS project/Company they then fix the code silently and include it within the new version and after some time, they make the information public
So if you run infrequently updated versions, then you run a risk of allowing hackers access as well.
(An good example I can think of is OpenCode which had an issue which could allow RCE and the security researcher team asked Opencode secretly but no response came so after sometime of no response, they released the knowledge in public and Opencode quickly made a patch to fix that issue but if you were running the older code, you would've been vulnerable to RCE)
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#155LiteLLM 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`
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#156Earlier quoted context omitted.
This is the security shortcuts of the past 50 years coming back to bite us. Software has historically been a world where we all just trust each other. I think that’s coming to an end very soon. We need sandboxing for sure, but it’s much bigger than that. Entire security models need to be rethought.
This assumes that we can get a locked down, secure, stable bedrock system and sandbox that basically never changes except for tiny security updates that can be carefully inspected by many independent parties. Which sounds great, but the way things work now tend to be the exact opposite of that, so there will be no trustable platform to run the untrusted code in. If the sandbox, or the operating system the sandbox run…
> This assumes that we can get a locked down, secure, stable bedrock system and sandbox that basically never changes except for tiny security updates that can be carefully inspected by many independent parties.
Don't just update every time the dependency project updates. Update specifically for security issues, new features, and specific performance benefits. And even then avoid the latest version when possible.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#157LiteLLM 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`
That's PyPI's behavior when they quarantine a package.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#158Their previous release would be easily caught by static analysis. PTH is a novel technique. Run all your new dependencies through static analysis and don't install the latest versions. I implemented static analysis for Python that detects close to 90% of such injections. https://github.com/rushter/hexora
Interesting tool, will definitely try - just curious, is there a tool (hexora checker) that ensures that hexora itself and its dependencies are not compromised ?
And of course if there is one, I'll need another one for the hexora checker....
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#159We just analysed the payload. Technical details here: https://safedep.io/malicious-litellm-1-82-8-analysis/
We are looking at similar attack vectors (pth injection), signatures etc. in other PyPI packages that we know of.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#160Earlier quoted context omitted.
They would have to find someone else if they grew too big. Though, the secondary doesn't necessarily have to be a maintainer or even a contributor on the project. It just needs to be someone else to do a sanity check, to make sure it is an actual release. Heck, I would even say that as the project grows in popularity, the amount of people required to approve a release should go up.
So if I'm developing something I want to use and the community finds it useful but I take no contributions and no feature requests I should have to find another person to deal with? How do I even know who to trust, and what prevents two people from conspiring together with a long con? Sounds great on the surface but I'm not sure you've thought it through.
It wouldn't prevent a project that has a goal of being purposely malicious, just from pushing out releases that aren't actually releases.
As far as who to trust, I could imagine the maintainers of different high-level projects helping each other out in this way.
Though, if you really must allow a single user to publish releases to the masses using existing shared social infrastructure. Then you could mitigate this type of attack by adding in a time delay, with the ability for users to flag. So instead of immediately going live, add in a release date, maybe even force them to mention the release date on an external system as well. The downside with that approach is that it would limit the ability to push out fixes as well.
But I think I am OK with saying if you're a solo developer, you need to bring someone else on board or host your builds yourself.