keyring-core

keyring-core is the foundational crate of the Keyring ecosystem, providing a cross-platform Rust API for managing the storage and retrieval of passwords and other secrets in secure credential stores. Application developers depend on it, together with one or more keyring-compatible credential stores, to add secret management without writing platform-specific code.

The API centers on an Entry, identified by a service name and a user name, with set_password/get_password and set_secret/get_secret methods that read and write the underlying credential. A pluggable store abstraction lets you install a default credential store at startup, and the crate ships mock and sample stores for testing.

What You Get

• An Entry API keyed by service and user name for managing credentials
• set_password/get_password and set_secret/get_secret for strings and binary data
• delete_credential to remove the underlying stored credential
• A pluggable credential-store interface with set_default_store/unset_default_store
• Built-in mock and sample stores for testing credential-store integrations
• A structured Error enum that classifies failures and wraps underlying store errors

Common Use Cases

• Adding cross-platform secret storage to a Rust application or CLI
• Reading and writing passwords in the OS keychain via a keyring-compatible store
• Testing credential-store logic against a mock store before shipping

Under The Hood

Architecture — The crate is small and interface-driven. api.rs defines the public Entry type and the CredentialStore/Credential traits that backend stores implement; a process-wide default store is installed via set_default_store and consulted when Entry::new and the get/set/delete methods run. attributes.rs handles the service/user attribute model, error.rs defines the Error enum and Result alias, and mock.rs plus src/sample/ provide in-memory stores used for testing and as reference implementations.

Tech Stack — Pure Rust with no default features and a minimal dependency footprint; a sample feature enables an extra credential store useful during testing. It is the core of a multi-crate ecosystem where OS-specific stores (keychain, secret-service, credential manager) are shipped as separate compatible crates.

Code Quality — Actively maintained (29 contributors, 12 releases to a 1.0) with tests colocated across error.rs, attributes.rs, mock.rs, and the sample store, plus an ambiguity.rs example. The trait-based store boundary keeps the core decoupled from any platform, and errors are modeled explicitly rather than swallowed.

API Design — The API is deliberately tiny and readable: install a store, Entry::new(service, user), then set_password/get_password/delete_credential. Separating the store from the entry API means the same application code works against any backend, and the bundled mock store makes getting started (and testing) essentially boilerplate-free.