v2.0.0-rc.1: : Early release of v2

This is a complete release of keyring v2 based on the latest secret-service v3. It's marked as a release candidate both to allow external user testing and to prevent unwitting upgrades (because good docs that explain how to move code from v1 to v2 have not yet been written). The actual v2 release is expected in about a week.

See the release notes for the alpha and beta versions of v2 for more info about what's in v2 relative to v1.

v2.0.0-beta.1: Add service-level search to secret-service

This release introduces one option in the secret-service credential store builder: a boolean search_all which means to search for credentials in all collections (i.e., use service-level search).  When you turn on search_all in the builder, it causes all the credentials to include a target attribute (as well as using the target for the collection name in which the credential is created), and it always searches for credentials at service level including the target attribute.  This means:

• if search_all is off (the default), then we are completely compatible with v1 credentials and we have to do the explicit check for a locked credential on get and delete.
• if search_all is on, then we will never see any v1 or search_all=off credentials at all (because none have a target attribute).

Note that v1 and search_all=off will find credentials built with search_all=on (because they ignore the target attribute).  In addition, because of the way the secret service works, doing a v1 or search_all=off set-password call will remove the target attribute from an existing credential with the same service and user.

Thus, to write a v2 client that always uses service-level search but is compatible with non-service-level search clients, the service-level search client should always delete any existing non-target entry with the same user and service before setting a password.  This is very easy to do because you can use two credential stores side-by-side in the same v2 client.

In order to publish this release to crates.io, we have reverted to using v2 of the secret-service, because v3 is not yet released.  If v3 is released before we are out of beta, we will integrate it into our release. Otherwise, we should be able to do a single dot release that incorporates it.

v1.2.1: bug fix on Windows

The maximum allowed password length was not being checked correctly on Windows, because the check did not take into account the UTF-16 encoding that would be applied to the password before it was stored (#85). This release fixes that one bug.

v2 alpha 4: pre-release that can't go to crates.io

This is a stable pre-release of keyring-rs v2, but it can't be published to crates.io because it uses a not-yet-published dependency (secret service v3). Main changes since version 1.2:

1. Platform-specific credentials and credential stores are now described by traits: CredentialApi and CredentialBuilderApi. Clients can bring their own credential stores, can set the store that should be used by default for creating new entries, and can specify the creation of a credential in a specific store.
2. Entry::new and similar can now return errors. This is a breaking change in the API.
3. The Error enum is now non-exhaustive (and some of its entries have changed.). This is a breaking change in the API.
4. There is now a mock credential store that clients can use for platform-independent code testing (as requested by @moritzheiber).
5. The secret-service credential store is now using v3 of secret-service, and allows explicit control (via features) of which async runtime and encryption implementation used by zbus. For backwards compatibility, the default feature set enables secret-service with the async-io runtime and Rust-native encryption. If you want to avoid any use of an async runtime, then compile without the secret service by specifying default-features = false and adding the feature linux-no-secret-service. (Thanks to @Sytten for advice in this area.)
6. The secret service credential store now attempts to unlock entries before returning them (#84 - thanks @jkhsjdhjs).
7. The linux-kernel credential store keyutils has been added as a built-in credential store (thanks to @landhb). You can make this the default store by specifying the feature linux-default-keyutils (or by excluding the secret-service from the build completely, as described above).

Once v3 of the secret service is published, docs will be updated and this code will be re-published as a release candidate.

v1.2: Resolve platform differences around empty user names

As reported in #86, the MacOS platform treats an empty user-name (or service-name) string as a wildcard when doing a password retrieval. Other platforms do not act this way. As it's a tenet of this module to have consistent behavior on all platforms, a bug fix was needed. The resolution (as documented in #86 and #87 and in the docs) is to disallow the use of empty strings for target, service or user names in credentials, causing all attempted uses of such credentials to fail with a "credential not found" error. This resolution does not break the API or any existing API documentation (since the behavior on empty strings was not documented), but as it's a functionality change it merits a minor version bump.

Existing clients of the API who were relying on platform-specific behavior around the user of empty credential strings can still use this module, but they will have to explicitly specify their platform credentials using the new_with_credential call rather than using new or new_with_target as they may have been.

v1.1.2: update dependencies

We were using structopt in the CLI example, but it's now in maintenance because the latest clap incorporates all of the stuctopt features. Thanks to @gondolyr we are now on the latest clap.

There are no keyring-related functional changes in this release.

v1.1.1: iOS support

This release provides Keyring support on iOS. See the README for details.

v1.0.1: windows fixes in Cargo.toml

This patch release, thanks to @jyuch, fixes a problem with starting a new Cargo project on Windows that uses Keyring. There were missing features in Keyring's load of the winapi crate.

v1.0.0: updated API and increased functionality

This release adds many requested features and fixes many reported bugs; thanks everyone for the feedback! From the change log:

• Breaking API changes:
  • Keyring struct renamed to Entry
  • KeyringError enum renamed to Error, and is completely cross-platform.
• API enhancements:
  • Clients can now control how entries map to credentials; see Entry::new_with_target and Entry::new_with_credential
  • Clients can now retrieve platform credentials with metadata rather than just passwords; see Entry::get_password_and_credential.
  • Non UTF8 passwords now have their data available.
  • Non-login keychains are usable on Linux and Mac.
• Expanded documentation and cli example.

Pre-release of v1.0

This is a major version bump to 1.0. There are incompatible API changes and a lot of new features:

• The Keyring structure is now named Entry, which is far more accurate.
• The KeyringError structure is now named just keyring::Error. It is still an enum, but the values returned are platform-independent so no platform-specific code is needed for error handling.
• Clients now have a lot more control over the details of the credential used for a given entry: see the constructors on the Entry structure.
• The sample cli application has been completely revamped and shows how to use all aspects of the keyring.
• All credential use is backward-compatible with earlier versions.

NOTE: The cargo project version will not be updated until we release to crates.io.