Qubes OS: Do not use Keybase's keyring. Aka, "keybase config set gpg.command qubes-gpg-client"

Directly related to the concerns and issues in #4722, we need a way to use Keybase without importing our private key into keybase's keyring. Even subkeys still run the risk of exploitation.

I'm still unclear as to why keybase needs the private key to begin with if it has the ability to set the gpg command?

keybase config set gpg.command qubes-gpg-client

I know it imports the private key into its own keyring - but why? to validate my machine? why can't we use the gpg.command to sign the messages, not keybase's own keyring?

I am wondering if it has something to do with adding new machines. i didn't import my private key onto my mobile device; however, I am able to send encrypted messages from my mobile device after I validate my mobile device from my PC.

I think this is using keybase's new protocols - perhaps with their own key, as long as the device was validated by another trusted device.

Perhaps I am missing some advanced configuration for users that do not want to import their private key or subkey into Keybase's local keyring? Even if it isn't transmitted, it's still exploitable from the local VM in several ways - which goes against the Qubes PGP isolation model.

I am trying to avoid setting up an entire VM decided only to Keybase. That seems like a huge waste of system's resources, memory and disk usage - just to run a single keybase application.

Start with the issue's keybase config set gpg.command qubes-gpg-client entry point and the concerns documented in #4722. Determine whether Keybase can sign through that command without importing a private key or subkey into its local keyring. Done means the Qubes workflow is supported without requiring a dedicated Keybase VM.