v2.2.0: rework default feature set

In response to #153 and #148, suppressing the default feature set now suppresses the platform keystore dependencies on all platforms and uses the mock keystore as the default.

PLEASE NOTE: While this behavior is a breaking change on Mac, Windows, and FreeBSD, the behavior on those platforms before was unintended and undefined (suppressing default features did nothing), so this is considered a bug fix rather than a semver-breaking change that requires a major version bump.

v2.1.0: add runtime indication of credential persistence

This minor release adds support for asking credential stores at runtime about the lifetime of their stored credentials. See the documentation of CredentialPersistence for details.

This feature was suggested by @benwr in #147.

v2.0.5: documentation improvements

This release includes the updates to the keyring documentation from @landhb (see #137 and #138).

v2.0.4: cli and documentation improvements

There are no code changes in this patch release.

1. The CLI has been improved to support use in scripting. See #130 and #134.
2. Docs for the secret-service keystore have been improved to cover edge cases. See #132 and #133.

v2.0.3: patch release with two improvements

This release integrates two improvements from @phlip9 - thanks!

1. We don't do an unnecessary allocation on every get_password call.
2. There is always a default store available on all platforms (including Android - fixes #128).

v2.0.2: Fix misleading typo in documentation

This fixes user to be username in the documentation of secret-service attributes. The same sort of typo was in the Mac, iOS, and xplat docs, but it wasn't as serious there because it didn't affect attribute names used by the underlying implementations.

This is a documentation-only release: no code changes.

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.