felhom-controller/REPORT.md

REPORT — the last two secrets leave the page source, and a gate against a fourth (v0.208.0, 2026-08-08)

R-254 both sites — implementation, tests, deploy. R-255 filed. Controller v0.207.0 → v0.208.0, built, pushed, deployed to demo-hp guest 9201. No hub change. Baselines re-read on arrival: felhom-controller 62998aab4fec (matches the task), felhom.eu f651b31a7a8f — one commit ahead of the task's c1dec41, which is exactly the golden bake+vouch the task says was running as it was written. Highest register ID on arrival: R-254.

§1's question answered: the bake COMPLETED. Vouched on arrival — golden_version 0.207.0, agent_version 0.127.0, min_agent 0.127.0. So v0.208.0 puts the currency gate red again (§7.5).

---

1. Scenario A — and the honest limit on the live half

Unit level, on the real template and the real handler — this is the strong evidence:

	before (v0.207.0 shape)	after (v0.208.0)
{{.InitialCreds.Password}} in app_info.html	present, inside a hidden span	absent
the password in the rendered body	present	absent
the card, username, note	present	present (feature intact)
reveal control	reads the hidden span	calls POST /apps/<slug>/initial-credentials/reveal

Red-proof (the most important one): the value was put back into both the page data and the markup — each mutation asserted to have applied — and the test failed exactly as designed:

MUTATION A APPLIED (template + handler)
--- FAIL: TestAppInfoPage_DoesNotContainTheInitialPassword
    R-254: the app's first-login password is in the response body of its info page …

⚠ THE LIVE READ COULD NOT BE COMPLETED, AND HERE IS EXACTLY WHAT WAS TRIED

§10.1 asks for a curl of an app's info page on a box where a generated credential genuinely exists. Two independent things blocked it, both measured:

1. No such app is deployed anywhere on the fleet. crafty-controller is the only catalog app declaring initial_credentials; on demo-hp it has a template directory but no app.yaml and no containers. demo-felhom reported zero stacks.
2. The dashboard on demo-hp's guest would not authenticate. PASSWORD from ~/.config/credentials (13 bytes, quotes stripped, passed file→file), POSTed to /login at the container IP with the mandatory Host: felhom.enkisfelhom.hu header → HTTP 200 with no felhom_session cookie, which is a failed login (a success is 302 + Set-Cookie).

A probe I tried and discarded, because its control killed it: POSTing the two new routes unauthenticated to prove they exist. Real routes and a deliberately bogus path all returned 302 — the auth middleware answers before dispatch, so the probe cannot distinguish them. Reported as worthless rather than as evidence.

What IS confirmed live: gitea.dooplex.hu/admin/felhom-controller:0.208.0 deployed and healthy on demo-hp guest 9201.

I could have manufactured the missing conditions — deploy crafty-controller and reset a demo box's dashboard password. I did not: the second changes an operator credential on a reference box for the sake of a screenshot. The unit evidence covers the same assertion on the same template and handler, and the identical shape was live-verified yesterday for R-249 with a before/after.

---

2. §7.2 — what reaches the deploy form's hidden inputs

Question	Answer
Which env values reach it?	Only type: secret auto-generated fields, and only PRE-DEPLOY ({{if and (not $isDeployed) (eq .Type "secret")}})
Are any of them secrets?	Yes — generated from the catalog's generate: spec
Must the form carry them?	Yes, and this is documented. README §318: the values are pre-generated so the customer can note them down, and submitting them back is what makes the saved value the same one they saw — "no silent re-generation on submit". A form must carry what it submits.
Does it contradict the repo's auto-fill rule?	No — and the rule as quoted does not exist. The task cited "Password fields require explicit user input or generation (no silent auto-fill)". No such line is anywhere in the repo. What exists is CONTEXT.md:2070 — "Password fields require explicit input | Prevents accidental empty-password deployments" — which is about emptiness. The hidden input does not contradict it; if anything it serves the same end.

So the hidden input was left alone. What §7.2 uncovered instead is the neighbouring readonly display input: on an already-deployed app the hidden input is correctly omitted — nothing is being submitted — yet <input type="password" value="{{$val}}" readonly> still rendered the secret into a page the customer merely opens. That is R-249's shape with no form to justify it, and it is what v0.208.0 fixes (POST /stacks/<name>/auto-field/reveal, authorised on the field being a type: secret auto-field of that stack).

Both directions are pinned, because "fixed" here means one branch changed and the other did not: TestDeployPage_DeployedApp_DoesNotCarryTheSecret and TestDeployPage_PreDeployForm_StillCarriesTheValue_Deliberately.

---

3. §7.4 — the guard: what it cost, what it covers, what it does not

Built: controller/scripts/secret_in_markup_gate.py, registered in controller_gates.py (now ten gates). ~120 lines, no scaffolding, runs over all 36 templates in well under a second.

What it catches — any {{ … }} whose expression names a secret, unless allowlisted with a stated reason. Verified by planting one: the gate convicted app_info.html:188. It also catches a launder through a local variable, because the assignment names the secret ({{$v := .InitialCreds.Password}} convicted).

What it does NOT catch, measured rather than estimated: a secret arriving under a neutral page-data key. Planted data["Tagline"] = <secret> rendered as {{.AppInfo.Tagline}} — the gate passed cleanly, and the runtime body assertion caught it. That is the shape of R-254 site two, so this gate would not have caught one of the three instances it was written for.

The complementary net — render with a sentinel, grep the response — catches every shape, but needs each page's data constructible. 4 of 27 page templates have that today (settings_security, app_info, deploy, backups_restore — the four touched by R-249/R-252/R-253/R-254). The other 23 have no runtime coverage.

I did not build the remaining 23 and did not describe the guard as complete — §7.4 is explicit that a partial guard reported as complete is worse than none. Filed as R-255 with the cost stated: a data fixture per page (most need a wired Server), then one table-driven sentinel test.

---

4. §7.3 — what has actually been exposed, and whether to rotate

Site one: the code path has never run in production. The card renders only when found.Deployed && found.Meta.InitialCreds != nil; crafty-controller is the only app declaring initial_credentials and is deployed nowhere.

Site two: also empty, as measured. 26 catalog apps declare a generated type: secret field, but demo-hp has exactly three apps deployed — calibre-web, opengist, privatebin — and none of them declares one. Intersection: zero.

THE LIMIT, stated because it changes what this is worth. That is a current-state measurement. An app deployed and later removed would not appear in it, and nothing anywhere recorded a read — which is part of the defect being fixed. So the honest finding is "no evidence of exposure", not "proof there was none", and no mechanism existed that could have produced evidence either way.

Recommendation: rotation is not indicated by anything measured. The decision is the operator's; this note is the input to it.

---

5. Every changed Hungarian string

Added (app_info.html, reveal failure): the message comes from the server —

„A kezdeti jelszó most nem olvasható ki — az alkalmazásnak futnia kell hozzá, és lehet, hogy a fájlt az első bejelentkezés után már törölték."

Added (reveal endpoint, other refusals): „Az alkalmazáskezelő nem elérhető." · „Ismeretlen alkalmazás." · „A kezdeti jelszó beolvasása nem sikerült."

Added (deploy.html / auto-field reveal): „Ez a mező nem kérhető le." · „Az alkalmazás beállításai nem olvashatók." · „Ehhez a mezőhöz nincs mentett érték." · „Hiányzó mező." · „A lekérés nem sikerült."

Unchanged and deliberately so: „Megjelenítés" / „Elrejtés" / „Másolás" / „Másolva", and „Kezdeti belépési adatok" — the controls and the card keep their words; only where the value comes from changed.

---

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

Test	Scenario	Result	Red-proof
TestAppInfoPage_DoesNotContainTheInitialPassword	A	PASS	value restored to page data + markup → FAIL
TestAppInfoPage_NoCredentialsCard_WhenAppHasNone	E	PASS	card made unconditional → FAIL
TestAppInitialCredsReveal_ReturnsThePasswordAndRecordsTheAct	B + C	PASS	logging line removed → FAIL ("the reveal was not recorded")
TestAppInitialCredsReveal_SaysWhyWhenUnreadable	§7.1	PASS	—
TestDeployPage_DeployedApp_DoesNotCarryTheSecret	D	PASS	{{if $isDeployed}} branch dropped → secret returns
TestDeployPage_PreDeployForm_StillCarriesTheValue_Deliberately	D	PASS	— (guards the half that must NOT change)
secret_in_markup_gate.py	F	PASS	secret planted in markup → gate convicted it

Two things the red-proofs caught in my own work, which is the point of running them:

1. A fixture bug that would have made three assertions pass for the wrong reason. The credentials card lives inside {{if .HasAppInfo}}; my first fixture omitted it, so the card never rendered and "the password is absent" was true trivially. Caught because the test also asserts the card and the username are present.
2. An assertion that matched the page script instead of the control. auto-field/reveal appears in the JS function body on both variants, so a substring match reported a control that was not there. Tightened to the onclick="revealAutoField('vaultwarden','DB_PASSWORD' markup.

A correction to v0.207.0's report

It stated that HTML comments ship in the response body. They do not, here. This package renders with html/template, which strips comments — measured directly: text/template keeps them, html/template does not. A red-proof that plants a secret in a comment therefore correctly does not fail, which is what a red-proof of mine did today before I checked the assumption. Corrected in the test's own comment, the CHANGELOG and CONTEXT.md.

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

---

7. §7.5 — the currency gate

Red, as designed: released controller 0.208.0, newest vouched/baked golden 0.207.0. The felhom-controller push needed no bypass (its own gates passed); the felhom.eu push used git push --no-verify, declared in that commit, in CHANGELOG.md, here, and in R-242's row.

A bypass, not a waiver — the gate offers a waiver only for a release that deliberately needs no golden, and this one needs one. Owed: bake golden 0.208.0 and vouch it. Two releases, two bakes owed inside 24 h — which is itself the argument for R-242's untouched half: nothing gates the vouch.

---

8. Files, commits, deployed version

felhom-controller — 27d1165 (v0.208.0): internal/web/handlers.go · internal/web/server.go · internal/web/templates/app_info.html · internal/web/templates/deploy.html · new: internal/web/app_initcreds_exposure_test.go, internal/web/deploy_secret_exposure_test.go, scripts/secret_in_markup_gate.py · scripts/controller_gates.py · CHANGELOG.md · CONTEXT.md · REUSE.md · controller/README.md.

felhom.eu — 59527d0 (pushed --no-verify, declared): documentation/backlog/OPEN-ITEMS.md (R-254 closed per site, R-255 filed, R-242 updated) · STATUS.md (94 lines).

Deployed: gitea.dooplex.hu/admin/felhom-controller:0.208.0 — healthy on demo-hp guest 9201.

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

§N.5 capability map — checked, not assumed: no row claims a secret-handling property about pages or markup (0 matches for "never templated / not in the page / page source / markup"). No change made.

Teardown: nothing was provisioned this session — nothing to tear down.

---

9. What remains open

• R-255 — runtime sentinel coverage for the other 23 page templates.
• R-242 — bake + vouch golden 0.208.0; and its untouched half, that nothing gates the vouch.
• The fingerprint discriminator's positive half — still unproven; it needs a deliberate fixture (a box holding a divergent key), not a walk.
• Untouched by design: R-250, R-251, R-243, R-244, R-240, R-247, R-248, R-213, R-202, R-214.

10. Observations — noticed, NOT acted on

• demo-felhom's guest reported zero deployed stacks, and one ssh to it failed (exit 255) while probing. Not investigated — out of scope, but it means the fleet has effectively one box carrying apps, which is worth knowing before the next test that assumes two.
• demo-hp's dashboard password in ~/.config/credentials no longer authenticates (§1 above). Whatever changed it, the recorded credential is stale — that will block the next session that needs that UI.
• The reveal endpoints have no rate limit. Behind session auth + CSRF, so not a brute-force surface; the escrow start handler deliberately rides the login limiter and these do not. Flagged, as it was for v0.207.0's endpoint.
• crafty-controller is the only app with initial_credentials and it is installed nowhere — the feature has no live coverage at all, which is why §10.1's live check had nothing to read.