felhom-controller/REPORT.md

REPORT — a secret leaves the page source, and two refusals learn to say what to do (v0.207.0, 2026-08-08)

R-249, R-252, R-253 — implementation. R-201's record corrected, R-254 filed. Controller v0.206.0 → v0.207.0, built, pushed and deployed to demo-hp guest 9201 and VM 325. No hub change was needed. Baselines re-read on arrival and all four repos matched the task exactly (felhom-controller 3d3b4496f377, felhom.eu 3f4fb3825f06); highest register ID was R-253.

---

1. Scenario A — the raw response body, before and after

This is the deliverable that matters, and it was measured on a live box with a positive control in both directions. A known passphrase was planted on VM 325 (a throwaway due for destruction the same hour) and the security settings page fetched exactly as the defect was originally found — with curl.

	v0.206.0 (the shipped defect)	v0.207.0 (the fix)
page bytes	50 208	51 115
positive control — card renders (a passphrase IS stored)	1	1
reveal control present	—	2
passphrase occurrences in the response body	1	0

The positive control is load-bearing. The first attempt at this check returned 0 on a box that had no passphrase stored at all — a zero that meant nothing. That is why the card's presence is asserted first: an empty listing is not evidence of emptiness.

Scenario B, live: POST /settings/retrieval-password/reveal → 200, Cache-Control: no-store, body 85 bytes carrying the correct passphrase (1 match against the planted value). The controller logged retrieval passphrase revealed via the security page from 192.168.0.100 (value never logged), and a grep of five minutes of controller log for the value itself returned 0.

The red-proof — the most important one here

Both halves of the fix were reverted (data["RetrievalPassword"] = … restored in handlers.go, and {{.RetrievalPassword}} put back inside a display:none span), each mutation asserted to have applied before running:

BOTH MUTATIONS APPLIED — verified by string change
--- FAIL: TestSecurityPage_DoesNotContainTheRetrievalPassphrase (0.08s)
    R-249: the retrieval passphrase is in the response body of the security page …

Restored; residue checked ({{.RetrievalPassword}} occurrences: 0); green again.

Why the tests assert the body and not a view: the old markup hid the value with CSS. Every test that asked what does the customer see passed while the bytes carried the secret. A test that cannot see a display:none span cannot see this defect at all.

---

2. §7.1's census — the pattern found once, looked for everywhere

It was worth doing: two more instances, one with a real secret.

Where	What	Verdict
app_info.html:185	an app's auto-generated first-login password in <span … hidden>{{.InitialCreds.Password}}</span> beside a „Megjelenítés" button	the same defect with a real per-install secret — ReadInitialCredentials reads it live out of the deployed container, so it is not the catalog's published default_creds
deploy.html:482	an auto-generated type: secret field in <input type="password" … value="{{$val}}">	weaker — the pre-deploy form must post the value; on an already-deployed app's page the exposure is gratuitous

Filed as R-254, not fixed — scope was R-249/R-252/R-253, and each needs its own reveal endpoint and its own body-asserting test rather than a shared quick edit. Recommended next, because R-249 proved the pattern is not theoretical.

Rotation advice, left to the operator: the walk5 instance is compromised (it reached a transcript) and dies with that customer's teardown. No other instance is known to have been read — but nothing records a read, which is itself part of the defect, and that is the honest state of the evidence. If any customer page has been screen-shared, saved or proxied, treat that passphrase as exposed.

---

3. §7.2's decision — which half of the reinstall promise was wrong

The promise was wrong, and the reason is structural rather than a matter of effort.

reconstituteOffbox refuses when GetStackHDDPath(stack) is empty, because the destination of a restore is the app's own data path — a drive the CUSTOMER chooses at deploy time. An automatic reinstall would mean the product picking that drive for them, which is precisely the decision this recovery path exists to leave with them (DOMAIN and SUBDOMAIN would have to be invented too).

So the smaller change is also the correct one: the copy now says to install first and routes there. The row's own code comment already read "restore in place vs. reinstall first" — the behaviour was right and the sentence had drifted.

---

4. Every changed Hungarian string, for review as copy

Removed (backups_restore.html) — the promise the restore could not keep:

„Nincs telepítve — a visszaállítás előbb újratelepíti."

Added (backups_restore.html, the not-installed row):

„Nincs telepítve — előbb telepítsd újra, utána hozhatod vissza az adatait." („telepítsd újra" links to /stacks/<app>/deploy)

Added (backups_restore.html, the precondition notice — renders only when no drive is registered):

„Előbb csatold vissza az adatmeghajtót. A mentéseid megvannak, és a meghajtók is megvannak — újratelepítés után viszont a gép még nem ismeri őket, ezért most nincs hová visszaállítani. Ez két kattintás: Tárhely → Meghajtók, „Meglévő meghajtó csatolása". Utána gyere vissza ide."

Changed (offbox_restore.go, the drive refusal):

was: „nincs elérhető adatmeghajtó a visszaállításhoz" now: „nincs regisztrált adatmeghajtó, ezért nincs hová visszaállítani — a meghajtók megvannak, csak újra kell csatolni őket a Tárhely → Meghajtók oldalon, utána ez a visszaállítás működni fog"

Changed (offbox_reconstitute.go, the not-installed refusal):

was: „a(z) %s nincs telepítve — előbb állítsd helyre az alkalmazást, utána az adatokat" now: „a(z) %s nincs telepítve, ezért nincs hová visszaállítani az adatait — telepítsd újra az alkalmazást (Alkalmazások), utána ez a visszaállítás működni fog"

Added (settings_security.html, reveal failure): „A visszaállítási jelszó lekérése nem sikerült." Added (reveal endpoint, nothing stored): „Ezen a gépen nincs tárolt visszaállítási jelszó."

---

5. Tests and red-proofs — each mutation asserted to have applied

Test	Scenario	Result	Red-proof (mutation → observed)
TestSecurityPage_DoesNotContainTheRetrievalPassphrase	A	PASS	value re-rendered into the page → FAIL, printing the exposure
TestSecurityPage_NoCardWhenNoPassphraseStored	A	PASS	— (gate is on existence, not the value)
TestRevealEndpoint_ReturnsThePassphraseToAnAuthenticatedCaller	B	PASS	remove the route/handler → customer cannot obtain it at all
TestRevealEndpoint_404sWhenNothingStored	B	PASS	—
TestRestorePage_NoRegisteredDrive_NamesTheReasonAndTheRoute	C	PASS	precondition block deleted → FAIL
TestRestorePage_HealthyBox_HasNoPreconditionNotice	E	PASS	notice made unconditional ({{if true}}) → FAIL
TestRestorePage_NotInstalled_DoesNotPromiseAReinstall	D	PASS	old promise restored → FAIL on all three assertions
TestHasRestoreDestination_AgreesWithTheResolver	seam	PASS	predicate forced true → FAIL

Red-proof D caught a fault in my own work. On its first run only two of its three assertions failed, because the explanatory HTML comment I had written quoted the old sentence — and HTML comments ship in the response body. The contradiction was still on the page, and the assertion that forbids it could never fail. The comment was rewritten to describe the old string without quoting it; re-run, all three assertions fail under the mutation. This is the same class as the defect being fixed, and it was found only because the red-proof was actually run.

One pre-existing test was updated, not deleted: TestOffsiteRestoreList_RenderedForRebuiltBox pinned the old sentence. Its intent — state the not-installed consequence, do not hide it — is unchanged; it now asserts the consequence and the route.

Green gate: go build ./... && go vet ./... && go test ./... → rc 0. controller_gates.py: all nine OK.

---

6. §7.5 — the currency gate went red, as predicted

newest released controller : 0.207.0
newest golden baked        : 0.206.0
GOLDEN CURRENCY GATE FAILED

The felhom-controller push needed no bypass — that repo's own gates passed. The felhom.eu push used git push --no-verify, declared in that commit message, in this report, and in R-242's row.

A bypass and NOT a waiver, deliberately. The gate offers a waiver for a release that deliberately needs no golden; this release needs one. Recording a waiver would have made the register say something untrue. Owed: bake golden 0.207.0 and vouch it.

---

7. Part 3 — the record

R-201's state field read PASSED + PROVEN-LIVE 2026-08-04 — the data half, from the drill — while the row body carried the fifth walk's journey pass. Corrected to BOTH HALVES PASSED — DATA 2026-08-04, JOURNEY 2026-08-07, with what it does not claim stated in the field itself: the journey is not smooth, and the discriminator's positive half is unproven.

The census asked for: a sweep of all 146 register rows found NO OTHER state field disagreeing with its own body. Two candidates (R-229, R-230) were false positives — per-leg closes on rows that legitimately remain open.

So the pattern is real but not currently widespread: R-218 on 2026-08-06, R-201 now, nothing else outstanding. The mechanism is worth naming, because it will recur: a row states status in two places — a bold phrase early in the What column and the State cell at the end — and a session that closes an item updates the body and the end cell, while the early phrase, which is what a reader sees first, goes stale.

---

8. Live validation — what was proven on a box, and what was not

#	Check	Result
1	curl the security page, passphrase absent	PASS, live, with before/after (§1)
2	the reveal works for a customer who asks	PASS, live — 200, no-store, correct value, logged
3	the two refusals rendered on VM 325	NOT PROVEN LIVE — stated plainly (below)
4	a healthy box's restore page unchanged	PASS, live — no notice, no not-installed hint

Check 3 is the honest gap. R-252's state is rebuild-only: the customer API refuses to deregister the last usable drive („ez az egyetlen használható tárhely — a leszerelés megtagadva"), and when storage_paths was emptied directly the controller re-registered one on restart, so HasRestoreDestination() was correctly true and the notice correctly did not render — which is Scenario E passing live, not a failure. R-253 likewise: after removing the app the controller still reports deployed=true (state stopped), so the row's Installed stays true.

Both notices are therefore pinned at the template + predicate level — by tests that drive the real template and the real predicate, each with a demonstrated red-proof — and not by a live render. I would rather say that than dress the template test up as a live one.

---

9. Files, commits, deployed version

felhom-controller — 8dbbc98 (v0.207.0): internal/web/handlers.go · internal/web/server.go · internal/web/templates/settings_security.html · internal/web/templates/backups_restore.html · internal/backup/offbox_restore.go · internal/backup/offbox_reconstitute.go · internal/web/offsite_restore_list_test.go · new: internal/web/retrieval_password_exposure_test.go, internal/web/restore_preconditions_test.go, internal/backup/restore_destination_test.go · CHANGELOG.md · CONTEXT.md · REUSE.md · controller/README.md

felhom.eu — 1fc3876 (pushed --no-verify, declared): documentation/backlog/OPEN-ITEMS.md (R-249/R-252/R-253 closed, R-254 filed, R-201's state field corrected, R-242 updated) · STATUS.md (93 lines).

Deployed: gitea.dooplex.hu/admin/felhom-controller:0.207.0 — healthy on demo-hp guest 9201 and on VM 325.

Register: highest ID moved R-253 → R-254.

---

10. What remains open

• R-254 — the two remaining render-then-hide instances. The recommended next item.
• R-242 — the bake + vouch of golden 0.207.0 this release now needs; and R-242's own half, that nothing gates the vouch.
• The discriminator's positive half — the fifth walk exercised R-241's mint guard positively and the fingerprint comparison only negatively. Proving the positive half needs a deliberate fixture (a box holding a divergent key), not a walk — and v0.206.0's guard now prevents that state arising by itself, which is exactly why it needs constructing.
• Untouched by design: R-250, R-251, R-243, R-244, R-240, R-213, R-202, R-214, R-247, R-248.

11. Observations — noticed, not acted on

• shares_restore.go:62,81 carries the same „nincs elérhető adatmeghajtó" string with no route, for the SMB-shares restore path. Out of scope (R-252 is the app path); the same one-line treatment would fix it.
• The reveal endpoint has no rate limit. It is behind session auth + CSRF, so it is not a brute-force surface, but the escrow start handler deliberately rides the login limiter and this does not. Deliberate omission, flagged.
• The Hetzner token in ~/.config/credentials cannot see storage box 611421 — GET /v1/storage_boxes/611421/subaccounts → 404 and GET /v1/storage_boxes → 200 with 0 entries. It is scoped to a different project than the hub's. Recorded so the next teardown does not re-derive it.