Skip to content

Conversation

@renovate
Copy link
Contributor

@renovate renovate bot commented Mar 29, 2025

This PR contains the following updates:

Package Type Update Change
keyring (source) dependencies major 2.3.3 -> 3.0.0

Release Notes

open-source-cooperative/keyring-rs (keyring)

v3.6.3

Compare Source

v3.6.2: : better docs, lighter-weight tests

Compare Source

Thanks to @​unkcpz, this release fully documents all the platform-specific modules in each platform on docs.rs.

The dev dependencies (used for testing) have been switched from using rand to using the lighter-weight module fastrand.

There are no functional code changes in this release, only test changes.

v3.6.1: : Update dependencies

Compare Source

Two of the dependencies (openssl and whoami) were discovered to have vulnerabilities which were fixed in minor or patch releases. This crate has been updated to insist that the minor/patch release number of these dependencies is high enough to ensure use of a patched version.

There is no reason to think that the vulnerabilities in these dependencies could have been exercised through this crate. In addition, builds of clients done after the dependencies were patched would have already picked up the non-vulnerable versions. So this change is simply to ensure that future builds cannot use the vulnerable versions.

There are no code changes in this release.

v3.6.0: : Add new combination keystore

Compare Source

This release contains a new credential store for Linux: a combination of keyutils (for use by headless processes) and secret service (for persistence of credentials beyond reboot). Thanks very much to @​soywod for the contribution!

v3.5.0: : Add debug logging of internal operations

Compare Source

  • Add debug logging of internal operations (thanks to @​soywod).
  • Revert iOS security-framework dependency to v2 (see #​225).

v3.4.0: : allow simultaneous use of secret-service and keyutils

Compare Source

As pointed out in #​214, it is possible to use both the secret-service and the keyutils credential stores at the same time, so this should be an allowed combination of specified features. This release allows that combination, selecting the secret-service as the default keystore but also loading the keyutils keystore.

v3.3.0: : Support additional credential store attributes

Compare Source

  • Add support for credential-store attributes other than those used by this crate. This allows the creation of credentials that are more compatible with 3rd-party clients, such as the OS-provided GUIs over credentials. Fixes #​208.
  • Make the textual descriptions of entries consistently follow the form user@service (or user@service:target if a target was specified).

v3.2.1: : Re-enable access to v1 credentials

Compare Source

The v3.2.0 release, which fixed #​204, had an unfortunate side effect: it broke compatibility with credentials that were originally written by a v1.x release (see #​207). This bug-fix release restores that compatibility.

With this change, the CLI changes in v3.2.0 have been reverted, because they are no longer necessary.

v3.2.0: : Improve secret-service handling of targets

Compare Source

As reported in #​201 and now fixed in #​204, the secret-service credential store implementation could not disambiguate credentials that were created with different targets unless the collections containing those targets had already been unlocked.

The fix for this issue introduces a compatibility break: secret-service credentials created by the keyring v1 implementation, which were readable using platform-independent code in keyring v2, are no longer readable without using platform-specific code in v3. The necessary platform-specific code is very simple, and it has been added to the CLI (both for documentation purposes and to allow the CLI to access v1 credentials). The comments in issue #​204 explain why the decision was made to add this secret-service-specific compatibility break; these include the fact that keyring v2 was released 18 months ago so only those users who haven't changed their password in a very long time would still have a v1 credential in their secret-service store.

The README has been updated to address this compatibility break and to provide recommendations for keyring clients who want to update their code to make sure users with old credentials are not impacted.

v3.1.0: : enhance the CLI

Compare Source

As reported in #​201, the CLI had a couple of problems:

  • It didn't allow empty user names, even on platforms where that's supported.
  • Its debugging output on Ambiguous errors provided no information about the underlying platform credentials.

The first issue was just a bug, now fixed.

The second issue stemmed from the fact that platform-independent code couldn't get at the details of the underlying platform-specific credentials. To fix this, the CredentialAPI had to be extended to provide access to the underlying platform credential's implementation of the std::fmt::Debug trait, and each of the keying credential stores extended to implement the new API.

To make this API extension backward-compatible, a default implementation was provided that did what the former code did: it revealed nothing. But that allows this release to be a SerVer-compatible dot release, rather than a major release.

v3.0.5: : update docs and clean up dead code

Compare Source

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

Compare Source

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

Compare Source

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

Compare Source

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

Compare Source

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

Compare Source


Configuration

📅 Schedule: Branch creation - "every weekend" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate bot force-pushed the renovate/keyring-3.x branch from 2396b67 to 8f9f6bd Compare June 15, 2025 08:01
@sonarqubecloud
Copy link

@renovate renovate bot force-pushed the renovate/keyring-3.x branch from 8f9f6bd to 2546317 Compare July 27, 2025 05:31
@sonarqubecloud
Copy link

@renovate renovate bot force-pushed the renovate/keyring-3.x branch from 2546317 to ae4ec0e Compare September 25, 2025 21:40
@sonarqubecloud
Copy link

@renovate renovate bot force-pushed the renovate/keyring-3.x branch from ae4ec0e to f88c18a Compare December 10, 2025 10:39
@sonarqubecloud
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant