All notable changes to this project will be documented in this file.

• Raised the cryptography floor to 50.0.0 for CVE-2026-69247 (GHSA-g6cj-pr64-35w5): PKCS#7 EnvelopedData decryption reported RecipientInfo failures in distinguishable ways, giving an application that reflects the outcome a Bleichenbacher oracle against the content-encryption key. GPG Meister does not decrypt PKCS#7 — cryptography is used only for AES-GCM and ChaCha20-Poly1305 in security/aead.py — so no released version was exposed. The bump keeps the dependency floor out of the affected range.

Unlock a key with a FIDO2 security key

Hardware tokens without the OpenPGP applet — the Security Key Series and other FIDO-only devices — can now take the place of a key passphrase. Enter the token's PIN, touch it, and the key opens. This needs no scdaemon, no pcscd, and no card reader; the only new dependency is fido2.

• A GPG key has one passphrase, so the token does not become it. The passphrase is a random secret, and each unlock method stores its own AEAD-wrapped copy: one slot sealed under the 32 bytes the token derives through the WebAuthn prf extension, one under Argon2id(emergency passphrase). Both yield the same secret, so enrolling a second token or retiring a lost one never rewrites the key. Same construction as version 3 vault key slots.
• Key creation offers Unlock this key with a security key. The passphrase is generated and never shown. An emergency passphrase is kept by default; dropping it produces a key only that token can ever open, and the dialog says so before the tick-box takes effect. Un-ticking the option re-arms the passphrase requirement, so the form cannot submit a key nothing can open.
• Existing keys can be bound to a token without being modified at all: the slot seals the passphrase the key already has. The passphrase is verified against the key first, so a slot can never hand back something GnuPG rejects.
• The Decrypt tab offers Decrypt with security key… once any key is enrolled. Derivation runs on a worker thread, because touching blocks for up to thirty seconds and a frozen window invites the user to unplug the token mid-operation.
• Recovered passphrases travel the existing hardened path — SecureBytes to an app-owned pipe to --passphrase-fd, never in argv — so no code in the encrypt, decrypt, or sign paths changed.
• Failures are separated by what the user must do about them: a missed touch (a YubiKey reports it with the same code as a refusal), a wrong PIN, a blocked PIN, a token that does not hold this key's credential, and missing Linux udev rules each say something different. A wrong PIN or missed touch stops immediately rather than trying the next enrolled token, because each retry spends another of the few attempts the token allows.
• Creating a key is ordered so it cannot leave one behind that nobody can open: if the slots cannot be stored after generation, the key — whose passphrase exists nowhere else — is deleted again rather than left in the keyring.

Documented in docs/security-key.md, including what this does not protect against: the private key stays on disk, so an OpenPGP card remains the stronger option where the hardware supports one.

Smartcard release: hardware tokens (YubiKey, Nitrokey, and other OpenPGP cards) can now hold the keys GPG Meister works with, and can act as a second way to unlock a vault backup.

Smartcard-held keys

• Keys whose private half lives on a token are recognised and labelled throughout the UI. A new Storage column on the Keys tab shows the device (YubiKey 12345678), with Local, Public only, and Secret key elsewhere for the other cases; the key details dialog and the signing-key pickers show the same information.
• Decrypting and signing with a card key ask for the card PIN instead of a passphrase, with the field, placeholder, and hint changing accordingly. The PIN travels the existing hardened path — SecureBytes to an app-owned pipe to --passphrase-fd, never in argv — because loopback pinentry lets gpg-agent ask us for the card PIN just as it asks for a passphrase.
• New Smartcard panel on the Keys tab shows the inserted card (device, serial, cardholder, reader, remaining PIN attempts) and the keys in its three slots, and links them into the app's isolated keyring. Slots whose public key is missing locally are called out, with the card's key URL when it has one.
• Card-specific failures are now distinguished from passphrase failures: an unplugged token or unavailable reader says so and asks for the token, and a rejected PIN warns that cards lock themselves after a few attempts.

Card management

• The smartcard panel can now change the user or admin PIN, unblock a locked user PIN with the admin PIN, move an existing private key onto the card, and generate a fresh key set on the device.
• These drive GnuPG's interactive editors through --command-fd, answering prompts by keyword rather than position, so a script that no longer matches a GnuPG version cannot answer the wrong question — notably "Replace existing keys?". An unscripted prompt aborts the run and reports which prompt was asked. --batch is dropped for these runs (GnuPG refuses its editors under it); loopback pinentry is kept, so PINs still never leave an app-owned pipe.
• Destructive actions are gated twice: the service refuses an occupied slot unless the caller passes an explicit overwrite flag, and the dialogs only pass it after the user types REPLACE. Moving a key also requires typing MOVE, since GnuPG leaves only a stub behind. Generating on-card keeps GnuPG's off-card backup of the encryption key on by default.
• Not verified against physical hardware — see docs/smartcard.md.

Vaults unlockable by a smartcard

• A vault can now be created with a token as an additional unlock method. Such vaults use format version 3: the payload is encrypted with a random file key that is wrapped once per unlock method ("key slot") — one slot for the master passphrase, one per selected token key. Opening the vault needs either.
• The master passphrase slot is written by default, so a lost or broken token cannot orphan a backup. Ticking Token only omits it, producing a vault the token alone can open; the option becomes available only once a token key is selected, and states plainly that losing the token destroys the backup.
• The vault import wizard offers "Smartcard PIN" as an unlock method when the file advertises one. Which methods a vault supports is read from its header alone, before any credential is entered.
• Vaults created without a token keep format version 2, byte-for-byte as before, so they remain readable by earlier releases.

• Field 15 of GnuPG's secret-key listing was read as "token serial" when it is in fact overloaded: + (secret key present locally), # (not available here), or a serial. Local keys were consequently flagged as stubs in the secret listing.
• The token serial is now carried into the public key listing as well, so smartcard-backed keys are recognisable everywhere instead of only in the secret listing. A serial that appears on a subkey (the common layout: offline primary, encryption subkey on the card) is attributed to its primary key.
• The smartcard panel explained why no token was found only when gpg happened to exit successfully. On the path GnuPG actually takes — exit code 2 — the cause was normalised to "no smartcard is available" before the panel saw it, so every specific hint was unreachable and the most common first-run failure, a missing scdaemon package, showed up as a bare "no token". GnuPG's own diagnostics now travel with the error.

• docs/smartcard.md names the tokens that work and the host packages needed. FIDO-only devices (the Security Key Series by Yubico) have no OpenPGP applet and cannot be used, and on Debian/Ubuntu scdaemon and pcscd are separate packages that gnupg does not pull in.

Security and quality release following a full multi-angle audit. No remotely exploitable vulnerabilities were found; the fixes below close locally-scoped weaknesses and harden defense-in-depth.