---
title: Cargo features
description: The default feature set, the linux-persistent opt-in, the build-host packages it needs, and which keyring backends are compiled in.
tags:
- reference
- features
- build
---
# Cargo features
`rtb-credentials` has one optional feature. The default set is empty.
| `linux-persistent` | off | Adds the freedesktop Secret Service (D-Bus) keyring backend on Linux |
```toml
[dependencies]
rtb-credentials = "0.6"
# or, for reboot-persistent Linux keychain storage
rtb-credentials = { version = "0.6", features = ["linux-persistent"] }
```
## What the default build includes
With no features enabled, the crate depends on `keyring` with
`default-features = false` and this explicit backend set:
| `v1` | the version-1 API surface |
| `apple-native-keyring-store` | macOS Keychain |
| `windows-native-keyring-store` | Windows Credential Manager |
| `linux-keyutils-keyring-store` | Linux kernel keyutils |
All three platform backends are compiled in on every build. The
platform selection is made by `keyring` at compile time for the target;
there is no runtime backend choice and no configuration key that selects
one.
## What `linux-persistent` changes
The feature enables `keyring/dbus-secret-service-keyring-store`, adding
the freedesktop Secret Service backend so Linux secrets survive a
reboot. Without it, the Linux backend is kernel keyutils, whose entries
are session-scoped and disappear when the session ends.
It affects Linux only. macOS Keychain and Windows Credential Manager
already persist across sessions and reboots, and the feature changes
nothing on those targets.
### Build-host requirements
`linux-persistent` pulls in `libdbus-sys`, which links against system
D-Bus. The build host needs both:
- `pkg-config`
- `libdbus-1-dev` (Debian/Ubuntu naming; `dbus-devel` on Fedora/RHEL)
```bash
# Debian / Ubuntu
sudo apt-get install -y pkg-config libdbus-1-dev
```
Without them the build fails at link time, not at run time, and the
failure comes from `libdbus-sys` rather than from this crate. That is
the whole reason the feature is opt-in: the default build stays hermetic
and needs no system packages on any platform.
### Runtime requirements
Enabling the feature is not sufficient on its own. The Secret Service
backend needs a D-Bus session bus and a running secret-service 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
even in a build that has the feature compiled in.
This is a common surprise: the feature makes persistent storage
*possible*, not *available*.
## There is no feature that removes the keychain
Every build compiles `keyring` and its platform backends in. There is no
`no-keychain` or `keychain-off` feature, and no way to build this crate
without the `keyring` dependency.
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 use `EnvStore` or its own
`CredentialStore` implementation instead.
## Feature unification affects the whole build graph
Cargo features are additive across a dependency graph. If any crate in a
build enables `linux-persistent`, it is enabled for every consumer of
`rtb-credentials` in that build, including ones that did not ask for it.
A workspace where one member wants persistent Linux storage therefore
imposes the `pkg-config` and `libdbus-1-dev` build requirement on
everything built alongside it.