27 releases (7 stable)

Uses new Rust 2021

new 2.0.0-beta.1 Jan 23, 2023
2.0.0-alpha.3 Oct 10, 2022
1.2.1 Jan 21, 2023
1.2.0 Jul 3, 2022
0.1.0 Feb 10, 2016

#3 in Authentication

Download history 8789/week @ 2022-10-07 5996/week @ 2022-10-14 7459/week @ 2022-10-21 6669/week @ 2022-10-28 7226/week @ 2022-11-04 8438/week @ 2022-11-11 5824/week @ 2022-11-18 6824/week @ 2022-11-25 6753/week @ 2022-12-02 7731/week @ 2022-12-09 10173/week @ 2022-12-16 2433/week @ 2022-12-23 3449/week @ 2022-12-30 8906/week @ 2023-01-06 8520/week @ 2023-01-13 11080/week @ 2023-01-20

32,716 downloads per month
Used in 58 crates (46 directly)

MIT/Apache

96KB
2K SLoC

Keyring-rs

CI Crates.io API Documentation on docs.rs

A cross-platform library to manage storage and retrieval of passwords (and other credential-like secrets) in the underlying platform secure store, with a fully-developed example that provides a command-line interface.

Published on crates.io

Usage

Currently supports Linux, iOS, macOS, and Windows. Please file issues if you have any problems or bugs!

To use this library in your project add the following to your Cargo.toml file:

[dependencies]
keyring = "1"

This will give you access to the keyring crate in your code. Now you can use the Entry::new function to create a new keyring entry. The new function expects a non-empty service name and a non-empty username which together identify the entry.

Passwords can be added to an entry using its set_password method. They can then be read back using the get_password method, and deleted using the delete_password method. (The persistence of the Entry is determined via Rust rules, so deleting the password doesn't delete the entry, but it does delete the underlying platform credential which was used to store the password.)

extern crate keyring;

use std::error::Error;

fn main() -> Result<(), Box<dyn Error>> {
    let service = "my_application";
    let username = "my_name";
    let entry = keyring::Entry::new(&service, &username);

    let password = "topS3cr3tP4$$w0rd";
    entry.set_password(&password)?;

    let password = entry.get_password()?;
    println!("My password is '{}'", password);

    entry.delete_password()?;
    println!("My password has been deleted");

    Ok(())
}

Errors

Creating and operating on entries can yield a keyring::Error which provides both a platform-independent code that classifies the error and, where available, underlying platform errors and/or more information about what went wrong.

Examples

The keychain-rs project contains a sample application (cli) and a sample library (ios).

The application is a command-line interface to the keyring. This can be a great way to explore how the library is used, and it allows experimentation with the use of different service names, usernames, and targets. When run in "singly verbose" mode (-v), it outputs the retrieved credentials on each get run. When run in "doubly verbose" mode (-vv), it also outputs any errors returned. This can be a great way to see which errors result from which conditions on each platform.

The sample library is a full exercise of all the iOS functionality; it's meant to be loaded into an iOS test harness such as the one found in this project. While the library can be compiled and linked to on macOS as well, doing so doesn't provide any advantages over the standard macOS tests.

Client Testing

This crate comes with a "mock" credential store that can be used by clients who want to test without accessing the native platform store. The mock store is cross-platform and allows mocking errors as well as successes.

Extensibility

This crate comes with built-in support for the keychain on Mac, the credential manager on Windows, and both secret-service and the kernel keyring on Linux. But it's also designed to allow clients to "bring their own credential stores" by providing traits that clients can implement. See the developer docs for details.

Dev Notes

  • We build using GitHub CI.
  • Each tag is built on Ubuntu x64, Win 10 x64, and Mac intel x64. The cli example executable is posted for all platforms with the tag.

Headless Linux

If you are trying to use keyring on a headless linux box, be aware that there are known issues with getting dbus and secret-service and the gnome keyring to work properly in headless environments. For a quick workaround, look at how this project's CI workflow uses the linux-test.sh script; a similar solution is also documented in the Python Keyring docs (search for "Using Keyring on headless Linux systems"). For an excellent treatment of all the headless dbus issues, see this answer on ServerFault.

Note that you can build this crate without secret-service support; this makes the Linux keyring (which works normally on headless linux) the default credential store on Linux platforms.

License

Licensed under either of

at your option.

Contributors

Thanks to the following for helping make this library better, whether through contributing code, discussion, or bug reports!

  • @Alexei-Barnes
  • @bhkaminski
  • @brotskydotcom
  • @complexspaces
  • @dario23
  • @dten
  • @gondolyr
  • @hwchen
  • @jasikpark
  • @jkhsjdhjs
  • @jonathanmorley
  • @jyuch
  • @landhb
  • @lexxvir
  • @MaikKlein
  • @Phrohdoh
  • @Rukenshia
  • @samuela
  • @stankec
  • @steveatinfincia
  • @Sytten

If you should be on this list, but don't find yourself, please contact @brotskydotcom.

Contribution

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.

Dependencies

~0–5.5MB
~84K SLoC