-
-
Notifications
You must be signed in to change notification settings - Fork 636
Description
What's the problem this feature will solve?
There's been a bunch of supply-chain attacks lately, especially in the npmjs ecosystem but we aren't immune to the same.
Their success is driven by how fast the ecosystem may start picking up latest releases of software shipped through public software repositories.
One technique to combat this is disallowing the most recent releases across the dependency tree. We could have an option to specify how fresh software is allowed to be in order to be installable. This would allow for a cooldown period in the deptree so if there's anything malicious, there's a better chance for it to be taken down before it gets into the user envs.
Describe the solution you'd like
I'd like to mimic what pnpm does — they have a minimumReleaseAge setting and an additional allowlist to allow overriding that for certain trusted projects.
This would need to work on the depresolver level, rejecting any candidates released too close to now.
This should likely be an opt-in. At least, at first.
Alternative Solutions
🤷♂️ Educate people and force them to verify every single bumped transitive dependency's source by hand..?
Additional context
I know that certain package index proxies used in corporate networks implement a similar strategy on the index level.
Dependabot has such a setting and Zizmor enforces it now.
But it's probably a good idea for us to implement it so that it's not locked to a specific closed-sourced vendor. Besides, they advertise this working for pip in the docs. Not sure how they do it since they're running pip-tools under the hood (at least in some cases).
Another example in the Python ecosystem is virtualenv's wheel seeding mechanism that has a delay of 28 days before it attempts updating pip / setuptools / wheel dists in its cache.
This is also somewhat similar to uv's --exclude-newer.