Optional keyring support for API token

[alcxyz]

Currently the API token is stored as a plaintext file with 0600 permissions. Consider optional system keyring integration (e.g. via go-keyring) for users who prefer it.

Low priority — current approach is standard and matches tools like gh, rclone, docker.

[alcxyz]

Implementation notes

Library

Use github.com/zalando/go-keyring — wraps macOS Keychain, Linux Secret Service (libsecret), and Windows Credential Manager.

Linux desktop compatibility

go-keyring uses D-Bus Secret Service API, which requires a provider running:

• GNOME: gnome-keyring-daemon (usually running)
• KDE: kwallet (usually running)
• Hyprland / wlroots / minimal WMs: No provider by default. Options:
  • Run gnome-keyring-daemon standalone (one line in home-manager)
  • Use KeePassXC (exposes Secret Service over D-Bus)
  • Use pass (GPG-based, no daemon needed, but needs a separate backend — go-keyring doesn't support it)

Proposed config

# "auto" | "keyring" | "pass" | "file"
token_storage = "auto"

• auto: try keyring → fall back to file
• keyring: require D-Bus Secret Service
• pass: use pass CLI (GPG-encrypted, no daemon)
• file: current behavior (~/.config/paperflow/token with 0600)

Token lookup order

CLI flag --paperless-token-file > keyring/pass > file

New commands

• paperflow token set — store token in configured backend
• paperflow token get — retrieve and print token
• paperflow token delete — remove from keyring
• paperflow init would offer keyring storage when available

Trade-off

go-keyring adds CGO dependency on Linux (for libsecret). Could use a build tag (-tags keyring) to keep default binary CGO-free, or just accept it since most desktop Linux has libsecret.