Bump keyring from 1.2.1 to 2.0.3

[dependabot]

Bumps keyring from 1.2.1 to 2.0.3.

Release notes

Sourced from keyring's releases.

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.

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:

... (truncated)

Changelog

Sourced from keyring's changelog.

Version 2.0.1

• fix the example in the README.

Version 2.0

• (API change) Allow creation of entries to fail.
• (API change) Introduce an ambiguous error on credential lookup.
• (API change) Make the Error enum non-exhaustive.
• (API change) Introduce traits for pluggable credential-store implementations. (This removes the old platform module.)
• 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 (thanks @​ryanavella).

Commits

• f800ce8 Merge pull request #129 from brotskydotcom/master
• e00c46e Bump patch version for release.
• cb2422b Ensure there is always a default store.
• 66228d9 Reorder declarations to maintain consistency.
• 9390b57 Unsupported platforms default to the mock backend so we always compile.
• 6d3b0e8 Merge pull request #126 from brotskydotcom/master
• cebb921 Credit new contribution.
• b002686 Merge pull request #124 from phlip9/extra-alloc
• 7117de6 Remove unnecessary clone/allocation in decode_password
• 2ce7dc5 Merge pull request #122 from brotskydotcom/fix-secret-service-docs
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)