-
Notifications
You must be signed in to change notification settings - Fork 860
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow artificial delay for security considerations for uv pip compile #3019
Comments
uv already has
|
Good to know that there is this option. It's not the most user friendly :) but I use uv through a bunch of shell aliases anyway so I should be able to make it work. Thank you. |
It seems kind of complicated to add at the top-level right now but if there's significant interest we can consider it in the future. |
Sounds good @zanieb Perhaps it's the kind of thing that belongs in some sort of config file. Maybe the equivalent of ruff.toml if you ever create such a thing for uv. |
Consider this a feature request and a bit of a weird one. But I'd love to hear your thoughts on it. Close it if it's not inline with the uv vision.
I've been thinking about what can be done to limit exposure to the supply chain attacks that were once theoretical but seem to be weekly now.
These are generally caught but may persist for a period of time before detected.
How do you feel about something like:
That is adding
--delay-in-days 7
which would only upgrade a library to a newer version if that update has been out for the specific number of days. So say there is pydantic 2.7.1 and we have pydantic 2.7.0 specified, --upgrade won't switch it to 2.7.1 until the 2.7.1 is at least 7 days old.It's not a perfect fix against these pypi attacks. But letting the rest of the world "go first" in trying out the updates could be a good hedge against just installing whatever was just published to pypi that hour.
Another really valuable aspect to this would be big-time bugs that get shipped and then pulled quickly. A recent example was mongoengine shipped a catastrophic bug that when used on a web server with threading=true enabled (uwsgi? gunicorn? I don't think it mattered) it would 100% fail all queries. This was quickly fixed but still took down my site because I didn't test it locally in a threaded server. Maybe this feature would have helped. At least the git hub issues would have been out and discussed by the time I started looking for what went wrong.
Any interest in this idea? I discussed it with the pip folks a year or two ago and I think they didn't see any value in it.
The text was updated successfully, but these errors were encountered: