Commander1024/ESP32_Serial_Swiss_Army_Knife
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Document legacy credential cleanup sign-off

Browse Source 
Record certificate continuity, existing-user validation, and full-mix
target telemetry while preserving the documented evidence limits.
This commit is contained in:
Commander1024
2026-09-08 19:21:09 +02:00
parent ac80863d80
commit d9ac1319aa
3 changed files with 34 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/legacy_credential_removal.md
+29 -1
View File
@@ -2,10 +2,38 @@
## Scope and status — 2026-09-08
Agreed removal of the obsolete shared web credential, user bootstrap/migration/synchronization paths, and related public APIs/commands. User-generated passwords and HTTPS certificate rotation remain supported. Implementation and integration are complete, host-tested and build-verified; target validation remains pending. No device operation, factory erase, commit or asset generation was performed.
Agreed removal of the obsolete shared web credential, user bootstrap/migration/synchronization paths, and related public APIs/commands. User-generated passwords and HTTPS certificate rotation remain supported. Implementation and integration are complete, host-tested and build-verified; **the user signed off the legacy-credential cleanup on 2026-09-08**. No device operation, factory erase, commit or asset generation was performed.
Separately, the user reported and accepted that ordinary HTTPS idle cleanup worked. This is a scoped functional report, not an invented soak, individual checklist execution, memory reserve approval, broader 8D.11/M3 sign-off or target validation of this credential removal. Prior measurements remain in [the idle-cleanup record](https_idle_cleanup.md).
## Target sign-off — 2026-09-08
User confirms: “the cert fingerprint did not change and I could use the preexisting test users. So that is a sign off”. Accept the legacy-credential/bootstrap cleanup based on this identity/account continuity confirmation and the full-mix telemetry below. This supersedes earlier pending-signoff/fingerprint-unconfirmed statements, not historical test attribution or evidence limits. Ordinary HTTPS idle cleanup retains its prior scoped acceptance. No wider phase/M3 acceptance, individual unreported provisioning/recovery/fault-injection test, all-key coverage, soak duration or numeric reserve approval is inferred.
User suspects the two boot authentication failures came from the two browser tabs reconnecting with pre-flash stale sessions. This is consistent with two failures already at boot, no further failures under load and zero invalid credential attempts, but remains a user-attributed likely explanation rather than a traced request diagnosis.
This sign-off update changes documentation only: no source/config changes, build/test rerun, upload, erase, asset generation or commit.
## User-supplied post-cleanup target evidence — 2026-09-08 (before sign-off confirmation)
User supplies a fresh-boot sample at 60 seconds and a full-client-mix sample with substantial reported test traffic. This confirms operational password/public-key login and the supported connected mix in this run, not explicit cleanup sign-off, exact certificate preservation, every account/key, blank-device provisioning, recovery, or power-loss behavior. Exact flashed revision, browser, duration, diagnostic enable state and before/after certificate fingerprint were not supplied.
| Memory (bytes) | Boot free / minimum / largest | Full mix free / minimum / largest |
|---|---|---|
| Internal 8-bit | 66,488 / 61,268 / 31,744 | 31,820 / 15,740 / 20,480 |
| Internal DMA | 58,732 / 53,512 / 31,744 | 24,064 / 7,984 / 20,480 |
| PSRAM | 8,246,148 / 8,184,056 / 8,126,464 | 8,112,076 / 8,074,196 / 7,995,392 |
Per-region lifetime minima are conservative/non-simultaneous; internal/DMA capability sets overlap. Loaded minima exceed the pre-idle-cleanup diagnostic capture (1,984/384 internal/DMA), but workloads differ and this is not causal attribution or reserve approval. SSH owner stack is 20,480 bytes, minimum-free 18,476 boot / 16,284 loaded; HTTPD/dispatcher margins unreported.
Boot: SSH/HTTPS started once with no startup failures, mDNS announced/ESP_OK, UART stopped with 230400 8N1 RTS/CTS/DTR-active configuration, USB attached/host closed, no broker clients or SSH sessions. Five accounts/two admins. HTTPS already processed two unauthenticated requests (two auth failures), but login attempts/invalid credentials remain zero; this is not a completely request-free baseline. Source of the requests is unknown, not evidence of bad passwords.
Loaded: USB client16 is the sole writer, SSH client9 and web clients10/11 observers, with SSH and browser admin consoles active. Two SSH sessions authenticate by public key as user/admin; two cookie logins authenticate by password as those roles. No specific key algorithm or exact verifier/key identity is established. UART at 230400 8N1 RTS/CTS/DTR active, all sampled UART/broker pending/events zero; no broker drop-counter output was supplied. User reports much traffic, but output does not establish bidirectional exercise of every route: browser serial RX and browser admin RX are zero in the supplied counters.
SSH: TCP/handshake success/auth attempts 2/2/2, all handshake/auth/timeouts/capacity/request rejection/IO/session-revocation failures zero; broker connect1, writer request1/denial1, no grants/revocations; admin admission1/no failures or backpressure. Stream RX/accepted/rejected 34/34/0, TX 299,932 bytes. Browser admin ticket issued/consumed1/1, connected1/disconnected0, TX136/RX0, all rejection/capacity/protocol/send/queue/backpressure counters zero. Web requests65/authenticated63/auth failures2 (unchanged from boot), root2/status56/tickets2/assets2, response errors0. Serial tickets issued/consumed2/2, no expired/rejected; serial WS connect2/disconnect0, no connection/service/broker failures. TX1,077 binary frames/495,147 bytes, control9 frames/774 bytes, RX0. Writer requests2/denials2, grants/releases/revocations0, send/queue/protocol/close counters0. Cookie sessions2/4, login attempts2, invalid/throttled/capacity/CSRF/logouts0. These counters support clean established WebSocket operation in this capture, not a measured first-attempt admission latency or absence of all pre-HTTP TLS failures.
No code/config changes, build, device commands or explicit sign-off were performed/inferred from this evidence update. Remaining target checks include unchanged HTTPS fingerprint, existing-account/key coverage, blank-device first admin and unavailable-only recovery as appropriate, plus longer cleanup/traffic observations if desired.
## User database
- `user_database_init(load_result)` takes no legacy credential. Missing `user_db/database` storage is committed as an empty v1 database; no account/password is imported.