[codex] add uv dependency cooldown

[Hynek Kydlíček (hynky1999)]

Summary

Adds a global uv dependency cooldown so package resolution ignores distributions uploaded within the last 14 days. This follows uv's current dependency cooldown documentation for [tool.uv] exclude-newer.

The lockfile was refreshed with uv 0.11.13 so it records the relative cooldown metadata without changing resolved package versions.

Validation

• uv --version: uv 0.11.13 (Homebrew 2026-05-11 aarch64-apple-darwin)
• uv lock --check: resolved 80 packages successfully
• uv run pytest: 549 passed in 78.87s
• uv run pytest tests/test_optional_dependencies.py: 1 passed in 1.11s

Notes

Older uv versions, including 0.9.14, warn on friendly duration syntax in [tool.uv]. uv 0.11.13 accepts exclude-newer = "14 days" and writes the expected lock metadata.

[gemini-code-assist]

Code Review

This pull request adds a tool.uv configuration to pyproject.toml to implement a dependency cooldown using exclude-newer. The review feedback correctly identifies that using relative durations like "14 days" within the configuration file leads to non-deterministic dependency resolution, as the results depend on the date the resolution is run. It is recommended to use a fixed RFC 3339 timestamp or move this setting to a CLI flag in the CI pipeline to ensure reproducible builds.

[Guilherme Penedo (guipenedo)]

this should probably be in the ci only. People install this directly themselves

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: fac10f2bb7

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "Codex (@codex) review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "Codex (@codex) address that feedback".

[Hynek Kydlíček (hynky1999)]

this should probably be in the ci only. People install this directly themselves

But then i just get pwned when i install package localy during dev....

14 days is fine enough, i find it hard to see where people would be severly limited by this

[Hynek Kydlíček (hynky1999)]

cc Guilherme Penedo (@guipenedo)

[Guilherme Penedo (guipenedo)]

this should probably be in the ci only. People install this directly themselves

But then i just get pwned when i install package localy during dev....

14 days is fine enough, i find it hard to see where people would be severly limited by this

it's still super weird, i dont want to start getting weird version conflicts just because one of the packages i am using is weird

[Guilherme Penedo (guipenedo)]

Let's just make sure our own CI uses this imo

[Hynek Kydlíček (hynky1999)]

No it's disaster waiting to happen, look at this: https://x.com/SocketSecurity/status/2054048025081737446

[Hynek Kydlíček (hynky1999)]

it's still super weird, i dont want to start getting weird version conflicts just because one of the packages i am using is weird

but you won't get them uv will resolve

[Guilherme Penedo (guipenedo)]

strongly against this, mixing a bunch of things together. I agree with adding it to our CI, but not with arbitrarily adding random constraints on every downstream consumer

[Hynek Kydlíček (hynky1999)]

strongly against this, mixing a bunch of things together. I agree with adding it to our CI, but not with arbitrarily adding random constraints on every downstream consumer

It's not mixing bunch of things together. Adding this to CI is kinda useless beyond preventing supply-chain attack on the package itself. Look at even the current supply chain attack, it's designed with dev machines in mind. We are literally waiting for one of the packages to get supply chained that your whole dev machine is compromised

[Guilherme Penedo (guipenedo)]

Adding this to CI is kinda useless beyond preventing supply-chain attack on the package itself

yeah which is our core responsibility to avoid. The rest is really not up to us imo. if each package maintainer started adding these things with some arbitrary time cutoff it'd be a mess. Besides, if someone doesn't use uv or has some other package that brings stuff in anyway this is all pointless.

[Hynek Kydlíček (hynky1999)]

yeah which is our core responsibility to avoid. The rest is really not up to us imo. if each package maintainer started adding these things with some arbitrary time cutoff it'd be a mess.

Why would this be a mess ? The whole point UV / package manager is to fine combination of of versions/packages that works, how would this be a mess ?

Point in case https://github.com/BerriAI/litellm/blob/litellm_internal_staging/pyproject.toml#L223, they got recently pwned.

The whole point is to prevent devs from getting fucked as well as anybody who install stuff to getting fucked.

yeah which is our core responsibility to avoid

And how do you plan to prevent this exactly ? How do you prevent dependencies from getting supply chained ?

[Hynek Kydlíček (hynky1999)]

Also, this won't prevent people that just install the package from PIP, to install whatever they want. This only apply for uv sync

[Guilherme Penedo (guipenedo)]

And how do you plan to prevent this exactly ? How do you prevent dependencies from getting supply chained ?

We prevent supply chained dependencies from supply chaining us through our CI by enforcing the rule on our own CI.
Locally you can apply whatever options you want on your own installs.
There is also the issue that if something had a security fix you are making the choice between the supply chain risk vs already patched security issue for people.

Also, this won't prevent people that just install the package from PIP, to install whatever they want. This only apply for uv sync

exactly, that's what I meant when I said "Besides, if someone doesn't use uv or has some other package that brings stuff in anyway this is all pointless."
It doesn't even apply uniformly and then you have people experiencing different behaviour for the same refiner version

Strongly against this

[Hynek Kydlíček (hynky1999)]

There is also the issue that if something had a security fix you are making the choice between the supply chain risk vs already patched security issue for people.

No you are not, you can always enforce package versions, by excluding temporarly this packages

[Hynek Kydlíček (hynky1999)]

exactly, that's what I meant when I said "Besides, if someone doesn't use uv or has some other package that brings stuff in anyway this is all pointless."

yes the whole point is to prevent people working on this package, to get compromised

[Hynek Kydlíček (hynky1999)]

How else do you think all these other packages like mistralai got compromised ? Simply because devs installed tanstack on their own computer, which had access to ssh keys etc and published a comprised version

[Hynek Kydlíček (hynky1999)]

Like tell me, what will this restriction prevent you from doing ? If you relly need a version of package that's newer than 14 days, we can always temp disable this.

[Guilherme Penedo (guipenedo)]

No you are not, you can always enforce package versions, by excluding temporarly this packages

This assumes you will actually keep track of all critical security fixes that happened in the last 14 days 24/7, which realistically you won't.

yes the whole point is to prevent people working on this package, to get compromised

Sure, but then you should just instruct codex or add something locally to prevent it on your own setup. You don't need to impact everyone using refiner.

Like tell me, what will this restriction prevent you from doing ? If you relly need a version of package that's newer than 14 days, we can always temp disable this.

this is not the right question. the right question is: do you need to impact every single person that will use the package just to address 2 people's setups? Surely it makes more sense to enforce security guarantees on those people's setups than to just do this for everyone

[Hynek Kydlíček (hynky1999)]

This assumes you will actually keep track of all critical security fixes that happened in the last 14 days 24/7, which realistically you won't.

No not true. There is big diff right. Changing this means somebody has to go and do work, which also means he should be very sure he is NOT exposing himself to such vuln. Compared to not having this, where you are exposed 24/7 unknowingly.

Sure, but then you should just instruct codex or add something locally to prevent it on your own setup. You don't need to impact everyone using refiner.

This is not true, if people get owned by having your package installed the blame will go on the people maintaining it. If you get supply chain attacked what do you tell me ? Git gud noob, you should have protected yourself (very few people know about this setting in uv) ? Or it's not my fault it's fault of the package that we got supply chain by ? Neither of this is right response

this is not the right question. the right question is: do you need to impact every single person that will use the package just to address 2 people's setups? Surely it makes more sense to enforce security guarantees on those people's setups than to just do this for everyone
It's the right question. I would consider the inversion, if we didn't live in post-mythos world where you supply chain is a thin that happens once in a while. We are living in a world where you get new attack every few days, so prevention should be default not an optional security.

I am okay with reducing time, we can do like 3 days. But for sure we want to have this. Also what's better re-evaluating policy once you get attacked ? Or re-evaluating when we actually see real arguments against it -> e.g people having issue because it doesn't let them installed packaged released 2 days ago ? Clearly second is way better.

[Guilherme Penedo (guipenedo)]

No not true. There is big diff right. Changing this means somebody has to go and do work, which also means he should be very sure he is NOT exposing himself to such vuln. Compared to not having this, where you are exposed 24/7 unknowingly.

Ok but he might be exposed to other vulnerabilities that have been patched? The argument applies both ways, and you are implicitly choosing one kind of vulnerabilities (supply chain attacks that are detected in a few hours over other types of security vulnerabilities or bugs that have been patched in newer versions)

This is not true, if people get owned by having your package installed the blame will go on the people maintaining it. If you get supply chain attacked what do you tell me ? Git gud noob, you should have protected yourself (very few people know about this setting in uv) ? Or it's not my fault it's fault of the package that we got supply chain by ? Neither of this is right response

Maybe we are not talking about the same thing. If refiner itself gets supply chain pwned, that is a big problem. If a dependency of refiner is, then no one will blame you. Just like now people are not blaming the packages that depend on tanstack! And maybe we can tone down the dumb rhetoric? wtf is this "Git gud noob, you should have protected yourself"

I am okay with reducing time, we can do like 3 days. But for sure we want to have this. Also what's better re-evaluating policy once you get attacked ? Or re-evaluating when we actually see real arguments against it -> e.g people having issue because it doesn't let them installed packaged released 2 days ago ? Clearly second is way better.

I care about two issues:

• refiner itself being compromised, in the sense that some version is pushed to pypi with malicious code (what happened to tanstack)
• us individually being compromised, and our keys exposed

The first is something that is our responsibility as maintainers. It makes sense to harden our CI so that the tanstack issue doesn't happen, either directly (in their case it was some cache bullshit) or through another compromised package running on our CI.

The second is something we should address by hardening our own individual local setups.

Forcing people to use outdated package versions when they install refiners is not something you should do in any case.

Besides this timestamp thing brings all sorts of reproducibility issues. If you want something like this then what people do is just pin the versions. We can pin the versions and update them every now and then after checking if you really insist, but the timestamp thing makes no sense as a thing you are distributing

[Hynek Kydlíček (hynky1999)]

Ok but he might be exposed to other vulnerabilities that have been patched? The argument applies both ways, and you are implicitly choosing one kind of vulnerabilities (supply chain attacks that are detected in a few hours over other types of security vulnerabilities or bugs that have been patched in newer versions)

Not really, because if you uv sync you will get what's inside the uv.lock, that's the beauty of it it will not upgrade by default. So without this you still have the same exact problem. And this is quite sensible default, you want no upgrade by default + have depedency bot to tell you you should upgrade. Same reason why linux servers don't bump version on every new update, only gets updated once in a while or because of security vulns.

Maybe we are not talking about the same thing. If refiner itself gets supply chain pwned, that is a big problem. If a dependency of refiner is, then no one will blame you. Just like now people are not blaming the packages that depend on tanstack! And maybe we can tone down the dumb rhetoric? wtf is this "Git gud noob, you should have protected yourself"

Two things:
A) Yeah I think you will still get partial blame, since you indeed could have prevented this by having this setting
B) It directly exposes you to being supply chain hacked. Again mistralai likely got supply chain attacked because one of the devs got his laptop compromised resulting in compromised package.

I care about two issues:

refiner itself being compromised, in the sense that some version is pushed to pypi with malicious code (what happened to tanstack)
us individually being compromised, and our keys exposed
The first is something that is our responsibility as maintainers. It makes sense to harden our CI so that the tanstack issue doesn't happen, either directly (in their case it was some cache bullshit) or through another compromised package running on our CI.

The second is something we should address by hardening our own individual local setups.

Forcing people to use outdated package versions when they install refiners is not something you should do in any case.

See point 1, you arleady do this with the frozen lock and its sensible default.

Besides this timestamp thing brings all sorts of reproducibility issues. If you want something like this then what people do is just pin the versions. We can pin the versions and update them every now and then after checking if you really insist, but the timestamp thing makes no sense as a thing you are distributing

I don't understand the issue with timestamp and reproducibility really. That's uv.lock responsibility

Really the only argument against this is if vllm releases a new version and you need this version to run a model. Beyond this there is no good argument against this.

[Hynek Kydlíček (hynky1999)]

Really the only argument against this is if vllm releases a new version and you need this version to run a model. Beyond this there is no good argument against this.

So yeah we can do 3 days and see if it's indeed a problem or not.

[Guilherme Penedo (guipenedo)]

Same reason why linux servers don't bump version on every new update, only gets updated once in a while or because of security vulns.

but that's still quite different. pinning versions is much more reasonable than this time based thing.

B) It directly exposes you to being supply chain hacked. Again mistralai likely got supply chain attacked because one of the devs got his laptop compromised resulting in compromised package.

You're much more likely to be compromised from some other random package you are using in something else, this is just one package. This doesn't really protect you from all other issues you can have on your local machine.

I don't understand the issue with timestamp and reproducibility really. That's uv.lock responsibility

ok but then what is the point of adding this in the first place? what is it actually doing then?

Really the only argument against this is if vllm releases a new version and you need this version to run a model. Beyond this there is no good argument against this.

I think the burden of proof is reversed, what does this thing actually solve that pinning versions or just relying on uv.lock doesnt solve?