How GitPersona Stores Your Credentials Safely

GitPersona stores SSH keys and HTTPS tokens on your behalf, which means the storage model has to hold up to scrutiny. Here's exactly where secrets live, and — just as important — where they never do.

The core principle: secrets and metadata are separate

GitPersona's own data files never contain a secret. Not a token, not a private key, not in a config file, a log, or the activity history. What GitPersona's store keeps is metadata: host, username, protocol, timestamps, and whether a reveal PIN is set for credentials; algorithm, fingerprint, and file paths for SSH keys. The secret itself lives exactly one place — your operating system's native secure storage.

Where the secret actually lives

The mechanism is platform-specific, and GitPersona uses the real one on each OS rather than rolling its own:

• Windows — Windows Credential Manager, with entries written under a Git-readable target name so Git's credential helper can authenticate directly.
• macOS — the login Keychain, via Apple's Keychain Services.
• Linux — the Secret Service API over D-Bus, which covers GNOME Keyring, KWallet, and compatible providers.

There is no plaintext fallback for any of them. If a platform has no secure store available — a headless Linux session with no Secret Service provider running, for example — GitPersona reports credential storage as unavailable rather than writing the secret somewhere less safe. Failing closed here is a deliberate choice: a missing feature is recoverable, a secret written to disk in plaintext is not.

SSH keys stay where SSH expects them

SSH keys follow the same separation. GitPersona writes key pairs to disk and maintains a managed block of Host stanzas in ~/.ssh/config so the right key is picked up automatically — but the private key bytes are never copied into GitPersona's own data, serialized, or logged. What's tracked is a reference: algorithm, fingerprint, and the file path where the key already lives.

Reveal PINs and secrets in transit

A stored credential can carry an optional reveal PIN that gates reading the token back later. The PIN itself is never stored — only an Argon2 hash of it, kept in a side map separate from the credential record. Verifying the PIN is required before a reveal, and that reveal is the only operation that ever surfaces the secret to the interface.

While a token is being created or rotated, it exists briefly in a zeroizing buffer — memory that's overwritten as soon as it's no longer needed — before going straight to the OS vault. It's never written to a temp file or held longer than the operation requires.

Why this matters more because there's no server

GitPersona runs entirely on your machine, with no account and no server that sees your credentials. That's a strong property, but it only means something if local storage is actually held to a high bar. Using each platform's real secure storage — instead of an app-managed encrypted file — means credentials benefit from OS-level protections GitPersona doesn't have to reimplement, and get revoked or rotated the same way any other credential on your machine would be.