v3.0.5: update docs and clean up dead code

As reported in #132, using the secret-service asynchronously via the keyring wrapper can lead to deadlocks. The docs have been updated to make this clear, and a recommendation has been added to use the sync-secret-service feature so as to avoid any issues related to async runtimes, even if the calling app may already be asynchronous.

While this fix was being made, it was discovered that new clippy lints in Rust 1.80 had been added. These lints revealed some dead code related to windows testing, and some documentation that was "legal" per the markdown spec but slightly ambiguous in intent. Both of these other issues were also fixed.

There are no code changes in this release relative to v3.0.4.

v3.0.4: expose cross-platform module alias

As reported in #197, there's no way for a client to access an instance of the default credential builder with platform-independent code. This releases fixes that oversight, and provides an example as part of the documentation of the credential module.

v3.0.3: Fix feature linux-native

Earlier releases didn't correctly use the keyring when the linux-native feature was specified. This release does.

Thanks to @Brooooooklyn for finding this issue!

v3.0.2: fix iOS and doc issues in v3 release

This patch release adds in the missing iOS APIs reported in #187 and the missing CHANGELOG entries reported in #189. It also updates the README to be a lot clearer about how the new feature system interacts with platforms.

v3.0.1: Support for new keystores and binary secrets

The major functional change between v2 and v3 is the addition of synchronous support for the Secret Service via the dbus-secret-service crate. This means that keyring users of the Secret Service no longer need to link with an async runtime.

The main API change between v2 and v3 is the addition of support for non-string (i.e., binary) "password" data. To accommodate this, two changes have been made:

1. There are two new methods on Entry objects: set_secret and get_secret. These are the analogs of set_password and get_password, but instead of taking or returning strings they take or return binary data (byte arrays/vectors).

2. The v2 method delete_password has been renamed delete_credential, both to clarify what's actually being deleted and to emphasize that it doesn't matter whether it's holding a "password" or a "secret".

Another API change between v2 and v3 is that the notion of a default feature set has gone away: you must now specify explicitly which crate-supported keystores you want included (other than the mock keystore, which is always present). So all keyring client developers will need to update their Cargo.toml file to use the new features correctly.

All v2 data is fully forward-compatible with v3 data; there have been no changes at all in that respect.

The MSRV has been moved to 1.75, and all direct dependencies are at their latest stable versions.

(The original 3.0.0 release had a compile-time issue related to Error traits in some environments; v3.0.1 fixes that.)

v3.0.0-rc.2: Likely final candidate for next major release

This is likely the final RC for the v3 release. Please try it out and provide feedback. From the README:

The major functional change between v2 and v3 is the addition of synchronous support for the Secret Service via the dbus-secret-service crate. This means that keyring users of the Secret Service no longer need to link with an async runtime.

The main API change between v2 and v3 is the addition of support for non-string (i.e., binary) "password" data. To accommodate this, two changes have been made:

1. There are two new methods on Entry objects: set_secret and get_secret. These are the analogs of set_password and get_password, but instead of taking or returning strings they take or return binary data (byte arrays/vectors).

2. The v2 method delete_password has been renamed delete_credential, both to clarify what's actually being deleted and to emphasize that it doesn't matter whether it's holding a "password" or a "secret".

Another API change between v2 and v3 is that the notion of a default feature set has gone away: you must now specify explicitly which crate-supported keystores you want included (other than the mock keystore, which is always present). So all keyring client developers will need to update their Cargo.toml file to use the new features correctly.

All v2 data is fully forward-compatible with v3 data; there have been no changes at all in that respect.

The MSRV has been moved to 1.75, and all direct dependencies are at their latest stable versions.

v3.0.0-rc.1: Next major version

From the README:

The major functional change between v2 and v3 is the addition of synchronous support for the Secret Service via the dbus-secret-service crate. This means that keyring users of the Secret Service no longer need to link with an async runtime.

The only API change between v2 and v3 is that the default feature set has gone away: you must now specify explicitly which crate-supported keystores you want included. So keyring clients will need to update their Cargo.toml file, but not their code.

All v2 data is fully forward-compatible with v3 data; there have been no changes at all in that respect.

The MSRV has been moved to 1.75, and all direct dependencies are at their latest stable versions.

v2.3.3: Updates for Rust 1.78

Rust 1.78 introduced a new clippy check and better guards on Windows when making slices from raw bytes. These changes required one small change in the platform-independent code and two small changes in the Windows-specific code.

v2.3.1: Windows platform update; minimum rust version specified

This release includes a contribution by @russellbanks which changes windows to use the windows-sys crate instead of winapi, as suggested by @thewh1teagle.

Specifies a minimum stable rust version of 1.68, which is the one that was current when this major version was released. Only the library is warranted to build on 1.68. In particular, none of the tests or examples will work; they require 1.70 for dev dependencies.

v2.3.0: Support OpenBSD

Thanks to @klemensn, this release should build and run on OpenBSD.