Development record
scanner network ipv4Re and macRe rely on a trailing ASCII word boundary, silently missing a hard_fail address whose only sin is an adjacent word char
scanner network ipv4Re and macRe rely on a trailing ASCII word boundary, silently missing a hard_fail address whose only sin is an adjacent word char
Evidence
internal/adapter/scanner/network.go:75 (ipv4Re, hard_fail) and :91 (macRe, hard_fail) both end in \b. macRe is fixed-length pure-word-char + trailing \b — the exact dead-corner class burst-4/5 removed from patterns.go — so a4:83:e7:11:22:33_eth0 and 10.1.2.3_gw / "192.168.1.44_gw": 1 are dropped whole. Reproduced through ScanText; the adjacency machinery does not rescue it (10.1.2.3_10.1.2.4 → 0 findings). history.go:139-145 acknowledges a trailing-boundary-dropped span slips both redaction stages; its literal backstop covers $HOME only.
Adversarial verdict: CONFIRMED for ipv4Re + macRe (minor); lanHostRe/deviceHostRe REFUTED
Dropping the trailing \b on the two host-shape warn patterns adds hundreds of FPs (types.Locals, www.lan from www.langchain.com) — their trailing \b is precision-load-bearing. For ipv4/mac the fix is measured zero-FP: drop trailing \b; macRe needs no compensating guard (insideLongerColonRun already suppresses on a hex-digit neighbour); ipv4Re needs an isASCIIDigit(line[end]) guard added to insideLongerDottedRun to keep 1.2.3.1234/[::ffff:192.168.0.1000] silent. Repo tree 74→74, GOROOT src 1201→1201 added FPs = 0. Not prior art: the burst-5 "no token pattern relies on trailing \b" invariant was scoped to patterns.go and predates the network set (iss-157).
Frontmatter
| id | iss-307 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | minor |
.abcd/work/issues/resolved/iss-307-scanner-network-ipv4re-and-macre-rely-on.md
open on GitHub ↗ · commit history ↗
mentions5
- dcn-26082000000000022026-08-20 — bughunt round 2 (branch bughunt-b/round-2): captured the round-2 records (iss-346..iss-357, with the two colliding ids re-minted as iss-358/iss-359), fixed
- dcn-26082000000000032026-08-20 — Bug-hunt round 1 (hunt A), landed late: the round ran 2026-08-19 on a branch that
- iss-157shared scanner (launch dry-run, lifeboat pack, history capture) has token-shaped secret patterns and identity matchers (username, email, home path, github remote) but no network-identifier patterns — a lifeboat pack or launch bundle carrying a tailnet IP, device hostnames, or firewall posture ships clean. Same root gap as the audit rule; fix belongs in the shared primitive, not per-surface.
- iss-358scanner lanHostRe and deviceHostRe keep the trailing ASCII word boundary the iss-307 sweep dropped from ipv4Re and macRe, so a LAN or device hostname abutting an underscore or alnum suffix is silently missed
- iss-2608231000561060The repo-conformance lint runs in no gate while the record says it gates CI, and it is not currently gate-ready, which are two problems needing separate decisions. Verified 2026-08-23 on origin/main. brief/04-surfaces/README.md row 16 describes /abcd:lint as checking the three-tier layout, AGENTS.md router, durable decisions, docs currency, privacy hygiene and identity positioning, and states it 'backs prepare-this-repo and gates CI (itd-85)'. It does not gate CI. The Makefile's preflight target is lint-reviews record-lint docs-lint plus build, vet, test and race, with no abcd lint, and the Makefile has no abcd lint or repolint target at all. Searching .github/workflows for an invocation of the repo-conformance lint, excluding the unrelated 'abcd docs lint', returns nothing in ci.yml or release.yml, whose only lint steps are go run ./cmd/record-lint and go run ./cmd/abcd docs lint. The surface runs only when a human types it. The second problem is why simply wiring it up does not work. On current main the lint emits 19 privacy-hygiene findings, 17 at blocker severity, and the sampled ones are not leaks. Nine of the 19 are in the scanner's own source or in ledger entries about the scanner, where the patterns appear as subject matter. Three sampled outside that set are documentation examples: a Linuxbrew prefix in a spec table and again in [dcn-2608200000000006](../../decisions/dcn-2608200000000006-homebrew-distribution-recorded-and.md), and a CHANGELOG entry recording that certain path shapes stopped being read as usernames. So gating it today would fail every build on content that is correct. iss-305, resolved, records the mechanism -- hasAbsHomePath lacks the leading-boundary predicate its scanner twin has -- and iss-307, iss-308 and iss-324 are adjacent boundary defects in the same family. A waiver marker exists, abcd-lint:allow with the legacy spelling abcd-audit:allow, and the rule's own source uses it on two lines, so the mechanism is available but is not applied across the corpus. What makes this worth deciding rather than filing and forgetting: the rule is right about the case that actually bit. An absolute home path written into a ledger issue body is exactly what its pattern catches, and on 2026-08-23 two sessions independently wrote one. Neither was caught by an instrument. record-lint did not see them because its roots are ['.abcd/development'] and the ledger is in .abcd/work; the lint that would have seen them does not run. Note the two are not interchangeable, since record-lint is scoped to the durable record while privacy-hygiene scans every tracked file, so widening record-lint's roots is a different fix from running the lint. Decide in order: whether the record's gates-CI claim is corrected or made true, and if made true, whether the false-positive rate is addressed by waivers, by the iss-305 boundary fix, or by narrowing what blocks. Leaving the claim standing while the surface runs nowhere is the shape enforcement-claims-are-facts names, and iss-2608230847432286 records the class.