Skip to content
GitPersonaGitPersona

Credential storage

GitPersona is built so that secret material and the metadata describing it are kept strictly apart. This page explains exactly where each lives.

The core principle

Secrets are separated from metadata. A token is never stored in GitPersona's own data files, never serialized into its store, and never written to logs or the activity history.

Warning: GitPersona does not store tokens in plaintext anywhere. If a guide ever suggests otherwise, treat it as incorrect.

Where secrets live

The secret itself is held in the operating system's native secure storage. GitPersona reads from and writes to that store; it does not keep a second copy. The mechanism is platform-specific:

  • Windows — Windows Credential Manager. Entries use a Git-readable target name, so Git can authenticate directly.
  • macOS — the login Keychain (Apple Keychain Services).
  • Linux — the Secret Service API (GNOME Keyring, KWallet, or any compatible provider) over D-Bus.
Warning: There is no plaintext fallback. If no secure store is available on the platform — for example a headless Linux session with no Secret Service provider running — GitPersona reports credential storage as unavailable rather than writing the secret anywhere less safe.

What metadata is kept

GitPersona's credential store keeps only non-secret metadata, so the app can list and manage credentials without ever holding the secret:

  • host and username
  • protocol (HTTPS)
  • created, updated, and last-used timestamps
  • whether a reveal PIN is set
  • the profile the credential is attached to, if any

Reveal PINs

A credential may have an optional reveal PIN that gates reading the token back. The PIN is stored only as an Argon2 hash in a side map — never in the credential record and never on the wire. Revealing a token requires verifying the PIN, and the reveal is the single operation that ever surfaces secret material to the interface.

Secret handling in transit

While a token is being created or rotated, it exists only briefly in a zeroizing buffer that overwrites its memory as soon as it is no longer needed, then goes straight to the vault. See Credentials for the day-to-day workflow.