v2.0.1: fix example in README

The README in v2.0.0 had example code that wouldn't compile. It also had a typo in the doctests that caused the README example to be skipped. This release fixes that documentation problem. There are no functional code changes since v2.0.0.

v2.0.0: general release of keyring v2

Keyring v2 (available on crates.io) is a significant upgrade from v1 while maintaining full backward compatibility on existing platforms. Here's a summary of the changes from v1:

• Introduce traits for pluggable credential-store implementations.
• Add a mock credential store for easy cross-platform client testing.
• Upgrade to secret-service v3.
• Always use service-level search in secret-service.
• Allow creation of new collections in secret-service.
• Add the kernel keyutils as a linux credential store.
• Add build support for FreeBSD.

The README contains instructions for upgrading v1 client code to work with v2. Enjoy!

v2.0.0-rc3: Updated docs

This release, which is fully compatible with v1 and fully documented, will become the v2 release in a few days unless issues are reported. Please try it out ASAP.

v2.0.0-rc.2: Improved performance and v1 compatibility

Here's how the secret-service credential store works now:

1. We always use service-level search.  So no options are needed to turn it on or off.
2. We always add a target attribute when creating new items.
3. We always just search for the service and user.  So we find both v1-style entries (with no target attribute) and v2-style entries (with the target attribute).  We filter the found results so they are either v1-style entries (which are assumed to have a matching target) or v2-style entries with a matching target.
4. If we ever get multiple hits on a search, we return an ambiguous error.
5. set-password works by doing get-password and then, if it finds a unique item, setting the password on that item.  If there is no matching item, it creates one in a collection labeled by the target (creating that collection if necessary).  Note that the default target is the only collection found by alias; all other collections are found by label.

This seems to provide the best of all worlds: v1 and v2 are now completely compatible, and we can create collections if the client uses a non-default target.  (Note that v1 never created collections, and it always used the target name as an alias, so in effect it was completely restricted to using the default collection.)

If (due to 3rd party items) an ambiguity is found, there are platform-specific entries for getting all the passwords or deleting all the matching items.

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.