felhom.eu/documentation/audits/r1299-window-button-2026-10-27

R-1299 — the one-time clean-up window gets a button (hub 0.174.0 → 0.174.1), and sec rm (cc-secrets 0.3.0), 2026-10-27 evening

The button

• Where: customer page → „Backup & DR" tab → card „Off-site clean-up window" (0.174.0 had it in the Overview's Backup card; the operator looked under Backup & DR first, so 0.174.1 moved it). Shown only when the box reports off-site enabled.
• Shows: the weekly switch, the normal cap (half the snapshots, at least 5), a waiting one-time grant and its limit, the last window (id, time, result, count, cap).
• Form: optional limit → confirm step (a GET; names the customer and the limit; stores nothing) → POST to the SAME route as the script address, /offsite/window-grant/<customer>, rule unchanged (wr(grpOffsite)), the page's CSRF. A waiting grant shows „Cancel the waiting window".
• Bound: a raised limit above the store's measured snapshot count is refused (a window cannot remove more than exist); the 500 ceiling stays. D55's 260-for-373 stays possible.
• Record: every grant and cancel writes an operator-only info event offsite_window_grant (who, customer, limit) and a log line.

Live check (operator's clicks; nothing removed)

1. 0.174.0, 20:07 CET: the operator granted ONE window on tester-1 with the normal cap through the confirm step (screenshots in the session). Hub DB (with WAL): offsite_window_grant:tester-1 = 1; log „ONE clean-up window granted for tester-1 with the normal cap, by operator session". No event row — the defect below.
2. 0.174.1, 20:42 CET: the operator pressed „Cancel the waiting window" under Backup & DR. Hub DB: the grant is empty; ONE stored row offsite_window_grant info „the waiting one-time window was cancelled (by operator session)", {"by":"operator session","cancelled":true}, source hub; the log line matches.

Defect found by step 1 and fixed in 0.174.1: the event went only to the dispatcher, which writes no row (it routes mail; info routes nowhere). The test had asserted the dispatcher CALL; it now reads the STORED rows — red with 0.174.0's shape (redproof-0174.1.txt).

Deploys

0.174.0: sha256:4f9ee04a… from d85198b8 (CI 2433), live 19:25 CET. 0.174.1: sha256:bb43f88a… from de57c090 (CI 2437), live 20:26 CET. Both built from a clean clone (the shared clone held another session's uncommitted installer edit), hub-only ArgoCD sync, Synced/Healthy, 0 restarts. Start-up 36 s / 31 s against a liveness kill at ~65 s → R-1326.

sec rm and the tidy-up

cc-secrets 0.3.0 (dc82cf9): one name per call, unknown refused, rm NAME commit + push, undo by git revert. 7 tests, 2 red-proofs (28/28 in all). The operator approved removing 46 dead names; sec-rm.txt holds the run (names only): 92 → 46 names, every removal committed and pushed, sec doctor all OK after.