fix: deny expect_used and guard both CSV emitters

[h4x0r]

Two independent defects, kept in separate RED/GREEN commit pairs so each half reads on its own.

1. CSV emitted with no escaping (commits 1–4)

supertimeline.rs::emit_csv interpolated every field straight into the row. Only description got quote-doubling, and even that was wrapped in unconditional quotes rather than escaped.

• No formula guard. A description beginning with =, +, - or @ reached the file as a live formula. Descriptions are built from evidence, so those values are attacker-chosen.
• No escaping at all on event_type, source or tags. A comma in a tag added a column, silently shifting every later field of that row. EventType::Other(String) carries a parser-supplied string and breaks the same way.

Both emitters now build rows with one csv_record helper that runs every field through jsonguard::csv_field — adopting the fleet guard rather than hand-rolling one. No field is exempt, so a column added later cannot reach the file unguarded.

A second instance, beyond the reported line. timeline_format.rs::write_csv (the issen timeline --format csv path, more used than supertimeline) wrote through csv::Writer: quoting was correct, but it applies no formula guard, on the same evidence-derived path and description. Fixing only supertimeline would have left the busier command exposed, so it is fixed here too, with its own RED. Replacing the writer costs none of its escaping — csv_separators_in_values_round_trip reads the output back with the csv crate and asserts commas, embedded quotes and embedded newlines survive.

Tests split rows with the csv crate (BurntSushi), already an issen-cli dependency — an independent RFC 4180 reader rather than a splitter written for the test.

What this does NOT close — two jsonguard gaps, both upstream

Adopting csv_field is the right move, but it does not make the output fully guarded or fully faithful. Measured against the vendored crate, not inferred:

Input	Emitted	Verdict
=cmd|'/C calc'!A0	'=cmd|'/C calc'!A0	guarded
\t=cmd|'/C calc'!A0	'=cmd|'/C calc'!A0	guarded (tab stripped first, so = becomes char 0)
\r=cmd|'/C calc'!A0	"\r=cmd|'/C calc'!A0"	quoted, not guarded
\n=cmd|'/C calc'!A0	"\n=cmd|'/C calc'!A0"	quoted, not guarded
=cmd|'/C calc'!A0	=cmd|'/C calc'!A0	bare — neither quoted nor guarded
\u{00A0}=cmd	\u{00A0}=cmd	bare — neither quoted nor guarded

1. The formula guard keys off character 0 only. Any lead-in that survives the control-character filter defeats it. CR/LF at least get quoted; a leading space or non-breaking space gets nothing at all and reaches the file completely bare. A filename beginning with a space is not exotic in real evidence. jsonguard PR #5 addresses the CR/LF half and is unmerged; the whitespace half is not covered by it.

2. csv_field silently strips control characters without setting lossy. "a\tb.txt" is emitted as "ab.txt" with lossy == false — a field reported differently from the source, with nothing signalling the change. For a supertimeline that is a faithfulness problem, not just a cosmetic one.

Neither is fixed here, and neither is worked around locally: forking the guard at the call site would leave issen and the rest of the fleet disagreeing about what "guarded" means. They belong upstream in jsonguard.

Version footing: 0.2.4 is the newest published; this workspace's lock resolves jsonguard to 0.2.3, whose text.rs is byte-identical to 0.2.4 (diffed both vendored copies). So no lock bump changes any of the above today.

cap_display is deliberately not used on these paths: CSV is a machine view, so values are emitted whole. issen's human-view truncation is already char-safe (truncate / truncate_desc use char_indices); no &s[..n] byte-slice remains in the CLI.

2. expect_used was not denied (commits 5–6)

issen denied unwrap_used but not expect_used, so .expect(..) stayed a sanctioned way to panic. correctness and suspicious were also absent. All 66 members inherit via lints.workspace = true and none override with their own [lints] table, so the root table is the effective config everywhere.

Adding the lints took clippy from clean to 510 findings across 60 files (--keep-going; without it cargo stops at the first failing crate and reports 1). Of those, 25 were production sites — the rest were test code.

No #[allow] was added to silence a production site. Every one was fixed where it was:

Count	Cause	Fix
8	Mutex::lock().expect("mutex poisoned") in DataSource::read_at (qcow2, aff4, vhd, dmg, dd, vmdk, iso, vhdx)	return RtError::Io naming the source
7	literal IOC regexes recompiled per call, issen-signatures STIX	one IOC_PATTERNS table compiled once, plus a test
6	env::var(..) in three aggregator build.rs	main returns Result; message names the variable
2	ProgressStyle::with_template(..), issen-mft-tree	fall back to default styling (the bar is cosmetic)
2	serde_json::to_string_pretty(..) in frequency / processes --json	propagate; both runs already return Result
1	FieldRegistry::resolve("logon-type") in presets::logons	named LOGON_TYPE const that FIELDS contains
1	sugar() in timeline_query	returns Result

The one worth a second look is the mutex family. read_at already returned Result<usize, RtError>, so the failure had an error channel and was panicking anyway. A poisoned lock means an earlier read panicked while holding it — and with the disk legs running under rayon, that turned one failed read of one image into a panic on every subsequent read of that image. Reachable, not theoretical.

Two fixes deserve their rationale stated, because both replace a panic with a quiet path:

• STIX IOC extraction. A pattern that fails to compile is now dropped rather than panicking, which on its own would cost an IOC class silently — a bundle's SHA-256 indicators would simply stop being extracted. every_ioc_pattern_compiles is the new test that makes the drop safe: it fails the build if the table ever shrinks. The guarantee moved from a runtime expect to a build-time check.
• uac PAM credential-staging regex. Now returns Option; a None pushes a RootkitFinding recording that the scan did not run. Returning an empty Vec would have read as "no credential staging found" — the opposite of what happened.

The remaining 482 test-side sites took the fleet-sanctioned opt-out: #![cfg_attr(test, allow(clippy::unwrap_used, clippy::expect_used))] in 11 crate roots, and a plain #![allow(..)] in 19 tests//examples/ files, which are separate crates the crate-root attribute cannot reach.

Gate

• cargo build --workspace — clean
• cargo clippy --workspace --all-targets --keep-going — 0 findings
• cargo fmt --all --check — clean
• cargo test --workspace --no-fail-fast — one failure, issen-mem dispatch::tests::dispatch_windows_netstat_returns_ok. Pre-existing: it fails identically on origin/main, and this branch changes no file under crates/issen-mem/.

Cargo.lock is deliberately not in this PR. Building here rewrites it because the root Cargo.toml carries a local [patch.crates-io] into a sibling repo whose forensicnomicon-core has moved to 1.5.0 — churn from another worktree's in-flight state, not from this change.

🤖 Generated with Claude Code