de13a7319b
Done with the commands below. The following crates have had various changes, and should get a patchlevel bump. Since they are pre-1.0, we do not need to distinguish new APIs from other changes. ``` cargo set-version --bump patch -p arti-client cargo set-version --bump patch -p safelog cargo set-version --bump patch -p tor-bytes cargo set-version --bump patch -p tor-cert cargo set-version --bump patch -p tor-circmgr cargo set-version --bump patch -p tor-config cargo set-version --bump patch -p tor-consdiff cargo set-version --bump patch -p tor-dirclient cargo set-version --bump patch -p tor-dirmgr cargo set-version --bump patch -p tor-error cargo set-version --bump patch -p tor-hsservice cargo set-version --bump patch -p tor-linkspec cargo set-version --bump patch -p tor-llcrypto cargo set-version --bump patch -p tor-netdir cargo set-version --bump patch -p tor-netdoc cargo set-version --bump patch -p tor-proto cargo set-version --bump patch -p tor-rpcbase cargo set-version --bump patch -p tor-socksproto ``` This crate has new features, but no new non-experimental Rust APIs. So even though it is post-1.0, it gets a patchlevel bump. ``` cargo set-version --bump patch -p arti ``` |
||
|---|---|---|
| .. | ||
| src | ||
| testdata | ||
| Cargo.toml | ||
| README.md | ||
README.md
tor-keymgr
Code to fetch, store, and update keys.
Overview
This crate is part of Arti, a project to implement Tor in Rust.
Likely to change
The APIs exposed by this crate (even without the keymgr feature)
are new and are likely to change rapidly.
We'll therefore often be making semver-breaking changes
(and will update the crate version accordingly).
Key stores
The [KeyMgr] is an interface to one or more key stores. The key
stores are types that implement the [KeyStore] trait.
This crate provides the following key store implementations:
- Arti key store: an on-disk store that stores keys in OpenSSH format.
- (not yet implemented) C Tor key store: an on-disk store that is backwards-compatible with C Tor (new keys are stored in the format used by C Tor, and any existing keys are expected to be in this format too).
In the future we plan to also support HSM-based key stores.
Key specifiers and key types
The [KeyStore] APIs expect a "key specifier" (specified for each supported key
type via the [KeySpecifier] trait), and a [KeyType].
A "key specifier" identifies a group of equivalent keys, each of a different type (algorithm). It is used to determine the path of the key within the key store (minus the extension).
[KeyType] represents the type of a key (e.g. "Ed25519 keypair").
[KeyType::arti_extension] specifies what file extension keys of that type are
expected to have (when stored in an Arti store).
The [KeySpecifier::arti_path] and [KeyType::arti_extension] are joined
to form the path of the key on disk (relative to the root dir of the key store).
This enables the key stores to have multiple keys with the same role (i.e. the
same KeySpecifier::arti_path), but different key types (i.e. different
KeyType::arti_extensions).
KeySpecifier implementers must specify:
arti_path: the location of the key in the Arti key store. This also serves as a unique identifier for a particular instance of a key.ctor_path: the location of the key in the C Tor key store (optional).
Feature flags
Additive features
(None yet.)
Experimental and unstable features
Note that the APIs enabled by these features are NOT covered by semantic versioning1 guarantees: we might break them or remove them between patch versions.
keymgr-- build with full key manager support. Disabling this feature causestor-keymgrto export a no-op, placeholder implementation.
-
Remember, semantic versioning is what makes various
cargofeatures work reliably. To be explicit: if you wantcargo updateto only make safe changes, then you cannot enable these features. ↩︎