LiteLLM Python package compromised by supply-chain attack

https://github.com/BerriAI/litellm/issues/24512

[Security]: CRITICAL: Malicious litellm_init.pth in litellm 1.82.8 — credential stealer · Issue #24512 · BerriAI/litellm

[LITELLM TEAM] - For updates from the team, please see: #24518 [Security]: CRITICAL: Malicious litellm_init.pth in litellm 1.82.8 PyPI package — credential stealer Summary The litellm==1.82.8 wheel...

GitHub
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 requirements we have for agent runtimes, lets use this momentum to make our dev environments safer! In such an environment the container would crash, we see the violations, delete it and dont' have to worry about it. We should treat this as an everyday possibility not as an isolated security incident.

So... I'm working on an open source technology to make a literal virtual machine shippable i.e. freezing everything inside it, isolated due to vm/hypervisor for sandboxing, with support for containers too since it's a real linux vm.

The problems you mentioned resonated a lot with me and why I'm building it, any interest in working to solve that together?: https://github.com/smol-machines/smolvm

GitHub - smol-machines/smolvm: Tool to build & run portable, lightweight, self-contained virtual machines.

Tool to build & run portable, lightweight, self-contained virtual machines. - smol-machines/smolvm

GitHub

Thanks for the pointer! Love the premise project. Just a few notes:

- a security focused project should NOT default to train people installing by piping to bash. If i try previewing the install script in the browser it forces download instead of showing as plain text. The first thing i see is an argument

# --prefix DIR Install to DIR (default: ~/.smolvm)

that later in the script is rm -rf deleting a lib folder. So if i accidentally pick a folder with ANY lib folder this will be deleted.

- Im not sure what the comparison to colima with krunkit machines is except you don't use vm images but how this works or how it is better is not 100% clear

- Just a minor thing but people don't have much attention and i just saw aws and fly.io in the description and nearly closed the project. it needs to be simpler to see this is a local sandbox with libkrun NOT a wrapper for a remote sandbox like so many of the projects out there.

Will try reaching you on some channel, would love to collaborate especially on devX, i would be very interested in something more reliable and bit more lightweight in placce of colima when libkrun can fully replace vz

Love this feedback, agree with you completely on all of it - I'll be making those changes.

1. In comparison with colima with krunkit, I ship smolvm with custom built kernel + rootfs, with a focus on the virtual machine as opposed to running containers (though I enable running containers inside it).

The customizations are also opensource here: https://github.com/smol-machines/libkrunfw

2. Good call on that description!

I've reached out to you on linkedin

GitHub - smol-machines/libkrunfw: A dynamic library bundling the guest payload consumed by libkrun with modifications specific for smolVM.

A dynamic library bundling the guest payload consumed by libkrun with modifications specific for smolVM. - smol-machines/libkrunfw

GitHub