credential_store: .encryption_key file persists on disk even when OS keyring succeeds

[jpoehnelt]

Bug

get_or_create_key() in src/credential_store.rs unconditionally writes the encryption key to ~/.config/gws/.encryption_key on first run, before attempting to store it in the OS keyring. The file is never cleaned up after a successful keyring store.

This means on a macOS machine with a fully functional Keychain, the encryption key exists in two places:

1. macOS Keychain (protected by login credentials / biometrics)
2. ~/.config/gws/.encryption_key (protected only by file permissions 0600)

Impact

The file-based key makes credential files portable — copying the entire ~/.config/gws/ directory to another machine transfers both the encrypted credentials and the key needed to decrypt them, defeating the purpose of keyring-based key storage.

Root Cause

In credential_store.rs lines 64–120, the Err(keyring::Error::NoEntry) branch:

1. Generates a random 256-bit key
2. Writes it to .encryption_key (lines 102–115)
3. Then does best-effort entry.set_password() (line 118)

The file write happens unconditionally regardless of whether the keyring store succeeds.

Proposed Fix

Only write .encryption_key as a fallback when the keyring is unavailable:

// Generate key
let mut key = [0u8; 32];
rand::thread_rng().fill_bytes(&mut key);
let b64_key = STANDARD.encode(key);

// Try keyring first
if entry.set_password(&b64_key).is_err() {
    // Keyring failed — persist to file as fallback
    write_key_file(&key_file, &b64_key);
} else {
    // Keyring succeeded — clean up any stale file
    let _ = std::fs::remove_file(&key_file);
}

Verification

ls -la ~/.config/gws/.encryption_key
# Should NOT exist on systems with a working keyring

[jpoehnelt]

The fix should also handle migration for existing users: when the keyring read succeeds (the Ok(b64_key) branch at line 53), clean up any stale .encryption_key file:

Ok(b64_key) => {
    // Keyring has the key — remove redundant file copy if present
    let _ = std::fs::remove_file(&key_file);
    // ... decode and return
}

Since get_or_create_key() runs on every CLI invocation, existing users who upgrade will have the file removed automatically on their next run — no separate migration step needed.

[capi]

I'm not sure if it's my setup, but now running inside a (Linux) Docker container without a working keyring, I get neither an entry nor the legacy .encryption_key, resulting in the credentials.enc no longer being able to be decrypted and the whole application stopped working. Used to work prior to 0.9.1 where this change was released.

[jpoehnelt]

can you file a bug for this

[jpoehnelt]

reopening. i'm working on a fix

[jpoehnelt]

Looks like it cleaned up the fallback key in one scenario when it shouldn't have. Will need to downgrade and login again.