build: set exclude-newer to 7 days

[wochinge]

Proposed Changes
Only install packages which are at least 7 days old to avoid some basic supply chain attacks:
https://x.com/__mharrison__/status/2037621081771745388

Disclaimer: Experimental PR review

Greptile Summary

This PR adds a rolling supply-chain protection window to the uv resolver by setting exclude-newer = "7 days" in [tool.uv]. The intent is to avoid installing packages that were published within the last 7 days, reducing exposure to typosquatting or fast-follow malicious releases as described in the referenced post.

Key points:

• pyproject.toml gains a [tool.uv] section with the relative exclude-newer = "7 days" setting.
• uv.lock is regenerated: uv stored both the resolved absolute cutoff timestamp (2026-03-23T20:02:18.050568Z) and the ISO-8601 duration span (P7D). The span allows uv to recompute the cutoff on future uv lock runs while keeping installs reproducible.
• Several dev/test dependencies were rolled back to their most recent pre-cutoff version (anyio, openai, langchain-core, pygments, googleapis-common-protos, jsonpointer, python-discovery, etc.) — all still fully within their stated semver ranges.
• No production source code was changed; this is purely a build-tooling configuration update.

Confidence Score: 5/5

• Safe to merge — purely a build-tooling change with no impact on production code.
• The change is minimal and well-scoped: one new TOML key and a regenerated lock file. The format "7 days" is the correct relative-duration syntax supported by uv (confirmed by the lock file correctly resolving it to an absolute RFC 3339 timestamp + P7D span). No P0/P1 issues were found.
• No files require special attention.

Important Files Changed

Filename	Overview
pyproject.toml	Adds [tool.uv] section with exclude-newer = "7 days" as a rolling supply-chain protection window; no other changes.
uv.lock	Lock file regenerated with [options] block storing the resolved absolute cutoff (2026-03-23T20:02:18Z) and the span (P7D); several packages downgraded to the most recent version older than 7 days (anyio, openai, langchain-core, pygments, etc.).

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Developer runs uv lock] --> B{Is package upload-time\n≤ now - 7 days?}
    B -- Yes --> C[Package eligible for resolution]
    B -- No --> D[Package excluded from resolution]
    C --> E[Resolve to best matching version]
    E --> F[Write lock file with\nabsolute cutoff timestamp\n+ P7D span]
    F --> G[uv sync uses pinned\nversions from lock file]
    G --> H[Reproducible install\nunaffected by exclude-newer]

Loading

_{Reviews (1): Last reviewed commit: "build: set exclude-newer to 7 days" | Re-trigger Greptile}

[github-actions]

@claude review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 91ef203da9

ℹ️ 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 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 address that feedback".

[claude]

The exclude-newer = "7 days" value is not a valid uv datetime format — see the inline comment for details on how to fix this.

Extended reasoning...

Overview

This PR adds a [tool.uv] section to pyproject.toml with exclude-newer = "7 days" to provide basic supply chain attack protection by preventing installation of packages published within the last 7 days.

Security Risks

The intent is supply chain security, but the implementation is broken. uv only accepts ISO 8601 absolute datetime strings (e.g., 2026-03-23T00:00:00Z) for exclude-newer — not relative duration expressions like "7 days". As a result, uv will emit a parse warning and silently ignore the setting, meaning no supply chain protection is actually applied. The correct fix is to set UV_EXCLUDE_NEWER dynamically in CI rather than using a static (and stale) config value.

Level of Scrutiny

This is a small config change, but it touches a security feature. The bug makes the feature a no-op, so this warrants a fix before merging.

Other Factors

The inline comment on the PR already describes the issue and the recommended fix in detail. No other concerns with the PR structure.