Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 547456 - gnome-base/gnome-keyring fundamentally incompatible with gnupg-2.1.x and semi-incompatible with gnupg-2.0.x
Summary: gnome-base/gnome-keyring fundamentally incompatible with gnupg-2.1.x and semi...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] GNOME (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Linux Gnome Desktop Team
URL:
Whiteboard:
Keywords:
: 545210 (view as bug list)
Depends on:
Blocks: 546980 551822 gnupg-2.1, gnupg-2.2
  Show dependency tree
 
Reported: 2015-04-23 06:38 UTC by Alexandre Rostovtsev (RETIRED)
Modified: 2016-07-10 12:10 UTC (History)
9 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandre Rostovtsev (RETIRED) gentoo-dev 2015-04-23 06:38:50 UTC
See https://lists.gnupg.org/pipermail/gnupg-devel/2014-August/028689.html for the long discussion.

Apparently the incompatibility somehow also spills over into seahorse (see https://bugzilla.gnome.org/show_bug.cgi?id=745843#c3).

So how do we handle this on gentoo gnome side? At the very minimum, we should probably give gnome-keyring a new flag ("gpg-agent") which is disabled by default (since gnupg-2.0.26-r3 is stable) and if enabled, pulls in gnupg-1.4.x.

But what about seahorse? Is there a way to make it work with gnupg-2 if gnome-keyring's gpg-agent is disabled?

It's rather bad if gnome ends up blocking gnupg-2.1.x :/
Comment 1 Pacho Ramos gentoo-dev 2015-05-04 10:31:44 UTC
If I understand it properly, at least for 2.0.x, the only issue is that annoying warning gnupg upstream added to scream gnome-keyring users, right? 

But I guess they will force a breakage for 2.1?

I will need to review what other distributions are doing as looks like both upstreams are not collaborative at all :S (I know Arch was simply patching seahorse configure to pass with 2.1... but probably it is really broken but hidden)
Comment 2 Pacho Ramos gentoo-dev 2015-05-04 10:36:41 UTC
Umm, I see Fedora is using old gnupg... but they have gnupg and gnupg2 as parallel installable (not Gentoo case)
Comment 3 Alexandre Rostovtsev (RETIRED) gentoo-dev 2015-05-04 13:47:03 UTC
(In reply to Pacho Ramos from comment #1)

That warning in 2.0.x is apparently not just to annoy users, but is warning about real problems:

https://lists.gnupg.org/pipermail/gnupg-devel/2014-August/028690.html

> 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.
Comment 4 Alon Bar-Lev gentoo-dev 2015-05-04 14:33:33 UTC
seahorse always has issues of using documented interfaces, I fixed this for gnupg-2 as well[1] to some extend.

they should use documented interfaces and catch up with gnupg project's features as they go. forcing people for a specific gnupg version due to their incompatibilities is wrong.

if there is arch patch for seahorse we should take it instead of making gnupg configuration/setup complex for users.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=375062
Comment 5 Pacho Ramos gentoo-dev 2015-05-04 14:46:54 UTC
I have reviewed what other distributions are doing:
- Fedora and Debian/Ubuntu are using gnupg1 (as they package both major versions)
- openSuSE and Arch are "as broken as us" :S 

From my point of view we should go for trying to slot gnupg versions (also, looks like upstream designed them to be parallel installable apart of a few man pages I see Fedora .spec is renaming to avoid conflicts).

Regarding about getting it solved in gnome-keyring side... right, looks like the best solution, but from what I am seing in upstream report I don't expect to get it solved anytime soon
Comment 6 Kristian Fiskerstrand gentoo-dev Security 2015-05-04 15:17:29 UTC
(In reply to Pacho Ramos from comment #5)
> I have reviewed what other distributions are doing:
> - Fedora and Debian/Ubuntu are using gnupg1 (as they package both major
> versions)
> - openSuSE and Arch are "as broken as us" :S 
> 
> From my point of view we should go for trying to slot gnupg versions (also,
> looks like upstream designed them to be parallel installable apart of a few
> man pages I see Fedora .spec is renaming to avoid conflicts).
> 
> Regarding about getting it solved in gnome-keyring side... right, looks like
> the best solution, but from what I am seing in upstream report I don't
> expect to get it solved anytime soon

Not sure what gave you that idea: [0] and "Originally I leaned against the idea of writing such a pinentry and hoped that the GONE folks will do that.  But that was no way forward and thus we have to bite the bullet and implement it for them."[1]

fwiw, the assuan hijacking is just silly incompetence

References:
[0] https://lists.gnupg.org/pipermail/gnupg-users/2015-April/053512.html
[1] https://lists.gnupg.org/pipermail/gnupg-users/2015-April/053522.html
Comment 7 Alon Bar-Lev gentoo-dev 2015-05-04 16:28:55 UTC
(In reply to Pacho Ramos from comment #5)
> I have reviewed what other distributions are doing:
> - Fedora and Debian/Ubuntu are using gnupg1 (as they package both major
> versions)
> - openSuSE and Arch are "as broken as us" :S 
> 
> From my point of view we should go for trying to slot gnupg versions (also,
> looks like upstream designed them to be parallel installable apart of a few
> man pages I see Fedora .spec is renaming to avoid conflicts).
> 
> Regarding about getting it solved in gnome-keyring side... right, looks like
> the best solution, but from what I am seing in upstream report I don't
> expect to get it solved anytime soon

as I wrote, we worked very hard in the past and will keep doing so, gnupg will not be slotted, there is no reason to do so, nor to confuse people which actually use the utility to use a specific minor of gnupg. the problem is only with gnome (as usual).

if you want, you can pack gnupg-1 as gnome-gnupg, prefix all files with gnime use it for seahorse only. then your problem will just begin.
Comment 8 Alexandre Rostovtsev (RETIRED) gentoo-dev 2015-05-05 05:07:46 UTC
(In reply to Kristian Fiskerstrand from comment #6)
> fwiw, the assuan hijacking is just silly incompetence

Not so much incompetence as a lack of any better api in gpg-1.4 and 2.0 to do what gnome needed to do, and now a lack of manpower to update to the 2.1 version of assuan.

(In reply to Alon Bar-Lev from comment #7)
> as I wrote, we worked very hard in the past and will keep doing so, gnupg
> will not be slotted, there is no reason to do so, nor to confuse people
> which actually use the utility to use a specific minor of gnupg. the problem
> is only with gnome (as usual).

Well, at the moment the only three ways I see to go forward are
(1) by default completely disable gnupg support in gnome-keyring and seahorse; or
(2) depend on <gnupg-2.1; or
(3) slot gnupg.

Somehow I think that average gnome users would not like (1), and the people needing advanced gpg features would not like (2)...
Comment 9 Kristian Fiskerstrand gentoo-dev Security 2015-05-05 07:21:31 UTC
(In reply to Alexandre Rostovtsev from comment #8)
> (In reply to Kristian Fiskerstrand from comment #6)
> > fwiw, the assuan hijacking is just silly incompetence
> 
> Not so much incompetence as a lack of any better api in gpg-1.4 and 2.0 to
> do what gnome needed to do, and now a lack of manpower to update to the 2.1
> version of assuan.
> 


Not to get into too much debate over this, but this is just not true. No matter how you look at it, such a cache should be implemented as pinentry, not hijacking the assuan session between gpg and gpg-agent, it is simply the wrong place. The reason this was noticed in the 2.1 move is that all secret key operations are now performed in gpg-agent, allowing for e.g socket forwarding and using a key on a remote host while keeping it local. The hijacking then breaks all gpg functionality. The assuan that _should_ have been used originally for the pinentry component is the same. 

So yes, it is silly incompetence.
Comment 10 Kristian Fiskerstrand gentoo-dev Security 2015-05-05 07:39:04 UTC
(In reply to Alexandre Rostovtsev from comment #8)


> 
> Well, at the moment the only three ways I see to go forward are
> (1) by default completely disable gnupg support in gnome-keyring and
> seahorse; or
> (2) depend on <gnupg-2.1; or
> (3) slot gnupg.

How about 
 (4) Fix GKD (especially given the willingness of gnupg upstream to support this process in [0, 1])

[0] https://lists.gnupg.org/pipermail/gnupg-users/2015-April/053512.html
[1] https://lists.gnupg.org/pipermail/gnupg-users/2015-April/053522.html
Comment 11 Pacho Ramos gentoo-dev 2015-05-06 10:55:24 UTC
(not a 3.16 problem... even if we need to fix it of course :/)
Comment 12 Pacho Ramos gentoo-dev 2015-05-06 11:00:30 UTC
(In reply to Kristian Fiskerstrand from comment #10)
[...]
> How about 
>  (4) Fix GKD (especially given the willingness of gnupg upstream to support
> this process in [0, 1])
> 
> [0] https://lists.gnupg.org/pipermail/gnupg-users/2015-April/053512.html
> [1] https://lists.gnupg.org/pipermail/gnupg-users/2015-April/053522.html

Well, after seeing neither upstream or any other distribution have been able to fix it yet... I guess that is probably not as easy as pretended :|

On the other hand the block on slotting gnupg looks to me much more like a try to force things to break to "push" people to make that work sooner than other :( Specially when gnupg is still supporting the 1.4.x series and is offering them to be parallel installable for cases like this one.
Comment 13 Kristian Fiskerstrand gentoo-dev Security 2015-05-06 11:13:58 UTC
(In reply to Pacho Ramos from comment #12)
> (In reply to Kristian Fiskerstrand from comment #10)
> [...]
> > How about 
> >  (4) Fix GKD (especially given the willingness of gnupg upstream to support
> > this process in [0, 1])
> > 
> > [0] https://lists.gnupg.org/pipermail/gnupg-users/2015-April/053512.html
> > [1] https://lists.gnupg.org/pipermail/gnupg-users/2015-April/053522.html
> 
> Well, after seeing neither upstream or any other distribution have been able
> to fix it yet... I guess that is probably not as easy as pretended :|
> 
> On the other hand the block on slotting gnupg looks to me much more like a
> try to force things to break to "push" people to make that work sooner than
> other :( Specially when gnupg is still supporting the 1.4.x series and is
> offering them to be parallel installable for cases like this one.

This can still be achieved by p.masking >=2.0 as it is today. But to mention one practical issue with slotting is a situation where a Ed25519 (or any other elliptic curve key) key works in Thunderbird but not in Seahorse, and the user filing a bug without knowing that different version used is a reason for it not working. 2.0 is to be discontinued, so 2.1 will replace that anyways.

1.4 is nice to have on some smaller footprint systems, for everything else there is really no reason not to use >=2.0, slotting only introduce complexities (security updates, compile time, &c) which is unnecessary. The root cause needs to be fixed, it has been a known issue for a long time and imho it has not been dealt with properly by gnome upstream. To introduce complexities for everyone else due to one owns poor choice is flawed.

As for "or any other distribution have been able to fix it yet" the ML post I linked is not that old, so time will show..
Comment 14 Kristian Fiskerstrand gentoo-dev Security 2015-05-06 11:20:16 UTC
> 
> This can still be achieved by p.masking >=2.0 as it is today. But to mention
> one practical issue with slotting is a situation where a Ed25519 (or any
> other elliptic curve key) key works in Thunderbird but not in Seahorse, and
> the user filing a bug without knowing that different version used is a
> reason for it not working. 2.0 is to be discontinued, so 2.1 will replace
> that anyways.

.. sometimes the head moves along quicker than the fingers, forgot this part:
Also remember that the secret keystore for 2.1 is not compatible with 1.4 since all secret key operations are performed by the agent and a per-key file is used for storage in a protocol agnostic format rather than in the secring. If slotting, this can cause issues for users not being careful due to mismatched storage for newly generated subkeys etc etc, it is a very bad idea to slot these versions (as opposed to 1.4 and 2.0 that shared the store)
Comment 15 Pacho Ramos gentoo-dev 2015-05-07 19:14:25 UTC
*** Bug 545210 has been marked as a duplicate of this bug. ***
Comment 16 Kristian Fiskerstrand gentoo-dev Security 2015-05-13 19:15:09 UTC
Add a GNOME3 pinentry based on gcr.: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=commit;h=be87785005d256b7f3dacc607ba5ea0a14de8593
Comment 17 Kristian Fiskerstrand gentoo-dev Security 2015-05-14 08:13:49 UTC
(In reply to Kristian Fiskerstrand from comment #16)
> Add a GNOME3 pinentry based on gcr.:
> http://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=commit;
> h=be87785005d256b7f3dacc607ba5ea0a14de8593

app-crypt/pinentry-0.9.2-r1 is in tree where this option is available through the gnome-keyring USE flag if you want to experiment with it.
Comment 18 Pacho Ramos gentoo-dev 2015-05-14 19:09:39 UTC
Thanks!, I guess we will probably need to add a USE flag to not build the gnupg stuff in gnome-keyring for not interferring with new pinentry, right?
Comment 19 Kristian Fiskerstrand gentoo-dev Security 2015-05-14 19:12:40 UTC
(In reply to Pacho Ramos from comment #18)
> Thanks!, I guess we will probably need to add a USE flag to not build the
> gnupg stuff in gnome-keyring for not interferring with new pinentry, right?

How you solve the details of that is up to you of course, but I would strongly recommend not enabling the current behavior in gnome keyring for openpgp by default as it is corrupting security, to the extent that the gnupg maintainers have now implemented a proper solution upstream to replace it. I would very much welcome feedback on the new implementation though.
Comment 20 Pacho Ramos gentoo-dev 2015-05-29 10:24:41 UTC
http://www.gossamer-threads.com/lists/gnupg/devel/71891

This will be useful in the near future to summarize what needs to be done.

For now I am still running Gnome 3.14 and I don't plan to change the behavior for that cycle... but as soon as 3.16 gets into the main tree (it should be near as looks to be no major problems apart of those involving this ;)) I will be able to start playing with the new pinentry (I am unsure if this will make 3.16 stack to rdepend on newer gnupg-2.1 and, then, if any more issues apart of seahorse/gnome-keyring will be blocking its future stabilization :/)
Comment 21 Kristian Fiskerstrand gentoo-dev Security 2015-06-07 11:04:38 UTC
gnupg 2.0.28 and pinentry 0.9.4 are now in tree which should enable this properly
Comment 22 Kristian Fiskerstrand gentoo-dev Security 2015-06-12 19:54:25 UTC
fwiw, the gnome subset implementation of gpg-agent is now removed, see https://bugzilla.gnome.org/show_bug.cgi?id=750514
Comment 23 Pacho Ramos gentoo-dev 2015-06-14 14:00:24 UTC
+*gnome-keyring-3.16.0-r1 (14 Jun 2015)
+
+  14 Jun 2015; Pacho Ramos <pacho@gentoo.org> +gnome-keyring-3.16.0-r1.ebuild:
+  Disable gpg-agent in favor of pinentry[gnome-keyring] (#547456)
+

Lets see how does it work (for now it looks to work ok for me... but... ;)
Comment 24 Mike Auty gentoo-dev 2015-06-16 00:16:45 UTC
So, with this change, no gpg-agent starts, meaning things like enigmail fail with an unhelpful error message along the lines of "no secret key available".

I've tried putting use-agent in my ~/.gnupg/gpg.conf, and I've tried upgrading to gnupg 2.1, both of which should cause gpg-agent to launch automatically, only neither seem to.  There's also supposed to be an /etc/X11/Xsessions.d/ file that should automatically launch it, but that never seems to get installed either.

I've found that adding an /etc/xdg/autostart file that executes:

/usr/bin/gpg-agent --daemon --use-standard-socket --pinentry-program=/usr/bin/pinentry-gnome3

Seems to solve the problem, but I'm not sure what the upstream-approved method of getting this all to work is supposed to be, or how we package that in gentoo (given we seem to have deviated slightly from the Xsessions.d that upstream suggested for gnupg-2.0.x, and that gnupg-2.1.x mechanism seems not to work, or at least not select pinentry-gnome3 when running within a windowed environment).

Any suggestions?
Comment 25 Kristian Fiskerstrand gentoo-dev Security 2015-06-16 16:24:51 UTC
(In reply to Mike Auty from comment #24)
> So, with this change, no gpg-agent starts, meaning things like enigmail fail
> with an unhelpful error message along the lines of "no secret key available".
> 
> I've tried putting use-agent in my ~/.gnupg/gpg.conf, and I've tried

use-agent is a dummy option, it is always used in >=2.0

> upgrading to gnupg 2.1, both of which should cause gpg-agent to launch
> automatically, only neither seem to.  There's also supposed to be an

That is weird, it should auto launch with standard sockets , are you sure you don't have a 2.0 agent still running or something? 

> 
> /usr/bin/gpg-agent --daemon --use-standard-socket
> --pinentry-program=/usr/bin/pinentry-gnome3
> 
> Seems to solve the problem, but I'm not sure what the upstream-approved
> method of getting this all to work is supposed to be, or how we package that

upstream generally recommend making /usr/bin/pinentry a symlink to the one to use, we could do that for the gnome3 variant. if no DISPLAY variable is set it defaults to pinentry-curses

> in gentoo (given we seem to have deviated slightly from the Xsessions.d that
> upstream suggested for gnupg-2.0.x, and that gnupg-2.1.x mechanism seems not
> to work, or at least not select pinentry-gnome3 when running within a
> windowed environment).

> 
> Any suggestions?

yeah, we should add this to eselect, for now can you try creating the symlink manually?

and remember to kill any runnin gpg-agent for testing the auto-launch
Comment 26 Pacho Ramos gentoo-dev 2015-06-17 19:26:31 UTC
I have it running properly:
 ps axu | grep gpg-ag
pacho     6253  0.0  0.0   6392  2048 pts/3    S+   21:25   0:00 grep --colour=auto gpg-ag
pacho    31363  0.0  0.0  13332   156 ?        Ss   jun14   0:06 gpg-agent --daemon


But maybe it was launched by something when it was needed :/, I will need to check
Comment 27 Mike Auty gentoo-dev 2015-06-19 18:54:56 UTC
Hiya, so setting the symlink and removing all autostart agents does seem to have worked, enigmail successfully pops up a dialog and decrypts the mail.  Gpg-agent exits immediately, meaning I don't get a short cache timeout, and for each email I want to read I've got re-enter the password.  I assume this is just a config option somewhere, so I'll have a dig into that...

Interestingly, the dialog is not the same as the one I got when using "--pinentry-program=/usr/bin/pinentry-gnome3"?  It was a modal dialog box, but looked just like a normal dialog box rather than one centered on the screen that sets all the background dark black.  I've double checked my symlink, and disabled theming and so on, so not sure what's causing that, but in general setting the proper symlink (maybe through eselect) is a suitable solution.  Thanks!  5:)
Comment 28 Pacho Ramos gentoo-dev 2015-06-20 08:59:54 UTC
Ah, it's true that the dialog I was getting was the gtk2 one, not the gnome3. And I see the symlink as pointing to the gtk2 one by default :/
Comment 29 Pacho Ramos gentoo-dev 2015-06-20 09:01:34 UTC
But I cannot change it using:
# eselect pinentry list
Available pinentry binary implementations:
  [1]   pinentry-gtk-2 *
  [2]   pinentry-qt4
  [3]   pinentry-curses

I would need to manually change the link
Comment 30 Alon Bar-Lev gentoo-dev 2015-06-20 09:03:25 UTC
yes, it is missing in eselect-pinentry, I will update.
Comment 31 Pacho Ramos gentoo-dev 2015-06-20 09:09:58 UTC
I am not sure if it would be possible to prefer "gnome3" one over "gtk2" when both are built. Currently gnome3 one is built with "gnome-keyring" USE flag and gtk2 with "gtk" USE flag, then, most Gnome 3 users will get both built but, if using "gnome" (maybe "gnome" USE flag instead of "gnome-keyring" could be used) they should prefer the gnome3 pinentry over gtk2 one
Comment 32 Alon Bar-Lev gentoo-dev 2015-06-20 09:11:21 UTC
(In reply to Alon Bar-Lev from comment #30)
> yes, it is missing in eselect-pinentry, I will update.

app-eselect/eselect-pinentry-0.5 available.
Comment 33 Pacho Ramos gentoo-dev 2015-06-20 10:46:02 UTC
It works, thanks!
Comment 34 Mike Auty gentoo-dev 2015-06-22 15:38:03 UTC
Just as an update, I've been checking the gpg-agent.conf and gpg.conf files, and believe I've got caching set appropriately, but since gpg-agent is launched on demand in --server mode, it doesn't do any caching and I need to enter my password for each and every encrypted email I want to read (or multiple when sending emails with encrypted attachments).

I haven't been able to locate how to resolve this, but my guess is that if pinentry-gnome3 doesn't do something clever with expiring keychain entries (which I don't think it does), then there's no good way to get caching enabled properly.  5:\  So my options appear to be either save it permanently to gnome-keychain, type it in each time, or create a custom xdg autostart script that launches the appropriate gpg-agent (which when running in --daemon mode, will cache the password for the right length of time).

Am I missing an easy fix?  Is the xdg script something we might want to incorporate into the gnupg package, or should we require that every user create it manually?
Comment 35 Kristian Fiskerstrand gentoo-dev Security 2015-06-22 16:29:25 UTC
(In reply to Mike Auty from comment #34)
> Just as an update, I've been checking the gpg-agent.conf and gpg.conf files,
> and believe I've got caching set appropriately, but since gpg-agent is
> launched on demand in --server mode, it doesn't do any caching and I need to
> enter my password for each and every encrypted email I want to read (or
> multiple when sending emails with encrypted attachments).

it shouldn't be starting in --server mode, that mode is barely even useful for certain debugging tasks, nothing you'll encounter in the real world. Can you post your config files somewhere?

> 
> I haven't been able to locate how to resolve this, but my guess is that if
> pinentry-gnome3 doesn't do something clever with expiring keychain entries
> (which I don't think it does), then there's no good way to get caching
> enabled properly.  5:\  So my options appear to be either save it
> permanently to gnome-keychain, 

Isn't that what we're trying to do here in the first place? If not the regular gtk pinentry is better choice anyways.
Comment 36 Mike Auty gentoo-dev 2015-06-23 00:51:03 UTC
Thanks for the pointer!  Turns out all of my gpg-agent.conf files were lacking "use-standard-socket" in them.  So it seems --server is gnupg's default without adding something specific to your config?  Presumably this will all go away with gnupg-2.1 (which is just waiting on bug 551822) where standard-sockets are indeed standard...
Comment 37 Brian Evans Gentoo Infrastructure gentoo-dev 2015-06-26 19:47:22 UTC
(In reply to Pacho Ramos from comment #23)
> +*gnome-keyring-3.16.0-r1 (14 Jun 2015)
> +
> +  14 Jun 2015; Pacho Ramos <pacho@gentoo.org>
> +gnome-keyring-3.16.0-r1.ebuild:
> +  Disable gpg-agent in favor of pinentry[gnome-keyring] (#547456)
> +
> 
> Lets see how does it work (for now it looks to work ok for me... but... ;)

This "fix" introduces an unsolvable circular dependency chain when none or just pinentry[-gnome-keyring] are installed.

gnome-base/gnome-keyring -> app-crypt/pinentry[gnome-keyring] -> app-crypt/libsecret -> gnome-base/gnome-keyring
Comment 38 Alexandre Rostovtsev (RETIRED) gentoo-dev 2015-06-26 23:14:01 UTC
(In reply to Brian Evans from comment #37)
> This "fix" introduces an unsolvable circular dependency chain when none or
> just pinentry[-gnome-keyring] are installed.
> 
> gnome-base/gnome-keyring -> app-crypt/pinentry[gnome-keyring] ->
> app-crypt/libsecret -> gnome-base/gnome-keyring

Fixed, thanks for noticing!

+  26 Jun 2015; Alexandre Rostovtsev <tetromino@gentoo.org>
+  gnome-keyring-3.16.0-r1.ebuild:
+  pinentry is pure runtime dep (bug #547456, thanks to Brian Evans).

+  26 Jun 2015; Alexandre Rostovtsev <tetromino@gentoo.org>
+  -libsecret-0.16.ebuild, libsecret-0.18.ebuild, libsecret-0.18.2.ebuild:
+  pdepend on gnome-keyring to fix circular dep (bug #547456, thanks to Brian
+  Evans). Clean up old.
Comment 39 Pacho Ramos gentoo-dev 2015-07-07 11:14:03 UTC
I will close this, for any new issues -> new bug report 

thanks