secret-sweep.sh fails on a clean main — a gate that cries wolf #53

New Issue

2026-09-05T01:24:00Z

paulhitt commented

2026-09-05 01:24:00 +00:00

(Migrated from gitlab.com)

Scripts/secret-sweep.sh fails on main with no secret present, and has for a while:

── assigned password
Tests/FlamenetRelayTests/AttachmentIntegrityTests.swift:55:
    token: "deadbeef", verdict: .truncated(expected: 1024, found: 512)))

The literal deadbeef — an attachment token in a truncation test — trips the "assigned password" pattern. Verified against main itself, so it is not something a branch introduced.

Why this is worth fixing rather than living with

🔴 A gate that fails on a clean tree teaches you to run it and ignore the answer. That is strictly worse than not having it: the one time it catches something real, the habit is already to shrug. I hit it publishing relay#50 and had to stop and prove the match was pre-existing before I could trust my own branch.

⚠️ It is not in .gitlab-ci.yml, so nothing is blocked — it fails only for whoever runs it by hand before pushing, which is exactly the person it is meant to protect.

Two ways to fix, and they are not equivalent

Narrow the pattern. deadbeef is a hex literal, not an assignment to a password-shaped name. A pattern that required a password/secret/token identifier on the left would not match it. This is the fix that keeps the gate honest.
Rename the fixture. Cheaper, and it makes this instance go away while leaving the pattern free to false-positive on the next hex literal anybody writes.

Prefer 1. If 2, note in the sweep why the fixture is named what it is, so nobody renames it back.

Done looks like: ./Scripts/secret-sweep.sh passes on a clean main, and a deliberately planted secret still fails it — prove both, not just the first.

`Scripts/secret-sweep.sh` fails on `main` with no secret present, and has for a while: ``` ── assigned password Tests/FlamenetRelayTests/AttachmentIntegrityTests.swift:55: token: "deadbeef", verdict: .truncated(expected: 1024, found: 512))) ``` The literal `deadbeef` — an attachment token in a truncation test — trips the "assigned password" pattern. Verified against `main` itself, so it is not something a branch introduced. ## Why this is worth fixing rather than living with 🔴 **A gate that fails on a clean tree teaches you to run it and ignore the answer.** That is strictly worse than not having it: the one time it catches something real, the habit is already to shrug. I hit it publishing relay#50 and had to stop and prove the match was pre-existing before I could trust my own branch. ⚠️ It is not in `.gitlab-ci.yml`, so nothing is blocked — it fails only for whoever runs it by hand before pushing, which is exactly the person it is meant to protect. ## Two ways to fix, and they are not equivalent 1. **Narrow the pattern.** `deadbeef` is a hex literal, not an assignment to a password-shaped name. A pattern that required a `password`/`secret`/`token` *identifier* on the left would not match it. This is the fix that keeps the gate honest. 2. **Rename the fixture.** Cheaper, and it makes this instance go away while leaving the pattern free to false-positive on the next hex literal anybody writes. Prefer 1. If 2, note in the sweep why the fixture is named what it is, so nobody renames it back. **Done looks like:** `./Scripts/secret-sweep.sh` passes on a clean `main`, and a deliberately planted secret still fails it — prove both, not just the first.

paulhitt commented

2026-09-07 22:30:36 +00:00

(Migrated from gitlab.com)

Verified fixed on main today: Scripts/secret-sweep.sh reports secret sweep clean (216 files, 1 line(s) marked as fixtures) — the deadbeef attachment token in AttachmentIntegrityTests is now marked as a fixture rather than tripping the assigned-password pattern. The gate no longer cries wolf, so closing.

Verified fixed on `main` today: `Scripts/secret-sweep.sh` reports `secret sweep clean (216 files, 1 line(s) marked as fixtures)` — the `deadbeef` attachment token in `AttachmentIntegrityTests` is now marked as a fixture rather than tripping the assigned-password pattern. The gate no longer cries wolf, so closing.

paulhitt (Migrated from gitlab.com) closed this issue

2026-09-07 22:30:36 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: extant2000/flamenet-relay#53