ci: adopt the fleet reusable workflow - #12
Merged
Merged
Conversation
This repo could not adopt until now. Its test job runs on
[ubuntu-latest, macos-latest], and `os-matrix` was a boolean: `true` would have
added windows, a platform it does not support, and `false` would have dropped
macos, one it does. Neither preserves the decision, and an adoption PR that
changes which platforms CI covers is a behaviour change wearing a config
change's clothes. The `test-os` input added upstream takes an explicit list, so
the platform set here is identical to before.
Two inputs, each carrying an existing decision across rather than changing it:
test-os the exact platform list the replaced workflow used
coverage floor 92, just under the 92.76% measured at the fleet scope
(--workspace --all-features, 80,212 lines). This repo had NO
coverage job, so there is no earlier number to regress from —
this is the first measurement, and the floor holds the line
rather than granting slack. Rendered as migration debt, with a
warning on every run, not as a passing gate.
`musl-static` stays here verbatim. It is repo-specific and it is a real
assertion: mem4n6 ships as a static binary, and "it built" is not the same claim
as "it has no external dependencies", so the job checks `file` and `ldd` output.
Its toolchain pin is deliberate — a floating `stable` adds the musl target to the
wrong toolchain and the pinned build then fails with E0463.
Adoption ADDS checks this repo never had: cargo-deny, cargo-vet, a secret scan,
a fuzz build-check, rustdoc with warnings denied, a path-dependency gate, and
coverage. It also retires two fleet-wide defects without either being fixed here
by hand — `cargo fetch --locked` (a bare `cargo fetch` re-resolves, making the
`--locked` check structurally unable to fail; measured in 62 repos) and a pinned
gitleaks version rather than resolving `releases/latest` at job time (~1-in-40
flake across 25 repos).
memf-windows and memf-core HUNT credentials in memory images, so they
necessarily contain examples of what credentials look like: the PEM header
markers ssh_agent_keys.rs searches for, the vendor key prefixes
cloud_credentials.rs registers via scan_pattern!, and synthetic tokens in
#[cfg(test)] assertions that prove each detector fires. gitleaks was
reporting the detector's own machinery as the thing it detects -- 31
findings, none of them a credential.
Every matched literal was inspected. All are placeholders or published
constants: a Stripe key whose body is the letter sequence ABCDEF, a Slack
token whose body is a counted digit ramp, the AIza and eyJhbGciOiJSUz format
PREFIXES used as matchers rather than any issued value, the well-known NTLM
hash of the empty string, and Firefox logins.json fixtures whose "encrypted"
blobs are four repeated letters followed by 1234567890abcdef. None opens
anything, none authenticates to anything, so no rotation is warranted.
Scoped to those literals via value regexes -- NOT by disabling rules and NOT
by excluding files. A real credential appearing in any of these same files
still fails the job.
Verified by four controls rather than by the green alone:
A allowlist in place 0 findings
B allowlist removed 31 findings
C allowlist in place, plus a planted AWS
key in firefox_credentials.rs 1 finding
D planted key removed 0 findings
C is the one that matters: it proves the allowlist narrowed the scanner to
these specific values instead of turning the files into a blind spot. B
proves the config is load-bearing rather than decorative. The mutation in C
was asserted present in the file before scanning and absent after, so the
control cannot silently no-op.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…fiable 1.75 All nine MSRV jobs were red. The workspace declared rust-version = "1.75" and no member could build there. A declared rust-version is a claim, and this one was false for every crate here except memf-correlate. The refusals were INHERITED -- compilation never reached memory-forensic's own source, because a dependency's declaration or an edition-2024 manifest refused first (ruzstd, home, and friends). So no member had a measured floor of its own; the number was simply never true. Each member was measured against the committed lock by finding the lowest installed toolchain that builds it, and now declares that number: 1.75 memf-correlate (genuinely still holds 1.75) 1.87 memf-core memf-format memf-linux memf-session memf-symbols 1.88 memf-carve memf-strings memf-windows 1.96 mem4n6 mem4n6 is a binary, so per fleet policy its floor is the pinned toolchain from rust-toolchain.toml rather than a library promise -- nothing pins a library dependency against a *4n6 CLI. It does build at 1.88; tracking the pin just avoids maintaining a second number for no downstream benefit. memf-correlate keeps 1.75 rather than being swept up to the workspace default. It is the one member whose graph still allows it, and a low floor on a library is worth keeping where it is real. Verified: all ten build at their declared floor. Control: memf-core still REFUSES at 1.85, so 1.87 is a real boundary rather than a number raised until the job went quiet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two unrelated failures, both in this PR's remaining reds.
Clippy (10 sites) is a consequence of declaring the real MSRV: clippy only
suggests is_none_or, is_multiple_of and repeat_n once the declared floor
reaches them, so raising 1.75 to the truth switched them on. Not a
pre-existing defect.
memf-linux check_hooks.rs, psxview.rs x2 map_or(true, ..) -> is_none_or
memf-windows cachedump/credman/hashdump/
psscan/wdigest % N == 0 -> is_multiple_of(N)
memf-windows dpapi/decrypt.rs, registry_keys.rs repeat().take() -> repeat_n
Docs were red before this PR and are unrelated to the MSRV work. 28 rustdoc
links were broken: some pointed at private items, which a public doc cannot
link to, and the rest resolved to nothing. Both were demoted to plain code
spans, so the identifier still appears in the text without rustdoc claiming a
target that does not exist.
Deliberately not "repaired" by inventing module paths. A path that merely
compiles is how a doc link ends up silently pointing at the wrong item; if a
link is wanted later it should be added by someone who knows which item was
meant.
Also magic_gid.rs: `/proc/<pid>/status` was being parsed as an unclosed HTML
tag. Wrapped in a code span.
Verified: clippy --workspace --all-targets --all-features -D warnings is
clean, cargo doc with RUSTDOCFLAGS=-D warnings is clean, and the suite passes
3593 with 0 failures under --no-fail-fast so the count covers every target
rather than stopping at the first failure.
Note on method: cargo doc stops at the first failing crate, so a single run
only ever reveals one crate's worth of errors. The first pass looked like 5
problems; it took repeated runs to reach zero. Treating one run's output as
the full list would have shipped a still-red job.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The Fuzz (build check) job never reached a build. cargo-fuzz refused the
manifest outright:
Error: manifest `.../fuzz/Cargo.toml` does not look like a cargo-fuzz
manifest. Add following lines to override:
[package.metadata]
cargo-fuzz = true
That marker was simply absent. cargo-fuzz names the fix in its own error text.
Reproduced locally and confirmed by control: before the change `cargo fuzz
list` fails with the identical message; after it, it lists all targets
(fuzz_crashdump, fuzz_hiberfil, fuzz_kdump, fuzz_lime, ...). The marker was
asserted present in the file before re-running, so the control cannot silently
no-op.
Limit of the local evidence, stated rather than glossed: `cargo +nightly fuzz
build` could NOT be run to completion here. It fails on this macOS/aarch64 host
with `ld: initializer pointer has no target` while linking a sanitizer-
instrumented binary -- a host linker issue, not a defect in the targets. CI
builds on ubuntu-latest, so the build itself is verified by the job and not by
me. What is verified locally is exactly the failure CI reported: the manifest
is now recognised.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This repo could not adopt until now. Its test job runs on
[ubuntu-latest, macos-latest], and
os-matrixwas a boolean:truewould haveadded windows, a platform it does not support, and
falsewould have droppedmacos, one it does. Neither preserves the decision, and an adoption PR that
changes which platforms CI covers is a behaviour change wearing a config
change's clothes. The
test-osinput added upstream takes an explicit list, sothe platform set here is identical to before.
Two inputs, each carrying an existing decision across rather than changing it:
test-os the exact platform list the replaced workflow used
coverage floor 92, just under the 92.76% measured at the fleet scope
(--workspace --all-features, 80,212 lines). This repo had NO
coverage job, so there is no earlier number to regress from —
this is the first measurement, and the floor holds the line
rather than granting slack. Rendered as migration debt, with a
warning on every run, not as a passing gate.
musl-staticstays here verbatim. It is repo-specific and it is a realassertion: mem4n6 ships as a static binary, and "it built" is not the same claim
as "it has no external dependencies", so the job checks
fileandlddoutput.Its toolchain pin is deliberate — a floating
stableadds the musl target to thewrong toolchain and the pinned build then fails with E0463.
Adoption ADDS checks this repo never had: cargo-deny, cargo-vet, a secret scan,
a fuzz build-check, rustdoc with warnings denied, a path-dependency gate, and
coverage. It also retires two fleet-wide defects without either being fixed here
by hand —
cargo fetch --locked(a barecargo fetchre-resolves, making the--lockedcheck structurally unable to fail; measured in 62 repos) and a pinnedgitleaks version rather than resolving
releases/latestat job time (~1-in-40flake across 25 repos).