I’m having some difficulty setting up split GPG. I followed the guide, I believe exactly except for using ed25519 for the key by adding the options ed25519 cert and then using
gpg --quick-add-key <fingerprint of cert key> ed25519 sign
gpg --quick-add-key <fingerprint of cert key> ed25519 auth
But when I run gpg --sign or gpg2 --sign, I get:
gpg: no default secret key: No secret key
gpg: signing failed: No secret key
$ qubes-gpg-client-wrapper
ERROR: Destination domain not defined! Set it with QUBES_GPG_DOMAIN env variable.
$ QUBES_GPG_DOMAIN=@default qubes-gpg-client-wrapper
Request refused
EOF
My understanding is that QUBES_GPG_DOMAIN should not be set due to @default in the policy file:
qubes.Gpg2 + client @default allow target=gpg
It’s also my understanding that the split-gpg setup in the graphical interface is outdated and should be ignored?
No, thats not correct. The qubes policy file is only knowing by dom0. You have to set in the Qube the name of the target.
You can set the environment variable as usual or in the config file /rw/config/gpg-split-domain like that:
And why should the setting in the graphical interface being outdated? This setting is new in qubes 4.2 and is basically not more than a graphical setup of the mentioned policy file.
@murdock Thank you for your quick reply! I tried writing the GPG Qube’s name to /rw/config/gpg-split-domain in the client VM, and it had the same effect as running QUBES_GPG_DOMAIN=@default qubes-gpg-client-wrapper:
Request refused
EOF
The reason I presumed we should ignore the setting in the graphical interface, is because it differs from the one recommended in the manual. And the manual uses gpg2 while the graphical interface uses gpg.
Here is the policy file generated by the graphical interface:
qubes.Gpg * @anyvm gpg ask
vs the one recommended in the guide:
qubes.Gpg2 + client @default allow target=gpg
The latter actually should remove the need to tell the client which Qube it connects to using the @default target and target=gpg– That means that if the client Qube doesn’t specify a target, it will be sent to gpg.
I was just following the official guide as closely as I could, and I don’t see anything about /rw/config/gpg-split-domain. Which instructions are you following?
Hmm, checked current docu and see, thats mainly changed since i have config that for my system.
The old one, that i follows, was (for example) here also:
But i dont understand the difference between gpg and gpg2. Both of them links to the same binary and version:
gpg --version
gpg (GnuPG) 2.4.5
gpg2 --version
gpg (GnuPG) 2.4.5
gpgv2 --version
gpg (GnuPG) 2.4.5
In my fedora is /usr/bin/gpg2 only a symlink to /usr/bin/gpg and gpg itself IS gpg v2.
So i actually don’t understand the difference and also the reason, why these changes was made in qubes.
@murdock, sorry, I believe I should have said the manual uses split-gpg-2 rather than gpg2. IIUC, split-gpg was updated due to changes in gpg that allow a cleaner separation between GPG client and server. You can read about the reasoning at the top of the repository Readme.
Also, one thing I forgot to mention is installation attempt my setup starts to differ from the guide:
Hmm, that means, you have no private key in your gpg secring. So your GPG is correct with
gpg: no default secret key: No secret key
gpg: signing failed: No secret key
But then i dont understand, why you use the qubes-gpg-client-wrapper, because that script is part of the “old” split-gpg method.
According to the documentation, that you mentioned, call of gpg in the client qube should be enough instead of gpg-client-wrapper.
This should be enough to have it running:
gpg-client-vm$ gpg -K
/home/user/.gnupg/pubring.kbx
-----------------------------
sec# rsa2048 2019-12-18 [SC] [expires: 2021-12-17]
50C2035AF57B98CD6E4010F1B808E4BB07BA9EFB
uid [ultimate] test
ssb# rsa2048 2019-12-18 [E]
After a little bit playing with split-gpg2 i have found something:
the documentation lacks of the information, that in dom0 split-gpg2-dom0 must be installed prior to configure split-gpg2. That package installs the mentioned policy file also.
thunderbird seems not to work with split-gpg2, nevertheless gpg -K shows me the private key, thunderbird does not find any private key. The thunderbird part, that was in the “old” split-gpg docu has disappeared (because that problem?) So currently we dont have any official documentation for thunderbird + split-gpg, what maybe the most important task of gpg blocks, the encryption of mails.
split-gpg2 creates new folders inside the .gnupg folder in the gpg server domain and uses that folder. Both folders are not synchronized, so gpg -K in the gpg-server-domain and gpg -K in the gpg-client-domain are not identical, both access different sets of keys.
At the end of the day, split-gpg2 looks not practically usable in the current state. @QUBES-Team: Please restore the old documentation for split-gpg with the setup for thunderbird.
Addition: Maybe my problems with gpg2 are caused by the fact, that i use a smartcard (more exactly a yubikey), that holds my gpg keys. So i dont have the secret keys in filesystem in the gpg vault, instead the vault holds only links to the secret keys on the card. That works with the “old” split gpg perfectly, but does’n’t work with the split-gpg2.
I installed split-gpg2-dom0 in dom0, powered off my client VM, disabled and re-enabled the split-gpg2-client service for it and powered it back on and get the same result: gpg -K shows no output, and nothing appears in the qrexec log for the client VM.
As for split-gpg2 allowing access to only a subset of keys. I understand this is a security measure to prevent malicious Qubes from extracting your master key, but if users want that, wouldn’t it make sense to store the master key in a different Qube than the everyday use keys? That seems both more secure and simpler. I agree with @murdock that not having the gpg wrapper mimic the behavior of gpg is likely to make life difficult for some people.
Thanks a lot @unman! The reverted docs seem to work for me.
I just want to add that gpg does seem to be designed to work with the master key on one machine and subkeys on another. From the manpage:
--export-secret-keys --export-secret-subkeys
…
The second form of the command has the special property to render the secret part of the primary key useless; this is a GNU extension to OpenPGP and other implementations can not be expected to successfully import such a key. Its intended use is in generating a full key with an additional signing subkey on a dedicated machine. This command then exports the key without the primary key to the main machine. GnuPG may ask you to enter the passphrase for the key. This is required, because the internal protection method of the secret key is different from the one specified by the OpenPGP protocol.
So simply storing the master key on a separate VM may be better than a home-rolled solution.