Recommend reading related blog post https://bernat.tech/posts/securing-python-supply-chain
Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
401–410 of 569 posts
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#402Earlier quoted context omitted.
> Remember that you are programmers and you can just program, you don't need a framework, you are already using the API of an LLM provider, don't put a hat on a hat, don't get killed for nothing. Programming for different LLM APIs is a hassle, this library made it easy by making one single API you call, and in the backstage it handled all the different API calls you need for different LLM providers.
I think almost everyone supports the openai api anyway (even Gemini). Not entirely sure why there needs to be a wrapper.
Msot do, but Anthropic indicates that theirs is "is not considered a long-term or production-ready solution for most use cases" [0]; in any case, where the OpenAI-compatible API isn't the native API, both for cloud vendors other than OpenAI and for self-hosting software, the OpenAI-compatible API is often limited, both because the native API offers features that don't map to the OpenAI API (which a wrapper that presents an OpenAI-compatible API is not going to solve) and because the vendor often lags in implementing support for features in the OpenAI-compatible API—including things like new OpenAI endpoints that may support features that the native API already supports (e.g., adding support for chat completions when completions were the norm, or responses when chat completions were.) A wrapper that used the native API and did its own mapping to OpenAI could, in principle, address that.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#403Earlier quoted context omitted.
> Remember that you are programmers and you can just program, you don't need a framework, you are already using the API of an LLM provider, don't put a hat on a hat, don't get killed for nothing. Programming for different LLM APIs is a hassle, this library made it easy by making one single API you call, and in the backstage it handled all the different API calls you need for different LLM providers.
There's only two different LLM APIs in practice (Anthropic and everyone else), and the differences are cosmetic. This is like a couple hours of work even without vibe coding tools.
> There's only two different LLM APIs in practice (Anthropic and everyone else), and the differences are cosmetic.
There's more than that (even if most other systems also provide a OpenAI compatible API which may or may not expose either all features of the platform or all features of the OpenAI API), and the differences are not cosmetic, but since LiteLLM itself just presents an OpenAI-compatible API, it can't be providing acccess to other vendor features that don't map cleanly to that API, and I don't think its likely to be using the native API for each and being more complete in its OpenAI-compatible implementation of even the features that map naturally than the first-party OpenAI-compatibility APIs.)
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#404This is tied to the TeamPCP activity over the last few weeks. I've been responding, and keeping an up to date timeline. I hope it might help folks catch up and contextualize this incident: https://ramimac.me/trivy-teampcp/#phase-09
This is fantastic, thank you. Your reporting has been great. But also, damn, the playlist.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#405We 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…
This stuff already exists - mobile phone sandboxed applications with intents (allow Pictures access, ...) But mention that on HN and watch getting downvoted into oblivion: the war against general computation, walled gardens, locked down against device owners...
You can have both. Bazzite Linux lets you sandbox applications and also control your own device.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#406[dead]
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#407Easy tool to check if you/other repos were expoed https://litellm-compromised.com
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#408Earlier 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.
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, and tons of other things.
Got the problem resolved.
So it definitely can reduce hiring lawyers even.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#409Supply chain compromises in AI tooling are becoming structural, not exceptional.
We've seen similar patterns in the last 6 months — Zapier's npm account
(425 packages, Shai Hulud malware) and Dify's React2Shell incident both
followed the same vector: a trusted package maintainer account as the entry
point. The blast radius keeps growing as these tools get embedded deeper
into production pipelines.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#410[dead]