Development record
launch --dry-run prints WouldRefuseOn with %v and no termsafe.Sanitize, so a committed repo filename carrying raw terminal escapes reaches the terminal and CI log (sibling of iss-259/iss-264 at an unrecorded site)
issueresolvedminoriss-2608211432258689
launch --dry-run prints WouldRefuseOn with %v and no termsafe.Sanitize, so a committed repo filename carrying raw terminal escapes reaches the terminal and CI log (sibling of iss-259/iss-264 at an unrecorded site)
Frontmatter
| id | iss-2608211432258689 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | minor |
.abcd/work/issues/resolved/iss-2608211432258689-launch-dry-run-wouldrefuseon-unsanitised.md
open on GitHub ↗ · commit history ↗
mentions3
- dcn-26082100000000032026-08-21 — Bug-hunt round 5, branch bughunt-b/round-5. Baseline (make preflight
- iss-259intent-store paths render to the terminal unsanitised in several intent verbs: intent plan prints res.Intent.Path and intent create prints the minted path without termsafe.Sanitize, and a hostile clone can commit a drafts/itd-N-<slug>.md whose filename tail carries control bytes (intentFileRe admits anything but a newline after the id), reaching the owner's terminal as escape sequences. The promote render sanitises its two paths as of spc-24; close the class once by sweeping the sibling intent renders through termsafe.Sanitize.
- iss-264cmd/record-lint prints Finding.File and Finding.Message raw — no termsafe.Sanitize and no path scrub on the findings path (its scrubPaths covers only the two error exits), so any rule echoing repo content lets a hostile clone inject terminal escapes into CI logs, and any finding message embedding an os error can leak absolute paths. The abcd CLI surface sanitizes at its findings renderer; the standalone binary does not. Found by the spc-27 security review, which also caught (and the change fixed) the one in-diff instance.