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>
GitHub answers a workflow dispatch on this repo with 422 "Actions has been
disabled for this user", so pushes to main produced no build at all — the last
run is still the commit before the console removal, and the deployed image
drifted behind main without anything reporting a failure.
hanzo.yml hands the build to platform.hanzo.ai, which schedules it onto the
self-hosted arcd pools over the native fabric and pushes to GHCR. Same path
luxfi/node uses. .github/workflows/build-lux-kms.yml is retired rather than
left as a second, broken way to produce the same image.
No deploy block: the kms Deployment is kustomize-managed with no operator CR,
so there is nothing for a Service-CR rollout to target.
VERSION 1.12.6 -> 1.12.8. The file had fallen behind the deployed tag v1.12.7,
so a tag build would have gone backwards.
Co-authored-by: Hanzo Dev <dev@hanzo.ai>
Dockerfile.server used plain 'go build' (vendor mode) + a single pre-COPY
'go mod download'. Two breakages: (1) the committed vendor/ lags go.mod
(luxfi/vm v1.2.3 in modules.txt vs v1.3.1 in go.mod) -> 'inconsistent
vendoring'; (2) COPY . . re-clobbers any regenerated go.sum with the stale
committed one, so a force-republished luxfi tag aborts the build on a
checksum mismatch.
Mirror the proven-green main Dockerfile: GOSUMDB=off + rm -f go.sum &&
go mod download before AND after COPY . ., and GOFLAGS=-mod=mod on build
so it resolves from the module cache instead of the inconsistent vendor
tree. Regenerate-not-bypass: integrity still enforced against go.sum.
Co-authored-by: Hanzo Dev <dev@hanzo.ai>
The route was registered on the bare mux with NO auth middleware and did
os.Getenv(name), returning the raw value. A caller reaching :8080 past the
network boundary (NetworkPolicy gap, port-forward, pod compromise, SSRF) could
`curl .../v1/kms/secrets/KMS_MASTER_KEY_B64` with no Authorization header and
exfiltrate the root REK protecting every per-secret DEK — plus MPC_TOKEN,
KMS_ENCRYPTION_KEY_B64, and (k8s/ variant) the S3 backup keys. On the live
lux-kms-go/kms statefulset KMS_MASTER_KEY_B64 is populated, so this was live
master-key exposure gated only by the network → CRITICAL.
Deleted, not gated: zero callers (kms-operator + kms client read via the
org-scoped path/ZAP; process env is never a secret source). The three
org-scoped secret routes are extracted into registerSecretRoutes so the exact
exposed route set is testable in isolation. Secrets now flow ONLY through
/v1/kms/orgs/{org}/secrets/* (requireOrgJWT) and the ZAP wire.
Regression TestSecretRoutes_NoEnvVarLeak: unauth -> 404, admin -> 404, the
process-env canary is never in the body. Corrected the stale kms.go doc
comment that referenced the route. Full cmd/kms suite green (CGO_ENABLED=0).
Co-authored-by: Hanzo Dev <dev@hanzo.ai>
Squashes all pre-rewrite history into a single root commit. Previous tree:
- 14506 commits including upstream Infisical fork history
- Multiple merge chains carrying pre-purge content
Force-rewrite per disk-space reclamation discipline. GHCR images
(1.9.9, 1.9.11) remain immutable; their git lineage is no longer
materialized.
