Should I mark/announce GNOME as incompatible with gpg2 for now?

[Stef Walter]

On 28.08.2014 15:30, Werner Koch wrote:
> On Thu, 28 Aug 2014 12:46, stef at thewalter.net said:
> 
>> It seems that you don't want gpg2 used with GNOME 3.x as is (in its
>> default configuration).
> 
> No, I want you to change the default configuration - I told you that
> over lunch during last years FOSDEM.  This mess is going on for many
> years now and a lot of people are annoyed.  Fortunately most users of
> GnuPG's S/MIME feature are using KDE and not GNOME and thus are not
> affected by that hijacking.  With 2.1 OpenPGP users will also be
> affected and thus I escalated this issue using the new warning.

Sorry I don't have time to work on this myself in the near future. The
gnome-keyring GPG agent stuff was written for GPG 1.4.x ... and the GPG
2 came around which changed (and is still changing) things
significantly. Fair enough, bit this is hardly as one sided as it might
seem.

It seems nobody cares enough about using those GPG 2.x features (which
depend on the real gpg-agent) to actually contribute a fix for this. I'd
be overjoyed at such a contribution and would help review and merge it.

>> Should I go ahead and announce that gpg2 (version 2.0.23+) is
>> incompatible with GNOME and people should USE gnupg 1.4.x with GNOME 3.x
> 
> The warning message says it all: GKR is hijacking the IPC between
> components of GnuPG - you don't have to mess with that!  Shall I start
> to encrypt and authenticate the IPC just to make it harder for GKR to
> mess with it - that would be a silly game.

This is not about a power trip or outsmarting each other or anything
like that. I'm looking for someone to help contribute a fix.

Until someone does have time to work on this ... it's obvious
gnome-keyring's gpg agent is only meant for gpg 1.4.x .... and we should
probably hard code that in during the build process.

>> I know Werner and I discussed solutions to this issue a more than a year
>> ago, but obviously neither of us has had enough time to make the changes
> 
> I tried to implement what we discussed but came to the conclusion that
> this won't work.  You simply can't have two daemons competing about
> cached items.  The caching is an integral part of GnuPG and any hacks
> around it would only trigger other bugs.

Fair enough. But why didn't you say something about this conclusion? Did
I miss an email or mailing list post about this? If so, could you link
to it?

>> a. gnupg needs to integrate with GNOME 3 (prompt via gnome-shell, and
>>    give the option to save passwords in the keyring) and gnome-keyring
> 
> There are no passwords to save.  You do not want to do that by default.
> If users figure out a way to do that anyway, they may do that but we
> should not make it too easy for them.  Recall that we are talking about
> passphrases to protect a private key and not about passphrases used in
> any authentication or encryption protocol.

This is not a default setting, but many users want to effectively unlock
one or more GPG keys when they unlock their machine. Optionally storing
the passphrases to protect the private key in the keyring allows for this.

>> I'd far prefer option (a) above. Any takers for implementing either one
>> of the above?
> 
> There is also a
> 
>  c) Write a Pinentry using the documented interface between gpg-agent
>     and Pinentry and make use of it.  If you don't want any caching,
>     well, you may disable caching in gpg-agent.conf.  The Guardian
>     Project actually used this custom Pinnetry approach to have a better
>     integration with the rest of the Java based Android GUI.  It is
>     easy: You already have a running daemon, you only need to write a
>     Pinentry connecting to that daemon.

True ... as long as it can cover all the features. I'm not against this
option either.

Cheers,

Stef