chore: adopt byteness/keyring v1.11.0 opt-out tags as standard build configuration

.github/workflows/ci.yml

@@ -39,6 +39,14 @@ jobs:
         run: go build -v ./...
       - name: Test
         run: go test -v -race -coverprofile=coverage.out ./...
+      # Standard consumer build configuration (working-with-secrets.md
+      # §1.10): credstore must stay green with the keyring opt-out tags
+      # the CLIs ship with. keyring_nofile / keyring_nopass are NOT in
+      # the set — credstore exposes those backends in cgo builds.
+      - name: Build and test with keyring opt-out tags
+        run: |
+          go build -tags keyring_no1password,keyring_nopassage ./...
+          go test -race -tags keyring_no1password,keyring_nopassage ./...
 
   lint:
     runs-on: ubuntu-latest

docs/development.md

@@ -44,9 +44,10 @@ purely additive or rides the coordinated consumer release train in
 [`working-with-state.md`](working-with-state.md) §6 — no tag until every
 ported consumer is green against the candidate SHA.
 
-## Known dependency cost
+## Keyring opt-out tags
 
-`byteness/keyring` compiles its 1Password openers (and transitively wazero /
-jaeger) into every consumer — documented in
-[`working-with-secrets.md`](working-with-secrets.md) §1.10; remediation
-tracked in cli-common#57.
+`byteness/keyring` (≥ v1.11.0) supports per-backend opt-out build tags;
+consumer CLIs build with `-tags keyring_no1password,keyring_nopassage` as
+standard configuration, and CI here tests credstore under the same set —
+see [`working-with-secrets.md`](working-with-secrets.md) §1.10 for the
+contract and why `keyring_nofile` / `keyring_nopass` are excluded.

docs/working-with-secrets.md

@@ -318,7 +318,13 @@ In automation, prefer `set-credential` per-secret over `init` for everything: it
 
 A note on what credstore exposes: as of #24, `credstore` recognizes six backend names — `keychain`, `wincred`, `secret-service`, `file`, `pass`, `memory`. `pass` is the only external secret manager exposed natively; it shells out to the `pass` CLI binary and has no Go SDK dependencies. KeePassXC users get native runtime resolution today through Secret Service (no separate backend needed). 1Password native backends are deliberately not exposed: ByteNess's `op` / `op-connect` / `op-desktop` openers all depend on the upstream `github.com/1password/onepassword-sdk-go` package, which is still pre-1.0 — exposing them here would put a beta SDK on the credential-access critical path. The "default path" above remains the recommendation for most users; `pass` is an opt-in alternative for users who specifically want runtime resolution and accept the per-backend availability/version coupling.
 
-**Known dependency cost (documented trade-off).** Not exposing the 1Password backends does not remove their code: `byteness/keyring` imports its op openers unconditionally, so the 1Password SDKs — and transitively a WASM runtime (`wazero` via `extism`) and the archived `jaeger-client-go` — compile into every credstore consumer. Measured 2026-06-11 against keyring v1.9.3 on a real consumer binary (`slck`): 63 packages in the import graph, ~10.6 MB of attributable symbols, no dead-code elimination (the openers are `init()`-registered). The accepted interim posture is this documented cost; the remediation — an upstream opt-out build tag in ByteNess/keyring — is committed in cli-common#57, and when it lands the consumer build flag becomes part of this standard's build configuration.
+**Standard build configuration: keyring opt-out tags.** Not exposing the 1Password backends does not by itself remove their code: `byteness/keyring` `init()`-registers its openers, so without intervention the 1Password SDKs — and transitively a WASM runtime (`wazero` via `extism`) and the archived `jaeger-client-go` — compile into every credstore consumer (measured 2026-06-11 against keyring v1.9.3 on `slck`: 63 packages, ~10.6 MB of attributable symbols). The remediation landed upstream in keyring v1.11.0 (ByteNess/keyring#93/#94, driven from cli-common#57): per-backend opt-out build tags. Every consumer CLI MUST build (Makefile, CI, and `.goreleaser` `flags:`) with:
+
+```
+-tags keyring_no1password,keyring_nopassage
+```
+
+These two are exactly the backends credstore does not expose. `keyring_nofile` and `keyring_nopass` MUST NOT be used: credstore's cgo builds delegate the `file` and `pass` backends to `byteness/keyring`, so those tags would break exposed functionality. cli-common's own CI builds and tests credstore under the standard tag set to keep the configuration green from the library side.
 
 ## §1.11 Compliance criteria
 

go.mod

@@ -4,7 +4,7 @@ go 1.26
 
 require (
 	github.com/byteness/go-libsecret v0.0.0-20260108215642-107379d3dee0
-	github.com/byteness/keyring v1.9.3
+	github.com/byteness/keyring v1.11.0
 	github.com/byteness/percent v0.2.2
 	github.com/dvsekhvalnov/jose2go v1.8.0
 	github.com/godbus/dbus/v5 v5.2.2
@@ -28,8 +28,7 @@ require (
 	github.com/uber/jaeger-lib v2.4.1+incompatible // indirect
 	go.opentelemetry.io/proto/otlp v1.9.0 // indirect
 	go.uber.org/atomic v1.11.0 // indirect
-	golang.org/x/crypto v0.51.0 // indirect
-	golang.org/x/sys v0.44.0 // indirect
-	golang.org/x/term v0.43.0 // indirect
+	golang.org/x/sys v0.46.0 // indirect
+	golang.org/x/term v0.44.0 // indirect
 	google.golang.org/protobuf v1.36.11 // indirect
 )

go.sum

@@ -8,8 +8,8 @@ github.com/byteness/go-keychain v0.0.0-20191008050251-8e49817e8af4 h1:HFl8GFmwK1
 github.com/byteness/go-keychain v0.0.0-20191008050251-8e49817e8af4/go.mod h1:9HlL8SWBRtCZE7sCNq+c3//H/oHywgSwtocmPTdOij8=
 github.com/byteness/go-libsecret v0.0.0-20260108215642-107379d3dee0 h1:j59wGsxaBk6aFBuuYofk2oznMGZYyzFovjDqavlJHM8=
 github.com/byteness/go-libsecret v0.0.0-20260108215642-107379d3dee0/go.mod h1:3FrDGTXj08zj6qtqlIvt0vS8eWNrrYpnXOEbcQgFmvM=
-github.com/byteness/keyring v1.9.3 h1:8ZnsYFdLiyAil2cIttxUVSRbNj5u+UG7AR7jH18tWkE=
-github.com/byteness/keyring v1.9.3/go.mod h1:fHz0D2UQARryadc45oHOmgo/v4F7JheVi2Mt/1GpH7Q=
+github.com/byteness/keyring v1.11.0 h1:RfMEASvS/pxc/Ulshv7h58f5gzU6TXQ5AuUsvbYdqec=
+github.com/byteness/keyring v1.11.0/go.mod h1:eTBEHu0izyjSx+ux8Rdpfrg/2bBco7ENlqEX7+fBP2c=
 github.com/byteness/percent v0.2.2 h1:vnIFh8WBR1xoC+U2etz0EMB1cgp+vsK6vynqTCeDziU=
 github.com/byteness/percent v0.2.2/go.mod h1:nwavge92FhIyfnldz4YWZD8uxPVvdh8NlzLRd1VYRDs=
 github.com/danieljoos/wincred v1.2.3 h1:v7dZC2x32Ut3nEfRH+vhoZGvN72+dQ/snVXo/vMFLdQ=
@@ -64,12 +64,10 @@ go.opentelemetry.io/proto/otlp v1.9.0 h1:l706jCMITVouPOqEnii2fIAuO3IVGBRPV5ICjce
 go.opentelemetry.io/proto/otlp v1.9.0/go.mod h1:xE+Cx5E/eEHw+ISFkwPLwCZefwVjY+pqKg1qcK03+/4=
 go.uber.org/atomic v1.11.0 h1:ZvwS0R+56ePWxUNi+Atn9dWONBPp/AUETXlHW0DxSjE=
 go.uber.org/atomic v1.11.0/go.mod h1:LUxbIzbOniOlMKjJjyPfpl4v+PKK2cNJn91OQbhoJI0=
-golang.org/x/crypto v0.51.0 h1:IBPXwPfKxY7cWQZ38ZCIRPI50YLeevDLlLnyC5wRGTI=
-golang.org/x/crypto v0.51.0/go.mod h1:8AdwkbraGNABw2kOX6YFPs3WM22XqI4EXEd8g+x7Oc8=
-golang.org/x/sys v0.44.0 h1:ildZl3J4uzeKP07r2F++Op7E9B29JRUy+a27EibtBTQ=
-golang.org/x/sys v0.44.0/go.mod h1:4GL1E5IUh+htKOUEOaiffhrAeqysfVGipDYzABqnCmw=
-golang.org/x/term v0.43.0 h1:S4RLU2sB31O/NCl+zFN9Aru9A/Cq2aqKpTZJ6B+DwT4=
-golang.org/x/term v0.43.0/go.mod h1:lrhlHNdQJHO+1qVYiHfFKVuVioJIheAc3fBSMFYEIsk=
+golang.org/x/sys v0.46.0 h1:noSf2Fq6F8DBgS+LysIkx7rIExoNHJsxOAtPp4rthXw=
+golang.org/x/sys v0.46.0/go.mod h1:4GL1E5IUh+htKOUEOaiffhrAeqysfVGipDYzABqnCmw=
+golang.org/x/term v0.44.0 h1:0rLvDRCtNj0gZkyIXhCyOb2OAzEhLVqc4B+hrsBhrmc=
+golang.org/x/term v0.44.0/go.mod h1:7ze4MdzUzLXpSAoFP1H0bOI9aXDqveSvatT5vKcFh2Y=
 google.golang.org/protobuf v1.36.11 h1:fV6ZwhNocDyBLK0dj+fg8ektcVegBBuEolpbTQyBNVE=
 google.golang.org/protobuf v1.36.11/go.mod h1:HTf+CrKn2C3g5S8VImy6tdcUvCska2kB7j23XfzDpco=
 gopkg.in/check.v1 v1.0.0-20200902074654-038fdea0a05b h1:QRR6H1YWRnHb4Y/HeNFCTJLFVxaq6wH4YuVdsUOr75U=