Skip to content

Cargo features

rtb-credentials has one optional feature, and it does nothing. The default set is empty.

Feature Default Effect
linux-persistent off None. Kept so existing manifests resolve; Linux storage already persists
[dependencies]
rtb-credentials = "0.6"

Which keychain store each target compiles in

The crate depends on keyring-core and exactly one platform store, chosen by the target:

Target Store crate Backend
macOS apple-native-keyring-store (keychain) Keychain
Windows windows-native-keyring-store Credential Manager
Linux and other Unix, except iOS and Android dbus-secret-service-keyring-store (crypto-rust, vendored) freedesktop Secret Service

iOS, Android and other targets compile no store, and KeyringStore returns CredentialError::Keychain on every call.

There is no runtime backend choice and no configuration key that selects one. The keyring crate and zbus are not in the graph.

What linux-persistent changed, and changes now

Up to 0.6.5 the feature enabled keyring/dbus-secret-service-keyring-store, which added the libdbus Secret Service store without ever selecting it: keyring's v1 feature already made its zbus Secret Service store the Linux default. Now the libdbus store is always the Linux backend, and the feature is an empty list. Removing it from a manifest changes nothing.

rust-tool-base's credentials-linux-persistent feature forwards to it, and likewise has no effect.

Build-host requirements

On Linux and other Unix targets, libdbus-sys compiles libdbus from source with the vendored feature and links it statically. The build host needs a C compiler for the target, and nothing else:

  • building for the host: cc (for example build-essential on Debian and Ubuntu)
  • building for x86_64-unknown-linux-musl: musl-gcc (musl-tools)

No pkg-config, no libdbus-1-dev, and no libdbus-1 on the machine the binary runs on.

Runtime requirements

The Secret Service needs a D-Bus session bus and a running provider such as GNOME Keyring or KWallet. A headless server, a container, or a CI runner typically has none of these, and keychain calls fail there.

There is no feature that removes the keychain

Every build compiles keyring-core and its target's store. There is no no-keychain or keychain-off feature.

A tool that must not ship keychain code (an air-gapped or regulated build, say) cannot get there by turning a feature off here. It has to not depend on rtb-credentials at all, and read its secrets some other way. EnvStore is no escape hatch, because it lives in this crate and brings the keychain store with it.