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

561–569 of 569 posts

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

#561

Post by zar1048576 »

bmurphy1976 wrote: post #559
throwawaytea wrote: post #408

Earlier quoted context omitted.

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,…

Hell, the tech savvy senior lawyers are already using LLMs to do the work that army's of juniors and other assistants did for them. Just like what is happening with software engineers. Anybody who thinks this isn't going to have some kind of impact is mental.

Definitely. But I think the nature of that impact is not entirely clear. In the legal context, LLMs are also hallucinating extensively, citing made up case law, etc. It’s not yet clear whether they are potentially solving one problem, while introducing many others.

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

#562

Post by kalib_tweli »

jFriedensreich wrote: post #243
kalib_tweli wrote: post #97

Earlier quoted context omitted.

Would value your opinion on my project to isolate creds from the container: https://github.com/calebfaruki/tightbeam https://github.com/calebfaruki/airlock This is literally the thing I'm trying to protect against.

I would split the agent loop totally from the main project of tightbeam, no one wants yet another new agent harness we need to focus on the operational problems. Airlock seems interesting in theory but its really hard to believe this could capture every single behaviour of the native local binaries, we need the native tools with native behaviour otherwise might as well use something like MCP. I would bet more on a gi…

Good points across the board. I ran into a lot of problems auditing the security of my approach and it was just too easy to circumvent.

First lesson was that the architecture had to be secure in structure, not configuration. Otherwise, a novice will run claude code on the host machine and just bork the entire setup.

So now I've replaced tightbeam runtime with a small runtime on the workspace container. Tightbeam and Airlock have been moved to separate pods. So you don't need network egress on the workspace pod at all.

Secondly, I'm isolating credentials on Tightbeam and Airlock with k8s jobs. Rather than airlock full CLI commands, you just create "airlock tools" with k8s secrets. Airlock controller never sees the secret. The tool could be like "git-create-branch" and "gh-create-pr".

Tightbeam is pretty much symmetrical. LLM credentials are tied to jobs.

I'm tying them together into a unified architecture now. Please do let me know if you have additional thoughts!

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

#563

Post by anderskaseorg »

password4321 wrote: post #558
anderskaseorg wrote: post #260

Earlier quoted context omitted.

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-...

Pardon my limited understanding but my read of the suggestion was simply to perform the same exact operation that the public would do to verifiably audit the exact source when generating the official published artifacts, the point was just that there was no automation to do so directly from the public repo.

The maintainer can verify the correspondence between source and release, but the public has been deprived of this verifiability.

This matters. Consider the XZ Utils compromise where a malicious maintainer hid the line that triggers compilation of the (otherwise dormant) backdoor payload in a generated file present only in the release tarball: https://www.openwall.com/lists/oss-security/2024/03/29/4. If the public had the ability to audit that the release tarball was correctly built from the version-controlled code, this would have been much more difficult to hide.

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

#564

Post by password4321 »

anderskaseorg wrote: post #563
password4321 wrote: post #558

Earlier quoted context omitted.

Pardon my limited understanding but my read of the suggestion was simply to perform the same exact operation that the public would do to verifiably audit the exact source when generating the official published artifacts, the point was just that there was no automation to do so directly from the public repo.

The maintainer can verify the correspondence between source and release, but the public has been deprived of this verifiability. This matters. Consider the XZ Utils compromise where a malicious maintainer hid the line that triggers compilation of the (otherwise dormant) backdoor payload in a generated file present only in the release tarball: https://www.openwall.com/lists/oss-security/2024/03/29/4 . If the public ha…

Thanks for circling back.

I interpret your comment as emphasizing that the current norm relying on publicly accessible (GitHub) infrastructure building releases in public and thus allowing public review of logs and artifacts provides tremendous value (and I admit that true 100% binary reproducibility is an often nearly unreachable goal still not yet typically expected as the norm).

> Breaking that chain via a private repo is a step backwards

I was stating that performing a reproducible build elsewhere and distributing the output could in theory still be validated though it would require re-running said build for one's self and comparing the outputs. This might encourage the pursuit of 100% reproducibility! The chain need not be considered broken just because the final link is private.

> the public has been deprived of this verifiability

This is not what I was trying to point out, though I agree the cost of verifying reproducibility would be higher. My point was that anyone could still perform the same steps themselves and verify the output. Yes this would be more work than reviewing logs on GitHub.

OP's primary concern with today's standard approach appears to be the automated connection from GitHub build action -> release. Even simply requiring manual maintainer intervention to copy the action output over to a release seems to satisfy both their and your concerns.

> If the public had the ability to audit that the release tarball was correctly built from the version-controlled code

I am not intimately familiar with all the details of the XZ fiasco but agree that it offers an opportunity to learn and make changes to work toward making sure nothing similar can happen to any project again. If I am reading your link correctly, it serves as an example of members of the public (not a maintainer of XZ) doing exactly what you said: auditing the release tarball. IIRC this occurred only after an additional point release (apparently allowing the attacker to fix a bug in their backdoor) because of a performance regression.

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

#565

Post by anderskaseorg »

password4321 wrote: post #564
anderskaseorg wrote: post #563

Earlier quoted context omitted.

The maintainer can verify the correspondence between source and release, but the public has been deprived of this verifiability. This matters. Consider the XZ Utils compromise where a malicious maintainer hid the line that triggers compilation of the (otherwise dormant) backdoor payload in a generated file present only in the release tarball: https://www.openwall.com/lists/oss-security/2024/03/29/4 . If the public ha…

Thanks for circling back. I interpret your comment as emphasizing that the current norm relying on publicly accessible (GitHub) infrastructure building releases in public and thus allowing public review of logs and artifacts provides tremendous value (and I admit that true 100% binary reproducibility is an often nearly unreachable goal still not yet typically expected as the norm). > Breaking that chain via a private…

Right, the public was able to spend manual effort hand-auditing one specific tarball after it had already been singled out as suspicious for other reasons. In order for verification to effectively increase supply chain security, it needs to become uniformly standardized, fully automated, and ubiquitous. That’s the ultimate goal of the provenance attestation mechanisms that would be defeated by indirection through private repositories.

If you want to require extra maintainer intervention for releases, there are better mechanisms available for that, such as workflow_dispatch.

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

#566

Post by montag »

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

Well this was prescient... https://news.ycombinator.com/item?id=47582220

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

#568

Post by donbaris »

MadsRC wrote: post #267
detente18 wrote: post #209

Earlier quoted context omitted.

Update: - Impacted versions (v1.82.7, v1.82.8) have been deleted from PyPI - All maintainer accounts have been changed - All keys for github, docker, circle ci, pip have been deleted We are still scanning our project to see if there's any more gaps. If you're a security expert and want to help, email me - krrish@berri.ai

Dropped you a mail from mads.havmand@nansen.ai

[dead]

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

#569

Post by nikisweeting »

postalcoder wrote: post #475
exyi wrote: post #471

Earlier quoted context omitted.

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

Note pnpm does not have this flag yet, please upvote this issue if you want it added: https://github.com/pnpm/pnpm/issues/11224

Currently pnpm only supports setting this option via persistent config file, not per-run.

Post reply on HN