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¶

Generated Go signatures and doc comments are on pkg.go.dev; the pages above add the behaviour a signature does not show.

Further reading¶

The blog carries a curated route through this subject: Building a command-line tool in Go collects everything written about it, ordered so you can start at the beginning rather than newest-first.