evault-store-keyring
OS-keyring–backed implementation of
evault-core'sSecretStoretrait — wrapskeyring-coreto satisfy the trait contract on Windows, macOS, and Linux.
OsKeyringSecretStore stores each variable's secret value in the platform's native credential store, keyed by the variable's UUID:
- Windows — Credential Manager (DPAPI-protected).
- macOS — Keychain.
- Linux — Secret Service (GNOME Keyring / KWallet) via D-Bus.
Errors from the underlying keyring-core crate are reduced to a fixed set of category labels: the service name, the account (a UUID — not secret, but not useful to attackers), and platform-specific paths or D-Bus identifiers are never carried into the error string. This is intentional: error messages are surfaced to the user and must not leak structural details that could narrow entropy.
Install
[]
= "0.1"
= "0.1"
Example: round-trip a secret
use ;
use VarId;
use SecretStore;
use OsKeyringSecretStore;
// Pick a unique service identifier so multiple applications can
// coexist on the same machine without colliding.
let store = with_service
.expect;
let id = new_v4;
store
.put
.expect;
let value = store.get.expect.expect;
assert_eq!;
store.delete.expect;
Headless environments
On Linux servers without D-Bus / Secret Service (e.g. SSH-only hosts, plain Docker containers), OsKeyringSecretStore::with_service returns SecretError::Unavailable. Callers should detect this and either:
- Fail fast with a clear message, or
- Fall back to a different
SecretStoreimplementation (e.g.MemorySecretStorefor ephemeral use, or a file-encrypted variant).
The integration tests in this crate demonstrate the "skip if unavailable" pattern.
Part of the evault workspace
This is the production secret-store implementation used by evault. See the workspace README for how it fits with the SQLCipher metadata store and the TUI.