Files
kms/VERSION
T
zeekayandHanzo Dev c199becfe4 kms: HTTP secret list — surface parity with the ZAP wire
The ZAP wire has carried OpSecretList (0x0042, {path, env} -> {names}) since it
was written. HTTP had get/put/delete and no list, so the two framings of the
same store disagreed about what you could ask it: a client that wanted to
enumerate had to open a ZAP connection or give up. The hanzo browser extension
gave up and pinned itself to Infisical /api/v3 paths instead.

  GET /v1/kms/orgs/{org}/secrets?path=&env=  ->  {"names": [...]}

Same handler shape and same envelope the ZAP op returns — one store, two
framings, now the same question set.

The pattern has no trailing segment, so ServeMux routes the bare collection here
and anything below it to the existing {rest...} handler. That split is the whole
risk in this change: invert it and list swallows every get, or get 400s on the
bare collection for want of a slash to split. TestSecretRoutes_ListAndGetDoNotShadow
asserts both directions, plus that an empty result is [] and never null.

Co-authored-by: Hanzo Dev <dev@hanzo.ai>
2026-07-26 01:04:30 -07:00

2 lines
7 B
Plaintext