On 08/15/13 11:24, ix4...@gmail.com
> On 15 August 2013 08:30, Alex <ix4...@gmail.com
>> On Friday, August 9, 2013 6:15:37 PM UTC+1, Abel Luck wrote:
>>>> I found https://alexcabal.com/**creating-the-perfect-gpg-**keypair/
>>>> think describes the scenario you have in mind. Just treat your
>>>> AppVMs as the "laptop" of the blog post. Appears to work ok, not sure
>>>> keysigning, interaction with keyservers etc. If I ever understand how
>>>> whole mess works, I might even do a writeup. Just so that I never, ever
>>>> have to figure this out again!
>>> I maintain a document that describes how to do this:
>>> It is not Qubes OS specific, and in fact assumes you want to use a
>>> smartcard, which might not be the case, so skip those bits.
>>> Also, use your vault vm instead of booting into an offline livecd as
>> Thanks for this abel - I see that figuring out how to sign other people's
>> keys is on the TODO list :-)
>> I have a setup that works for me now, but it seems that signing other
>> people's keys and uploading to the keyserver will be a long and tricky
>> process... Is anyone using this setup on a day to day basis and can advise
>> on how to make signing other people's keys reasonably usable?
> I think we're getting closer here -
describes a setup
> that seems quite usable with a traditional OS and a USB key.
> But, that method requires
> (a) networking from "vault"
> (b) mounting "vault"'s filesystem from an untrusted day-to-day AppVM
> Both of these are no-no's in QubesOS
I think such assumptions are no-no's in any reasonable environment
(including air-gapped). A vault that is network-connected is... not a
vault really. A vault whose filesystem is accessible by untrusted
entities... come on, is it a joke, or something?
> closer to a QubesOS setup, as it talks about a properly isolated
> environment (similar to the QubesOS vault), but does not explain what to do
> after you've signed someone else's key. How do you update your regular
> day-to-day keyring so that it knows the public key you signed is now
The problem is that the gpg in the vault should not be forced to process
any external (so untrusted) input. Copying somebody's else key there is
just breaking of all the security model that a air-gapped gpg can
provide to you.
So, generally not only you should not try to sign other keys in your
vault, you should not even import them there. More thoughts on this in
the ticket description and the thread linked from there: