Live data from Hacker News

Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

github.com

411–420 of 569 posts

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

#411
post #390

Earlier quoted context omitted.

This must be super stressful for you, but I do want to note your "I'm sorry for this." It's really human. It is so much better than, you know... "We regret any inconvenience and remain committed to recognising the importance of maintaining trust with our valued community and following the duration of the ongoing transient issue we will continue to drive alignment on a comprehensive remediation framework going forward…

I think we really need to use sandboxes. Guix provides sandboxed environments by just flipping a switch. NixOS is in an ideal position to do the same, but for some reason they are regarded as "inconvenient". Personally, I am a heavy user of Firejail and bwrap. We need defense in depth. If someone in the supply chain gets compromised, damage should be limited. It's easy to patch the security model of Linux with usersp…

What would be really helpful is if software sandboxed itself. It's very painful to sandbox software from the outside and it's radically less effective because your sandbox is always maximally permissive.

But, sadly, there's no x-platform way to do this, and sandboxing APIs are incredibly bad still and often require privileges.

> It's easy to patch the security model of Linux with userspaces, and even easier with eBPF, but the community is somehow stuck.

Neither of these is easy tbh. Entering a Linux namespace requires root, so if you want your users to be safe then you have to first ask them to run your service as root. eBPF is a very hard boundary to maintain, requiring you to know every system call that your program can make - updates to libc, upgrades to any library, can break this.

Sandboxing tooling is really bad.

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

#413
I think this gets a lot worse when we look at it from an agentic perspective. Like when a dev person hits a compromising package, there's usually a "hold on, that's weird" moment before a catastrophe. An agent doesn't have that instinct.

Oh boy supply chain integrity will be an agent governenace problem, not just a devops one. If you send out an agent that can autonomously pull packages, do code, or access creds, then the blast radius of compromises widens. That's why I think there's an argument for least-privilege by default--agents should have scoped, auditable authority over what they can install and execute, and approval for anything outside the boundaries.

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

#414

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

[flagged]

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

#415
post #306

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

[flagged]

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

#418
post #390

Earlier quoted context omitted.

This must be super stressful for you, but I do want to note your "I'm sorry for this." It's really human. It is so much better than, you know... "We regret any inconvenience and remain committed to recognising the importance of maintaining trust with our valued community and following the duration of the ongoing transient issue we will continue to drive alignment on a comprehensive remediation framework going forward…

I think we really need to use sandboxes. Guix provides sandboxed environments by just flipping a switch. NixOS is in an ideal position to do the same, but for some reason they are regarded as "inconvenient". Personally, I am a heavy user of Firejail and bwrap. We need defense in depth. If someone in the supply chain gets compromised, damage should be limited. It's easy to patch the security model of Linux with usersp…

I am happily running all third-party tools inside the Amazing Sandbox[1]. I made it public last year.

1 - https://github.com/ashishb/amazing-sandbox

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

#419
post #390

Earlier quoted context omitted.

I think we really need to use sandboxes. Guix provides sandboxed environments by just flipping a switch. NixOS is in an ideal position to do the same, but for some reason they are regarded as "inconvenient". Personally, I am a heavy user of Firejail and bwrap. We need defense in depth. If someone in the supply chain gets compromised, damage should be limited. It's easy to patch the security model of Linux with usersp…

What would be really helpful is if software sandboxed itself. It's very painful to sandbox software from the outside and it's radically less effective because your sandbox is always maximally permissive. But, sadly, there's no x-platform way to do this, and sandboxing APIs are incredibly bad still and often require privileges. > It's easy to patch the security model of Linux with userspaces, and even easier with eBPF…

> It's very painful to sandbox software from the outside and it's radically less effective because your sandbox is always maximally permissive.

Not really.

Let's say I am running `~/src/project1 $ litellm`

Why does this need access to anything outside of `~/src/project1`?

Even if it does, you should expose exactly those particular directories (e.g. ~/.config) and nothing else.

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

#420

Earlier quoted context omitted.

Welcome to the new era, where programming is neither a skill nor a trade, but a task to be automated away by anyone with a paid subscription.

alot of software isnt that important so its fine, but some actually is important. especially with a branding name slapped on it that people will trust

The industry needs to step up and plant a flag for professionalization certifications for proper software engineering. Real hard exams etc
Post reply on HN