Explanation¶
Background and reasoning. These pages answer "why is it like this", where the reference answers "what does it do" and the how-to guides answer "how do I".
| Page | Question it answers |
|---|---|
| Why the precedence chain is ordered this way | Why env beats the keychain, why there are two environment legs, and why the order cannot be configured. |
Why every secret is a SecretString |
What the type prevents that a String does not, and why it can be deserialised but not serialised. |
| Why literal secrets are refused in CI | What the refusal protects against, and why detection is one exact string. |
| Why Linux keychain storage is session-scoped by default | The build-hermeticity trade behind kernel keyutils, and what linux-persistent really buys. |
| What this crate does not do | Deliberate omissions, unsupported combinations, and known rough edges. |
Where this crate sits¶
rtb-credentials is one crate in the
phpboyscout Rust toolkit, extracted from
the rust-tool-base
framework so it can be used without adopting the framework around it. It
depends on no other toolkit crate.
Its scope is narrow on purpose: retrieve a stored static secret, and keep it in a type that resists leaking. Deciding which credential a tool needs is the tool's job; storing one durably is the platform's job; refreshing a short-lived token is outside the model entirely.
A sibling component in the Go toolkit,
go/credentials,
solves the same problem for Go tools with the same three storage modes
and the same precedence. The designs are intentionally parallel, but
they are separate implementations and the Rust one differs where Rust
allows something Go cannot — most visibly in
secret handling.