ci: require crates.io dependencies to be at least 48h old

[wjones127]

Aikido endpoint protection blocks developers from pulling crates.io versions that are too young, so a dependency bump that looks fine to whoever opened the PR can leave everyone else unable to build. Today nothing catches that until it reaches someone's machine, and the failure they see is an opaque cargo resolution error rather than "this version is too new".

This PR moves the check into CI. ci/check_dependency_age.py dates every crates.io version in Cargo.lock, python/Cargo.lock and java/lance-jni/Cargo.lock, and fails if any of them is under 48 hours old. It runs as a new step in the existing cargo-deny job.

Cargo's own registry.global-min-publish-age setting does not work for this. It only constrains resolution — versions already written into a lockfile are grandfathered in and never looked at again, so it cannot tell us whether what we committed is too new.

Publish times come from the pubtime field of the sparse index, looked up in three tiers: cargo's index cache under $CARGO_HOME/registry/index/*/.cache first, which dates all three lockfiles in about two seconds with no network at all; then index.crates.io; then the crates.io API. The last tier matters more than it looks — Aikido filters the index it serves to developer machines, so on a laptop the index simply omits the offending version, and without the API fallback the script would report "cannot be dated" for precisely the versions it exists to flag.

A version that no source can date fails rather than passing silently. A few very old versions predate the index pubtime backfill; those are reported and allowed.

Escape hatch

Dependabot security updates ignore cooldown by design, so a security fix can arrive minutes after publication. ci/dependency-age-allowlist.toml exempts a specific crate and version, with a required reason so every exemption is reviewable in the diff. Entries go inert once the version passes 48 hours, so pruning them is housekeeping rather than urgent.

An entry here only unblocks CI. The version has to be allowlisted in Aikido too, or developers stay blocked locally — the file says so at the top.

Also changed

Dependabot gets a matching two-day cooldown on the cargo ecosystem so grouped weekly bumps stop proposing versions CI would reject. python/Cargo.lock and java/lance-jni/Cargo.lock are added to the paths filter in rust.yml, since otherwise a bump confined to one of those would not trigger the job that checks it.

Testing

The check fails on main right now, which demonstrates it works rather than indicating a problem with the PR. #9236 bumped opendal to 0.59.2 about six hours after that version was published; it clears the 48h floor around 02:40 UTC on 2026-09-17, after which CI here should go green on its own. Verified locally that adding the opendal family to the allowlist takes the run from 18 violations to a clean exit.

Not included

The uv, pip and maven ecosystems get no cooldown, and there is no equivalent age check for Python or Java dependencies. The same argument applies to them, but Aikido's Rust path is what is biting today.

🤖 Generated with Claude Code

[wjones127]

This check will succeed in 6 hours. It's a new rule and I don't want to have to revert and republish #9236

[lance-gatekeeper]

⚠️ Gate recommendation: approve with a non-blocking risk.

The merge from main leaves the assessed patch unchanged, and the dependency-age scan now succeeds against the updated lockfiles; the earlier OpenDAL age window elapsed as expected.

The escape hatch remains an operational two-system contract: CI cannot verify that the matching Aikido exception was installed, so an exemption merged out of order can still leave developer builds blocked. The allowlist documents the required ordering; maintainers should confirm the Aikido change before accepting an exemption.