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

[zssz]

Description

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

Motivation:
#359 added GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND and made .encryption_key a durable fallback, but it did not change how the keyring crate itself is compiled. The remaining issue was that keyring could still silently fall back to its in-memory mock backend on platforms where we intended to use the native OS keyring.

What this PR changes:

• Enables native keyring backends only on supported desktop targets:
  • macOS: apple-native
  • Windows: windows-native
  • other targets: plain keyring
• Keeps #359's file fallback behavior intact for Docker, CI, and other headless/minimal environments.
• Regenerates Cargo.lock so the Linux D-Bus-related dependencies introduced by the earlier approach are no longer part of this PR.
• Marks auth_commands::tests::config_dir_returns_gws_subdir as serial to avoid a race with other tests mutating GOOGLE_WORKSPACE_CLI_CONFIG_DIR during local verification.
• Updates the automation workflow so the Gemini Reviewed job does not hard-fail on fork PR review events when GitHub provides a read-only token.

Why this fixes it:

• On macOS and Windows, backend=keyring now compiles against a real native backend instead of risking the in-memory mock backend.
• On Linux and other non-desktop targets, the default build stays minimal and continues to rely on #359's file-based fallback path.
• The workflow fix prevents unrelated automation failures from masking the actual CI state for forked PRs.

Note on Cargo.lock:
The lockfile changed because the dependency graph is now target-specific. After regenerating it, the Linux D-Bus-related crates from the previous approach are no longer part of this branch.

This does not add 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 backend compilation, test isolation, and workflow behavior; 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: 11fdc10

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?

[googleworkspace-bot]

/gemini review

[zssz]

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?

Implemented in fb45eaa.

I changed keyring to use target-specific features:

• macOS: apple-native
• Windows: windows-native
• other targets: plain keyring with no extra native backend features

That keeps #359’s file fallback as the default minimal path for Docker/CI/headless environments, while still fixing the macOS case where backend=keyring could silently use the mock backend.

I also regenerated Cargo.lock, which removes the Linux D-Bus-related dependency additions from this PR.

[gemini-code-assist]

Code Review

This pull request correctly enables native keyring backends for macOS and Windows by using target-specific dependencies in Cargo.toml. This change addresses a critical issue where credentials could be silently stored in an in-memory mock backend instead of the secure OS store. The implementation is sound and follows best practices for platform-specific features in Rust. Additionally, the pull request includes a fix for a test race condition in src/auth_commands.rs by correctly marking a test that interacts with environment variables as serial. The changes are well-explained and improve the security and reliability of credential storage.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 64.39%. Comparing base (7e22a3d) to head (11fdc10).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #373      +/-   ##
==========================================
- Coverage   64.40%   64.39%   -0.02%     
==========================================
  Files          38       38              
  Lines       15584    15583       -1     
==========================================
- Hits        10037    10034       -3     
- Misses       5547     5549       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[googleworkspace-bot]

/gemini review

[gemini-code-assist]

Code Review

This pull request correctly enables native keyring backends for macOS and Windows by using target-specific dependencies in Cargo.toml. This resolves the issue where the keyring crate could silently fall back to a non-persistent in-memory store. The changes are well-structured and directly address the motivation described. Additionally, the pull request includes a fix for a test race condition by serializing a test that modifies shared environment state, which is the correct approach. The changes look solid and improve the credential storage mechanism as intended.

[googleworkspace-bot]

/gemini review

[gemini-code-assist]

Code Review

This pull request addresses an issue where the keyring crate could silently fall back to a mock in-memory store on macOS and Windows. The fix uses target-specific dependencies in Cargo.toml to enable native keyring backends on these platforms. Additionally, a test is marked as serial to prevent race conditions related to environment variables, which should improve test suite stability. The changes appear correct and align with the pull request's goals.

[zssz]

@jpoehnelt should we move this forward? Let me know if you think it needs more changes.