chore(lint): make the next process-environment read fail the build - #1843
Conversation
|
This pull request is part of a Mergify stack:
|
Merge Protections🔴 3 of 7 protections blocking · waiting on 👀 reviews and ⛓️ dependency
🔴 ⛓️ Depends-On RequirementsWaiting for
This rule is failing.Requirement based on the presence of
🔴 👀 Review RequirementsWaiting for
This rule is failing.
🔴 🔎 ReviewsWaiting for
This rule is failing.
Show 4 satisfied protections🟢 🤖 Continuous Integration
🟢 Enforce conventional commitMake sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
🟢 📕 PR description
🟢 🚦 Auto-queueWhen all merge protections are satisfied, this pull request will be queued automatically. |
2361d62 to
e94d90b
Compare
Revision history
|
There was a problem hiding this comment.
🟡 Changes recommended
The cargo-deny ban and Clippy enforcement need correction before approval.
Get a fresh assessment by requesting another Copilot review.
Pull request overview
This pull request adds safeguards against unsafe process-environment access and removes the temp-env dependency.
Changes:
- Adds Clippy and cargo-deny restrictions.
- Updates build scripts and smoke tests with explicit exceptions.
- Documents environment-testing practices.
File summaries
| File | Reviewed change |
|---|---|
deny.toml |
Adds the temp-env ban; critical finding (3 votes): use name instead of crate. |
crates/mergify-cli/tests/live_smoke.rs |
Uses vars_os for child environment inheritance. |
crates/mergify-cli/build.rs |
Allows the build-time environment read. |
clippy.toml |
Defines forbidden APIs; moderate finding (2 votes): enable clippy::disallowed_methods; nit (1 vote): complete both messages. |
Cargo.toml |
Removes the temp-env dependency. |
AGENTS.md |
Documents safe environment-testing practices. |
Review details
Suppressed comments (1)
clippy.toml:23
- Both lint reasons end with
building a child process's, which is an incomplete possessive and leaves the exception unclear. Saybuilding a child process's environmentin both entries.
{ path = "std::env::vars", reason = "read it through `mergify_core::env`; iterating the whole environment is only right when building a child process's, and needs an explicit allow" },
{ path = "std::env::vars_os", reason = "read it through `mergify_core::env`; iterating the whole environment is only right when building a child process's, and needs an explicit allow" },
- Files reviewed: 6/6 changed files
- Comments generated: 2
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
A convention nobody can enforce decays, and this one had already decayed once: `AGENTS.md` told contributors to use `temp_env` "never the unsound process-global `std::env::set_var` (`unsafe_code = "forbid"` bans it anyway)". Both halves were wrong. `temp_env` calls `set_var`, from inside a dependency, where the workspace's `forbid(unsafe_code)` does not reach. `unsafe_code = "forbid"` was already the guard against *our* code mutating the environment: `set_var` and `remove_var` are `unsafe fn`. So the new coverage is on the read side, which is what drifts: - `clippy.toml` disallows `std::env::var`, `var_os`, `vars` and `vars_os`, each with its replacement in the message, so a new direct read fails the build with a pointer to `mergify_core::env`. `set_var` / `remove_var` are listed as documentation of a rule `forbid(unsafe_code)` already enforces, and to say what someone relaxing that lint would be unlocking. `set_current_dir` joins them: it is the *safe* process-global mutator, it races every relative path in every other test thread, and two existing comments (`mergify-config/src/paths.rs`, `mergify-ci/src/scopes_detect/ changed_files.rs`) show contributors were already tempted by it. - `deny.toml` bans the `temp-env` crate, since no lint over our source can see a `set_var` that happens inside a dependency. It blocks the one we used, not the class: cargo-deny cannot express "nothing that calls setenv", and the file says so. Two explicit allows, both for reads that are not the process environment. `build.rs` reads cargo's environment for this one invocation and cannot depend on `mergify-core`. `live_smoke.rs` copies the parent's environment into the child it spawns, and does it with `vars_os` now: `vars` panics on a single variable that is not valid Unicode, which would have taken down every case in that file before it spawned anything. `AGENTS.md` states the rule with its reason, since the next person needs the argument and not just the rule, and with the two things that are easy to get wrong: an overlay hides the host environment, and it does not reach a dependency or a child process. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Change-Id: I185b16b8d8b1c65f325301628c1e6b1d1de789c1
e94d90b to
3aefe93
Compare
A convention nobody can enforce decays, and this one had already
decayed once:
AGENTS.mdtold contributors to usetemp_env"neverthe unsound process-global
std::env::set_var(unsafe_code = "forbid"bans it anyway)". Both halves were wrong.temp_envcallsset_var, from inside a dependency, where the workspace'sforbid(unsafe_code)does not reach.unsafe_code = "forbid"was already the guard against our codemutating the environment:
set_varandremove_varareunsafe fn.So the new coverage is on the read side, which is what drifts:
clippy.tomldisallowsstd::env::var,var_os,varsandvars_os, each with its replacement in the message, so a newdirect read fails the build with a pointer to
mergify_core::env.set_var/remove_varare listed as documentation of a ruleforbid(unsafe_code)already enforces, and to say what someonerelaxing that lint would be unlocking.
set_current_dirjoinsthem: it is the safe process-global mutator, it races every
relative path in every other test thread, and two existing comments
(
mergify-config/src/paths.rs,mergify-ci/src/scopes_detect/ changed_files.rs) show contributors were already tempted by it.deny.tomlbans thetemp-envcrate, since no lint over oursource can see a
set_varthat happens inside a dependency. Itblocks the one we used, not the class: cargo-deny cannot express
"nothing that calls setenv", and the file says so.
Two explicit allows, both for reads that are not the process
environment.
build.rsreads cargo's environment for this oneinvocation and cannot depend on
mergify-core.live_smoke.rscopies the parent's environment into the child it spawns, and does it
with
vars_osnow:varspanics on a single variable that is notvalid Unicode, which would have taken down every case in that file
before it spawned anything.
AGENTS.mdstates the rule with its reason, since the next personneeds the argument and not just the rule, and with the two things
that are easy to get wrong: an overlay hides the host environment,
and it does not reach a dependency or a child process.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com