Live data from Hacker News

Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

github.com

541–550 of 569 posts

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

#541
post #94

Earlier quoted context omitted.

Bifrost is the only real alternative I'm aware of https://github.com/maximhq/bifrost

Virtual Keys is an Enterprise feature. I am not going to pay for something like this in order to provide my family access to all my models. I can do without cost control (although it would be nice) but I need for users to be able to generate a key and us this key to access all the models I provide.

I just deployed it to test it out and this is FALSE. I was able to create Virtual Keys on the free version with no issues.

Please do a double take on the facts, you might falsely deter people.

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

#543

Earlier quoted context omitted.

Any app can be sandboxed on macOS and by default newly created apps are; that's why I say if you create a new app in Xcode then anything run by that app is sandboxed out of the box. App Store enforces it but beyond that isn't involved.

I feel like we're just talking about different things? I've just said that I'm aware of apps being sandboxed, that does not mean that some random program you run from your terminal is sandboxed.

Right, I'm skipping a step.

What I'm saying is that it's very easy now to take some arbitrary task - doing a compile/release cycle for example - and quickly knock up a simple signed macOS .app that sandboxes itself and then invokes the release script as a subprocess. Sandboxing is transitive and the .app itself can authenticate to the OS to obtain creds before passing them to the subprocess.

In the past I've thought about making a quick SaaS that does this for people so they don't have to fiddle with it locally and maybe some day I still will. But you can easily do it locally especially with Xcode and AI now. You wouldn't have to know anything about macOS development.

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

#544
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…

`sandbox-venv` is a small shell script that sandboxes Python virtual environments in separate Linux namespaces using Bubblewrap (and soon using only command `unshare`, bringing the whole script down to effectively 0 deps).

https://github.com/sandbox-utils/sandbox-venv

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

#546

Earlier quoted context omitted.

I feel like we're just talking about different things? I've just said that I'm aware of apps being sandboxed, that does not mean that some random program you run from your terminal is sandboxed.

Right, I'm skipping a step. What I'm saying is that it's very easy now to take some arbitrary task - doing a compile/release cycle for example - and quickly knock up a simple signed macOS .app that sandboxes itself and then invokes the release script as a subprocess. Sandboxing is transitive and the .app itself can authenticate to the OS to obtain creds before passing them to the subprocess. In the past I've thought…

Ah, yes. I totally agree with that and wish that's how people built software.

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

#549
post #237

I just installed Harbor, and it instantly pegged my cpu.. i was lucky to see my processes before the system hard locked. Basically it forkbombed `grep -r rpcuser\rpcpassword` processes trying to find cryptowallets or something. I saw that they spawned from harness, and killed it. Got lucky, no backdoor installed here from what i could make out of the binary

> i was lucky to see my processes before the system hard locked. how do you do that? have Activity Monitor up at all times?

btop

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

#550
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

uv also has --exclude-newer-package which I think can be used for overriding just a certain package.

https://docs.astral.sh/uv/reference/cli/#uv-run--exclude-new... https://docs.astral.sh/uv/reference/settings/#exclude-newer-...

Post reply on HN