fix(auth): enable native keyring backends on top of #359

[zssz]

Description

This PR is now rebased on top of the latest main, including #359.

Motivation:
#359 added GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND and preserved .encryption_key as a durable fallback, but it does not change how the keyring crate itself is compiled. The remaining problem is that keyring was still declared without any native backend features, so keyring v3 could silently fall back to its in-memory mock backend. In practice, that meant gws auth login could appear to succeed, while the selected keyring backend was not actually backed by the host OS secure store.

Why this fixes it:

• It enables the native keyring backends in Cargo.toml, so the default keyring backend is backed by a real platform implementation instead of the in-memory mock store.
• In combination with feat(credential_store): add GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND env var #359, this gives gws both real OS-keyring support when available and a persistent .encryption_key fallback when it is not.
• The rebased branch intentionally keeps credential_store.rs aligned with main from feat(credential_store): add GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND env var #359 rather than reintroducing overlapping logic.

Additional local fix from verification:
While rebasing and verifying on top of #359, cargo test exposed a test race in auth_commands::tests::config_dir_returns_gws_subdir, where it could observe GOOGLE_WORKSPACE_CLI_CONFIG_DIR while another serialized test was mutating it. This PR marks that test as #[serial_test::serial] as well.

Note on Cargo.lock:
The Cargo.lock diff is large because enabling the native keyring backends pulls in the transitive platform-specific dependencies needed for persistent secure storage.

This is not adding a new command or Discovery request path, so there is no relevant --dry-run output for the template section below.

Dry Run Output:

{
  "not_applicable": "This change updates auth credential backend compilation and a test isolation fix; it does not add a new command or API request body."
}

Checklist:

• My code follows the AGENTS.md guidelines (no generated google-* crates).
• I have run cargo fmt --all to format the code perfectly.
• I have run cargo clippy -- -D warnings and resolved all warnings.
• I have added tests that prove my fix is effective or that my feature works.
• I have provided a Changeset file (e.g. via pnpx changeset) to document my changes.

[changeset-bot]

🦋 Changeset detected

Latest commit: b0e72c5

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@googleworkspace/cli	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves a critical authentication persistence issue where gws auth login credentials could not be decrypted in subsequent processes. The problem stemmed from the keyring crate silently defaulting to an in-memory mock backend, preventing the encryption key from being securely stored. The solution involves explicitly configuring the keyring crate to use native operating system keychains, streamlining the fallback mechanism to local key files, and adding a new test to validate the correct keyring backend is in use.

Highlights

• Native Keyring Backends Enabled: The keyring crate dependency in Cargo.toml was updated to explicitly enable native platform-specific features, including apple-native, windows-native, linux-native-sync-persistent, and crypto-rust, ensuring proper persistence of authentication credentials.
• Key-File Loading Refactoring: A new helper function, load_key_file, was introduced in src/credential_store.rs to centralize and improve the logic for loading encryption keys from local files.
• Regression Test Added: A new test case, default_keyring_backend_is_not_mock, was added to src/credential_store.rs to prevent future regressions by asserting that the keyring crate does not fall back to its in-memory mock implementation.
• Unit Test Isolation: The get_or_create_key function was modified to ensure that unit tests use local key-files for persistence, avoiding unintended interactions with the host operating system's keychain.

Changelog

• .changeset/fix-auth-keyring-backend.md
  • Added a new changeset file documenting the fix for keyring backend persistence.
• Cargo.lock
  • Updated package dependencies to reflect the new features enabled for the keyring crate and its transitive dependencies.
• Cargo.toml
  • Modified the keyring dependency to enable native platform-specific features for secure credential storage.
• src/credential_store.rs
  • Added a new helper function load_key_file to encapsulate key loading logic from files.
  • Refactored get_or_create_key to utilize the new load_key_file helper and include specific handling for test environments.
  • Introduced a new test default_keyring_backend_is_not_mock to verify that the keyring backend is not the mock implementation.

Activity

• The author, zssz, provided a detailed description outlining the bug, its motivation, and the proposed solution.
• The author completed a checklist of development best practices, including code formatting, linting, and adding tests.
• No further human activity, such as comments or reviews, has been recorded since the pull request's creation.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Generative AI Prohibited Use Policy, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request addresses a critical authentication persistence bug by enabling native keyring backends and refactoring credential loading. The changes enhance security by utilizing strong cryptographic primitives and secure file permissions, with no high or critical security vulnerabilities identified. My feedback focuses on improving the robustness of the new test to prevent potential issues in CI environments.

[github-actions]

/gemini review

[jpoehnelt]

Thanks for this PR! #359 has been merged which adds GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND and ensures .encryption_key is always preserved as a fallback. This PR's approach of enabling native keyring backends is complementary — it would fix why the keyring silently fails on macOS, while #359 ensures the fallback always works regardless.

Could you rebase this on top of the latest main (which includes #359) so we can evaluate the two together? The credential_store.rs has changed significantly.

[zssz]

Thanks for this PR! #359 has been merged which adds GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND and ensures .encryption_key is always preserved as a fallback. This PR's approach of enabling native keyring backends is complementary — it would fix why the keyring silently fails on macOS, while #359 ensures the fallback always works regardless.

Could you rebase this on top of the latest main (which includes #359) so we can evaluate the two together? The credential_store.rs has changed significantly.

I rebased the branch onto #359, kept this PR scoped to enabling the native keyring backends in Cargo.toml, and verified it locally. During verification, cargo test exposed a pre-existing race in auth_commands::tests::config_dir_returns_gws_subdir, where it could observe GOOGLE_WORKSPACE_CLI_CONFIG_DIR while another serialized test was mutating it. That is addressed in b0e72c5 by marking config_dir_returns_gws_subdir as #[serial_test::serial] as well.

Updated PR title and description aswell.

[github-actions]

/gemini review

[jpoehnelt]

/gemini review

[gemini-code-assist]

Code Review

This pull request correctly addresses a critical issue where authentication credentials were not being persisted securely due to the keyring crate silently falling back to an in-memory mock backend. By enabling the native keyring features in Cargo.toml, the application will now correctly use the host OS's secure storage, with a robust file-based fallback. The additional fix to serialize a test that was subject to a race condition is also a good catch and correctly implemented. The changes are well-executed and significantly improve the security and reliability of credential management.

[jpoehnelt]

D-Bus dependency: This introduces a build-time dependency on libdbus-1-dev for Linux (which is why CI is failing). Many of our users run

• gws in Docker/CI environments that don't have a D-Bus session bus available. How do you envision this working in headless environments? Should we gate the native backend behind a cargo feature flag so the file-only fallback (from feat(credential_store): add GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND env var #359) remains the default for minimal-dependency builds?

• Interaction with feat(credential_store): add GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND env var #359: PR feat(credential_store): add GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND env var #359 (now merged) added GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND=file for environments where the OS keyring is unreliable. Could you rebase on latest main and verify the two approaches work together? The key question is: when backend=keyring is selected and native backends are enabled, does the keyring actually round-trip correctly on macOS now, or does there need to be additional configuration?