Development record
no commit-time gate for user-private identifiers: the canonical home for this is itd-74 (name-banlist, in drafts/) — its private-banlist layer (local untracked file + committed guard hook, refuse by entry-key only, never echoing the value) is exactly the gate this incident needed. This issue is NOT a new primitive: it records the field evidence that itd-74's scope must include machine identifiers (hostnames, tailnet IPs/prefixes, device names), not only harness/project names, and that the incident strengthens the case for promoting itd-74 out of drafts (a maintainer decision). Generic patterns (iss-154/157) catch shapes; only the banlist catches this user's actual names. Prior art at skill level: the confidential-sources sync-banlist guard; dogfood prototype already live per itd-74's own record. Complements, does not replace, iss-154.
no commit-time gate for user-private identifiers: the canonical home for this is itd-74 (name-banlist, in drafts/) — its private-banlist layer (local untracked file + committed guard hook, refuse by entry-key only, never echoing the value) is exactly the gate this incident needed. This issue is NOT a new primitive: it records the field evidence that itd-74's scope must include machine identifiers (hostnames, tailnet IPs/prefixes, device names), not only harness/project names, and that the incident strengthens the case for promoting itd-74 out of drafts (a maintainer decision). Generic patterns (iss-154/157) catch shapes; only the banlist catches this user's actual names. Prior art at skill level: the confidential-sources sync-banlist guard; dogfood prototype already live per itd-74's own record. Complements, does not replace, iss-154.
Frontmatter
| id | iss-158 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | major |
.abcd/work/issues/resolved/iss-158-private-names-banlist-native-gate.md
open on GitHub ↗ · commit history ↗
mentions5
- dcn-26072900000000012026-07-29 — privacy-leak follow-up: illustrative machine identifiers in anything committed or published always come from reserved documentation ranges (RFC 5737 IPv4, RFC 3849 IPv6, RFC 2606 domains, RFC 7042 MACs; hostnames derived from the persona registry, e.g. alice-laptop) — the itd-79 persona rule applied to infrastructure. Recorded as principle `examples-use-reserved-identifiers`; enforcement is the iss-154 allowlist-inversion lint (flag any identifier OUTSIDE the reserved ranges), whose shipping promotes the principle to a discipline. No new intent: real private identifiers are itd-74's banlist territory — the incident evidence extends itd-74's scope to machine identifiers (iss-158) rather than founding a second primitive. Incident issue text deliberately names no repo and no values (shape only), so the ledger itself cannot re-leak.
- iss-154privacy-hygiene detects only absolute home paths — no network-identifier patterns (IPv4 incl. CGNAT/tailnet 100.64/10, hostnames, device names, ports-in-context). Field incident: an agent committed a Tailscale investigation (tailnet IP, two device hostnames, firewall posture, service port, presence/away patterns) into a public repo's committed tier and audit passed it silently. The v1 deferral note names only emails and private-repo names; network identifiers are not even recorded as deferred.
- iss-2608241612087533the release derivation cannot tell a back-filled resolution from a fresh one, so a ledger hygiene sweep re-announces old work as this release's content. internal/core/release/emit.go and internal/core/changelog/shipped.go read only folder membership and the record's impact field; neither reads resolved_by. The cut therefore equates 'record entered resolved/ since the base tag' with 'shipped in this release'. That equation holds only because RS001 now lands resolution inside the fixing commit, and a bulk hygiene sweep is the legitimate exception. Live instance: the 2026-08-24 sweep (089c0d61) closed 33 already-fixed records, and the v0.6.4 cut renders 14 of them as changelog entries for work first tagged v0.4.0, v0.4.1, v0.4.2 and v0.6.2 — four of the 14 are already cited by id under the 0.6.2 heading. The four records deciding the additive impact class (iss-98, iss-99, iss-100, iss-158) all describe pre-v0.6.3 work, so the version and the receipt tier rest on them too. Candidate fix: exclude an added record whose resolved_by.commit is reachable from the base tag, which needs the stamp back-filled on the six swept records that carry none.
- itd-74abcd Keeps the Names You Ban Out of Everything You Publish
- spc-20name-banlist