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 :/
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)
Umm, I see Fedora is using old gnupg... but they have gnupg and gnupg2 as parallel installable (not Gentoo case)
(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.
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
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
(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
(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.
(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)...
(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.
(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
(not a 3.16 problem... even if we need to fix it of course :/)
(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.
(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..
> > 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)
*** Bug 545210 has been marked as a duplicate of this bug. ***
Add a GNOME3 pinentry based on gcr.: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=commit;h=be87785005d256b7f3dacc607ba5ea0a14de8593
(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.
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?
(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.
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 :/)
gnupg 2.0.28 and pinentry 0.9.4 are now in tree which should enable this properly
fwiw, the gnome subset implementation of gpg-agent is now removed, see https://bugzilla.gnome.org/show_bug.cgi?id=750514
+*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... ;)
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?
(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
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
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:)
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 :/
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
yes, it is missing in eselect-pinentry, I will update.
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
(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.
It works, thanks!
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?
(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.
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...
(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
(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.
I will close this, for any new issues -> new bug report thanks
