rtb-credentials 0.6.6

OS keychain credential storage. Part of the phpboyscout Rust toolkit.
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81

---
title: Cargo features
description: The default feature set, the no-op linux-persistent feature, the keychain store compiled in for each target, and what the build host needs.
tags:
  - reference
  - features
  - build
---

# 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 |

```toml
[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.