Linux 0.9.1: encrypted credentials become undecryptable on same machine after key-storage change

[mkrueger12]

Summary

On Linux, gws 0.9.1 can end up with unreadable encrypted OAuth credentials even though credentials.enc exists and the CLI previously authenticated successfully.

Current failure:

{
  "error": {
    "code": 401,
    "message": "Authentication failed: Failed to decrypt credentials: Decryption failed. Credentials may have been created on a different machine. Run `gws auth logout` and `gws auth login` to re-authenticate.",
    "reason": "authError"
  }
}

And gws auth status reports:

• encrypted_credentials_exists: true
• encryption_valid: false
• encryption_error: "Could not decrypt. May have been created on a different machine."
• plain_credentials_exists: false

This looks like the same bug family as #27, but on Linux with 0.9.1 after the recent key-storage changes.

Environment

• OS: Debian GNU/Linux 13 (headless-ish environment)
• gws: 0.9.1
• DBUS_SESSION_BUS_ADDRESS is present
• libsecret-1-0 is installed
• no visible gnome-keyring-daemon process
• ~/.config/gws/credentials.enc exists
• ~/.config/gws/.encryption_key does not exist

Evidence

gws auth status:

{
  "auth_method": "oauth2",
  "client_config": "/home/max/.config/gws/client_secret.json",
  "client_config_exists": true,
  "encrypted_credentials": "/home/max/.config/gws/credentials.enc",
  "encrypted_credentials_exists": true,
  "encryption_error": "Could not decrypt. May have been created on a different machine.",
  "encryption_valid": false,
  "plain_credentials": "/home/max/.config/gws/credentials.json",
  "plain_credentials_exists": false,
  "storage": "encrypted"
}

And an API call fails with:

{
  "error": {
    "code": 401,
    "message": "Authentication failed: Failed to decrypt credentials: Decryption failed. Credentials may have been created on a different machine. Run `gws auth logout` and `gws auth login` to re-authenticate.",
    "reason": "authError"
  }
}

Why this looks like a regression

Issue #27 was fixed by #28 (fix(auth): stabilize encrypted credential key fallback).

But 0.9.1 includes:

• 5872dbe: Stop persisting encryption key to .encryption_key file when OS keyring is available. Existing file-based keys are migrated into the keyring and the file is removed on next CLI invocation.

On this Linux machine, there is no .encryption_key fallback file anymore, and the stored encrypted credentials are no longer decryptable. That suggests the CLI believed the OS keyring was stable/available at write time, but a later process could not retrieve the same key reliably.

Suspected cause

The Linux keyring availability check may be too optimistic in some environments:

• write path succeeds via an OS-keyring code path,
• fallback .encryption_key is removed / never written,
• subsequent process cannot retrieve the same key,
• credentials.enc becomes effectively unreadable.

This may be specific to headless Linux / DBus / Secret Service combinations where keyring access is partially available but not stable across invocations.

Expected

If the OS keyring is not reliably available on Linux, gws should preserve a stable fallback instead of leaving credentials.enc unreadable.

Actual

credentials.enc exists but cannot be decrypted on the same machine, causing all authenticated commands to fail.

Request

Could you confirm whether 5872dbe introduced a Linux regression here, and whether Linux should retain .encryption_key fallback unless keyring retrieval is proven stable across fresh processes?

[GiGurra]

same happens on macos. tried re-authing, says it's successful, but in the end doesn't work. I get the exact same error for all commands that you have

[tvvignesh]

I get the same error when running gws auth export --unmasked > gws_credentials.json on a mac - i had initially tried it on a linux headless server