I've been following the recent security breach with the LiteLLM package and it got me thinking about how we can better protect ourselves in the future. I have a couple of ideas:
1. Using lock files can help prevent issues from updates, but they can also force us to stick to older, possibly outdated versions.
2. Working in a sandbox environment, like a Docker container or virtual machine, might be safer, but it adds some complexity to the setup.
As a library maintainer that heavily depends on many other libraries, I'm curious about the best strategies for safeguarding our users. Should we pin all dependencies in the pyproject.toml? Or is there a bigger issue within the ecosystem that needs to be addressed? I'd love to hear how others manage this, whether you're a user or a maintainer, and what improvements could be made to help avoid such attacks.
4 Answers
Using hash pinning in the requirements.txt with --require-hashes can catch version substitution attacks. This approach, alongside a CI step that checks new dependencies against known compromised hashes, offers a solid defense. Lock files are useful, but they require manual review, which can be overlooked. The hash method is more automated and harder to ignore.
Absolutely! I think it's crucial to pin everything, or we'll just keep getting hit by hacks.
If you're using `uv`, you can set it to avoid installing packages that are fresh out of the oven, like those less than a week old. You can run the upgrade with this command:
```bash
uv lock --upgrade --exclude-newer "1 week"
```
Alternatively, you can change this setting globally with a config file. For Unix, add this to your `~/.config/uv/uv.toml`:
```toml
exclude-newer = "1 week"
```
To make sure everyone on your team also gets the older packages, you can put similar lines in your `pyproject.toml`. Also, I wrote a blog post that discusses more `uv` tips to minimize dependency issues if you’re interested!
Wow, I didn’t know you could do that with `uv`! Definitely going to try it out.
Thanks for sharing that! I wasn't aware of this option before.
It seems like there’s no clear-cut answer for whether to pin dependencies or not. Not pinning can leave you vulnerable to attacks, while pinning can cause you to miss out on important security fixes. If you hope that packages generally improve over time, maybe keeping them unpinned is better? But it's a tough call!
Honestly, the simplest solution is just to pin your versions. It’s a hassle, but peace of mind is worth it in the long run.
Do people really still use requirements.txt? I thought we moved on to pyproject files and lock files.