Skip to content

credentials

Storage-mode abstraction for user-supplied secrets in Go CLIs — the config records how a secret is stored (an env-var name, a keychain reference, or a literal), never a plaintext secret unless you explicitly ask for it. A pluggable Backend sits behind the modes, and the OS keychain is an auditable opt-in.

go get gitlab.com/phpboyscout/go/credentials

gitlab.com/phpboyscout/go/credentials is the credential-storage layer extracted from go-tool-base, where it backs every setup wizard, doctor check, and runtime resolver. It answers one question consistently — where does this secret live, and how do I get it back? — so a tool does not re-implement the same env/keychain/literal switch at every call site.

Why

  • Framework-free. The core's only dependencies are cockroachdb/errors and golang.org/x/term (for the stdlib prompt's masked entry). No config framework, no TUI, no go-tool-base — a depfootprint_test.go guard enforces the boundary.
  • Secrets stay out of config by default. ModeEnvVar records a variable name; ModeKeychain records a service/account reference. Only ModeLiteral writes the secret itself — and it is refused under CI=true.
  • Auditable keychain opt-out. The go-keyring backend lives in the optional credentials/keychain subpackage. Omit its blank import and the linker strips go-keyring and all keychain IPC from your binary — provable via SBOM. See the keychain opt-out.
  • UI-agnostic capture, overridable. A Prompter seam captures the interactive input; a stdlib default ships in the box, and a tool swaps in a themed TUI so prompts match the rest of its UX.

Where next

Reference

The Go API reference is on pkg.go.dev — types, functions, and the Backend / Prompter contracts, kept accurate from the package doc comments.