Post-release deep review of the merged HOMECORE platform PR (#1451)
turned up several real issues, fixed here:
- homecore-hap: StoredAccessory's permanent Ed25519 signing seed and
StoredSetup's SRP salt/verifier were reachable via derived Debug.
Not actively triggered by any current code path, but a future
logging/panic-message change (an ordinary thing to add) would have
printed the accessory's compromise-forever identity key in
plaintext -- there's no rotation mechanism. Added manual, redacted
Debug impls matching the existing SetupCode pattern; StoreState/
PairingStore's derived Debug inherits the redaction automatically.
New test pins the exact rendered output.
- homecore-api: /api/history/period and /api/logbook rejected the
default (no filter_entity_id/entity) call shape once a room had
more than 32 known entities -- exactly how the real HA frontend
calls these endpoints. The MAX_HISTORY_ENTITIES cap now only
applies to an explicit, unusually-large filter list; the existing
MAX_API_HISTORY_ROWS total-row budget already bounds the actual
work regardless of entity count. Two new tests: unfiltered succeeds
with 40 known entities, explicit oversized filter is still rejected.
- homecore-api: fire_event (both REST and WS) restricted event_type
to [a-z0-9_]+, but real HA integrations commonly fire mixed-case,
dotted, or hyphenated types (mobile_app.notification_action,
ios.action_fired). Factored the check into a single
is_valid_event_type() shared by both transports, relaxed to what
actually matters for server safety: non-empty, length-bounded, no
control characters.
- homecore-migrate: write_config_entries/write_device_registry/
write_entity_registry's atomic no-clobber write had no escape
hatch -- an operator who fixed a bad source row (or wanted a fresh
re-import) had to manually delete prior output first. Added a
--force CLI flag (default off, preserving the existing no-clobber
default and its explicit malformed_entry_is_an_error_not_a_partial_write
test) that atomically replaces an existing destination. First
attempt used bare fs::rename, which hit real ERROR_ACCESS_DENIED
sharing-violation flakiness on Windows; switched to pre-clearing
the destination then publishing through the same hard_link step
the default path already uses reliably.
All touched crates re-verified: homecore-hap 46 tests (was 45),
homecore-api 20+6+6+7=39 tests (was 18+6+6+7=37), homecore-migrate 25
tests (was 24), all 0 failed, clippy clean under -D warnings.
Also corrected the public v2051 GitHub release notes: "Wasmtime
36.0.12 component loading" was inaccurate (the crate uses the
core-module API with a hand-rolled host ABI, not the Component
Model/WIT) -- doc-only, not a code change.
Co-Authored-By: claude-flow <ruv@ruv.net>
ruv