Hey everyone,
Coming back to this thread, I think that the circumstances around this change have evolved. At this point, malware authors are exploiting any lever of “mutable references” that is available to them. In my mind, this behavior is itself a mutable reference.
Not all users are using hashes and lock files and resolution still downloads and is executing code on users’ machines. We should work towards closing the gap to some value in a shorter timespan for PyPI. If there needs to be follow-up work or if we need to adjust the value later, that is all fine to do. Having this hole open now is worrying to me in our new age of autonomous and chain-able exploitation, it just makes the messes harder to clean up and reason about when things go wrong.
If we’re supporting the “noticed botched release, want to fix it without needing a new release” then we’re talking on the timescale of days. Even a value of 14 days until a release is “locked” would go a long way to preventing mass-cleanup events.
My reading of the primary disagreements from the thread are:
- Whether this prevents supply chain attacks at all: it doesn’t prevent, but it makes the clean-up easier. Users not doing exactly the right thing (pinning old versions instead of hashes) are also more protected.
- Staging releases would be better: agree, but they are a significant feature including UI design and project opt-in. I think we should consider it separately to this suggestion. Implementing this feature is one more database query during the upload step and is transparent to most users.
- More ecosystems support updating releases: agree, but many of these ecosystems have additional protections in place, like staging environments. PyPI is publish-to-live installs almost immediately and doesn’t offer staging environments.
If there isn’t any disagreement about implementing this feature in any way in PyPI I would recommend we do so and then we can discuss and change the exact value later.