Many of us enjoy developing in Linux. But using Linux as our primary operating system is not always an option. For me, that means working on a Windows desktop while also spending a lot of time in Linux tools and WSL2.
One small part of that setup kept bothering me: GnuPG passphrase prompts on Windows.
On Linux, you can use a graphical pinentry that fits your desktop environment. macOS has options that feel at home there, too. In my Windows GnuPG setup, pinentry-basic.exe worked, but its prompt looked disconnected from the rest of the operating system. The problem was not that it failed to ask for a passphrase—it did that job. I wanted the prompt to look and behave like a Windows prompt.
That was the starting point for Pinentry for Windows, or PFW: a GnuPG pinentry that opens the Windows Security credential window.
The screenshot uses a fictional signing identity. In use, GnuPG supplies the description shown in the window.
A different problem appeared in WSL2
I also use GnuPG from WSL2. There, a passphrase request commonly appears through a terminal or shell pinentry. That makes sense for a Linux terminal, but when my desktop is Windows, I wanted the option to show the prompt on that desktop instead.
PFW v2.0.0 adds a Linux relay for this case. The WSL2 gpg-agent launches the relay as its pinentry; an authenticated bridge opens Windows Security in the interactive Windows session.
Notice the [archlinux] label: the window identifies the paired distribution that requested the prompt.
The private key stays in WSL2. Signing and decryption still happen in its GnuPG environment. Only the pinentry request and response cross the bridge, over TLS 1.3 and Hyper-V/vsock with paired certificates. WSL does not need to launch a Windows .exe.
This also means something PFW does not do: it does not make keys stored by Windows GnuPG available to Linux GnuPG. I’m asking users whether they need that separate feature before considering a design for it.
Optional caching with Windows Hello
For an eligible software-key passphrase, you can choose Remember me. The persistent cache is opt-in, and each time PFW retrieves a saved passphrase it requires a fresh Windows Hello verification.
Windows Hello here protects access to the optional cache; it does not replace GnuPG or authorize every signature. Smart-card and hardware-token PINs are never placed in this persistent cache.
Trying it
The v2.0.0 release provides Native AOT executables for Windows and Linux on x64 and ARM64, along with SHA-256 checksums. It requires Windows 11 24H2 or newer. You only need the .NET SDK if you plan to build from source.
To set up the Windows pinentry, run in PowerShell 7:
irm 'https://exec.baliestri.dev/pfw-setup.ps1' | iex
WSL2 requires additional broker registration and certificate pairing. The README has the complete steps, plus screenshots, troubleshooting, and uninstall instructions.
PFW is open source. If you use GnuPG on Windows or WSL2, I’d like to know what you currently use for passphrase prompts—and whether this approach feels more at home on your desktop.
Top comments (0)