CodeVetter · Repo Unpack · Risk map
BurntSushi/ripgrep
ripgrep has a small but real attack surface for a search tool: it executes external programs (decompressors, `--pre`, `--hostname-bin`), reads a config file from an environment-variable-named path whose contents become command-line flags, and memory-maps files it does not control. The codebase acknowledges most of these explicitly in comments — the mmap `unsafe` block calls its own reasoning "suspect", and `resolve_binary` exists specifically to stop Windows CWD-relative program resolution. The most fragile coupling is the 246KB `defs.rs` flag table, where a single flag touches parsing, help text, man page and four completion generators. The experimental index path is the least-finished area: `grep-index` opens with `#![allow(warnings)]`, its literal module is self-described as a prototype, and `index::read` doesn't actually use the index yet.
- Arbitrary code execution is by design in three places — `--pre` (`Command::new(bin).arg(path)`), `-z` decompressors, and `--hostname-bin` — all spawned with the user's environment inherited.
- `resolve_binary` is a deliberate Windows security mitigation: without it, `Command::new` hands relative paths to `CreateProcess`, which searches the CWD, so `rg -z` in an untrusted tree could run an attacker-planted `gzip.exe`. On non-Windows it is a no-op returning the path unchanged.
- `RIPGREP_CONFIG_PATH` turns a file's contents into command-line arguments that are prepended to argv, so anything that can set that env var or write that file can inject flags including `--pre` — a full code-execution vector with no allowlist or validation.
- The memory-map `unsafe` block carries an explicit hazard note: a file truncated concurrently with the search can raise SIGBUS and abort the process, and the author writes "This reasoning should be treated as suspect."
- File IO is unbounded outside the repo root by nature — `walk_builder` starts at user-supplied paths with `follow_links(self.follow)` and `same_file_system(self.one_file_system)`, so `-L` on a hostile tree can be walked out of the intended subtree.
- Index discovery reads `RIPGREP_INDEX_PATH` and otherwise walks every ancestor of the CWD looking for `.ripgrep`, a lookup the code itself flags as "subject to TOCTOU problems".
- `crates/index/src/lib.rs` opens with `#![allow(warnings)]`, suppressing all compiler lints for the entire index crate — including dead code and unused results.
- `crates/index/src/literal.rs` is self-described as "currently a prototype ... hastily written in order to bootstrap ngram extraction", so the ngram query construction (`GramQuery::And/Or/Literal`) is not production-hardened.
- Indexed search is effectively dead weight today: `index::read` binds the opened index to `let _index` and runs a full exhaustive search anyway, so `-X` costs index-open time for zero pruning benefit.
- `crates/core/flags/defs.rs` is 246KB — larger than the next two biggest files combined — and each flag must stay consistent across `Flag::update`, `doc_short`, `doc_long`, `doc_category` and `completion_type`, making it the highest blast-radius file for CLI changes.
- `FlagValue::unwrap_switch`/`unwrap_value` panic via `unreachable!` on mismatch; this is intentional (a bug indicator) but means an `is_switch()`/`update()` inconsistency in a new flag is a runtime panic rather than a compile error.
- Error reporting is global mutable state: three `AtomicBool`s (`MESSAGES`, `IGNORE_MESSAGES`, `ERRORED`) set once at startup and read at exit, so any code path that prints an error without going through `err_message!` silently fails to change the exit code.
- `eprintln_locked!` calls `std::process::exit(0)`/`exit(2)` directly on write failure, bypassing destructors and any in-flight buffered output — an abrupt-termination path inside a macro used throughout the binary.
- Sorting and parallelism are coupled by an assertion rather than the type system: `walk_builder` contains `assert_eq!(1, self.threads, "sorting implies single threaded")`, so a future change to the thread heuristic would panic at runtime.
- The `FLAGS` slice order is load-bearing for generated documentation ("The order of these flags matter ... This is why the deprecated flags are last"), an invariant no test enforces.
- `is_readable_stdin()` is documented as a heuristic with a "terrible failure mode": exec-process APIs that open an unused stdin pipe make `rg foo` appear to hang while it waits on stdin.