diff --git a/documentation/audits/evidence-backup-promise-2026-09-16/phaseE-freshbox.txt b/documentation/audits/evidence-backup-promise-2026-09-16/phaseE-freshbox.txt index 94e317a3..3a789723 100644 --- a/documentation/audits/evidence-backup-promise-2026-09-16/phaseE-freshbox.txt +++ b/documentation/audits/evidence-backup-promise-2026-09-16/phaseE-freshbox.txt @@ -141,3 +141,66 @@ scsihw: virtio-scsi-single ## really running, not a form that silently refused. Captured deliberately early: ## „it started" is a fact worth holding before an eight-minute wait, because a ## stalled form and a running install look identical from outside. +## 2026-09-16T15:57:05Z the documented recovery: cold stop, detach CD, boot from disk +update VM 335: -delete ide2 +update VM 335: -boot order=scsi0 +boot: order=scsi0 +status: running +## e1-22-after-install.png THE TRAP REPRODUCED, exactly as the 2026-09-16 drill measured it: +## the install completed, the box rebooted itself (the „Automatically reboot" +## box was left ticked, as a volunteer would), and it came back INTO THE +## INSTALLER — the graphical entry this time, showing the EULA. Cause: a guest +## reboot reuses the RUNNING QEMU process's boot order (`ide2;scsi0`), so the +## disk-first change an installer makes does not apply to that reboot. +## A volunteer with the stick still in the machine sees this too. +## IT ALSO MEANS: a completed install and a stuck one look identical on screen. +## Completion was judged from the machine's behaviour (it rebooted by itself), +## never from the picture. +## e1-23-first-boot.png FIRST BOOT OF THE INSTALLED SYSTEM — the volunteer's first screen, and it is +## Felhom's, in Hungarian, with no admin URL anywhere: +## „Felhom otthoni szerver" +## „Ezen a gépen most nincs dolgod, és bejelentkezni sem kell." +## „A beállításhoz kövesd a Felhomtól kapott útmutatót." +## `tester1 login:` +## „Felhom — a doboz készen áll, és a párosításra vár." +## „Párosító kód: ZB3-7HM" +## „Nyisd meg az e-mailben kapott linket, és add meg ezt a kódot és a +## Tulajdonosi jelmondatodat (az 5 szót a Felhom üzemeltetőjétől kaptad)." +## „Ez a képernyő magától frissül — nincs teendő a doboznál…" +## `8006` appears 0 times. The login prompt carries the box's own hostname. +## The pairing code is non-secret by design: binding also needs the owner +## passphrase, which is not on this screen and not in this file. +## THE HUB SIDE, same minute: the box registered ITSELF from the universal secret-free image. +## /hosts → „(generic ISO, awaiting a bind) A box that installed from the universal secret-free ISO +## and registered itself." +## Appliance 1969bbb5-8502-41e2-9df0-b540bb6a85da +## Pairing code ZB3-7HM <- the same code the box's own screen shows +## MAC bc:24:11:45:0c:96 <- the same NIC the installer named (nic0) +## Hardware Standard PC (i440FX + PIIX) · AMD Ryzen Embedded V1756B · 7.8 GB +## NOTHING was pressed on the operator side to make this happen. +## AND THE CUSTOMER ALREADY HAS THE MAIL: „Kösd össze a Felhom dobozodat" arrived at 12:23:00Z today +## (the automatic one that followed this morning's host delete), valid 7 days, naming exactly the +## two things to enter — the pairing code from the screen and the five-word owner passphrase, which +## it says is never sent by e-mail. So this walk needs NO operator press for the bind: O1 of the +## previous drill is gone. The link itself is a capability URL and appears in no committed file. +## 2026-09-16T16:00:11Z BIND — the volunteer path: the customer opens the link from their own e-mail + bind page: http=200, 3202 bytes + form fields (values not shown): ['pairing_code', 'passphrase'] + bind POST -> http=200 + page says: Felhom — Doboz összekötése Felhom doboz összekötése Sikeres összekötés. A doboz kb. egy percen belül folytatja a telepítést. Ezt az oldalt bezárhatod — a beállítás a háttérben befejeződik, és a vezérlőpultod hamarosan elérhető lesz. Felhom.eu +## SECRET HANDLING, corrected from this project's one real slip (2026-09-16 morning): +## the owner passphrase was extracted from the hub page's `data-secret` ATTRIBUTE straight into a +## 0600 file and never printed — the earlier leak happened because the masking covered element TEXT +## only, and the attribute went to the transcript. The page carries exactly one such attribute +## („Credentials Retrieval Password"), length 35; only the length is recorded here. +## 2026-09-16T16:00:11Z BIND — SUCCEEDED, and this time with ZERO operator presses. +## The bind page asked for exactly the two things the e-mail named: `pairing_code` and `passphrase` +## (field names read from the form, not guessed — guessing them cost an extra attempt on the claim +## page in the previous drill). +## The page answered: „Sikeres összekötés. A doboz kb. egy percen belül folytatja a telepítést. +## Ezt az oldalt bezárhatod — a beállítás a háttérben befejeződik, és a vezérlőpultod hamarosan +## elérhető lesz." +## THE DIFFERENCE FROM THE 2026-09-16 MORNING DRILL: that walk needed O1, an operator pressing +## „Send self-bind link", because no automatic mail existed for a customer who was already waiting. +## This walk used the mail the hub sent ITSELF after the host delete (R-509, proven at 12:23:00Z), +## so the pre-declared operator press is gone. diff --git a/documentation/audits/evidence-backup-promise-2026-09-16/screens/e1-22-after-install.png b/documentation/audits/evidence-backup-promise-2026-09-16/screens/e1-22-after-install.png new file mode 100644 index 00000000..9b0387f3 Binary files /dev/null and b/documentation/audits/evidence-backup-promise-2026-09-16/screens/e1-22-after-install.png differ diff --git a/documentation/audits/evidence-backup-promise-2026-09-16/screens/e1-23-first-boot.png b/documentation/audits/evidence-backup-promise-2026-09-16/screens/e1-23-first-boot.png new file mode 100644 index 00000000..172acd9c Binary files /dev/null and b/documentation/audits/evidence-backup-promise-2026-09-16/screens/e1-23-first-boot.png differ