dev-util/cargo-fuzz
Cargo subcommand for fuzzing a crate with libFuzzer
ChangeLog
commit 1d108753cf613636bce908fb7eda66c48c13bb50
Author: lucascouts <lucascs@protonmail.com>
Date: Fri Sep 11 22:21:03 2026 -0300
add(app-benchmarks/vegeta-12.13.0, app-misc/watchexec-2.7.2, dev-go/govulncheck-1.8.0, dev-util/{ast-grep-0.45.3, cargo-fuzz-0.13.2, cargo-geiger-0.13.0, cargo-llvm-cov-0.9.1, cargo-mutants-27.1.0, reviewdog-0.21.0, shfmt-3.14.1, tokei-15.0.0}, dev-vcs/trufflehog-3.97.4, net-analyzer/nuclei-3.11.1), mod(.autoupdate/packages.toml)
Thirteen Rust and Go developer tools, none of which ::gentoo carries. Two
new categories: app-benchmarks (vegeta, next to ::gentoo's hey/wrk/siege)
and dev-go (govulncheck, next to ::gentoo's delve/gopls).
Only three existed anywhere: watchexec and tokei in guru, nuclei in pentoo.
Those three are derived from those ebuilds and moved forward -- watchexec
2.5.0 -> 2.7.2, tokei 14 -> 15, nuclei 3.11.0 -> 3.11.1 -- with CRATES
regenerated and ~arm64 added, which guru does not keyword. The other ten
are new.
DEPENDENCY RESOLUTION, AND WHY IT DIFFERS FROM dev-vcs/gitleaks
The six Go packages take a `go mod vendor` tarball hosted on
distfiles.obentoo.org as a second SRC_URI, the shape ::gentoo uses for
dev-go/golangci-lint. gitleaks, the overlay's existing Go package, instead
sets RESTRICT=network-sandbox and runs `ego mod download` at build time --
which pulls code off the network with nothing in the Manifest to check it
against. Here every dependency is covered by a Manifest checksum and the
build stays inside the sandbox. The cost is a tarball to regenerate on each
bump; every autoupdate record says so.
govulncheck: PROBE THE TAGS, NOT THE RELEASES
golang/vuln stopped publishing GitHub releases at v1.1.4 (January 2025) but
kept tagging; the current tag is v1.8.0, from three days ago. Pinning what
releases/latest reports is not merely stale, it is broken: v1.1.4 carries
golang.org/x/tools v0.29.0, which predates the Go 1.27 AST and panics with
"unexpected expr: *ast.KeyValueExpr" on any modern tree. Measured on four
projects before switching the record to rank tags.
This is the mirror image of the trap documented at the top of packages.toml,
where ranking tags is what misleads. Both records now state which endpoint
lies and why -- watchexec is the opposite case in the same commit: its tag
space is shared with a library crate sitting six majors ahead
(watchexec-v8.4.1 against CLI v2.7.2), so there the release endpoint is the
only safe one.
FOUND BY LOOKING AT THE INSTALLED IMAGE, NOT THE EBUILD
* ast-grep also installs a binary named `sg`, straight on top of
/usr/bin/sg from sys-apps/shadow -- a symlink to newgrp, base system. The
ebuild removes it, guarded so upstream dropping the binary fails loudly
rather than silently changing what ships.
* shfmt and govulncheck both report their version through
debug.ReadBuildInfo(), which for a tarball build says "(devel)". They
installed fine and then could not name themselves: `shfmt --version` said
"(devel)" and the scanner called itself govulncheck@v0.0.0, in output
people paste into reports. One patch each, in files/.
LICENSING
nuclei is MIT but statically links github.com/projectdiscovery/ldapserver,
which is GPL-2, so the binary is effectively GPL-2 and LICENSE says so. The
HashiCorp dependencies that first looked AGPL are not: the MPL-2.0 text
names the AGPL in its Secondary License clause.
cargo-llvm-cov drops its test-helper dev-dependency in src_prepare. It is a
git dependency pinned by rev, and cargo.eclass's [patch] entry does not
substitute a git source pinned that way, so cargo reaches for the network
even with the tarball unpacked beside it. Since cargo resolves the whole
graph before it knows only the binary is wanted, the dependency has to go;
the suite that uses it is restricted.
SECURITY REVIEW
Reachability analysis with govulncheck 1.8.0 rather than dependency-level
counting alone -- roughly half the declared findings are not reachable:
shfmt 0, govulncheck 0, vegeta 3 of 7, reviewdog 4 of 7, nuclei 5 of 8,
trufflehog 6 of 11. Rust side, osv-scanner over Cargo.lock: watchexec
clean, ast-grep 1, cargo-fuzz 2, cargo-llvm-cov 2, cargo-mutants 5, tokei
16, and cargo-geiger 62 across 40 packages -- it has not released since
August 2025 and carries cargo 0.86 against 0.97. No dependency was bumped
away from upstream: that would diverge the tree and break the next bump.
VERIFIED LOCALLY, NOTHING MERGED (host has no sudo)
All thirteen built and installed through `ebuild ... clean install` under a
PORTAGE_CONFIGROOT with the four unprivileged overrides; pkgcheck
--cache=no is clean on all thirteen; every md5-cache _md5_ matches its
ebuild; all thirteen autoupdate records were probed against the live
endpoint and agree with the packaged version.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Author: lucascouts <lucascs@protonmail.com>
Date: Fri Sep 11 22:21:03 2026 -0300
add(app-benchmarks/vegeta-12.13.0, app-misc/watchexec-2.7.2, dev-go/govulncheck-1.8.0, dev-util/{ast-grep-0.45.3, cargo-fuzz-0.13.2, cargo-geiger-0.13.0, cargo-llvm-cov-0.9.1, cargo-mutants-27.1.0, reviewdog-0.21.0, shfmt-3.14.1, tokei-15.0.0}, dev-vcs/trufflehog-3.97.4, net-analyzer/nuclei-3.11.1), mod(.autoupdate/packages.toml)
Thirteen Rust and Go developer tools, none of which ::gentoo carries. Two
new categories: app-benchmarks (vegeta, next to ::gentoo's hey/wrk/siege)
and dev-go (govulncheck, next to ::gentoo's delve/gopls).
Only three existed anywhere: watchexec and tokei in guru, nuclei in pentoo.
Those three are derived from those ebuilds and moved forward -- watchexec
2.5.0 -> 2.7.2, tokei 14 -> 15, nuclei 3.11.0 -> 3.11.1 -- with CRATES
regenerated and ~arm64 added, which guru does not keyword. The other ten
are new.
DEPENDENCY RESOLUTION, AND WHY IT DIFFERS FROM dev-vcs/gitleaks
The six Go packages take a `go mod vendor` tarball hosted on
distfiles.obentoo.org as a second SRC_URI, the shape ::gentoo uses for
dev-go/golangci-lint. gitleaks, the overlay's existing Go package, instead
sets RESTRICT=network-sandbox and runs `ego mod download` at build time --
which pulls code off the network with nothing in the Manifest to check it
against. Here every dependency is covered by a Manifest checksum and the
build stays inside the sandbox. The cost is a tarball to regenerate on each
bump; every autoupdate record says so.
govulncheck: PROBE THE TAGS, NOT THE RELEASES
golang/vuln stopped publishing GitHub releases at v1.1.4 (January 2025) but
kept tagging; the current tag is v1.8.0, from three days ago. Pinning what
releases/latest reports is not merely stale, it is broken: v1.1.4 carries
golang.org/x/tools v0.29.0, which predates the Go 1.27 AST and panics with
"unexpected expr: *ast.KeyValueExpr" on any modern tree. Measured on four
projects before switching the record to rank tags.
This is the mirror image of the trap documented at the top of packages.toml,
where ranking tags is what misleads. Both records now state which endpoint
lies and why -- watchexec is the opposite case in the same commit: its tag
space is shared with a library crate sitting six majors ahead
(watchexec-v8.4.1 against CLI v2.7.2), so there the release endpoint is the
only safe one.
FOUND BY LOOKING AT THE INSTALLED IMAGE, NOT THE EBUILD
* ast-grep also installs a binary named `sg`, straight on top of
/usr/bin/sg from sys-apps/shadow -- a symlink to newgrp, base system. The
ebuild removes it, guarded so upstream dropping the binary fails loudly
rather than silently changing what ships.
* shfmt and govulncheck both report their version through
debug.ReadBuildInfo(), which for a tarball build says "(devel)". They
installed fine and then could not name themselves: `shfmt --version` said
"(devel)" and the scanner called itself govulncheck@v0.0.0, in output
people paste into reports. One patch each, in files/.
LICENSING
nuclei is MIT but statically links github.com/projectdiscovery/ldapserver,
which is GPL-2, so the binary is effectively GPL-2 and LICENSE says so. The
HashiCorp dependencies that first looked AGPL are not: the MPL-2.0 text
names the AGPL in its Secondary License clause.
cargo-llvm-cov drops its test-helper dev-dependency in src_prepare. It is a
git dependency pinned by rev, and cargo.eclass's [patch] entry does not
substitute a git source pinned that way, so cargo reaches for the network
even with the tarball unpacked beside it. Since cargo resolves the whole
graph before it knows only the binary is wanted, the dependency has to go;
the suite that uses it is restricted.
SECURITY REVIEW
Reachability analysis with govulncheck 1.8.0 rather than dependency-level
counting alone -- roughly half the declared findings are not reachable:
shfmt 0, govulncheck 0, vegeta 3 of 7, reviewdog 4 of 7, nuclei 5 of 8,
trufflehog 6 of 11. Rust side, osv-scanner over Cargo.lock: watchexec
clean, ast-grep 1, cargo-fuzz 2, cargo-llvm-cov 2, cargo-mutants 5, tokei
16, and cargo-geiger 62 across 40 packages -- it has not released since
August 2025 and carries cargo 0.86 against 0.97. No dependency was bumped
away from upstream: that would diverge the tree and break the next bump.
VERIFIED LOCALLY, NOTHING MERGED (host has no sudo)
All thirteen built and installed through `ebuild ... clean install` under a
PORTAGE_CONFIGROOT with the four unprivileged overrides; pkgcheck
--cache=no is clean on all thirteen; every md5-cache _md5_ matches its
ebuild; all thirteen autoupdate records were probed against the live
endpoint and agree with the packaged version.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>


View
Download
Browse