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

[Ximin Luo]

On 29/08/14 08:11, Stef Walter wrote:
> On 28.08.2014 17:39, Ximin Luo wrote:
>> On 28/08/14 11:46, Stef Walter wrote:
>>> Hey guys,
>>>
>>> I noticed this commit:
>>>
>>> https://gitorious.org/gnupg/mainline/commit/b896fccaada0caf1987eb95ac99dd6b4ca609c4b
>>>
>>>
>>>
>>>
> It seems that you don't want gpg2 used with GNOME 3.x as is (in its
>>> default configuration).
>>>
>>> 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 for now?
>>>
>>> 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 happen.
>>>
>>> To summarize, either:
>>>
>>> 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 can then drop its gpg-agent
>>> implementation, as its features would now be found elsewhere.
>>>
> 
>> From the view of an outsider: gnupg is a lower-level program, GNOME
>> 3 is a higher-level desktop environment. It sounds ridiculous to 
>> suggest that lower-level utilities should have to do anything
>> special for desktop environments to work with it.
> 
> Nah, this happens all the time. Low level stuff, like the kernel,
> libraries, and gnupg are there to enable higher level features.
> Developers and system administrators often access these low level APIs
> and tools ourselves, but that is an exception, at the end of the day
> they are combined into higher level features for the user to actually use.
> 
> It's never a surprise that the high level features have a bearing on
> the capabilities and APIs of the underlying tools.
> 

What you just said doesn't have any relevance nor address what I said.

"gnupg needs to integrate with GNOME 3" would be like saying "Linux TCP stack needs to integrate with Firefox".

Perhaps this is not what you meant; the things mentioned below sound much more reasonable.

>> Is there some more reasonable, generalised, non-GNOME-specific 
>> interface (that GNOME 3 happens to implement) that you can suggest 
>> gnupg to adhere to instead?
> 
> Well, as Werner suggested, gnupg has such a semi-standard "pinentry"
> interface.
> 
> Someone needs to write a gnome-shell prompter using it (one could use
> this Gcr API if desired [1]). In addition that pinentry prompter needs
> to be able to optionally save the private key password in
> gnome-keyring (libsecret API [2]) so that the user can optionally have
> the private keys automatically unlocked whenever they are logged into
> their GNOME session.
> 
> These are the two features that the gnome-keyring GPG agent enables,
> and the two features that replacement would need to provide.
> 
> Cheers,
> 
> Stef
> 

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140829/4c6484cf/attachment.sig>