This crate, keyring-core
, is part of
the Keyring ecosystem. It provides a cross-platform library to manage storage and retrieval of passwords (and other secrets) in secure credential stores, as used by the keyring application. If you are a developer looking to integrate secret-management facilities into your app, this is the crate you should use as a dependency, along with one or more keyring-compatible credential-stores.
To use this crate in your project, include it in your Cargo.toml
, either with or without the sample
feature (which enables a credential store useful while testing). There are no default features.
In your application code, set your default credential store using set_default_store
when you start up, and unset it with unset_default_store
when you shut down. Use the Entry::new
function to create a new keyring entry. The new
function takes a service name and a user's name which together identify the entry.
Passwords (strings) or secrets (binary data) can be added to an entry using its set_password
or set_secret
methods, respectively. (These methods create or update an entry in your chosen credential store.) The password or secret can then be read back using the get_password
or get_secret
methods. The underlying credential (with its password/secret data) can be removed using the delete_credential
method.
Here is a simple example application that uses the (included) mock credential store and does absolutely nothing:
use keyring_core::{set_default_store, mock, Entry, Result};
fn main() -> Result<()> { set_default_store(mock::Store::new()); let entry = Entry::new("my-service", "my-name")?; entry.set_password("topS3cr3tP4$$w0rd")?; let password = entry.get_password()?; println!("My password is '{}'", password); entry.delete_credential()?; Ok(()) }
Creating and operating on entries can yield an Error
enum that classifies the error and, where relevant, includes underlying credential store errors or more information about what went wrong.
This crate comes with two cross-platform credential stores that can be used by clients who want to test their credential-store-independent logic. The first of these is a mock store with no persistence that allows mocking errors as well as successes. The other is a sample store with file-based persistence. Neither of these stores is secure or robust, so they should not be used in production. See the developer docs for details.
There are some changes in the API relative to that in the [keyring crate v3](https://crates.io/crates/keyring/3.6.2. Both client and credential store developers will need to make changes. Developers should read the keyring-core design document to better understand the new API.
- In the older API, credential stores were fairly opaque, exposing only a credential builder function (which was a singleton). In the current API, credential stores are richer objects with their own lifecycle, so
set_default_credential_builder
has becomeset_default_store
, and it receives the default store via a sharedArc
rather than an owningBox
. There is also anunset_default_store
function to release the store. - The new client-facing API does not reveal the
Credential
object, which is exclusively part of the credential-store provider API. As part of this change, the Ambiguous error now returns a list of entries. - The new API's
get_credential
call now fails if there is no existing credential for an entry, and returns an entry rather than a credential. - The new API exposes credential search and returns entries for all the matching credentials. Many thanks to @wiimmers for showing the way with his keyring-search crate. I am hoping he will integrate his search facilities into all the new credential stores.
Licensed under either of
- Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
at your option.
The full list of library contributors may be found in the Contributors file.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.