keyring-rs

keyring-rs is a Rust crate that gives applications a single, simple API for setting, getting, and deleting passwords and binary secrets using the native secure storage on macOS, Windows, and *nix systems (Keychain, Credential Manager, Secret Service/libsecret, and kernel keyutils). Rather than shipping its own crypto or persistence layer, it delegates to whichever OS-level credential store is available, so secrets never touch application-controlled disk files in plaintext.

The crate has a long history in the Rust ecosystem, originally combining the API and the credential-store backends in one package; that logic has since been split so the underlying keyring-core crate and individual store implementations can be composed independently, while this crate remains the batteries-included entry point most applications reach for first. It also ships extensive sample CLI code (behind an opt-in cli feature) used to build companion tools like a command-line credential inspector and a cross-platform GUI.

What You Get

• A unified Entry API for setting, getting, and deleting passwords/secrets across macOS, Windows, and Linux
• Native backend delegation to Keychain, Credential Manager, Secret Service (zbus/dbus), and Linux keyutils — no custom encryption to audit
• Support for both UTF-8 password strings and arbitrary binary secrets
• An optional cli feature with sample code for building command-line and GUI credential tools
• A modular architecture (via the separate keyring-core crate and per-platform store crates) for apps that need finer control over which stores are linked

Common Use Cases

• Storing a user’s API token or password for a desktop CLI tool without writing it to a plaintext config file
• Building a desktop or Tauri app that needs to remember login credentials securely between launches
• Caching short-lived cloud or database credentials in the OS keychain instead of environment variables
• Building developer tools that need to store secrets (e.g. git credential helpers, cloud CLIs) using the same store the OS itself trusts

Under The Hood

Architecture - The crate is deliberately thin: src/lib.rs gates two mutually-exclusive-by-default modules behind Cargo features. The v1 module (src/v1.rs, ~120 lines) reproduces the original keyring-rs 1.x API surface (Entry::new, set_password, get_password, delete_credential) by wiring straight into whichever platform credential-store crate (Keychain, Windows Credential Manager, zbus/dbus Secret Service, Linux keyutils) is selected via target-specific Cargo dependencies. The cli module (src/cli.rs) instead exposes use_named_store/use_default_store helpers over the newer keyring-core abstraction, letting callers pick a named backend at runtime; this is the glue reused by the bundled keyring-cli, leak-test, and unit-test example binaries and by the external Python and Tauri GUI companion projects. Tech Stack - Built on Rust 2024 edition (MSRV 1.88), the crate has a single runtime dependency, keyring-core, and pulls in platform-specific store crates (apple-native-keyring-store, windows-native-keyring-store, zbus-secret-service-keyring-store, dbus-secret-service-keyring-store, linux-keyutils-keyring-store, db-keystore) conditionally via [target.'cfg(...)'] dependency blocks, so a given build only links the stores relevant to its OS. Dev-dependencies (clap, rpassword, zeroize, fastrand) support the example CLIs and leak/unit test harnesses rather than the library itself. Code Quality - The core library code is intentionally minimal (under 200 lines across lib.rs, v1.rs, and cli.rs), which keeps the audit surface small; the heavier lifting (encryption, OS API calls) lives in the separate, independently-versioned store crates. Testing responsibility is pushed to the unit-test and leak-test example binaries, which exercise every available credential store on the host platform and specifically check that secret bytes don’t leak into the heap — a deliberate, security-conscious test design rather than conventional inline #[test] functions. API Design - The v1 feature preserves a stable, beginner-friendly API (Entry::new(service, user).set_password(...)) unchanged since the original crate, minimizing breakage for long-time users, while the cli/keyring-core path trades a little simplicity for explicit backend selection needed by multi-store tooling. Documentation is thorough for a crate this size: the README, module-level doc comments, and an external wiki all explain when to use v1 versus linking keyring-core directly, and explicitly steer applications with fine-grained needs away from this crate’s cli feature toward the leaner core.