git_bin is configurable and threaded through AppState, but only the smart-HTTP path uses it. Three other call sites hardcode the binary name and resolve it through PATH.
Sites
Honors the configured binary:
git/smart_http.rs:107, :427, :618, :676 — all Command::new(git_bin)
Hardcodes "git":
git/issues.rs:15, :50, :67, :92, :113, :124, :184, :205, :210, :215api/ipfs.rs:2549, :2607api/repos.rs:3070, :7815
Why it matters
An operator who sets the knob gets it on some paths and not others, with no indication that the split exists. The plausible reasons for setting it — pinning a specific Git version, pointing at a wrapper, or using a hardened install outside PATH — all break silently when half the node ignores it. A version pin that holds for push but not for issue storage is arguably worse than no pin, because it looks like it worked.
There is no correctness difference when the configured value happens to equal the PATH-resolved git, which is presumably why this has not surfaced.
Fix direction
Thread git_bin through the remaining call sites. git/issues.rs currently takes only repo_path, so its signatures need the binary passed in — that is the bulk of the change.
Worth adding a test that asserts no Command::new("git") string literal survives outside #[cfg(test)], since the split re-opens easily. A grep-based test is unglamorous but is the thing that actually holds this closed.
Validation status
Verified by grep over the crate and by reading the call sites. Not verified by running the node against a non-PATH Git binary.
Found during an external audit pass. Duplicate-checked against open and closed issues; no existing coverage found, but the search used a limited keyword set.
git_binis configurable and threaded throughAppState, but only the smart-HTTP path uses it. Three other call sites hardcode the binary name and resolve it throughPATH.Sites
Honors the configured binary:
git/smart_http.rs:107,:427,:618,:676— allCommand::new(git_bin)Hardcodes
"git":git/issues.rs:15,:50,:67,:92,:113,:124,:184,:205,:210,:215api/ipfs.rs:2549,:2607api/repos.rs:3070,:7815Why it matters
An operator who sets the knob gets it on some paths and not others, with no indication that the split exists. The plausible reasons for setting it — pinning a specific Git version, pointing at a wrapper, or using a hardened install outside
PATH— all break silently when half the node ignores it. A version pin that holds for push but not for issue storage is arguably worse than no pin, because it looks like it worked.There is no correctness difference when the configured value happens to equal the
PATH-resolvedgit, which is presumably why this has not surfaced.Fix direction
Thread
git_binthrough the remaining call sites.git/issues.rscurrently takes onlyrepo_path, so its signatures need the binary passed in — that is the bulk of the change.Worth adding a test that asserts no
Command::new("git")string literal survives outside#[cfg(test)], since the split re-opens easily. Agrep-based test is unglamorous but is the thing that actually holds this closed.Validation status
Verified by
grepover the crate and by reading the call sites. Not verified by running the node against a non-PATHGit binary.Found during an external audit pass. Duplicate-checked against open and closed issues; no existing coverage found, but the search used a limited keyword set.