Ability to check if a dependency is too new (missing enforcement part of `min-publish-age`)

[linus-mullvad]

Problem

Getting (nightly) support for preventing cargo from upgrading dependencies to too new versions (-Zmin-publish-age) is a step in the right direction! #17009. But I can't find any way to enforce a don't-use-too-new-dependencies policies in repositories.

The new feature seems to focus on protecting the developer from accidentally upgrading to a too new dependency when modifying Cargo.lock locally. I see no way currently to integrate this in CI to let a project deny PRs and changes that tries to upgrade dependencies beyond the allowed point in time.

Without this I'm not sure how min-publish-age could benefit my projects, as I cannot easily protect my supply chain from too new dependencies.

Proposed Solution

Make cargo check and cargo build min-publish-age-aware and exit with a specific error code if any dependency in the dependency tree is too new. That would prevent anyone from ever compiling a too new dependency. This is arguably the important part, since a newly published malicious crate can only cause damage when actually built.

Also introduce a subcommand that only checks that the lockfile adheres to established configuration rules. This could run much faster in CI and would not need to check the actual code.

Notes

No response

[epage]

The ability to preserve versions within the lockfile was intentional as a mechanism to allow people to pull in critical too-new versions, like a security fix that was just released. Having a mechanism to enforce old versions would run counter to this and I would be inclined to say we should not support such a feature.

It could make sense to report such a version in a way that people can review it. I believe cargo update --workspace -vv will report versions that are too new. You could have a CI job that triggers on lockfile changes and reports the output of that command to CI.

[weihanglo]

Make cargo check and cargo build min-publish-age-aware and exit with a specific error code if any dependency in the dependency tree is too new.

Do you have a reproducible example for this? This should naturally work, if min-publish-age is configured, and the too-new dependency is not recorded in the lock file yet.

[weihanglo]

Relevant discussions:

• fix: cap lockfile verification memory and add trustLockfile opt-out pnpm/pnpm#11878
• minimumReleaseAge is silently bypassed for versions already in bun.lock oven-sh/bun#30525

[linus-mullvad]

allow people to pull in critical too-new versions

This is of course needed as well. But IMHO not at the cost of not at all being able to enforce a min-publish-age policy. A way to solve this could be with the exclude list (that is also a blocker for at least my adoption). When a project need to pull in a security fix, they temporarily add it to their exclude list.

[linus-mullvad]

Do you have a reproducible example for this? This should naturally work, if min-publish-age is configured, and the too-new dependency is not recorded in the lock file yet.

My intuition would be that the code that resolve dependencies, when the lockfile needs new dependencies, would be to simply not consider too new versions. If my min-publish-age is configured to 7 days and I add foo = 1 to my Cargo.toml and run cargo build, it would add the newest version of foo that satisfies the version requirement, but is older than 7 days.

If you meant invocation in the scenario where the lockfile already contains too new dependencies, then I would assume it to fail by default. But it could also try to downgrade the dependency. Automatically downgrading would align with the fact that cargo build already modifies the lockfile when its outdated today.

[weihanglo]

Sorry. Still confused. Not sure if you actually used it or not.

For dependency not yet in lockfile. Your intuition matches the implementation. That should just work like previously mentioned. If there is anything not working feel free to share a repro.

For the latter "Too-new version already in the lockfile", like epage suggested, the current workaround is grepping the verbose output (which is NOT meant for programmable use cases though). Something like

# WARNING: Cargo's verbose output is subject to change
if ! out=$(cargo +nightly -Zmin-publish-age update --workspace --dry-run -v 2>&1); then
    echo "$out"
    echo "error: cargo update failed"
	exit 1
fi
if echo "$out" | grep "minimum age "; then
    echo "min-publish-age violation"
    exit 1
fi

For exclusion config and adopting security fixes, yeah they are useful, though we currently have the not-perfect CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow cargo update --precise. Personally I would love to see the stabilization sonner than being blocked on these incremental improvements, unless there is a one-way-door decision that we cannot revert once stabilized. There are some other tools like https://crates.io/crates/cargo-cooldown actively exploring the possibilities btw.

[linus-mullvad]

the current workaround is grepping the verbose output (which is meant for programmable use cases though)

Do you mean that the following text is meant for programmable use? It very much look human facing and not something that has a stable guaranted format:

$ cargo +nightly -Zmin-publish-age update --workspace --dry-run -v
    Updating crates.io index
error: failed to select a version for the requirement `namespec = "^0.0.1"`
  version 0.0.1 is too new (published 34 minutes ago, minimum age 7 days)
location searched: crates.io index
required by package `mullvad-daemon v0.0.0 (/home/faern/src/mullvadvpn-app/.worktrees/min-publish-age/mullvad-daemon)`
help: to use too-new packages anyways, re-resolve with `CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow`

I tried doing this at first. But since I need an exclusion list (we can't wait a week to use our own crates when we release them), it became a bit too finicky to implement that parsing for my taste and I figured it would be better to engage upstream to see if we could discuss tooling improvements.

You could argue that what I'm asking for is exclusion list support. And yes, I want that also. Honestly one of these features could be enough, even if a bit ugly. With only exclusion support I could easily use the cargo +nightly update --dry-run workaround to find errors. But without exclusion list support I would need better tooling to check if any package is too new, and give me an easy to parse list of the names, so I can implement exclusion lists myself.

Cargo cooldown has no subcommand to assert a Cargo.lock contains no too-new dependency and fail if it does.I did look at cargo cooldown before. But it actively states that it does not solve the problem I'm trying to solve:

cargo-cooldown is intended for local development workflows where you refresh dependencies and build immediately. CI pipelines and release automation should usually use plain Cargo against committed Cargo.lock files.

Personally I would love to see the stabilization sonner ...

I'm not contesting that. As long as there are no one-way-door decisions to be made I also like quick stabilization. But that's why I want to bring up desired functionality early. To let the community discuss the direction of this feature, and evaluate if there are any potential one-way-door decisions in the way or not. As the feature is implemented right now, I can't really use it efficiently and I don't know if improving it in the direction I would like involves any one-way-door decisions or not.

[weihanglo]

Do you mean that the following text is meant for programmable use? It very much look human facing and not something that has a stable guaranted format:

Sorry it is for human only somehow I wrote it wrong

[linus-mullvad]

We implemented the CI enforcement check as a python script: mullvad/mullvadvpn-app#10798

It parses out dependencies from Cargo.lock and then queries https://index.crates.io/... to get the pubtime. We might re-implement it as a proper shareable github action later. I think this temporarily solve the problem, but also show that native cargo support would be a lot better. Manually parsing Cargo.lock and querying the index is not sustainable long term, and is something cargo would be a lot better suited to do.

EDIT: I do not think this feature request is blocking the stabilization of min-publish-age. Having that feature as currently implemented on stable sooner rather than later would be the best supply chain upgrade in itself.