Upgrading to 0.24.5 silently invalidates existing authentication (AUTH_004 until re-login)

[ryancheley]

Summary

After upgrading youtrack-cli from 0.24.4 to 0.24.5, every authenticated command fails with
❌ Not authenticated [AUTH_004] even though the stored credentials from 0.24.4 are still on
disk / in the keyring. The security remediations in 0.24.5 (#740–743 / PR #744) appear to have
changed credential handling so the previously-stored token can no longer be read. The only fix
is to run yt auth login again.

If the re-login is intended (e.g. the old storage was insecure and must be re-written), the
release notes / an upgrade notice should say so explicitly. If it's not intended, it's a
credential-read regression.

Reproduction

1. Authenticate on 0.24.4 (yt auth login), confirm yt issues list --project-id X works.
2. Upgrade to 0.24.5 (uv tool upgrade youtrack-cli).
3. Run any authenticated command:

$ yt auth status
❌ No authentication credentials found [AUTH_004]
Run 'yt auth login' to authenticate first.

$ yt issues list --project-id NGDEV --format json --top 3
❌ Not authenticated
❌ Error listing issues: Failed to list issues

What survived the upgrade (so the token isn't gone, just unreadable)

• ~/.config/youtrack-cli/.env intact: YOUTRACK_BASE_URL present, YOUTRACK_API_KEY='[Stored in keyring]'.
• macOS keyring still has entries under service youtrack-cli.
• But 0.24.5's own loader can't read it:

from youtrack_cli.auth import AuthManager
AuthManager().load_credentials()   # -> None on 0.24.5
                                   #    (returned the AuthConfig with a valid token on 0.24.4)

yt auth login re-stores the credential and everything works again on 0.24.5.

Impact

• Silent break on upgrade: the credentials look present, but every command fails until re-login.
• The runtime error (AUTH_004 / Failed to list issues) doesn't explain that an upgrade
  invalidated the token, so it's easy to misdiagnose as a network/permission problem.

Suggestions

• If intentional: add an upgrade note in the 0.24.5 release notes and, ideally, a one-time
  migration message ("credential storage changed in 0.24.5 — please run yt auth login").
• If unintentional: restore read-compatibility with credentials written by ≤0.24.4, or migrate
  them on first run.
• Consider making yt auth status distinguish "no credentials" from "credentials present but
  unreadable/incompatible" to aid diagnosis.

Context

Surfaced via a downstream tool that shells out to yt issues list --format json; the upgrade
broke it purely through this auth change (the JSON/query surface itself is unaffected).

[github-actions]

Profile summary:

GitHub user: ryancheley
🟢 No concerns found with user's profile.
🟢 No concerns found with recent PR activity.
🟢 No concerns found with recent issue activity.

For a more detailed report, run `gh-profiler ryancheley`.

[ryancheley]

Investigated — this is not a code regression in 0.24.5, and the credential-read path is unchanged. Evidence:

1. Diff: the credential storage/read code (security.py, config.py, models.py) is byte-identical between v0.24.4 and v0.24.5. The only auth.py change in 0.24.5 is the new http:// cleartext warning inside verify_credentials() — a different method that is not on the load_credentials() path.
2. Dependencies: uv.lock changed only the youtrack-cli version line; no dependency (keyring, pydantic, cryptography) version moved. A uv tool upgrade resolves runtime deps from pyproject, which also didn't change.
3. Empirical: an in-process keyring store→load round-trip on 0.24.5 returns the token correctly — the loader reads what it writes.

What actually causes the symptom: macOS Keychain items are access-bound (ACL) to the specific binary that created them. uv tool upgrade youtrack-cli rebuilds the tool's virtualenv with a new python binary path, so the OS keychain no longer grants the new binary access to the token stored by the old one. keyring.get_password(...) returns None → load_credentials() returns None → AUTH_004, even though the entry is still in Keychain. Re-running yt auth login re-stores it under the new binary, which is why that fixes it. This can happen on any upgrade/move that relocates the binary, not specifically 0.24.5.

Fix (PR #747): implements your third suggestion — yt auth status now distinguishes "no credentials" from "stored but unreadable" and tells you to re-run yt auth login, so this stops being misdiagnosed as a network/permission problem:

⚠ Credentials are stored in the system keyring but can't be read.
This can happen after upgrading or moving the CLI — the OS keychain may no longer grant the new binary access to the saved token.
Run 'yt auth login' to re-store your credentials.

Not pursuing a "credential migration" since there's no format/read change to migrate from — the stored data is identical and readable; the OS access grant is the moving part.

[ryancheley]

Root cause identified (from the logs) — and fixed in 0.24.6

Digging into ~/.local/share/youtrack-cli/youtrack-cli.log on 0.24.5 showed this wasn't a plain "upgrade invalidated my token" — it was two bugs in the credential/token security code that made auth unreliable shortly after every yt auth login (it would work right after login, then fail on the next invocation):

1. Credential decryption failed outright:

youtrack_cli.security.credentials - ERROR -
  {'error': 'Fernet key must be 32 url-safe base64-encoded bytes.',
   'event': 'Failed to decrypt credential'}

The Fernet key for the stored credential was malformed, so the token couldn't be decrypted back.

2. The expiry check was self-contradictory — every check logged both of these for the same token:

youtrack_cli.security.tokens - ERROR   - {'event': 'Token expired',        'expiry_date': 2026-07-08 20:36:39}   # ~1 day in the PAST
youtrack_cli.security.tokens - WARNING - {'event': 'Token expiring soon',   'days_until_expiry': 4}               # ...but also 4 days out

So it simultaneously believed the (permanent) token expired ~24h ago and expires in 4 days. The expiry_date came out ~24h in the past on every call — looks like a naive-vs-timezone-aware datetime comparison (the log rows pair a local 20:36:39 with a UTC …03:36:39Z field).

Status

Upgrading to 0.24.6 resolves it — auth now persists and decrypts correctly across invocations (verified end-to-end against a live instance). So whatever changed between 0.24.5 → 0.24.6 fixed the Fernet-key handling / expiry logic.

Filing this detail in case it's useful for a regression test around credential encryption + token-expiry comparison, so a future security change doesn't reintroduce it. Happy for this to be closed as fixed-in-0.24.6.