Skip to main content
← Back to list
01Issue
BugShippedSwamp CLI
Assigneesstack72

Relationships

#1463 Redactor false positives: HH:MM:SS timestamps masked as IPs, SHA-256 digests masked as secrets (both inside code fences)

Opened by jasonbarnett · 7/29/2026· Shipped 7/29/2026

Two redactor false positives I hit while filing #1461 and #1462, offered as data points rather than as a new bug: this is the same class as #1241, #1303, and #1392, and I think it's really just further evidence for one ask in #1241 that hasn't landed yet. Filing so the two patterns are written down; happy for it to be closed as a duplicate if they're already tracked somewhere I didn't find.

Filed with redaction left on, so the examples below are obfuscated: read <colon> as a literal :, and note that the SHA-256 digest is shown truncated. Writing them literally does not survive submission — which is the same notation tax #1241, #1303, and #1392 all had to pay, and arguably the cleanest statement of the problem.

Environment: swamp 20260727.193526.0-sha.03dabbb5, linux/aarch64.

Credit where it's due first

#1241 asked for four things. Two of them clearly shipped, and they changed my experience of this from "silent corruption" to "minor annoyance":

  • "Report what was changed — echo each redaction with its location." The CLI now prints a full per-line before/after diff on submit. This is why I noticed the corruption immediately instead of discovering it later in the stored body, which was #1241's core complaint.
  • "Offer an opt-out (--no-redact)." Present and documented on the command. Reaching for it sooner would have saved me the workaround I describe below — my own fault, not the tool's.

So the reporting and escape-hatch story is in good shape. What follows is only about matcher precision.

The two patterns

1. HH<colon>MM<colon>SS timestamps read as IP addresses

Pasting workflow-runner output redacted every wall-clock timestamp:

Redacted 6 IP addresses from issue content.
  " system │ Starting workflow remote-demo · 20<colon>18<colon>09 UTC"
    → " system │ Starting workflow remote-demo · [IP-1] UTC"
  "  build │ done echo-on-worker in 729ms · 20<colon>18<colon>10 UTC"
    → "  build │ done echo-on-worker in 729ms · [IP-2] UTC"

My guess is the IPv6 matcher reading a HH<colon>MM<colon>SS value as three colon-separated groups, though I haven't looked at the implementation. If so, requiring more groups, or hex-only segments, or rejecting candidates whose segments are all 2-digit decimal, would likely clear it. #1392 already covers this matcher over-firing on loopback and RFC 5737 addresses; the timestamp shape doesn't appear in that list, so it may have survived that fix.

This is the one with real cost, because timestamped log output is probably the single most common thing pasted into a swamp bug report. In my case the affected block was the "here is what the CLI actually prints" evidence in a docs-drift issue, so the redacted version quietly undercut the comparison the issue existed to make.

2. SHA-256 hex digests read as secrets

(digest truncated below; the real value was 64 hex chars)

Redacted 3 secrets from issue content.
  "\"checksum\": \"868f2f74…17030a\", \"isLatest\": true },"
    → "\"checksum\": \"[REDACTED-SECRET-1]\", \"isLatest\": true },"

These were checksum fields from swamp data versions <model> log — content digests of a 29-byte log file. High-entropy hex is genuinely hard to distinguish from a token and I don't think there's a clean general fix, so I raise it only because digests appear throughout swamp's own data and report output. A checksum-keyed JSON value might be a safe enough context to exempt.

Why I think this is #1241's remaining ask rather than its own fix

Both of my cases were inside fenced code blocks, which is exactly what #1241's first and highest-value ask covers:

Don't redact inside fenced code blocks and tables — that is where evidence lives, and where a reporter has most deliberately chosen the text.

That ask doesn't appear to have shipped with the rest. If it does, both patterns above stop mattering without anyone having to touch the IP or secret matchers, and so does the next false positive of this kind — which, going by #1241 → #1303 → #1392, there will be one of. That seems like better value than narrowing matchers one shape at a time, though I recognise "don't scan code fences" has an obvious downside if real secrets get pasted into them, and I'm not close enough to the threat model to know how that trade was settled.

One thing worth preserving

Identical inputs collapsed to the same placeholder ([REDACTED-SECRET-1] three times), which happened to preserve the exact property I was demonstrating — that three log artifacts were byte-identical. Deliberate or not, it meant the redacted body still made its point. Worth keeping if the matchers get touched.

Minor corroboration

I independently hit the --body requires --title quirk that #1241 notes at the end, when repairing #1461 with swamp issue edit. Already recorded there, so not raising it separately — just confirming it's still current.

02Bog Flow
✓OPEN✓TRIAGED✓IN PROGRESS✓SHIPPED+ 1 MOREASSIGNED+ 2 MOREREVIEW+ 4 MOREPR_MERGED+ 1 MORECONTRIBUTOR_NOTIFIED

Shipped

7/29/2026, 9:19:34 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack727/29/2026, 8:36:59 PM
Editable. Press Enter to edit.

stack72 commented 7/29/2026, 9:19:42 PM

Thanks @jasonbarnett 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.