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
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
// grrr clippy... you cannot specify extra bounds with the async fn syntax...
// default implementations don't always make sense...
//! Secret lair private keystore
//!
//! [](http://holochain.org/)
//! [](https://forum.holochain.org)
//! [](https://chat.holochain.org)
//!
//! [](https://opensource.org/licenses/MIT)
//! [](https://www.apache.org/licenses/LICENSE-2.0)
//!
//! This crate mostly provides the `lair-keystore` executable allowing
//! initialization, configuration, and running of a Lair keystore.
//!
//! If you want to run an in-process keystore, this crate also provides the
//! canonical sqlite store.
//!
//! For making use of a Lair keystore in a client application, see the
//! [lair_keystore_api](https://crates.io/crates/lair_keystore_api) crate.
//!
//! # What is lair-keystore, and why does it exist?
//!
//! Lair Keystore is a general asymmetric cryptographic private key store
//! project originally written for Holochain, but intended to be usable for
//! any application.
//!
//! The store mainly tracks the "seed" data that for ed25519 and x25519 allow
//! generation of keypairs, and can be thought of as synonymous with private
//! keys.
//!
//! Lair allows derivation of this seed material for usage similar to HD
//! wallets, with the intention that an end-user could create a "root" seed,
//! from which could be deterministically derived a revocation seed and any
//! number of device and application seeds, which would all be retrievable from
//! a securely stored paper mnemonic of the root. (This has not yet been
//! implemented in Holochain).
//!
//! Lair Keystore was originally intended to be a standalone binary.
//! Given the overhead and security implications of having a process with access
//! to private key material, it was originally envisioned that an end-user would
//! run a single keystore on their system, and be prompted with a pin-entry UI
//! that would unlock access to the private keys for a specified period of time,
//! or every time an operation with a private key occurred in the case of "deep
//! locked" seeds. (This has also not been implemented in Holochain, and
//! moreover, Holochain has moved farther away from this intention by running
//! Lair Keystore as an "in process" library which makes it easier to bundle
//! executables).
//!
//! [lair_keystore_api::LairClient] is the main type that is used to access
//! the keystore, and it mainly functions over an IPC connection (unix domain
//! sockets on Linux and MacOs, and named pipes on Windows). This type allows
//! you to create, access, export, and import tagged seeds, and then, using
//! either those tags or the public keys that are derived from those seeds,
//! perform signing, verification, encryption, and decryption operations.
//!
//! # Rust conventions for dashes and underscores:
//!
//! - Install with an underscore: `cargo install lair_keystore`
//! - Use binary with a dash: `$ lair-keystore help`
//! - Cargo.toml with an underscore:
//!
//! ```text
//! [dependencies]
//! lair_keystore = "0.1.1"
//! ```
//!
//! - Library usage with underscores:
//!
//! ```
//! use lair_keystore::*;
//! ```
//!
//! # `lair-keystore` commandline executable usage:
//!
include!;
/// Re-exported dependencies.
use *;
use *;
pub
pub use create_sql_pool_factory;