Addon: Split GPG using GPG v2.1 architecture

[marmarek]

Reported by joanna on 8 Mar 2012 16:01 UTC
None

Migrated-From: https://wiki.qubes-os.org/ticket/474

[marmarek]

Comment by joanna on 31 Mar 2012 12:13 UTC
http://lists.gnupg.org/pipermail/gnupg-devel/2012-February/026573.html

[marmarek]

Comment by joanna on 31 Mar 2012 12:13 UTC
http://lists.gnupg.org/pipermail/gnupg-devel/2012-February/026573.html

[marmarek]

Modified by joanna on 8 Oct 2012 09:22 UTC

[marmarek]

Modified by joanna on 8 Oct 2012 09:22 UTC

[marmarek]

Modified by joanna on 2 Nov 2012 14:23 UTC

[marmarek]

Modified by joanna on 2 Nov 2012 14:23 UTC

[marmarek]

Modified by joanna on 8 Feb 2013 12:57 UTC

[marmarek]

Modified by joanna on 8 Feb 2013 12:57 UTC

[marmarek]

Modified by joanna on 24 Feb 2013 15:29 UTC

[marmarek]

Modified by joanna on 24 Feb 2013 15:29 UTC

[marmarek]

Comment by abel on 12 Mar 2013 09:51 UTC
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.

[marmarek]

Comment by abel on 12 Mar 2013 09:51 UTC
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.

[marmarek]

Modified by joanna on 12 Mar 2013 10:29 UTC

[marmarek]

Modified by joanna on 12 Mar 2013 10:29 UTC

[marmarek]

Comment by joanna on 12 Mar 2013 10:35 UTC
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...

[marmarek]

Comment by joanna on 12 Mar 2013 10:35 UTC
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...

[marmarek]

Modified by Nukama on 4 May 2013 16:06 UTC

[marmarek]

Modified by Nukama on 4 May 2013 16:06 UTC

[marmarek]

Modified by joanna on 1 Aug 2013 11:56 UTC

[marmarek]

Modified by joanna on 1 Aug 2013 11:56 UTC

[marmarek]

Modified by joanna on 20 Apr 2014 17:02 UTC

[marmarek]

Modified by joanna on 20 Apr 2014 17:02 UTC

[marmarek]

Modified by joanna on 20 Apr 2014 17:05 UTC

[marmarek]

Modified by joanna on 20 Apr 2014 17:05 UTC

[marmarek]

Comment by anonymous on 9 Nov 2014 19:10 UTC
GnuPG v2.1.0 has been released as 'modern' (stable).

Overview: https://www.gnupg.org/faq/whats-new-in-2.1.html
Announcement Email: http://lists.gnupg.org/pipermail/gnupg-announce/2014q4/000358.html

[marmarek]

Comment by anonymous on 9 Nov 2014 19:10 UTC
GnuPG v2.1.0 has been released as 'modern' (stable).

Overview: https://www.gnupg.org/faq/whats-new-in-2.1.html
Announcement Email: http://lists.gnupg.org/pipermail/gnupg-announce/2014q4/000358.html

[marmarek]

Fedora 22+ have gpg 2.1 packaged.
Related discussion: https://groups.google.com/d/msgid/qubes-devel/20150309013432.GA2361%40mail-itl
A prototype implementation done by HW42: https://git.ipsumj.de/hw42/qubes/split-gpg2.git (git only, no gitweb)

[marmarek]

Fedora 22+ have gpg 2.1 packaged.
Related discussion: https://groups.google.com/d/msgid/qubes-devel/20150309013432.GA2361%40mail-itl
A prototype implementation done by HW42: https://git.ipsumj.de/hw42/qubes/split-gpg2.git (git only, no gitweb)

[andrewdavidwong]

Just doing a routine check: Is it still correct that @rootkovska is assigned to this issue?

[andrewdavidwong]

Just doing a routine check: Is it still correct that @rootkovska is assigned to this issue?

[marmarek]

I would assign HW42, but he don't have github account...

[marmarek]

I would assign HW42, but he don't have github account...

[andrewdavidwong]

@marmarek: That's ok, I already have him assigned in the features tracker.

I'll update it to remove Joanna. (Should I remove you, as well, or are you working on this?)

[andrewdavidwong]

@marmarek: That's ok, I already have him assigned in the features tracker.

I'll update it to remove Joanna. (Should I remove you, as well, or are you working on this?)

[marmarek]

are you working on this?

No, I'm not.

[marmarek]

are you working on this?

No, I'm not.

[Vfreeze31]

Just curious, is this still an open issue or does the system now use GPG 2.1 branch?

[Vfreeze31]

Just curious, is this still an open issue or does the system now use GPG 2.1 branch?

[marmarek]

On Tue, Jun 07, 2016 at 09:57:35PM -0700, Iestyn Best wrote:

Just curious, is this still an open issue or does the system now use GPG 2.1 branch?

While we use GPG 2.1 (as it is in Fedora 23), split-gpg doesn't take
advantage of its new agent architecture. Take a look at linked PoC
above.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

On Tue, Jun 07, 2016 at 09:57:35PM -0700, Iestyn Best wrote:

Just curious, is this still an open issue or does the system now use GPG 2.1 branch?

While we use GPG 2.1 (as it is in Fedora 23), split-gpg doesn't take
advantage of its new agent architecture. Take a look at linked PoC
above.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

For ease of access, I've made a clone of HW42's repository on github: https://github.com/marmarek/split-gpg2

[marmarek]

For ease of access, I've made a clone of HW42's repository on github: https://github.com/marmarek/split-gpg2

[andrewdavidwong]

HW42:

What's the current status of this?

It's currently nearly unchanged since I created it. I have been using it
since then.

and what more needs to be done?

I wan't to change the way how the gpg-agent replacement on the client
side is started and by the way fix the case when the user doesn't answer
the accept dialog.

Marek proposed to ask per key. Currently it asks only once for all
accesible keys.

A qubes-builder Makefile needs to be added (packaging it self should be
(mostly) done).

It might be useful to reimplement it in python so it better fits into the
Qubes environment (for example rubys regex behave a litlle bit different
then pythons).

Are you still working on it?

As mentioned above it has been untouched since a while (especially the
last months I didn't had much time in general). But I'm still planing to
work on it.

[andrewdavidwong]

HW42:

What's the current status of this?

It's currently nearly unchanged since I created it. I have been using it
since then.

and what more needs to be done?

I wan't to change the way how the gpg-agent replacement on the client
side is started and by the way fix the case when the user doesn't answer
the accept dialog.

Marek proposed to ask per key. Currently it asks only once for all
accesible keys.

A qubes-builder Makefile needs to be added (packaging it self should be
(mostly) done).

It might be useful to reimplement it in python so it better fits into the
Qubes environment (for example rubys regex behave a litlle bit different
then pythons).

Are you still working on it?

As mentioned above it has been untouched since a while (especially the
last months I didn't had much time in general). But I'm still planing to
work on it.