Cargo config option to default to locked/frozen

[rickvanprim]

Describe the problem you are trying to solve
I would like to be able to specify in a workspace's cargo config that by default running commands such as cargo build imply the --locked/--frozen option so that users/build machines don't accidentally update Cargo.lock or rely on the network. To go along with this, cargo would need to support --unlocked/--unfrozen switches or cargo vendor would need to ignore --locked/--frozen.

Describe the solution you'd like
Somewhere in .cargo/config I am able to specify default switches for cargo invocations and cargo has command line options to unset binary switches that may be defaulted on.

Notes
The intent here is to ensure that dependencies are only explicitly and deliberately updated, instead of accidentally happening if someone happens to invoke cargo incorrectly (or a tool like rust-analyzer does).

[petreeftime]

There's already an option that prevents network access via

[net]
offline = true

Maybe making it a tristate true/false/update could be a solution?
Edit: although update suggests it only does updates offline, so instead build would make more sense.

[rickvanprim]

I think the documentation (pasted below) is slightly unclear, but my understanding is that --frozen is equivalent to --offline --locked. I don't believe there is currently a way to specify the locked part in the config. So that's half of this request.

The other half is changing the default behavior in the config and being able to override it in the other direction. Currently cargo defaults to online/unlocked unless specified otherwise on the command line. I want cargo in my repo to default to offline/locked unless specified otherwise on the command line.

--frozen
--locked
Either of these flags requires that the Cargo.lock file is up-to-date. If the lock file is missing, or it
needs to be updated, Cargo will exit with an error. The --frozen flag also prevents Cargo from
attempting to access the network to determine if it is out-of-date.

These may be used in environments where you want to assert that the Cargo.lock file is
up-to-date (such as a CI build) or want to avoid network access.

--offline
Prevents Cargo from accessing the network for any reason. Without this flag, Cargo will stop with
an error if it needs to access the network and the network is not available. With this flag, Cargo
will attempt to proceed without the network if possible.

Beware that this may result in different dependency resolution than online mode. Cargo will
restrict itself to crates that are downloaded locally, even if there might be a newer version as
indicated in the local copy of the index. See the cargo-fetch(1) command to download
dependencies before going offline.

May also be specified with the net.offline config value.

[ojeda]

Related (but not the same): #7169

[jrose-signal]

Poking this to point out that --offline --locked is stricter than --frozen, because it won't automatically download the crates that are in the lockfile.

I came here looking for an environment variable I could set in our CI, rather than a config option, but either would be sufficient. Plain command-line args are much harder to thread through wrapper scripts.

[jonhoo]

I'll add in another use-case for a configuration setting like this: build analysis. I have a (assumed non-malicious) build setting where developers can write what are essentially CI scripts (arbitrary bash) to build whatever artifacts they may want out of their crates. However they write their build, one requirement is that it provides a "receipt" of sorts that lists any and all dependencies they take. To aid in that, I provide a command they can supply a list of their lockfiles to and it'll generate said receipt in the appropriate format + location. Unfortunately, I don't have a good way at the moment to ensure that users don't then run commands that might add dependencies (code generation steps, cargo update, cargo add, whatnot). But if I could generate a configuration that ensured that any subsequent Cargo invocation be --locked, any (accidental) attempt by a user to do something that'd add in a dependency not "seen" by the recipt generation logic would be met with an error.

[briansmith]

To go along with this, cargo would need to support --unlocked/--unfrozen switches or cargo vendor would need to ignore --locked/--frozen.

We should be clear on the goal. IMO, the feature makes the most sense when it is treated as a strict security control, which implies:

• It should not be possible to weaken a default --locked or --frozen setting from the command line. This would reduce the need to audit every invocation of audit in a build/CI pipeline to ensure it doesn't override the default, including in scripts that do cargo <command> $@ or equivalent.
• A .cargo/config.toml in a nested directory (or otherwise more specific configuration) should only make the configuration stricter, not loosen the configuration. One should be able to git checkout a project without needing to audit (for the purpose of this feature) any .cargo/config.toml in it to ensure it doesn't loosen the configuration.

Even considering built-in commands, the set of commands that would need to be allowed to modify the lock file by default would likely grow over time. Similarly, the set of commands that should be allowed to do networking would likely grow over time. And, since custom commands can be configured, we'd need a way to control this for a dynamic set of commands.

The above considerations suggest that the configuration options should be structured as allowlist of commands that are allowed to alter Cargo.lock, and an allowlist of commands that are allowed to do networking. Cargo might warn when test, build, etc. are included in the allowlist because including them kind of defeats the purpose.

The above also suggests that the use of this new configuration mechanism should basically eliminate the ability for cargo build,``cargo test, etc. to ever update the lock file (or do networking if they are so restricted by the configuration).

The need to restrict which commands modify the lock file (r otherwise change dependency resolution) is a much more urgent and important feature than the ability to control frozen globally, especially since we can already control net.offline globally, so we should consider designing a global setting for --locked separately. I think the long term goal is that Cargo.lock contains enough information such that there would be no loss of security or repeatability (other than failing if there is a networking or integrity error) regardless of whether a package needs to be fetched from the network or whether it is already cached. There is a privacy issue with the fetch, and other reasons to avoid fetching implicitly, but there are other controls for handling those (custom registries, net.offline, etc.).