I recently came across the LiteLLM package hack and it got me thinking about security measures we can take to avoid such risks in the future. I've considered a couple of options:
1. **Lock files**: They can help protect against vulnerabilities in new versions of packages, but the downside is that they often trap us in older versions, missing important security updates.
2. **Sandbox environments**: Using setups like Docker containers or virtual machines adds a layer of safety, but can be tricky to implement.
On another note, as a library maintainer that relies on many other libraries, what strategies can I employ to safeguard users? Should all packages in the pyproject.toml file be pinned? It's clear that we might need broader improvements across the entire ecosystem. I'd love to hear how you handle these challenges both as a user and a maintainer. What do you think should be bettered to avoid such attacks?
6 Answers
To be honest, I'm considering just giving up. I'm really hoping the issues around the .pth vulnerability get resolved soon since it seems like we keep facing new threats like this one.
Honestly, just pin your versions. It's an easy way to minimize risks, especially with everything going on.
Using hash pinning in your requirements.txt can help catch version substitution attacks, even if a compromised version shows up under an existing tag. This works well if combined with a CI step that checks for known-compromised hashes before accepting new dependency bumps. Lock files are useful, but they require manual review of changes; the hash method is more straightforward.
For sure, better to pin all versions. If not, who knows when the next hack will strike!
I'm on the fence about whether to pin dependencies or not. If I don't pin them, I risk attacks like the LiteLLM incident, but pinning means I could miss out on important updates. Isn't it better to leave them unpinned, assuming packages generally fix problems more than they introduce new ones?
If you're using the `uv` tool, you can avoid installing too-new packages (like those less than a week old) by using an exclude option. You can run `uv lock --upgrade --exclude-newer "1 week"` to update your lock file accordingly. This setting can also be configured in your user/system-wide configuration file. You might want to add exclude rules to your `pyproject.toml` to ensure everyone in your project uses dependencies with a bit of history. This can reduce risks significantly!
That sounds super handy! I didn't even know about this feature, I'm definitely going to give it a try.
Very cool, thanks for sharing! I had no idea this option existed.
An often overlooked layer is local audit logging for everything in your pipeline. If you’re running local LLMs, consider tools like VeilPiercer which log all prompts and responses, providing a comprehensive record of what goes through your system. It operates offline, ensuring no data is sent elsewhere, which is a nice security measure.
People still use requirements.txt? I thought `uv` rendered that obsolete with pyproject!