Addon: Split GPG using GPG v2.1 architecture

[joanna]

​http://lists.gnupg.org/pipermail/gnupg-devel/2012-February/026573.html

[abel]

I've investigated this a bit more and here are my findings.

1. This is blocking on a release of Gnupg 2.1, and possibly subsequent distro packaging

I've been using the gnupg 2.1 git branch for some time as part of my Android porting work, and it is quite stable. It is up to the Qubes devs if this issue is important enough to consider compiling a gnupg 2.1 package from source.

2. Version 2.1 is necessary due to fundamental changes in the way gpg2 and gpg-agent work

In the 2.1 series, gpg-agent will be the sole holder of all public+private key material, and the gpg2 client will merely interface with gpg-agent over a UNIX domain socket.

3. The socat utility will let us bridge gpg-agent and gpg2 over the Qubes rpc system

At Marek's suggestion I investigated socat as a way to proxy the gpg2<->gpg-agent domain socket connection through Qubes' RPC. If I have more time I'll setup a working example between two VMs running hot'n'fresh 2.1.

[joanna]

I don't think it would be a problem to keep GPGv2.1 e.g. as a subrepo of gpg-split.git.

However, what I don't like in your description above is that you wrote: "gpg-agent will be the sole holder of all public+private key material". The fundamental problem with current implementation is that one needs to import public keys (untrusted files!) into the secure vault where gpg backend is running. And this is what we want to get rid of, and my mail to gunpg-devel, referenced above, was exactly about how to achieve that. Now, when you say that gpg-agent is maintaing both secret and public keys, I don't see how we can gain anything from v2.1? And this seems contradictory to Werner Koch wrote in this thread: "GnuPG-2 has been designed to separate private key and public key operations.". Also note that he mentiones v2, not v2.1...