Skip to main content

Crate secretx_keyring

Crate secretx_keyring 

Source
Expand description

Linux kernel keyring backend for secretx.

§Integration test status

Unit tests (URI parsing, error mapping) pass without credentials. The integration test (SECRETX_KEYRING_INTEGRATION_TESTS=1) uses the Linux kernel keyring directly (no daemon required). Run with:

SECRETX_KEYRING_INTEGRATION_TESTS=1 cargo test -p secretx-keyring

On Linux, secrets are stored via the kernel persistent keyring, which survives across logout/login sessions for a configurable window (default: a few days, set by /proc/sys/kernel/keys/persistent_keyring_expiry). Secrets do not survive reboots.

See keyutils(7) for the kernel keyutils subsystem overview.

Persistent keyring probe: get and put probe keyctl_get_persistent before each operation. If the kernel does not support CONFIG_PERSISTENT_KEYRINGS (e.g. some containers, restricted namespaces, or hardened kernels), SecretError::Unavailable is returned rather than silently falling back to the session keyring (which expires when the process exits).

Integration-tested 2026-04-28: Linux headless (kernel persistent keyring, no daemon).

URI: secretx:keyring:<service>/<account>

use secretx_keyring::KeyringBackend;
use secretx_core::{SecretStore, SecretValue, WritableSecretStore};

// Read
let store = KeyringBackend::from_uri("secretx:keyring:my-app/api-key")?;
let value = store.get().await?;

// Write (requires WritableSecretStore in scope)
store.put(SecretValue::new(b"new-secret".to_vec())).await?;

Structs§

KeyringBackend
Backend that reads and writes secrets via the Linux kernel keyring.