2 Commits

Author	SHA1	Message	Date
Joseph Doherty	cbfe296279	fix(secrets): close the pre-host hole in the store-path guard (0.6.1) ... Found by the HistorianGateway adoption of 0.6.0, which probed the rejected paths instead of observing a clean boot — a clean boot being equally consistent with the validator not being wired at all. An application that expands ${secret:} references before building its host composes this subsystem in a throwaway ServiceCollection with no IHostEnvironment in it, then migrates the store from that container. SecretsOptionsValidator resolves the content root from IHostEnvironment and skips the under-content-root rule when it is absent, so pre-host an absolute in-content-root path passed the only rule still applying, the migrator CREATED the database, and the boot failed a second later once the real host registered IHostEnvironment and the rule finally fired. The observable result was a rejected boot that still left an empty store, with -wal and -shm siblings, at the rejected path — the same artifact that made the MxGateway outage read as "the database is there, it's just empty", which is precisely what this guard exists to prevent. A relative path was unaffected because the absolute-path rule fires with or without a content root; that asymmetry is what exposed it. The mistake was conflating "no IHostEnvironment registered" with "no content root exists". New AddZbSecrets overload takes the content root explicitly; the 3-argument overload is unchanged and still falls back to IHostEnvironment, so this is additive. SecretsOptionsValidator gains a string? constructor alongside the IHostEnvironment? one. Reproduced first in an isolated harness before changing anything: a bare host rejects both bad paths leaving no artifacts, and a bare ServiceCollection with no IHostEnvironment migrates an in-content-root path to disk. Both are now regression tests, the second paired with a positive control asserting the old behaviour still holds when no content root is supplied — so the test is about the explicit content root rather than about paths in general. Also documents an upgrade note that applies to 0.6.0: a store seeded under the old relative default is orphaned rather than migrated, and nothing signals it.	2026-08-11 08:37:53 -04:00
Joseph Doherty	944595ad32	feat(secrets): fail-closed store-path validation; default moves outside the content root ... Secrets:SqlitePath is now validated at startup by SecretsOptionsValidator using two rules in the new public SecretsStorePathRules. Both come from production incidents and neither implies the other. Must be absolute: a relative value resolves against the process working directory, which for a Windows service is C:\Windows\System32, so the store lands outside the installation; in a dev loop it lands in the source tree (a gateway was observed writing its secrets database into src/, tripping that repo's own tree-hygiene test). Must not be inside the content root: an absolute path can still point into the directory every deployment procedure in this family renames on upgrade. On 2026-08-09 a gateway's credential store sat inside its Server\ directory; the deploy renamed Server to Server.bak.*, the database went with it, and the process created a fresh empty one at the same path. Every consumer lost its credential, silently, for two days. The existing "must be absolute" convention did not help — the path was absolute. The rules reject rather than relocate. Silently moving a credential store presents later as an authentication failure pointing nowhere near the configuration that caused it; a boot error is seen immediately by whoever caused it. Validation is deliberately not exempted in Development: a guard that never runs in a dev loop or in CI rots, and the configuration behind the outage looked entirely reasonable. BREAKING for configuration, not API. SecretsOptions.SqlitePath now defaults to an absolute per-user path under LocalApplicationData; it was "secrets.db", which the new rules reject. An application configuring a relative path will fail to boot — remove the key or set an absolute one outside the content root. All five deployed instances of this family were checked first and already set an absolute path outside their content root, so the migration edge (a host relying on the OLD default now finding nothing and creating an empty store — this bug, re-introduced by its own fix) does not apply to any of them. Per-user rather than machine-wide is deliberate: CommonApplicationData is /usr/share on Linux and macOS, which a normal user cannot write, so a machine-wide library default would fail every consuming application's boot on a developer machine. An application may compute its own default; the configured value always wins. Validator registration is idempotent. AddZbSecrets is legitimately called more than once in real compositions, and TryAddEnumerable cannot de-duplicate a factory-built descriptor — it de-duplicates on implementation type, which a factory does not carry, so it throws on the second call rather than skipping. The existing suite caught this. Tests cover both rules including the segment-boundary case (/srv/app-data must not read as inside /srv/app — a false positive on a fail-closed startup rule is an application that will not boot), that the shipped default satisfies the rules it ships with, that the default is not machine-wide, idempotent registration, and — most importantly — that a bad path actually throws when IOptions is resolved, since a correctly implemented validator that is never invoked is the same "guard that does not fire" failure this change exists to prevent. Family bumps to 0.6.0. Adds a dependency on ZB.MOM.WW.Configuration 0.1.0 for the shared OptionsValidatorBase/ValidationBuilder vocabulary, which every consumer already references.	2026-08-11 08:18:37 -04:00