[Suggestion]: Bump git2 to 0.21.0 to clear RUSTSEC-2026-0183/0184 for downstream consumers

[mohitranka]

Which fff frontend(s)?

Core or Rust crate

What problem are you trying to solve?

Reporting from downstream — we depend on fff-search 0.10.1 (plus fff-grep and
fff-query-parser) in an unrelated Rust project, and it surfaced in our dependency audit.

The workspace root pins git2 = { version = "0.20.2", ... }, which resolves to 0.20.4.
That version carries two unsoundness advisories:

Advisory | Issue | Patched -- | -- | -- RUSTSEC-2026-0183 | Remote::list() passes a null pointer to slice::from_raw_parts() when the remote advertises no refs | >= 0.21.0 RUSTSEC-2026-0184 | BlameHunk from Blame::blame_buffer() can build Signatures from null pointers | >= 0.21.0

To be clear, I don't think fff is actually affected. Grepping fff-search 0.10.1's
sources, git2 usage looks limited to status queries — git2::Repository,
Repository::init, git2::Status*, git2::Error. Neither Remote::list() nor
blame_buffer()/BlameHunk appears anywhere. So this is a hygiene request, not a bug
report, which is why it is filed here rather than as a bug.

The actual cost is downstream. Both advisories are informational = "unsound", so
cargo audit and cargo deny surface them for every consumer of fff-search. Each of us
then has to triage them independently and add a suppression. On our side that meant:

{ id = "RUSTSEC-2026-0183", reason = "no direct git2 usage; transitive via fff-search, affected API never called" },
{ id = "RUSTSEC-2026-0184", reason = "no direct git2 usage; transitive via fff-search, affected API never called" },

A one-line bump in the workspace Cargo.toml removes that work for everyone downstream.

I noticed #670 and #671 covered a RustSec sweep in July; these two are dated May but may
have been missed since they are informational rather than vulnerabilities.

---

Proposed solution

Bump the workspace git2 to 0.21.0. The fixes are
rust-lang/git2-rs#1250 and
#1254, both merged in May 2026, and
0.21.0 is published and unyanked.

Happy to open a PR — though given default-features = false, your feature set, and the
vendored libgit2, you are better placed to judge whether 0.20 to 0.21 needs code changes.

Reporting from downstream — we depend on fff-search 0.10.1 (plus fff-grep and fff-query-parser) in an unrelated Rust project, and it surfaced in our dependency audit.

The workspace root pins git2 = { version = "0.20.2", ... }, which resolves to 0.20.4.
That version carries two unsoundness advisories:

Advisory Issue Patched
RUSTSEC-2026-0183 Remote::list() passes a null pointer to slice::from_raw_parts() when the remote advertises no refs >= 0.21.0
RUSTSEC-2026-0184 BlameHunk from Blame::blame_buffer() can build Signatures from null pointers >= 0.21.0
To be clear, I don't think fff is actually affected. Grepping fff-search 0.10.1's
sources, git2 usage looks limited to status queries — git2::Repository,
Repository::init, git2::Status*, git2::Error. Neither Remote::list() nor
blame_buffer()/BlameHunk appears anywhere. So this is a hygiene request, not a bug
report, which is why it is filed here rather than as a bug.

The actual cost is downstream. Both advisories are informational = "unsound", so
cargo audit and cargo deny surface them for every consumer of fff-search. Each of us
then has to triage them independently and add a suppression. On our side that meant:

{ id = "RUSTSEC-2026-0183", reason = "no direct git2 usage; transitive via fff-search, affected API never called" },
{ id = "RUSTSEC-2026-0184", reason = "no direct git2 usage; transitive via fff-search, affected API never called" },
A one-line bump in the workspace Cargo.toml removes that work for everyone downstream.

I noticed #670 and #671 covered a RustSec sweep in July; these two are dated May but may
have been missed since they are informational rather than vulnerabilities.

Proposed solution
Bump the workspace git2 to 0.21.0. The fixes are
rust-lang/git2-rs#1250 and
#1254, both merged in May 2026, and
0.21.0 is published and unyanked.

Happy to open a PR — though given default-features = false, your feature set, and the
vendored libgit2, you are better placed to judge whether 0.20 to 0.21 needs code changes.

Proposed solution

No response