Skip to main content
← Back to list
01Issue
BugShippedSwamp Club
Assigneeskeeb

Relationships

#1241 Issue submission redactor silently corrupts report bodies

Opened by ehazlett · 7/18/2026· Shipped 7/18/2026

The Lab's submission redactor rewrites issue bodies in ways that silently destroy meaning. We hit a case where it rewrote a report's evidence such that the report argued the opposite of its actual finding, and the only signal was a one-line count with no indication of what changed or where.

Note: this report deliberately avoids writing either triggering pattern literally, because doing so corrupts this issue too — the first submission mangled its own description of trigger 2. Where the patterns are meant, they are written as NAME〈eq〉value (read 〈eq〉 as an equals sign) and scheme〈css〉host〈at〉 (read 〈css〉 as colon-slash-slash and 〈at〉 as an at-sign).

What happens

Consider a report whose central evidence is a comparison table — one row showing output that is correctly masked, the other showing output that is not:

| case A | SOME_VAR〈eq〉***              |
| case B | SOME_VAR〈eq〉the-actual-value |

Every NAME〈eq〉value construction is replaced with [REDACTED-SECRET]. Because both rows contain one, both collapse to the same string — yielding a table that shows identical output on both sides, i.e. evidence that nothing is wrong. The contrast that was the entire point of the report is gone, and nothing in the stored body indicates it was altered.

The substitution also consumes the following closing quote or backtick. A YAML line of the form

run: echo "SOME_VAR〈eq〉${FROM_VAULT}"

loses its trailing " and breaks the surrounding code fence.

Submission printed only:

Redacted 4 secrets from issue content.

No locations, no before/after, no way to distinguish "redacted something harmless" from "destroyed the finding". We only caught it by re-fetching the issue and re-reading it. The report had to be reworded in prose — describing values rather than showing them — to survive submission.

Two known triggers

  1. NAME〈eq〉value pairs → [REDACTED-SECRET], consuming the following closing quote or backtick.

  2. scheme〈css〉…〈at〉… spans → treated as a user〈colon〉pass〈at〉host credential and greedily collapsed, eating everything between the 〈css〉 and the next 〈at〉. Hit previously on #1213, where placeholder ws〈css〉… URLs in repro steps caused the loss of several steps and an entire Expected/actual section, because a later 〈at〉swamp/… package mention closed the match.

    This trigger corrupted the first submission of this very issue: the sentence above originally contained a literal example, and the redactor consumed the explanation along with it.

Why this is worth fixing properly

The failure is silent, destructive, and biased toward the worst case. It hits hardest on reports whose evidence is a literal before/after of secret-shaped strings — exactly what a redaction, credential-handling, or masking bug report consists of. A reporter who doesn't re-read the stored body will believe they filed something they did not, and a maintainer reads a mangled artifact with no marker saying it was altered.

It also cuts against the redactor's own purpose: it fires on deliberately fake canary values chosen for a bug report, while the corruption it causes discourages including precise evidence at all. That this very issue had to be written in a private notation to survive filing is the clearest statement of the problem.

Ask

Any of these would substantially help, roughly in order of value:

  • Don't redact inside fenced code blocks and tables — that is where evidence lives, and where a reporter has most deliberately chosen the text.
  • Report what was changed — echo each redaction with its location, so the reporter can see immediately whether the finding survived. The current count gives no way to tell corruption from a no-op.
  • Narrow the matchers — the pair form is far too broad for a body that routinely contains shell and YAML; the credential matcher should not span across lines or unbounded distances.
  • Offer an opt-out (--no-redact, or a confirmation on submit) for reporters who have deliberately sanitized their content.

Environment

  • swamp 20260718.014016.0-sha.93325715; the second case previously on #1213
  • Repair after the fact is possible with swamp issue edit <n> --title "…" --body "…" — note --body requires --title alongside it even when the title is unchanged
02Bog Flow
✓OPEN✓TRIAGED✓IN PROGRESS✓SHIPPED+ 1 MOREASSIGNED+ 5 MOREREVIEW+ 4 MOREPR_MERGED+ 1 MORECONTRIBUTOR_NOTIFIED

Shipped

7/18/2026, 8:10:03 AM

Click a lifecycle step above to view its details.

03Sludge Pulse
keeb assigned keeb7/18/2026, 7:28:20 AM
Editable. Press Enter to edit.

keeb commented 7/18/2026, 8:10:11 AM

Thanks @ehazlett for reporting this! The fix has been merged and a release is on its way. We appreciate your contribution to swamp.

Sign in to post a ripple.