Development record
hidden runes reach committed records verbatim because termsafe.EncodeHiddenRunes is not applied at the record-write boundary
hidden runes reach committed records verbatim because termsafe.EncodeHiddenRunes is not applied at the record-write boundary
Found by the round-2 adversarial security review of build/itd-179, and recorded rather than chased: the class REPRODUCES ON MAIN.
A bidi override, zero-width space, C1 control or DEL typed into a capture body,
a wontfix_reason or an abcd intent "<text>" headline lands in the committed
record verbatim today. The branch adds two more instances of the class
(--grounds on the ledger side and on the intent side, where the Markdown
writer has no equivalent of yamlScalar's below-0x20 guard) but does not
create it.
The repo already owns the canonical primitive: internal/termsafe/termsafe.go
declares itself "the one canonical sanitiser ... before it is written to a
terminal or a human report", and EncodeHiddenRunes carries a test saying a
caller can no longer smuggle a terminal escape or a Trojan-Source reorder into
a JSON surface OR A COMMITTED RECORD. It is called at two boundaries only
(internal/core/cite/fetch.go:212, internal/core/memory/ingest.go:694). It
landed for iss-359, category security, whose remedy was to percent-encode
surviving non-printing runes at the boundary.
So this is a one-canonical-primitive gap, not a missing primitive: the record write boundary does not call the sanitiser the repo built for it.
FOR THE FACILITATOR: closing this is a separate change with its own blast radius (every record-writing path), which is why it is captured open rather than folded into itd-179. Note the interaction: applying EncodeHiddenRunes at the grounds boundary would also close the invisibility half of iss-2608301206034359.
Grounds
- pursued: no committed ledger or intent record can carry a bidi override or zero-width rune verbatim again; a record written through any of these verbs still holding one raw would show it wrong
Frontmatter
| id | iss-2608301206073609 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | minor |
.abcd/work/issues/resolved/iss-2608301206073609-hidden-runes-reach-committed-records.md
open on GitHub ↗ · commit history ↗
mentions5
- iss-359cite fetch records a redirect-controlled FinalURL verbatim, so C1, bidi and zero-width runes in a hostile Location query reach abcd docs lint --json and the committed citations baseline raw; the termsafe doc claim that encoding/json escapes control characters is false for those classes
- iss-2608301206034359the grounds substance floor counts runes not letters so twenty zero-width spaces satisfy the promoted refusal
- iss-2608301306580014the privacy backstop has two blind spots over the issue ledger: the escaped Windows home path yamlScalar writes and a harness_leak root that excludes the ledger
- iss-2609251823551349capture disposition writes disposition_grounds and exit_condition redacted but never through termsafe.EncodeHiddenRunes (internal/core/capture/reading.go:471-479), so a bidi or zero-width rune in --exit-condition lands in the committed record verbatim, the class iss-2608301206073609 closed for other free-text writes (review-capture 2).
- itd-179The reasoning behind what was pursued no longer evaporates at the gate — readiness and triage record grounds for the conjecture, not only the decision