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 |
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 examplebuild-essentialon 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.