mirror of
https://github.com/luxfi/kms.git
synced 2026-10-30 16:23:36 +00:00
zeekayandHanzo Dev
bf57162556
A list is a subtree query — it spans sub-paths, and with no env filter it spans environments. The wire answered with bare NAMES, and a bare name is not an address in a store keyed by (path, env, name): the only thing a caller can do with one is re-join it at the path it happened to query. For any record one segment deeper, or in another environment, that names a key which does not exist. So the list named a secret and the matching get missed it — and LoadEnv, whose whole job is "fetch everything here and set it", exits the process on the first such record. The list now answers with COORDINATES on both framings, and the coordinate type moves to its own leaf package: the client needed to name a record and could not import the server's storage package to do it without dragging the database into every binary that reads one secret. One coordinate, one place, imported by store, zapserver, zapclient and the HTTP face alike. GetSecretsWith reads each record at its own coordinate. It still keys the result by name, because os.Setenv does — an environment is a flat namespace — so two records under the subtree that share a name now ERROR naming both coordinates instead of one silently winning. A process that boots with the wrong DATABASE_URL and never learns is the failure being avoided. Find also bounds itself (10000 rows) and SAYS when it did. An enumeration is authenticated, but one request that pulls the whole keyspace into memory and onto the wire is still an amplification lever — and a cap that did not report itself would reintroduce the very defect this surface was hardened against: a short list that reads as the whole truth. Whitespace in an env or name is refused on write for the same reason: a list query trims its filter, so a stored "prod " could never be selected by ?env=prod and would answer empty, which reads as an empty store. Co-authored-by: Hanzo Dev <[email protected]>