Would you use Windows-hosted GnuPG keys from WSL2?

[baliestri]

Pinentry for Windows v2.0.0 lets GnuPG in WSL2 show passphrase prompts on the Windows desktop. It does not make private keys stored by Windows GnuPG available to Linux GnuPG: signing and decryption still happen in the environment that owns the key.

I'm considering whether there is a real need to use Windows-hosted GnuPG keys from WSL2 without copying their private material into WSL. Before designing anything, I'd like to hear which workflows this would actually help.

Possible directions, not commitments

• A separate WSL command/profile could explicitly use the Windows gpg-agent through its restricted extra-socket, while regular gpg and its local WSL keys remain unchanged. The WSL profile would still need the corresponding public keys.
• A transparent proxy that selects the Windows or WSL agent by key would be more convenient, but routing stateful GnuPG agent sessions safely is substantially more complex.
• Calling Windows gpg.exe through WSL interop might cover some workflows, but would require interop and would not make a host key available to native Linux GnuPG.

None of these paths has been implemented or validated for this project. In particular, the current WSL pairing only authorizes pinentry prompts; it must not automatically authorize signing or decryption with Windows keys. An opt-in feature would need separate authorization and revocation. Windows Hello protecting a saved passphrase is not the same as approving each key operation, especially when gpg-agent has its own cache.

What would you need?

1. What concrete task requires a Windows-hosted key from WSL: Git commit signing, OpenPGP signing, decryption, a smart card, or something else?
2. Would an explicit command or per-repository gpg.program be sufficient, or must the same WSL gpg automatically choose between local and Windows keys?
3. Is importing public keys only into an isolated WSL profile acceptable?
4. Should Windows require approval for every remote signing/decryption operation, even if its GnuPG agent already has the passphrase or PIN cached?
5. Would optional WSL interop with Windows gpg.exe meet your needs, or do you need the operation to be initiated by native Linux GnuPG?

Please describe your workflow and the distribution/key type if relevant. A 👍 reaction is useful for gauging demand, but a concrete example will help determine whether this belongs in the project at all.