[bruce-y]

L1 credential rotation currently forces clients and servers to switch a single shared secret together. Allow BAZEL_REMOTE_L1_AUTH_SECRET to contain a comma-separated set of accepted keys so servers can accept new,old while runner agents move to the new key.

Parse, trim, and deduplicate accepted keys into a hash set when constructing the unary and streaming interceptors. Each request checks membership with a single map lookup. Requests still supply exactly one credential. A non-empty configuration with no usable keys rejects requests; the existing explicitly empty development configuration and exempt RPCs retain their behavior. Document the server-first rotation sequence and single-key client configuration.

Validation passed on Blacksmith Testbox: go test -race ./server . -count=1. Coverage includes both RPC interceptor types, overlap, retired keys, empty entries, malformed request lists, and duplicate metadata. Repository-wide gofmt and diff checks pass. BenchmarkAuthSecretLookup measures hits and misses for 1, 2, 16, and 128 configured keys.

Targets patchset, which contains the Blacksmith L1 authentication code and is the source of release tags. No credentials, releases, or deployments are changed.

On the same AMD EPYC Testbox, a successful lookup with two configured 64-byte keys measured a median of 7.44 ns/op versus 32.43 ns/op for the previous scan (three 200 ms samples per case). Both used 0 allocations/op. At 128 keys, the lookup measured 8.73 ns/op versus 1767 ns/op. These are lookup microbenchmarks, not end-to-end RPC latency.

[blacksmith-staging]

Overlap list accepts new and old keys

Before, both keys were rejected because the list was compared as one literal secret. After, both new-key and old-key pass on unary and streaming RPCs.

_Merge-base

_{This PR 929e14a7}

Also checked · 3 more claims, all matched observations

Retired key rejected after rotation
Empty-only list rejects everything
Clients must send exactly one key

_{Proof on 929e14a7}

View full Proof report