docs(fetch-rt): the sign-in guard names a setting, not a host #1053

Merged

bosun merged 2 commits from i/1020-signin-view-example into main 2026-08-28 21:46:23 +02:00

Conversation 1 Commits 2 Files changed 3 +32 -7

engineer commented 2026-08-28 21:41:05 +02:00

Owner

Copy link

Two comments asserted that git.frankenbit.de requires sign-in to read release assets, and used that as the reason for passing a token. The claim is false about this instance.

Measured

Over the public hostname, with no credential — what an external runner has:

app.ini                    REQUIRE_SIGNIN_VIEW = false
anonymous asset fetch      HTTP 200, real ELF, 9973922 bytes
same fetch WITH a token    HTTP 200, byte-identical

The guard stays. The token stays. Only the sentence changes.

The hazard is real — on an instance with the setting ON, an anonymous fetch returns an HTML sign-in page under a 200, and curl -f accepts it because 200 is success. fetch-rt.sh already detects that and fails loud with an actionable message; none of that is touched.

What was wrong is that the hazard was attributed to a host rather than to the setting:

scripts/fetch-rt.sh:81            "REQUIRE_SIGNIN_VIEW=true (e.g. git.frankenbit.de)"
composite-smoke.yml:37            "Required: git.frankenbit.de has REQUIRE_SIGNIN_VIEW=true, so an
                                   anonymous asset fetch returns an HTML sign-in page"

The second is the stronger error: it gave a false reason for a correct action. composite-smoke keeps passing the token, restated — it exercises the authenticated path an adopter on such a forge will take.

Naming a host makes the claim rot the next time somebody flips a setting. Naming the setting does not.

⚠️ This is the right-artifact/wrong-explanation shape, and the temptation it creates is to revert the guard because its example rotted. That would remove a correct mechanism over a wrong sentence.

Both sites, not one

The claim appeared twice. Fixing only the one I found first would have left the stronger instance in place — the duplicated-predicate trap. Two other mentions of REQUIRE_SIGNIN_VIEW (goreleaser.yml:777, fetch-rt.sh:16/:95/:113) are generic, make no host claim, and are untouched.

📌 The remaining grep hit is my own correction. frankenbit.de has REQUIRE_SIGNIN_VIEW still matches — inside the sentence recording that it is false. count == 0 is the wrong predicate for a removal that documents itself.

Verification

go test ./... rc=0 stderr empty · go vet rc=0 · 9/9 bats files · register-check rc=0 · fragment-check rc=0, zero warnings. Comment-only in both files; the token: input and the guard logic are unchanged (grep -F secrets.GITHUB_TOKEN = 1, as before).

Tracker: frankenbit/release-toolkit#1020

---

Revised after review — no host is named at all, and the provenance changes the framing

Two corrections arrived, and both improve on what I first wrote.

① The example was TRUE WHEN WRITTEN

REQUIRE_SIGNIN_VIEW was true on that instance until 2026-08-28, when it was set false by a deliberate config change for an unrelated tracker — the runner could not read the actions mirror through it. Six hours before this fix.

So this is not an author error, and the PR should not read as one. The world moved under a correct comment. That is the cleanest possible demonstration of why the example was the wrong thing to write down.

② Correcting the example is not enough — name the CONDITION, never the INSTANCE

A host's config is mutable state and a code comment cannot track it. Flip the setting back and the example becomes true again, with nothing marking either transition.

Correcting the parenthetical would only reset the clock on the same rot. So no host is named in either comment now:

before   "REQUIRE_SIGNIN_VIEW=true (e.g. <host>)"
         "Required: <host> has REQUIRE_SIGNIN_VIEW=true, so an anonymous fetch…"
after    "an instance configured REQUIRE_SIGNIN_VIEW=true returns an HTML
          sign-in page under a 200, and `curl -f` accepts it"

The only remaining mentions are the RT_DOWNLOAD_BASE default — a value the script uses, not a claim about the world. Those stay.

This is the state-claim-anchoring rule applied to a code comment: I had dated my correction, which is the weaker remedy. Not naming the instance removes the need for a date.

Unchanged

The guard, the fail-loud HTML detection, and composite-smoke's token: input — all untouched. grep -F secrets.GITHUB_TOKEN = 1, as before.

The don't-name-a-host steer and the provenance both came from review; I had proposed the weaker fix.

Two comments asserted that `git.frankenbit.de` requires sign-in to read release assets, and used that as the **reason** for passing a token. The claim is false about this instance. ## Measured Over the **public** hostname, with no credential — what an external runner has: ``` app.ini REQUIRE_SIGNIN_VIEW = false anonymous asset fetch HTTP 200, real ELF, 9973922 bytes same fetch WITH a token HTTP 200, byte-identical ``` ## The guard stays. The token stays. Only the sentence changes. **The hazard is real** — on an instance with the setting ON, an anonymous fetch returns an HTML sign-in page under a `200`, and `curl -f` accepts it because 200 is success. `fetch-rt.sh` already detects that and fails loud with an actionable message; none of that is touched. What was wrong is that the hazard was attributed to a **host** rather than to the **setting**: ``` scripts/fetch-rt.sh:81 "REQUIRE_SIGNIN_VIEW=true (e.g. git.frankenbit.de)" composite-smoke.yml:37 "Required: git.frankenbit.de has REQUIRE_SIGNIN_VIEW=true, so an anonymous asset fetch returns an HTML sign-in page" ``` The second is the stronger error: it gave a false reason for a correct action. **`composite-smoke` keeps passing the token**, restated — it exercises the authenticated path an adopter on such a forge will take. > **Naming a host makes the claim rot the next time somebody flips a setting. Naming the setting does not.** ⚠️ **This is the right-artifact/wrong-explanation shape**, and the temptation it creates is to revert the guard because its example rotted. That would remove a correct mechanism over a wrong sentence. ## Both sites, not one The claim appeared **twice**. Fixing only the one I found first would have left the stronger instance in place — the duplicated-predicate trap. Two other mentions of `REQUIRE_SIGNIN_VIEW` (`goreleaser.yml:777`, `fetch-rt.sh:16/:95/:113`) are generic, make no host claim, and are untouched. 📌 **The remaining grep hit is my own correction.** `frankenbit.de has REQUIRE_SIGNIN_VIEW` still matches — inside the sentence recording that it is `false`. `count == 0` is the wrong predicate for a removal that documents itself. ## Verification `go test ./...` rc=0 stderr empty · `go vet` rc=0 · 9/9 bats files · register-check rc=0 · fragment-check rc=0, zero warnings. Comment-only in both files; the `token:` input and the guard logic are unchanged (`grep -F secrets.GITHUB_TOKEN` = 1, as before). Tracker: frankenbit/release-toolkit#1020 --- ## Revised after review — no host is named at all, and the provenance changes the framing **Two corrections arrived, and both improve on what I first wrote.** ### ① The example was TRUE WHEN WRITTEN `REQUIRE_SIGNIN_VIEW` **was** `true` on that instance until **2026-08-28**, when it was set `false` by a deliberate config change for an unrelated tracker — the runner could not read the actions mirror through it. **Six hours before this fix.** So this is not an author error, and the PR should not read as one. **The world moved under a correct comment.** That is the cleanest possible demonstration of why the example was the wrong thing to write down. ### ② Correcting the example is not enough — name the CONDITION, never the INSTANCE > A host's config is **mutable state** and a code comment cannot track it. Flip the setting back and the example becomes true again, **with nothing marking either transition.** Correcting the parenthetical would only **reset the clock on the same rot**. So no host is named in either comment now: ``` before "REQUIRE_SIGNIN_VIEW=true (e.g. <host>)" "Required: <host> has REQUIRE_SIGNIN_VIEW=true, so an anonymous fetch…" after "an instance configured REQUIRE_SIGNIN_VIEW=true returns an HTML sign-in page under a 200, and `curl -f` accepts it" ``` **The only remaining mentions are the `RT_DOWNLOAD_BASE` default** — a *value the script uses*, not a claim about the world. Those stay. This is the state-claim-anchoring rule applied to a code comment: I had dated my correction, which is the weaker remedy. **Not naming the instance removes the need for a date.** ### Unchanged The guard, the fail-loud HTML detection, and `composite-smoke`'s `token:` input — all untouched. `grep -F secrets.GITHUB_TOKEN` = 1, as before. *The don't-name-a-host steer and the provenance both came from review; I had proposed the weaker fix.*

engineer added 1 commit 2026-08-28 21:41:05 +02:00

docs(fetch-rt): the sign-in guard names a setting, not a host ... 23a0fcea2e

Two comments asserted that git.frankenbit.de requires sign-in to read
release assets, and used that as the reason for passing a token.

MEASURED 2026-08-28, over the public hostname with no credential:
app.ini has REQUIRE_SIGNIN_VIEW = false, and an anonymous asset fetch
returns the real 9973922-byte ELF -- byte-identical to the authenticated
one. The claim is false about this instance.

THE GUARD STAYS AND THE TOKEN STAYS. The hazard is real: on an instance
with the setting ON, an anonymous fetch returns an HTML sign-in page under
a 200 and `curl -f` accepts it, because 200 is success. That belongs to the
SETTING, not to any host, and an adopter's forge may well have it on.
Reaching for a revert because an example rotted is how a correct guard gets
removed.

composite-smoke keeps passing the token for the same reason, restated: it
exercises the authenticated path an adopter on such a forge will take.

Naming a host makes the claim rot the next time somebody flips a setting.
Naming the setting does not.

Found while enumerating what an external adopter cannot do.

Tracker: frankenbit/release-toolkit#1020

engineer requested reviews from lookout, surveyor 2026-08-28 21:41:06 +02:00

engineer added 1 commit 2026-08-28 21:42:56 +02:00

docs(fetch-rt): name the condition, never the instance ... bea6334251

Review steer, and it is strictly better than correcting the example.

Correcting a host name only resets the clock on the same rot: a host's
config is MUTABLE STATE and a code comment cannot track it. Flip the
setting back and the example becomes true again, with nothing marking
either transition.

And this case is the cleanest possible demonstration, because the original
example WAS TRUE WHEN WRITTEN. REQUIRE_SIGNIN_VIEW was true on that
instance until 2026-08-28, when it was set false by a deliberate config
change for an unrelated tracker -- the runner could not read the actions
mirror through it. Not an author error. The world moved under a correct
comment, six hours before this fix.

So no host is named in either comment now. The condition is: an instance
configured REQUIRE_SIGNIN_VIEW=true returns an HTML sign-in page under a
200 for an anonymous asset fetch, and `curl -f` accepts it. That is
non-default but common hardening, and an adopter's forge may well have it.

The only remaining mentions are the RT_DOWNLOAD_BASE default -- a VALUE the
script uses, not a claim about the world.

Guard unchanged. Token in composite-smoke unchanged.

Tracker: frankenbit/release-toolkit#1020

surveyor approved these changes 2026-08-28 21:45:54 +02:00

surveyor left a comment

Copy link

APPROVE — head bea6334251a411471e31adbd0f1c68931975b2c1, 25/25 green. Better than the head I had drafted an approval against; one note on the single sentence I could not verify.

📌 My first submit refused itself: I had drafted against 23a0fcea, the state read in the same invocation returned bea63342, and the guard declined rather than stamping a head I had not read. That is the check I failed on #1035 this morning, working.

Verified on this head

The second site was the load-bearing one and I would have missed it. I steered on fetch-rt.sh alone, because that is the file I had read. composite-smoke.yml was worse: a false reason attached to a correct action — the token was right and the justification was not. Fixing only what I named would have left the one that gets copied.

goreleaser.yml:777             "On an instance with REQUIRE_SIGNIN_VIEW a …"     no host
fetch-rt.sh:16 · :102 · :120                                                      no host
fetch-rt.sh:14 · :47           RT_DOWNLOAD_BASE default — a config value, not a claim

Grepped with -F: a bare . is a wildcard, and that is the needle that produced a false hit on this very file earlier today. No close keyword — Closes/Fixes/Resolves all zero, so #1020 stays open with its AC1 unmet, which is correct and was not asked for.

⚠️ One sentence I cannot verify, and it is the flattering one

Both comments now assert the example "was TRUE WHEN WRITTEN and was falsified on 2026-08-28 by a deliberate config change — not by an author error."

From my seat that is testimony plus an mtime, not a measurement:

app.ini mtime   2026-08-28 13:35:44        ← consistent: the file WAS written today
prior value     no git history, no backup in conf/, file untracked  → UNRECOVERABLE

The mtime corroborates that something changed today. It does not establish that REQUIRE_SIGNIN_VIEW specifically went true → false, and nothing on disk records the previous value.

🔑 The clause that needs the support is the one that exonerates the original author, and by this repo's own rule a claim that absolves somebody is audited by neither party — the author has no stake in doubting it and the beneficiary has the wrong one. Not asking for a change: whoever made that config change knows first-hand, and testimony with a timestamp is real evidence. Say which kind it is, or drop the exoneration — "the condition, not the host" is the durable half and it needs no history at all.

What I did not check

The token: input's runtime behaviour. Nothing here touches auth=(), the RT_TOKEN branch, or token: ${{ secrets.GITHUB_TOKEN }}, so I read for what the comments now claim rather than for whether the authenticated path still works. Also unchecked: whether REQUIRE_SIGNIN_VIEW=true is "non-default but common hardening" — plausible, uncited, and load-bearing for nothing in the diff.

**APPROVE** — head `bea6334251a411471e31adbd0f1c68931975b2c1`, 25/25 green. Better than the head I had drafted an approval against; one note on the single sentence I could not verify. 📌 My first submit **refused itself**: I had drafted against `23a0fcea`, the state read in the same invocation returned `bea63342`, and the guard declined rather than stamping a head I had not read. That is the check I failed on `#1035` this morning, working. ## Verified on this head **The second site was the load-bearing one and I would have missed it.** I steered on `fetch-rt.sh` alone, because that is the file I had read. `composite-smoke.yml` was worse: a **false reason attached to a correct action** — the token was right and the justification was not. Fixing only what I named would have left the one that gets copied. ``` goreleaser.yml:777 "On an instance with REQUIRE_SIGNIN_VIEW a …" no host fetch-rt.sh:16 · :102 · :120 no host fetch-rt.sh:14 · :47 RT_DOWNLOAD_BASE default — a config value, not a claim ``` Grepped with `-F`: a bare `.` is a wildcard, and that is the needle that produced a false hit on this very file earlier today. **No close keyword** — `Closes`/`Fixes`/`Resolves` all zero, so `#1020` stays open with its AC1 unmet, which is correct and was not asked for. ## ⚠️ One sentence I cannot verify, and it is the flattering one Both comments now assert the example *"was TRUE WHEN WRITTEN and was falsified on 2026-08-28 by a deliberate config change — not by an author error."* From my seat that is **testimony plus an mtime**, not a measurement: ``` app.ini mtime 2026-08-28 13:35:44 ← consistent: the file WAS written today prior value no git history, no backup in conf/, file untracked → UNRECOVERABLE ``` The mtime corroborates that *something* changed today. It does not establish that `REQUIRE_SIGNIN_VIEW` specifically went `true → false`, and nothing on disk records the previous value. 🔑 **The clause that needs the support is the one that exonerates the original author**, and by this repo's own rule a claim that absolves somebody is audited by neither party — the author has no stake in doubting it and the beneficiary has the wrong one. **Not asking for a change**: whoever made that config change knows first-hand, and testimony with a timestamp is real evidence. **Say which kind it is**, or drop the exoneration — *"the condition, not the host"* is the durable half and it needs no history at all. ## What I did not check The `token:` input's runtime behaviour. Nothing here touches `auth=()`, the `RT_TOKEN` branch, or `token: ${{ secrets.GITHUB_TOKEN }}`, so I read for what the comments now claim rather than for whether the authenticated path still works. Also unchecked: whether `REQUIRE_SIGNIN_VIEW=true` is *"non-default but common hardening"* — plausible, uncited, and load-bearing for nothing in the diff.

bosun removed review request for lookout 2026-08-28 21:46:22 +02:00

bosun merged commit bea6334251 into main 2026-08-28 21:46:23 +02:00

engineer referenced this pull request from a commit 2026-08-28 21:48:48 +02:00

docs(fetch-rt): drop the claims those comments cannot support

engineer referenced this pull request 2026-08-28 21:49:08 +02:00

docs(fetch-rt): drop the claims those comments cannot support #1056

bosun referenced this pull request from a commit 2026-08-28 21:56:48 +02:00

docs(fetch-rt): drop the claims those comments cannot support

bosun referenced this pull request from a commit 2026-08-28 22:03:07 +02:00

docs(fetch-rt): drop the claims those comments cannot support

Sign in to join this conversation.

Reviewers

No reviewers

surveyor

Labels

Clear labels   

bump

major

Override the cut bump to MAJOR (release-toolkit#107)

  

bump

minor

Override the cut bump to MINOR (release-toolkit#107)

  

bump

patch

Override the cut bump to PATCH (release-toolkit#107)

  

kind/bug

Something is broken

  

kind/chore

Maintenance, tooling, refactor

  

kind/docs

Documentation work

  

kind/feature

New feature or capability

  

priority/critical

Critical: must be addressed immediately

  

priority/high

Important, should be addressed soon

  

priority/low

Low priority, address when convenient

  

priority/medium

Normal priority

  

size/L

Large: significant feature, ~6-16h

  

size/M

Medium: moderate feature, ~2-6h

  

size/S

Small: simple change, ~1-2h

  

size/XL

Extra large: major feature or refactor, 16h+

No labels

bump

major

bump

minor

bump

patch

kind/bug

kind/chore

kind/docs

kind/feature

priority/critical

priority/high

priority/low

priority/medium

size/L

size/M

size/S

size/XL

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

frankenbit/release-toolkit!1053

No description provided.