Hello, This patch should solve the issue in seahorse. It should work with gnupg-1.4 and 2.0. Please check.
Created attachment 108604 [details, diff] seahorse-0.8.2-gpg2.patch
Another comment... gnupg upstream does not wish to support gpg-agent-info option anymore... Although I added this patch to gpg, I may remove it if upstream will not accept it... In order to work correctly, you need to run seahorse-agent with --variables just like using ssh-agent... and put this in environment... But first I wish to see if the patch works for you.
I'd be more interested in what upstream thinks, as I don't personally use seahorse at all. Maybe another member of the gnome team uses it?
could you describe what the issue exactly is ? You should try to get the patch upstream, they are quite responsive but please consider 0.8.x branch is not developed actively anymore.
The issue is that gpg2 agent protocol was enhanced without consulting the agent... I will contact upstream, but I need someone who uses this package to confirm that it works... As I don't use it, and don't understand why it should be used anyway... :)
I will try to test out patch in the next day or so. Been short on time and can't afford to have problems with sending email. In my case seahorse is very important because it catches my passphase for my gpg keys in evolution. Without, pinentry pops up each time I send an email. Which is better than before, an error and no passphrase pop up. But pinentry nor any other agent I am aware of catches it from evo in gnome. Not that I am to familiar with agents or etc. Plus seahorse has gnome integration. I can clear my cached passphrases, or leave them there for an indefinite period of time. Which is quite nice also. Not to mention all I did was emerge seahorse, and start the agent. Which I added to my gnome session so it's started on login. I have a gui to manage my keys, and the agent for catching passphrases.
William: This what gpg-agent also does... Unless you have a good reason to why gnome integration is important, you can always run gpg-agent in xinit context. In order to test it, you can use: $ gpg-agent --daemon bash And run whatever in the new context.
(In reply to comment #7) > William: This what gpg-agent also does... Unless you have a good reason to why > gnome integration is important Because again I have control via GUI tools ;) It integrates with the notification area and etc when the passphrases are cached. So I have visual confirmation of them being catched. I can bring up the interface and view which of my keys are cached, remove them from cache/agent. > > In order to test it, you can use: > $ gpg-agent --daemon bash I tried that in a terminal. Pinentry would keep popping up in evolution and the passphrase was never catched. So not sure where the problem lies in communication amoung the apps there. But the passphrases were not cached.
(In reply to comment #8) > > $ gpg-agent --daemon bash > > I tried that in a terminal. Pinentry would keep popping up in evolution and the > passphrase was never catched. So not sure where the problem lies in > communication amoung the apps there. But the passphrases were not cached. This is strange! And should be solved. Are you sure you are running evolution from within the new shell?
(In reply to comment #9) > Are you sure you are running evolution from within the new shell? I am absolutely sure I am not, I might try that to see what happens. I am launching evolution via an icon, not command line. So it's in it's own shell, or the session one. Should be irrelevant to the agent, as seahorse does not seem to care. I have seahorse-agent started by my gnome session on login. That's also where I would have gpg-agent --daemon if that worked for my needs.
Please just try to activate evolution via the new shell... I wish to know if the gpg-agent is working or not. gpg locate the agent via the GPG_AGENT_INFO environment variable. This is only for testing... If that's working use: eval `gpg-agent --daemon` In your gnome session on login, it will set up the environment correctly for the icon tool. The gpg-agent does not use the gpg-agent-info so the environment of gpg should be set correctly in order for it to find the agent.
No, it doesn't work. For a while now (I don't know exactly when), sending gpg signed email in evo has completely hard-hung the box. I haven't looked into it deeply, because I haven't had time; I just turned off automatic pgp signing. It happend both when agent has they key cached, and when it doesn't. I'll see if I can find any other useful information. (gpg-agent works fine for portage signing...)
Okay, I take it back. After rebooting because of that last hang, I can send email in evo fine. The only thing I can think of is that app-crypt/gnupg-2.0.1-r3 fixed my problem (but required an agent restart)
Daniel: I don't understand, seahorse works without the attached patch?!?!?! Or you don't use the seahorse at all and use gpg-agent?
Sorry, I wasn't clear. I use gpg-agent, via keychain. I don't use seahorse.
(In reply to comment #15) > Sorry, I wasn't clear. I use gpg-agent, via keychain. I don't use seahorse. So what are you doing at this bug?
Well... Tried keychain, and it works. No need for the gpg-agent-info fixups since it works using environment.
OK... Upstream does not accept the gpg-agent-info option fixup... gnupg-2.0.2 will not accept this option. I really don't know why they wish to break an existing behavior... So you must run seahorse at xinit environment and use: eval `seahorse-agent --variables` It will set GPG_AGENT_INFO variable correctly for application to use.
William: If you test it we may provide a solution for all seahorse users...
Yes I will do ASAP. It's on my list, just trying to keep my head above water atm.
Ok I finally made time to test this. In breif it did not work. First I tried to add the --variables to my gnome session. Where I have seahorse-agent started on login normally. No matter how I quoted it via ``,'', or "" the --variables part did not show up in ps output. So I tried it from a terminal. I killed the running seahorse-agent. I ran seahorse-agent --variables. That time the --variables argument did show up in ps, and I could see the env var being set just after I ran the command. I then fired up evolution from the same terminal window. In either case, when I went to enter my gpg passphrase, the popup was a pinentry one, not the seahorse one. So passphrases were not cached by seahorse. Not sure what else I can try outside of abnormal scenarios. For all common ones, like I tested. It seems even with the patches, gnupg-2 is not playing well with seahorse or visa versa. Now reverting back to gnupg-1 again, and seahorse will start working again. At this point it's more than likely time to contact seahorse upstream. To find out if they are going to port seahorse to work with gnupg-2. If they have no plans do to so, and gnupg upstream has no plans to deprecate, or stop developing gnupg-1. Then all comes back to my first comments, of slotting gnupg. Seahorse in tree has been effectively broken by this for over a month or so now. And I am not sure I will spend/waste any more time trying to get something that works perfectly with one version of a package. Working with a newer version of the package, outside of upstream support. Mostly because we are not making any progress on forcing seahorse to work with gnupg-2 despite all efforts. Which are appreciated. So one of these days, it might be time to stop peeing in the wind on this. :)
1. Upstream already committed this patch, see: http://bugzilla.gnome.org/show_bug.cgi?id=375062 2. The --variables works with seahorse, and it has nothing to do with this patch. 3. From your description it seems like evolution unset the variable?!?! Since it has nothing to do with seahorse if the standard pinentry is running. Somehow gpg does not get the environment setting. 4. seahorse works with the patch, I checked it using regular gpg commands. I guess something wrong with usage. But I won't install evolution just now (381 packages!). Thanks for trying this.
(In reply to comment #22) > 1. Upstream already committed this patch, see: > http://bugzilla.gnome.org/show_bug.cgi?id=375062 That's great. Did you get any information from them if they planned to port to gnupg-2. Or if your patches effectively did that for them, then their opinion/plans don't really matter. Since they accepted patch :) Thanks for making that and getting it to upstream. > 2. The --variables works with seahorse, and it has nothing to do with this > patch. Ok, good to know, I was not sure about that aspect. > 3. From your description it seems like evolution unset the variable?!?! Since > it has nothing to do with seahorse if the standard pinentry is running. Somehow > gpg does not get the environment setting. Ok if I get more time I will see about testing this further. I am still doing some other upgrades atm. SO have not reverted back to gnupg-1. I will see if I can experiment some more. > 4. seahorse works with the patch, I checked it using regular gpg commands. I > guess something wrong with usage. But I won't install evolution just now (381 > packages!). Good news is, you don't have to recompile evo afterward :) Just seahorse, and not even sure it needs to be compiled against a particular version of gnupg. Just runtime seems to work with gnupg-1, and not gnupg-2. > Thanks for trying this. No problem, sorry for the delays, and thank you for continuing to look for a resolution on this. Sorry I don't have more time to help out. No time to help with other packages I really need either.
BINGO :) wlt@wlt ~ $ killall seahorse-agent wlt@wlt ~ $ seahorse-agent --variables GPG_AGENT_INFO=/wlt/.gnome2/seahorse-S51mWn/S.gpg-agent:19751:1; export GPG_AGENT_INFO wlt@wlt ~ $ wlt@wlt ~ $ $GPG_AGENT_INFO wlt@wlt ~ $ export GPG_AGENT_INFO="/wlt/.gnome2/seahorse-S51mWn/S.gpg-agent:19751:1" wlt@wlt ~ $ $GPG_AGENT_INFO bash: /wlt/.gnome2/seahorse-S51mWn/S.gpg-agent:19751:1: No such file or directory wlt@wlt ~ $ evolution-2.8 Seems the variable is not properly being exported to the env. Thus is never set for evolution to use it. So evolution is not unsetting the variable. Now once I fired up evo, and composed an email, I got the passphrase dialog from seahorse not pinentry. So if we can get the env var setup properly. Then we most likely have a fix, and can be done with all this. :)
I don't understand. Why: $ eval `seahorse-agent --variables` Dos not produce the right statement.
(In reply to comment #25) > I don't understand. > Why: > $ eval `seahorse-agent --variables` > Dos not produce the right statement. It does, and is the only thing that does. However I can't seem to set that anywhere for it to be available globally and work. I have tried putting it all over the place in my gnome session, and ended up adding it to my .bash_profile I tried .gnomerc, but that did not work. I do not believe I can use .xinitrc with gdm or etc. So basically I have yet to find a place to put that, so when I fire up evolution in my desktop it can get the var and communicate with seahorse. So far only doing the above in a terminal, and firing up evolution in that same terminal works. Very open to any advice or input on other locations I could put the statement and have the variable available anywhere in my desktop env.
Oh yeah, putting it in .bash_profile makes the var available in any shell, but it does not work when I fire up evolution. I get pinetry prompt, not seahorse.
what about putting it in /etc/X11/xinit/xinitrc.d/40-seahorse or something like that ? (probably means it would work with .xinitrc
ok, just tested comment #25 line in .xprofile and it works. It's probably a bug that seahorse doesn't provide env vars if started with the session (although I might have missed something). Btw I'm using seahorse-0.9.10 but it should work with 0.8.2 too.
(In reply to comment #29) > ok, just tested comment #25 line in .xprofile and it works. It's probably a bug > that seahorse doesn't provide env vars if started with the session (although I > might have missed something). Btw I'm using seahorse-0.9.10 but it should work > with 0.8.2 too. > Which bug? What do you mean? Seahorse prints a shell script line which should be run under current environment... Can you please explain what does not work and what you expect?
I mean that seahorse advises you to add seahorse-daemon to your session (which I did) for handling passphrase caching, ... I simply assumed it would set environment variables so that evolution can use it. It used to use it before I got pinentry pulled in by some update. When pinentry entered the game, evolution was just using it in place of seahorse but now with this line in my .xprofile everything is back to normal.
(In reply to comment #31) > I mean that seahorse advises you to add seahorse-daemon to your session (which > I did) for handling passphrase caching, ... I simply assumed it would set > environment variables so that evolution can use it. It used to use it before I > got pinentry pulled in by some update. No... A process cannot set environment to other process unless the other process is a child process. > When pinentry entered the game, evolution was just using it in place of > seahorse but now with this line in my .xprofile everything is back to normal. Well... it has nothing to do with pinentry, just that on gnupg-2 upstream removed an option in gpg.conf file that allowed seahorse to use an option and not environment to redirect gpg to its agent. So the change was really moving from an option in config file to environment, and since the environment should be set globally, you noticed this change. I am glad all works for you, William can you confirm so we push this to users?
keychain and other wrappers all do variations on the following: (where $AGENT is ssh-agent, gpg-agent, seahorse-agent) Either of these, depending on what you want ===== "eval `$AGENT`" ===== $AGENT >agentfile eval "$(<agentfile)" ===== keychain uses a twist on the second one. maybe we should just add seahorse-agent support to keychain?
when pushing this to the user, just don't forget to add an elog about this trick. See app-i18n/scim ebuild for reference.
Adding eval `seahorse-agent --variables` To .xprofile does make the variables available in the env. However it's not work for me. When I try to send a gpg signed email I get an error popup that states Could not create message Because "gpg: problem with the agent: General IPC error" gpg: skipped "my@emailaddress.com": General error gpg: signing failed: General error ," you may need to select different mail options. So being as how I have not found a working place to put the env vars, I will more than likely have to reverse back to gnupg-1.x so I can get things working again as normal.
I will see about trying seahorse 0.9.x later on. Since it seems I was using a different version than the other commenter. So it's possible that version will work correct, and the one I am using will not. Despite any patches. That's at least my assumption for now. I will see about making some time later today and testing out that theory.
Adding eval `seahorse-agent --variables` To ~/.xprofile Works as expected with seahourse 0.9.x. I just emerged seahorse-0.9.91 from gentopia overlay. And it works with gnupg-2, as it did before with gnupg-1. Now just need to see about getting 0.9.x into tree from overlay :) Little different than before, but moot. The difference of starting seahorse-agent via gnome session, as opposed to .xprofile. Not a big deal at all. So I think we can effectively say that seahorse 0.8.x just does not want to work with gnupg-2 despite patches and etc.
Correction we have found a temporary fix, but not an ideal permanent solution. I have issues with the passphrase expiring, and can't seem to change that. Since the seahorse gui stuff does not recognize the agent is already started and running. At some point another seahorse-agent is launched, that I am not launching and is not part of my session. So I end up with two trying to catch passphrase, the one that works, and the other. It's causing some funkiness, and while it works most of the time. It's not all of the time, and not integrated as it should be. IMHO So we are making progress and a bit closer, but not there just yet.
Thank you for testing. But is there any reason why people who use none stable gpg will use none stable seahorse? If 0.9.X works, I think we can close this issue.
0.9.x is only in overlay, so can't really close till something is resolved in tree I would imagine. Not to mention the resolution is kinda shady. Like right now I show a lock in my gnome notification area. It shows my passphrases as cached. Yet I still get a pop up in evolution for my passphrase, but it is at least a seahorse pop-up. Not to mention other seahorse stuff not recognizing the seahorse-agent running. Bottom line still having to enter my passphrase more than I want to :) So even if 0.9.x is in tree, it's not a 100% resolution, but likely one good enough for ~arch for now. Might be justification to get 0.9.x into tree though, unless it has other issues.
Ok, I finally went upstream with this. I am trying to get a link to the thread for others to read. Bottom line, no version of seahorse will work with gnupg-2 at this time. Period end of story. There are two seahorse developers, and I got that information from one of them. Flat out here is a snippet of their post. "I think the two of us that are actively developing seahorse are still trying to get our heads around what to do as neither of us are using distros that include gpg-2.0 and don't personally have use cases that require it (although I don't think we'd complain if someone wanted to supply the card readers and smart cards). Basically my advice for the moment is don't use gpg-agent and have a parallel installation of gpg-1.4.x." When I first ran into this problem. I as well as other called for gnupg to be slotted. After quite a bit of grief, drama, and etc. It was decided it would not be slotted. And here we are months later, and we still have in tree breakage. Bottom line, seahorse was in tree before gnupg-2 was unmasked. Unmasking it caused breakage. That breakage needs to be fixed. gnupg needs to be slotted, as it was pre 2.0. If there is continued refusal to slot, I will have to escalate the matter to devrel. There is no reason to allow breakage in tree to persist for more than 2 months. A resolution is not in site, and the ONLY option at this time is to slot gnupg-2. I will re-open that bug that I initially filed on it. Linking it to this one. But really I am done on this. I have spent considerable time trying to get things to work with gnupg-2.0. More than I should have had to. Please respect my time, and effort to help with the choice of not slotting gnupg. By now slotting it, since we have exhausted all possibilities, at this time.
wltjr: Slotting gnupg is not suitable for several reasons, and there is one that will be particular concern to developers amongst it. First of all the reasons for users: 1. Requires the introduction of eselect-gnupg to flip between instances, because we cannot patch everything else to run gnupg-1 || gnupg-2. 2. In line with an eselect, patching gnupg to have ~/.gnupg/ and ~/.gnupg2/ 3. Find every other application that uses those directories as well, and patch them. 4. Migration between the two is painful and data-loss-prone (the downgrade in particular). 5. It is possible to generate stuff with gnupg2 that gnupg1 is not capable of handling. Now the reason for developers: 6. Amongst the upcoming tree-signing stuff, we will be making use of a feature (a specific interface actually) that is coming in gnupg2, because the only way of doing the same set of action in gnupg is over 1000x slower and not reliable. There are exactly two breakages that the gnupg1 to gnupg2 migration has exposed thus far (and quite frankly I was expecting a LOT more): 1. The IDEA cipher stuff, which upstream refuses to touch for patent reasons 2. seahorse doesn't behave properly with gnupg2 yet.
And on the two breakages 1. there are 3rd-party developers working on the IDEA issue 2. by your own testing seahorse-0.9x has major progress to working with gnupg2 - why not work with somebody on the GNOME team sympathetic to your causes and get it working right?
(In reply to comment #42) > > 1. Requires the introduction of eselect-gnupg to flip between instances, > because we cannot patch everything else to run gnupg-1 || gnupg-2. Not sure why it's one or the other. All upstream docs say the two are designed to co-exist, and there are benefits. > 2. In line with an eselect, patching gnupg to have ~/.gnupg/ and ~/.gnupg2/ I revert back and forth, using the same ~/.gnupg/ dir and conf files without a problem. So not sure why that would need to be slotted as well. I do it without even logging out of gnome. :) > 3. Find every other application that uses those directories as well, and patch > them. I would imagine that to be more of a problem with app linkage, than dir locations. Understandable either way. Does make me wonder what other distro's are doing about this. Due to upstream comment mentioning a lack of gnupg-2 on some. > 4. Migration between the two is painful and data-loss-prone (the downgrade in > particular). As stated above, I have gone back and forth with no problem? Can you provide an example/test or a way for me to replicate a problem from going back and forth from gnupg-1 <-> gnupg-2. But not sure why slotting would require going back and forth. That's usually the solution to co-existence. > 5. It is possible to generate stuff with gnupg2 that gnupg1 is not capable of > handling. Sure, but then again gnupg-1.x apps would be using gnupg-1, everything else gnupg-2. Quite many things in tree are slotted now. > Now the reason for developers: > 6. Amongst the upcoming tree-signing stuff, we will be making use of a feature > (a specific interface actually) that is coming in gnupg2, because the only way > of doing the same set of action in gnupg is over 1000x slower and not reliable. I have no problems with that aspect. I can understand the benefit to gnupg-2. I just don't like the breakage, and have been doing all I can to help resolve. (In reply to comment #43) > > 2. by your own testing seahorse-0.9x has major progress to working with gnupg2 Negative, very slight at best progress. I really would not call it that, since it did not work reliably. Had issues when ssh keys were cached by seahorse-agent which resulted in more than one instance, and issues there. I have had gnupg-2 installed for going on two+ weeks now and have tried everything possible. It's been quite some headache, and way more effort than I wanted to put in. But was trying to be a team player there. Thus finally contacting upstream to get the real details and info on how to get it working. Much less their plans on getting it working. Why no one else contacted upstream, and just tried to resolve the matter outside of which, I don't understand. Oh well. If S.F. didn't suck so bad, I would provide a link to thread on list archive. I would rather people read it first hand than posting unedited snippets. > - why not work with somebody on the GNOME team sympathetic to your causes and > get it working right? Well considering I contacted upstream, and got their input on the matter. Not really sure what else to say. Here is another snippet from upstream post "The real issue is gpgme <=> gpg-2.0. There needs to be a new version of gpgme that will use /prefix/bin/gpg2 instead of /prefix/bin/gpg. I don't think sym linking will work as a stop gap procedure." So is it really even a seahorse problem there? I have been trying to quite some time now to get things to work right. They were working fine. Re-emerging gnupg-1.4.6 at any time resolves all issues. From everything I read on gnupg's site, gnupg-1 and gnupg-2 were designed to co-exist. I would imagine apps should be aware of that and use one or the other, or at least be known to work with one, and not the other. But really I am not wasting any more time. I have a nasty hack to emerge gnupg-2.x when I need to update my system, and then revert back to gnupg-1.x so things will work. I don't have the ability to resolve this myself. Upstream does not have a solution at this time. They don't feel it's a priority, or etc. Partly due to lack of gnupg-2 on their OS. Final snippet from upstream. So I am aware of the problem, I have a way around it for now. I am not happy with it, but am done. Don't want to waste any more time. Or make this into a big deal or a problem for others. If other users have the same problem, or etc. So be it. I guess the other benefits are worth the problems or headaches. Finally I just know I am not allowed to break the tree. Even for packages that were stale, and about to be removed or etc. Regardless of if it's one or more, or package importance. Given the time frame now since initial breakage. Not sure what else to say or do. But have other things I need to work on. It's out of my hands from here. I will leave testing and a final solution to others. Sorry, did all I could.
Ok, last bit, likely belongs on other bug. Seems other distros are "slotting" Or allowing both to be installed and co-exists. Here are package list links to gnupg-2 on Debian, Ubuntu, RHEL, and Fedora. http://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelist&word=gnupg2&version=unstable&arch=amd64 http://packages.ubuntu.com/cgi-bin/search_contents.pl?searchmode=filelist&word=gnupg2&version=feisty&arch=amd64 http://rpm.pbone.net/index.php3/stat/4/idpl/3890355/com/gnupg2-2.0.2-39.el4.at.x86_64.rpm.html http://rpm.pbone.net/index.php3/stat/4/idpl/3891179/com/gnupg2-2.0.2-39.fc6.at.x86_64.rpm.html Now notice the RH approach is less stuff suffixed with 2, and only a few apps, gpg2, etc suffixed with a 2. Their 1.x gnupg package doesn't seem to provide some things like agent or etc. The ones that are provided by gnupg-2, but not suffixed as such. Bit of food for thought, so slotting is not unheard of, or out of the question. But really belongs on other bug, not this one :)
Gnome: Is there any reason why not adding 0.9.X into tree so we can close this issue for people who use none stable gnupg?
>> 4. Migration between the two is painful and data-loss-prone (the downgrade in >> particular). >As stated above, I have gone back and forth with no problem? Can you provide an >example/test or a way for me to replicate a problem from going back and forth >from gnupg-1 <-> gnupg-2. But not sure why slotting would require going back >and forth. That's usually the solution to co-existence. Double-checking this, I see upstream gpg is in the process of back-porting the items I have concerns about, so excluding those, there remains the stuff where new crypto was added to libgcrypt (which is used by gpg2), while the embedded stuff in gpg1 languishes. Will this bite most users? No, it's fringe, but it is important to me. With regards to libgpgme calling gpg via the binary, we install a symlink at gpg that points to gpg2, and the only changes in the entire CLI interface are the additions of smartcard stuff and the changes in agent passphrase handling. In the passphrase handling: --use-agent, --no-use-agent and --gpg-agent-info no longer do anything. change the environment variable is you want the same action, but be aware that not passing in an agent will cause gpg2 to run the agent itself temporarily. --passphrase-fd, --passphrase-file, --passphrase: all of these require the use of --batch now. The --passphrase* items had warnings to this effect in 1.4*. For the agent-info stuff and seahorse writing the passphrase to gpg.conf, make sure that it passes --batch as required, and put a shell wrapper around gpg that catches --gpg-agent-info or supplies it from gpg.conf as needed. I'm sorry that you aren't happy with the resolution thus far, but I simply don't have the time at the moment to dig into why seahorse is not behaving correctly. Go back and use gnupg-1.4 on your boxes, but when the tree-signing stuff happens, you will have to use gpg2 (and it would be nice to seahorse working before then).
in reply to comment #46 seahorse-0.9.x series is considered development branch by upstream. afaik, this is way it is not in the tree (even p.masked). Don't know when they plan to make a new stable branch but I think it will happen soonish as seahorse is making its way to gnome modules.
(In reply to comment #46) > Gnome: Is there any reason why not adding 0.9.X into tree so we can close this > issue for people who use none stable gnupg? The problem is not resolved in Seahorse 0.9.x So it being added to tree, won't allow for this bug to be closed. Let me make it clear NO VERSION OF SEAHORSE WORKS WITH GNUPG-2. Is that clear? (In reply to comment #47) > > With regards to libgpgme calling gpg via the binary, we install a symlink at > gpg that points to gpg2, and the only changes in the entire CLI interface are > the additions of smartcard stuff and the changes in agent passphrase handling. Did you not see where seahorse upstream clearly said they did not believe a symlink would work, even as a stop gap. So that's part of the problem right there. Trying to force gnupg-1 apps to work with gnpg-2. > I'm sorry that you aren't happy with the resolution thus far, Because there is not a resolution, and this problem/breakage occurred in early January. If there was even a half working, hack solution. I would use it and be some what happy. But NOTHING works, and trying to make things work is worse than peeing in the wind. Oh and by the way, most of what I use gpg for is Gentoo stuff :) Really did not use it before that. > but I simply > don't have the time at the moment to dig into why seahorse is not behaving > correctly. I don't get why you all do not realize it's more than just seahorse. Not everything works with gnupg-2 only. Other distros ship/provide both at the same time. So it's not an issue there. > Go back and use gnupg-1.4 on your boxes, but when the tree-signing > stuff happens, you will have to use gpg2 I have been, and will be reverting back to gnupg-1.4. That's why I was quite through most all of January and February aside from attempts with gnupg-2. So 2+ months breakage is allowed for a upcoming feature which is not even in tree yet? That just sounds wrong to me. > (and it would be nice to seahorse working before then). Well from everything I have read, gnupg-1 has benefits, and will continue to be developed and released. It's possible seahorse might never move to gnupg-2. Since gnupg-2 does not support all of gnupg-1. Plus gnupg-1 can use aspects of gnupg-2 in the background. Since the link is not on this bug, I will leave it and a snippet as a conclusion. http://lists.gnupg.org/pipermail/gnupg-announce/2006q4/000242.html "GnuPG-2 has a different architecture than GnuPG-1 (e.g. 1.4.5) in that it splits up functionality into several modules. However, both versions may be installed alongside without any conflict. In fact, the gpg version from GnuPG-1 is able to make use of the gpg-agent as included in GnuPG-2 and allows for seamless passphrase caching. The advantage of GnuPG-1 is its smaller size and the lack of dependency on other modules at run and build time. We will keep maintaining GnuPG-1 versions because they are very useful for small systems and for server based applications requiring only OpenPGP support." Please slot and allow for both gnupg-1 and gnup-2 to be installed. Just as upstream intends, and just as other distros are doing. Why re-invent the wheel, even if it's only 1 or two apps that are broken with gnupg-2 at this time. If others in the future don't use gnupg-2, and require gnupg-1. What is the solution? None, no good.
(In reply to comment #49) > NO VERSION OF SEAHORSE WORKS WITH GNUPG-2. Is that clear? No. The patch *WORKS*. I have written it, and tested it. We keep this open only because you find the configuration of environment variables too complex. It works for the 0.8.X series and 0.9.X series, it was committed by upstream in 0.9.X series.
(In reply to comment #50) > > The patch *WORKS*. The patch applies. > I have written it, and tested it. Please provide exact steps then for me to get it working in my gnome desktop as you have yours. Thanks > We keep this open only because you find the configuration of environment > variables too complex. Um no it's that there is no place to put them that works reliably. As stated if I put eval `seahorse-agent --variables` in ~/.xprofile It can work for a bit in my gnome session. HOWEVER seahorse utilities do not recognize the seahorse-agent running. At times another seahorse-agent can get launched, since they don't acknowledge the one running. Like when it comes time for 0.9.x to cache ssh keys. I finally killed off the one that the session kept starting, due to being fired up via ssh, or a seahorse gui. Despite a seahorse-agent already running via --variables. Guess your not getting the difference of how seahorse works per --variables mode, and --execute mode. How is that working? Which once another seahorse-agent starts, the one that worked via the vars in ~/.xprofile are not longer valid. Passphrase is not cached, and I either get pinetry passphrase pops, or the same repeating pop ups from seahorse. Also these aren't just normal env variables. They must be available to all apps in the gnome session. So it's setting the variables in the session in a manner that is 100% recognized by all seahorse utilities, not to mention works 100% of the time. As it did before gnupg-2. > It works for the 0.8.X series and 0.9.X series, it was committed by upstream in > 0.9.X series. > When even upstream is telling me it's not going to work, and partly due to other things. Upstream also suggested a link, and I have tried all, and variations. None are working. In fact I will include the snippet where upstream suggested the link. "The short answer to all of the above is use seahorse-0.9.92 and chain seahorse-agent into starting your session like http://live.gnome.org/Seahorse/SessionIntegration says to. At the moment don't try and use gpg-agent from gpg-2.0 and seahorse." Which means I need at min, gpg-agent from gnupg-1, not 2. So what am I doing wrong? None of it I find difficult, just none so far work at all reliably and 100% of the time. Please provide your exact working steps. From emerge, to env vars, to logging into gnome session, entering passphrase once so it can be cached, then sending emails. From various instances of Evolution. Open first time, enter passphrase, it's catched, email signed, & sent. Close evo, and repeat. Then fire up other apps, like cvs, which will use my ssh keys to access cvs.gentoo.org. Then go back and send another email. All the while why having passphrase cached from the one entry. Also any seahorse tools being aware that an agent is running. As stated in comment 37 it did work very briefly for me with seahorse 0.9.x and gnupg-2, but you can see between comments, how much time past before it stopped working in my same login in session. Comment 38. Further attempts I could not even get that initial window. But as you also stated in comment 22, you did not have evolution at first, had to emerge it. And I am sure any testing you are doing is minimal, and not on an extending daily basis spanning weeks and months. Much less once the problem was created by your actions, really should have been doing the testing and resolving sooner. IMHO. Emerging evolution and seahorse back in January, not mid February. I had been using seahorse reliably with evolution, no problems since becoming a dev. So about 6+ months no problem, till first part of 07 when 2.0 was unmasked, and not slotted as 1.9.x was. Not to mention all the craziness I have gone through trying to get any version of seahorse to work as it did before gnupg-2, with gnupg-2.
Oh yeah and for gnupg-2.x to get stabilized it must work with a stable tree. Of which seahorse 0.8.2 is already stable. So till it can be resolve 100%. You are likely going to add breakage to the stable tree. It might be permitted to break ~arch for a few months. But I am pretty sure stable can't break at all. For any users or apps. So likely a solution will have to be documented, or there will be bugs filed. Much less getting gnupg-2.x stabilized so portage can take advantage of the new features, or what ever was mentioned in comment 42, #6. So good luck with stabilizing gnupg-2.x :) You might be able to avoid this stuff for now. But your modifications to seahorse would have to be committed as stable before gnupg-2.x can be. I for sure won't sign off there, and will comment on any stabilization bugs, till this is resolved. ;) Been trying to help, but even that will fall off shortly, leaving the burden to others.
More info. I tried reverting back to gnupg-1 with seahorse 0.9.2, even recompiled it. Seems there was a problem there, not sure if it was due to regression from gnupg-2 or what. Anyway I was experimenting a bit more. I ended up killing seahorse all together, just to see what would happen. This time I got a pop-up from it looks like gnome-keyring-manager. It's caching my gpg stuff from evolution and working as seahorse was. However only as long as evolution is open. As soon as I close and launch it again, I have to re-enter passphrase. Still less entries than before, but not quite back to what was normal before. Not sure if this ability was always there or not. No clue on why gnome has two quite similar apps. Not to mention their ability to integrate with each other is quite confusing. This might explain why seahorse 0.9.x worked at first with gnupg-2 via ~/.xprofile and env vars. But oddly stopped and did not again reliably. I will recompile 0.9.x less it's keyring use flag and see if that makes any difference. Having done that, I got 0.9.x to start working again with gnupg-1.4.x. I can start seahorse-agent just about anywhere as a deamon and as long as it's running. Passphrase and ssh keys are cached. Looks like the keyring flag on seahorse 0.9.x is causing some issues there. Testing again seahorse 0.9.x, less the keyring use flag, against gnupg-2.x. I tested via firing up the seahorse-agent via seahore guis/tools, by session, and by variables. Just to see if the keyring flag causes another instance of seahorse-agent to get started. I could live for now with the seahorse guis/tools not recognizing the seahorse-agent running. If it works 100% of the time I am logged into my gnome session. Ok did that, and things seem to be working again with seahorse 0.9.x WITHOUT keyring use flag set, gnupg-2.x, and setting env vars via eval, --variables in ~/.xprofile. Things seem to be back to working again. So got the possible solution working again, along with identifying another possible problem with the solution and seahorse compiled with keyring useflag set :) Hopefully this will continue working no matter what I do in my gnome session. Also the seahorse gui's are showing the agent running this time. So seahorse is 100%. Unless there are some benefits to the keyring use flag on seahorse 0.9.x, might be best to drop flag, and force to off for now. Also not sure if gnome session will remember seahorse-agent was running on log out, and try to start it again on log in. Despite it existing in ~/.xprofile and already being started. seahorse-agent likely needs to be modified so there can't be more than one instance running at a time. That would resolve gnome recording it in running session and re-starting on log in/ session initiation. Now this does not work with seahorse 0.8.x, so likely will have to wait till 0.9.x is in tree, and stabilized before gnupg-2 can be stabillized. For the record, seahorse 0.8.1 is stable in tree, no 0.8.2 as mistakenly stated in comment #52 This I would consider progress, finally :)
Ok after all that, I am finally concluding the eval `seahorse-agent --variables` in ~/.xprofile is not a working replacement or option. That one session I started before posting last comment. I just ended a bit ago, logged out of gnome. It was working fine, EXCEPT at one point when I tried to cvs up, my ssh-agent crashed. It seemed to effect seahorse a bit as well. No ssh passphrases could be catched. I figured I would log out and see how that would effect things. When I logged back in, seahorse-agent and etc worked with evolution just fine. BUT the seahorse guis tools weren't showing the agent-running. Which is similar behavior I have experienced and commented on before. Also means <100%, much less ssh issues. Giving up, I finally re-emerge gnupg-1.4.6, added seahorse-agent back to my gnome session. Still have seahorse 0.9.x without keyring useflag. Will need to file a bug on seahorse about those problems. Bottom line, gpg passphrase catching is back and working again. Not to mention ssh passphrase being cached now by seahorse-agent, without me having to do a ssh-add at a terminal in my gnome session. So back to 100%, and then some with the ssh, all with gnupg-1.4.x. So I will be sticking with gnupg-1.x for the foreseeable future. At least till upstream, seahorse developers, have a known resolution, and way for seahorse to work 100% with gnupg-2.
gnome: Can anyone test seahorse-1.0 and address this issue? Thanks!
I have taken this matter upstream. "Seahorse requires an install of GPG 1.x" http://www.gnome.org/projects/seahorse/RELEASE-NOTES-STABLE.txt End of story
(In reply to comment #56) > "Seahorse requires an install of GPG 1.x" > End of story Seahorse is broken, end of story indeed...
(In reply to comment #57) > (In reply to comment #56) > > "Seahorse requires an install of GPG 1.x" > > End of story > > Seahorse is broken, end of story indeed... > jacub: Seahorse is not broken. It is working with gnupg-2.0. The problem is that people should use it via environment variables instead of letting it update the gpg.conf file. This is where the reporter (gnome user) finds it difficult. If you run all from shell with proper environment settings all works (from my understanding and testing). I don't use gnome, so I cannot help in how to run a process at login which can affect the environment of the whole xsession. So I really don't think anything is broken, just that we need some help from someone who understand and explain how to make gnome work with session wide environment.
from my testings, even with proper environment variables, passphrase caching doesn't work. In evolution the passphrase dialog pops up when you click on an encrypted message, type the password, see the message, everything is good. Go to another message and come back to an encrypted message with the same key (I only have one anyway) and the passphrase dialog pops up again... Since I moved back to gnupg-1 I don't see this problem anymore. So maybe seahorse is broken but I don't understand why there is such resistance in slotting gnupg when the user has to mask some versions to make the darn thing work (given that upstream says it's slot safe)!
(In reply to comment #58) > > jacub: Seahorse is not broken. It is working with gnupg-2.0. alonbl: Prove it. I have asked for instructions for getting it to work in gnome. FYI Seahorse is now integrating more with gnome and going under the gnome projects umbrella. So it's not going to be as much of a side application, but the application for gpg and gnome. > The problem is that people should use it via environment variables instead of > letting it update the gpg.conf file. People meaning anyone wanting to use gpg inside a gnome desktop environment. Where in multiple applications will launch in a session. So the variable must be available in a session, to all applications. > This is where the reporter (gnome user) finds it difficult. Um, I have taken this upstream do the developers of seahorse. They have since gone upstream themselves. I have also tried just about every thing suggested, I could think of, and where session or etc variables are set. Nothing works as it does when I simple revert back to gnupg-1.4.6. > If you run all from shell with proper environment settings all works (from my > understanding and testing). > I don't use gnome, alonbl: That is the problem. You have effectively broken things that need to work in the gnome desktop environment. Things that are stable, and will prevent gnupg-2.x from going stable. > so I cannot help in how to run a process at login which can > affect the environment of the whole xsession. alonbl: This is a problem you have created. You need to setup a test environment and come up with a solution to the problem created. Otherwise there needs to be some other solution. Which there is unnecessary resistance against it. > So I really don't think anything is broken, just that we need some help from > someone who understand and explain how to make gnome work with session wide > environment. alonbl: Why don't you subscribe to seahorse developers mailing list. Go discuss this with the developers as I have. Which as a user of seahorse, gnome, etc is way over board. When you make a change in portage that breaks other packages. It's not others responsibility to fix that. There are versions of seahorse that are stable. No version of gnupg-2.x is stable. It's one thing to break ~arch for 2+ months. Breaking stable won't fly, thus gnupg-2.x won't be stabilized. So the point in all this is?
wltjr: You don't help in solving the problem, so please if you don't wish to help us solving the problem stop writing these long descriptions. The seahorse-agent is working as far as gnupg-2.0 is concerned, and I was in touch with upstream in order to resolve this issue. Gilles: Are you willing to help solving this issue? I don't believe the problem is on seahorse-agent, but somewhere on evolution side, I just need to pinpoint this. 1. Can you please create an ebuild for seahorse-1.0, verify that it is working with your current configuration. 2. Add USE debug and run seahorse-agent with --no-daemonize --variables, open a new shell, set the environment variable and execute evolution from there. See that the debug output is produceing, store it somewhere. 3. Upgrade to gnupg-2.0 4. Try 2 again. 5. Attach the output of both tests, or any strange behavior. Thanks!
(In reply to comment #61) > wltjr: You don't help in solving the problem, so please if you don't wish to > help us solving the problem stop writing these long descriptions. What is wrong with you? If you look through the past comments. I have tried everything suggested. That I can think of. That any document I can find covers. I have taken this upstream. I am going to escalate this matter. I have let it fester long enough, and seems some are just not getting things.
Created attachment 113289 [details] /usr/bin/gpg Here is a wrapper that seems to fix it for wltjr. Just replace the /usr/bin/gpg symlink with this wrapper. Here is a link to it if I do some mods: http://dev.gentoo.org/~betelgeuse/gpg-wrapper When this is committed the debug echo code should be removed.
(In reply to comment #63) > When this is committed the debug echo code should be removed. betelgeuse: I believe that gnome has some kind of mechanism to set environment to the whole session so these kind of wrapper are not nessary. Are you using gome? Can you please help us in finding where you can place the following: eval `seahorse-agent --variables` Thanks!
(In reply to comment #64) > (In reply to comment #63) > > When this is committed the debug echo code should be removed. > > betelgeuse: I believe that gnome has some kind of mechanism to set environment > to the whole session so these kind of wrapper are not nessary. > Are you using gome? Can you please help us in finding where you can place the > following: > eval `seahorse-agent --variables` > > Thanks! > I use KDE, keychain and enigmail and they currently work just fine for me. I just coded that script because robbat2 did not have the time and he gave me the algorithm.
(In reply to comment #65) > I use KDE, keychain and enigmail and they currently work just fine for me. I > just coded that script because robbat2 did not have the time and he gave me the > algorithm. > Oh... Thanks! Well... Me neither. since gnome herd is on CC and never commented, I guess we will not have a solution for this any time soon. I think the wrapper script is an ugly and not needed hack. Never the less, thank you for writing this.
alonbl: sure, GNOME might have a way to set the env vars higher up in the process tree, but the problem still exists whenever there is a need to have the environment outside of the existing process tree scope. Say you are starting gpg-agent with keychain when you login. Now upstream releases a security advisory for gpg-agent - do you force everybody to restart their X session? that's not acceptable. more importantly, wltjr reports that the wrapper attached here REALLY does fix the problem, while all past hackery with eval stuff everywhere has not. Additionally, he notes that because of the way --variables works, if your agent goes away in the middle of the session, it still breaks unless you use the wrapper.
alonbl: I also know that upstream gnupg rejected your patch to re-add the support for agent-info, but I think they are wrong in that regard. It really is a feature that is needed, and furthermore not having it breaks Werner's claims that gnupg2 is compatiable with gnupg1.
(In reply to comment #68) > alonbl: > I also know that upstream gnupg rejected your patch to re-add the support for > agent-info, but I think they are wrong in that regard. It really is a feature > that is needed, and furthermore not having it breaks Werner's claims that > gnupg2 is compatiable with gnupg1. Whatever. I don't think we should support something that is intentionally rejected by upstream. All claims you raised in comment#67 are valid but irrelevant, since this is not the way upstream supports this package. You raised your claims and they were rejected... So yes, you need to login/logout after an upgrade... Just like you would have done with ssh-agent. You need to take this back to upstream if you really believe that you are correct. But the whole discussion does not suggest why the environment magic did not work when running evolution from correct context. Is there some component which unset/modify GPG_AGENT_INFO?!?!?
digging at the evolution thing, there might be cases similar to the apache init script, where large parts of the environment are filtered.
(In reply to comment #70) > digging at the evolution thing, there might be cases similar to the apache init > script, where large parts of the environment are filtered. This is what needed to be found and fix (If actually exists).
i think you have a lot more chance of getting werner to change gpg than finding every other possible place that breaks this. I'm going to take the script to upstream gnupg in the meantime, and wltjr is taking it to the seahorse people.
(In reply to comment #69) > > Whatever. > I don't think we should support something that is intentionally rejected by > upstream. > If you want to go with what upstream does, don't install /usr/bin/gpg at all as that's what they do. src_install() { make DESTDIR="${D}" install || die dodoc ChangeLog NEWS README THANKS TODO VERSION dosym gpg2 /usr/bin/gpg dosym gpgv2 /usr/bin/gpgv echo ".so man1/gpg2.1" > "${D}/usr/share/man/man1/gpg.1" echo ".so man1/gpgv2.1" > "${D}/usr/share/man/man1/gpgv.1"
in reply to comment #61: yes, I'm willing to debug this. I'll report with the traces ASAP
Well all, I had some time, and since I don't trust any feedback from CC list anymore, I just installed latest evolution and seahorse (ebuild at bug#128780). I am not gnome or evolution user... But with my low skills I could make evolution to work. And suprise suprise, everything including seahorse is working for me. seahorse is working great with gpg2 (User should switch into environment in stead of modifying configuration file). evolution does not block the GPG_AGENT_INFO environment variable, I run it from a shell having this variable in its environment. gpgme-1.4 works OK. I may be crazy, but there is a proper way to solve issues. I will be most glad if someone will HELP in finding the REAL problem and cause. I am sure that after we find the cause we will be able to quickly solve this. So the cause is not seahorse -- I am sure. The cause is not evolution -- As it does not block the environment variable. The cause may be gpgme as I did not get any response regarding bug#170910 -- But it works for me. The cause may be gpg2 as this is bug is all about it... But I am not sure we find the cause there. The cause may be end-user setup environment which is different than mine -- But I don't have any special environment. The cause may be human factor... I believe this is the one... Anyone is willing to help SOLVING this issue?
Just for the record: app-crypt/gnupg-2.0.3 app-crypt/gpgme-1.1.4 app-crypt/seahorse-1.0 mail-client/evolution-2.8.3-r1
(In reply to comment #76) > Just for the record: > app-crypt/gnupg-2.0.3 > app-crypt/gpgme-1.1.4 > app-crypt/seahorse-1.0 > mail-client/evolution-2.8.3-r1 > Strange as seahorse release notes specify that you need gnupg-1* http://www.gnome.org/projects/seahorse/RELEASE-NOTES-STABLE.txt Changes between 0.9.92 and 1.0: ================================ * Seahorse requires an install of GPG 1.x Looking at their configure.in it can only be installed with 1.2 or 1.4 installed. checking for appropriate GnuPG version... configure: error: Appropriate version of GnuPG not found. Please install one of versions: 1.2 1.4 Also you should note that this bug has been opened way before 1.0 was released and as such version bumps could have solved this issue in between. Also seahorse-1.0 does not seem to be available in Portage yet.
(In reply to comment #77) > Looking at their configure.in it can only be installed with 1.2 or 1.4 > installed. > > checking for appropriate GnuPG version... configure: error: Appropriate version > of GnuPG not found. Please install one of versions: 1.2 1.4 > > Ah I see you sed the configure.in to accept 2.0. But there must be some reason why upstream still wants 1* ?
(In reply to comment #77) > Strange as seahorse release notes specify that you need gnupg-1* > > http://www.gnome.org/projects/seahorse/RELEASE-NOTES-STABLE.txt And on http://www.gnome.org/projects/seahorse/download.html it states: * GnuPG 1.2.x, 1.4.x or 2.x But if it works, why argue about quotes. > Looking at their configure.in it can only be installed with 1.2 or 1.4 > installed. This is a mistake. They removed 2.0 from configure of my patch, applied everything else and even made some improvements. > Also you should note that this bug has been opened way before 1.0 was released > and as such version bumps could have solved this issue in between. I know! I solved it!!!! I even had a patch for current portage version. > Also seahorse-1.0 does not seem to be available in Portage yet. As I wrote in comment#75, ebuild for seahorse-1.0 is at bug#128780. The only issue is gpg-agent which now accept only environment settings. And it seems the cause that making people confused.
(In reply to comment #78) > Ah I see you sed the configure.in to accept 2.0. But there must be some reason > why upstream still wants 1* ? Not that I can think of. There was a change in the agent protocol in gpg-agent of gnupg-2.0. This was resolved, upstream accepted the patch. Now, as far as gpg-agent is conserned and as for my testing there should be no other incompatibilities between seahorse and gpg-agent.
(In reply to comment #75) > > I am not gnome or evolution user... But with my low skills I could make > evolution to work. Please provide exact steps and details. Claims are not sufficient. > And suprise suprise, everything including seahorse is working for me. Everything including what? Describe what was working? Did seahorse GUI's tools show the agent as running? > seahorse is working great with gpg2 (User should switch into environment in > stead of modifying configuration file). Switch into the environment? What does that mean? > evolution does not block the GPG_AGENT_INFO environment variable, I run it from > a shell having this variable in its environment. You are starting evolution from a shell? What about from a gnome menu? Or Desktop icon? Where is the GPG_AGENT_INFO variable set? Can you stop/restart seahorse-agent mid session and have everything working when evolution is launched via gnome menu or etc? > I may be crazy, but there is a proper way to solve issues. I will be most glad > if someone will HELP in finding the REAL problem and cause. I am sure that > after we find the cause we will be able to quickly solve this. If you would join the developer mailing list and discuss it with the developers of seahorse and etc. That would help considerably. No clue why one would attempt to resolve issues like this, outside of working with upstream. > The cause may be end-user setup environment which is different than mine -- But > I don't have any special environment. You need to describe your environment. Are you using gnome session? How are you starting seahorse-agent and from where. > The cause may be human factor... I believe this is the one... > > Anyone is willing to help SOLVING this issue? Yes for two months now. You just keep leading in crazy directions. Had we followed robbat2's comment from the get go. Written a wrapper script like Betelgeuse did. Which works 100% as things did before gnupg-2. Which I have also provided to upstream. We would have been mostly done with this months ago. Which IMHO the script is still a hack, but everything we have done so far is much worse. Dropping in the script in place of gpg -> gpg2 symlink. Is all that is required to make things work. Beyond that one can launch seahorse-agent via preferences gui, and/or have it started by session on login. If for some reason seahorse-agent crashes, or one wants to stop it mid session. Then restarts it, all apps work. Unlike when working with a non-updateable global session variable.
wltjr: I am not using it from gnome menu, I am using evolution from shell with proper environment settings. After I get prompted from passphrase I get a try icon which allows me to view cache and clear it. I don't see any option to see if agent is running. You CANNOT stop/start the agent without modifying environment. This feature will not be available with gnug-2.0. So if you use gnome session you must login/logout. This is not new we already discussed it, so why you keep asking about this? In order to prove that there is actually no issue to solve, I made the effort of installing all the related packages, I think my experiment prove that. But I won't install gnome... As I believe someone from gnome herd should help in finding out what you are doing wrong so environment variable are not propagated. With all the respect on your efforts and the fact that your are a Gentoo developer, please stop tell me how to solve the issue, and find what is wrong with your environment, it should not be so difficult to make it work. The fact that you point us to upstream when there is actually no problem to solve also does not help us nor upstream. There is a line describing how environment can be set: http://live.gnome.org/Seahorse/SessionIntegration I guess the .gnomerc alternative is the simplest. This is the last time I (alonbl) handle this issue, unless someone actually finds a problem. I don't really care if it is not solved or robbat2 decides to continue working on this or creating any hack as he desires. But if we start branching upstream I guess I will stop (my-self) handle gnupg packages. I think this issue should have been closed as RESOLVED:INVALID a long time ago. But with respect to you, wltjr, we are still discussing this.
(In reply to comment #82) > wltjr: I am not using it from gnome menu, I am using evolution from shell with > proper environment settings. That's not going to fly. Most people will launch from an icon, either on menu, menubar, or desktop icon. > After I get prompted from passphrase I get a try > icon which allows me to view cache and clear it. I don't see any option to see > if agent is running. If you have an icon in your notification area, a lock. That confirms the agent is running. > You CANNOT stop/start the agent without modifying environment. That is how it has always worked. So when people are going to first start the agent how can they do that? They have to start it via the seahorse preferences GUI. Which then the session records it and will restart it on next log in. However once they start the agent via the GUI it's immediately available in that session. This is how it has always worked, and needs to going forward. >This is not new we already discussed it, so why you keep asking > about this? Because you are breaking existing functionality that people are used to. It's not going to fly. > In order to prove that there is actually no issue to solve, I made the effort > of installing all the related packages, I think my experiment prove that. Again I have yet to have you detail steps on how you are setting up your environment. How you are starting seahorse-agent in the first place. How many times must I ask for the steps in detail? So I can follow them, and get to where you are. > But I won't install gnome... As I believe someone from gnome herd should help > in finding out what you are doing wrong so environment variable are not > propagated. How the hell are you testing this if you don't have gnome installed. You need the full gnome desktop environment with gnome session and all. Get on board. > With all the respect on your efforts and the fact that your are a Gentoo > developer, please stop tell me how to solve the issue, and find what is wrong > with your environment, it should not be so difficult to make it work. You have yet to replicate a normal gnome environment. As you have stated you are not a gnome user. So don't tell me my gnome env is incorrect. It's been fine for quite some time. I spent considerable time looking for where in the gnome env I could start seahorse agent via --variables and have it working. Plus as a gentoo developer again, why are you not on upstream mailing lists? Why are you not creating a full environment to test and work this out? Why are you dumping this problem you created on others? Expecting them to help resolve it. If I added a package to tree, that broke any package. Even an old one no one uses. It's my fault. I must do what ever is necessary to make things right again. It's no one else's responsibility to fix my breakage. Not the package maintainer of the package I broke, any other dev, and surely not users of said broken package. > The fact that you point us to upstream when there is actually no problem to > solve also does not help us nor upstream. Um if you would communicate with seahorse developers there are quite many problems regarding all of this. They have many bugs filed, and more than one thread on the developers ml about all this. If their S.F. archive was not screwed up. I would provide links so you could follow it that way. Upstream had many reports of a symlink from gpg -> gpg2 causing seahorse to crash flat out. They were surprised we did not have that problem on Gentoo. > There is a line describing how environment can be set: > http://live.gnome.org/Seahorse/SessionIntegration Nice, re-providing a link provided in comment 51 > I guess the .gnomerc alternative is the simplest. Again as previously stated in this bug, .gnomerc is not a viable solution. It did not work for me. Must we spin the merry go round? > This is the last time I (alonbl) handle this issue, unless someone actually > finds a problem. Again it's breakage you caused. If you refuse to work on the matter to find a solution, and simple leave it to others. I will likely have to escalate the matter. > I don't really care if it is not solved or robbat2 decides to continue working > on this or creating any hack as he desires. But if we start branching upstream > I guess I will stop (my-self) handle gnupg packages. That's probably best for now. Since you obviously do not want to deal with all problems of maintaining said package. Nor do you want to work with, or listen to those trying to help resolve all this with you. It's wasted hours of my time, because of your mess. So no gripes form me if you let someone else maintain that package. The few HOURS I spent yesterday with robbat2 and Beltegeuse, produced the only 100% working solution for gnupg-2 and seahorse. Which was a simple script. Something that was suggested quite early on and ignored for some reason. alonbl: No matter, I still explored every path you suggested and more. None worked, all had issues and at best was 80%-90%, never 100%. > I think this issue should have been closed as RESOLVED:INVALID a long time ago. > But with respect to you, wltjr, we are still discussing this. Dude it's not fixed or resolved. Bottom line, seahorse is stable on Gentoo. gnupg-2 is not. Good luck there ;) And oh by the way, did you not notice another user commenting about the same problem, comment 59. How many more have to run into this same problem. Before you will believe it to be real. Realize it was caused by your actions. That there is more to be done to resolve the matter. For now we have a working solution, and IMHO a wrapper script is a much better replacement for a gpg binary, than a symlink from gpg -> gpg2. So question is, do we make said wrapper part of a gnupg-2 install? I am thinking it would be a good idea. Might be some other quirks we can deal with on gnupg-2 only systems via the wrapper.
FTR, gpg2 works fine in gnome in general; I've been using it for a long time now, via keychain. I don't use seahorse, and have zero interest in it (which is why I haven't commented so far). The gpg agent correctly caches my gpg pasphrase for the configure length of time, and evolution correctly uses the agent to access my gpg keys. I suspect the easiest way to do this would be to use keychain.
dang: are you aware seahorse will be the official gnome app for gpg, ssh key caching, keyring and etc in Gnome 2.18. I am not sure if gnome-keyring-manager will remain or not. I can't find a project home page atm for gnome keyring manager. Seahorse http://www.gnome.org/projects/seahorse/ http://live.gnome.org/Seahorse It's no longer something developed outside of gnome.
Yes gnome-keyring-manager will still be present in Gnome 2.18, but in gnome 2.20 will only be seahorse. "Since seahorse and gnome-keyring-manager are sharing use cases, it seems a good goal for GNOME 2.20 to integrate all missing features in seahorse and deprecate gnome-keyring-manager (since seahorse is more actively developed and maintained). This needs discussion with developers from both modules, though." http://lwn.net/Articles/218548/ So seahorse is not going anywhere, and is not as much of an optional package as it was in the past.
At the moment, seahorse and gnome-keyring-manager are orthogonal. gnome-keyring-manager encrypts and keeps <key, secret> pairs, and is used for things like storing passwords for evolution. I'll be surprised if it goes away, but there's pleanty of time to deal with that. I, personally, don't care if seahorse is official or not; I still won't use it, because keychain (note: not keyring, keychain) is much more useful. However, I guess it's important that seahorse work. I guess one of us will have to look into it...
just for the record... seahorse completely replaces gpg-agent, which is not a wise thing to do, since gpg-agent has many features that are not supported by seahorse, for example: storing private keys redirecting requests to smartcard, redrecting request to other agents. So current design of seahorse will not enable it to live much longer. I've briefly discussed this issue with upstream, they are aware of the problem, I raised an option to implement it as a transparent bridge between the application and original gpg-agent, modifying the UI state as commands pass from application to gpg-agent. All seahorse need to be is a UI, every crypto functionality should be implemented by appropriate project, so that people be able to see their key state in a fancy UI. So there is a long way to go until such component can be used as mainstream key manager even in gnome environment.
Hi, did some new test with latest gpg2/gpgme, seahorse-0.9.92 and evolution 2.9.92 In this attempt, I tried launching seahorse using gnome session in the control-center (which is how I understood seahorse-agent should be launched from the text in seahorse preferences). As it didn't work, I tried the ubuntu way describe on l.g.o (I had to tweak init scripts to get it working) Then I launched evolution to see how it behaved wrt do passphrase handling. In the first case, pinentry poped up in place of seahorse so I guess this is not the proper way to launch seahorse-agent and upstream needs better wording in the preference dialog. In the second case, exactly like when we launched seahorse-agent from .xprofile (.xsession isn't loaded unless you select custom session in gdm afair). The first time you click on an encrypted email, seahorse agent asks for you passphrase, then you see the lock in the notification area meaning the passphrase in now cashed (for me the cache lasts 5 minutes). Clicking to another and coming back to this mail in less than 5 minutes prompts the passphrase dialog again and the lock disappear. This test were done by launching evolution either from an icon or by restoring the session. Looking at gnome-terminal to see what's the gnome env, in the first case, there is no GPG* env var, while in the second they are present. I couldn't get proper traces since I was in a hurry this morning. Will post some ASAP.
(In reply to comment #89) > Hi, did some new test with latest gpg2/gpgme, seahorse-0.9.92 and evolution > 2.9.92 Thanks for you description. Can you please use seahorse-1.0 for your tests? ebuild is available at bug#128780. I recommend that before you solve the whole gnome environment hacks, just run all manually as described in comment#61.
*** Bug 159505 has been marked as a duplicate of this bug. ***
I had time to retest this with gnupg-2.0.3, gpgme-1.1.4 and seahorse-1.0. The behavior was the same than my previous comment so I talked about it upstream. According to Albrecht Dreß: > Afaict, the interaction between gpgme and gpg2 is at least party broken > [1, 2]. I guess seahorse will not work in this environment unless the gpg > people fix their part. > Unfortunately, there has been *no* progress yet (not even a comment from > the gpg developers), although I reported this fact in both the gnupg-devel > list and in the bug tracker. This is clearly a very unsatisfactory > status, and it does apparently hit /any/ application using gpgme (in my > case the MUA Balsa [3] which does not interact with seahorse). > [1] https://bugs.g10code.com/gnupg/issue772 > [2] http://lists.gnupg.org/pipermail/gnupg-devel/2007-February/023676.html > [3] http://balsa.gnome.org So this afaict/s this is not a problem with gnome, seahorse nor evolution but with gnupg2 and gpgme.
*** Bug 172643 has been marked as a duplicate of this bug. ***
Upstream thread on this topic seahorse and gnupg2 http://sourceforge.net/mailarchive/forum.php?thread_name=1174765646.12335.11.camel%40su.perronet.esiee.net&forum_name=seahorse-devel
Anybody got better ideas on how to get upstream GnuPG to look at the actual bug?
(In reply to comment #95) > Anybody got better ideas on how to get upstream GnuPG to look at the actual > bug? > Threat of violence or war maybe ? :) Everyone is bugging them and they seem quite reluctant to even comment. Not sure if that's due to both being able to co-exist, and simply just not having gnupg-1. Or what, but a comment or something from gnupg devs would surely help to shed some light at least on a direction this should all be going. Less they are silently working on a solution? Seems they are the same upstream for gpgme, so it's all in their hands. Otherwise you know my thoughts on resolution. Same today as day one, at least till upstream gets their act together :)
*** Bug 174363 has been marked as a duplicate of this bug. ***
*** Bug 175351 has been marked as a duplicate of this bug. ***
Ok 4 months is enough. Taking this matter upstream has not resolved a single thing. The arguments presented so far to have gnupg-2 only system seems more personal preference than technical merit. Much less feasibility. This needs resolution sooner than later. As I stated on day one, back in early January on bug #159623. The only resolution AT LEAST FOR NOW seems to be to slot gnupg and provide BOTH gnupg-1 and gnupg-2. Even if there is technical benefits to a gnupg-2 only system, it's not feasible at this point. I hate to escalate this matter, but this breakage, and dep graph borkage MUST be resolved sooner than later. Neither gnupg-2 or newer versions of Gnome like 2.18 will ever be stabilized till this is resolved. Upstreams are pointing fingers all over the place, then claims of everything working. So we need a downstream resolution. If this is not resolved in a timely manner I will take the topic to the -dev ml. Where it's likely to turn into another unnecessary flame fest. But hopefully something will come out of it, so this can be resolved. Dup bugs are racking up, and it's time to close all and put this matter to end, 4 months later.
I'm fully willing to stabilize gnome 2.18 without seahorse. Seahorse is *not* important enough to hold up gnome 2.18. Doesn't mean this doesn't need to be fixed.
(In reply to comment #100) > I'm fully willing to stabilize gnome 2.18 without seahorse. Seahorse is *not* > important enough to hold up gnome 2.18. Doesn't mean this doesn't need to be > fixed. Sure no worries, but it's upstream Gnome project that keeps touting Seahorse as part of Gnome 2.18 http://www.gnome.org/start/2.18/notes/en/ Not to mention the media :) "The best new feature in 2.18 is Seahorse" http://www.linux.com/article.pl?sid=07/04/02/1919225 http://www.desktoplinux.com/news/NS8054031017.html ... So gnome can surely be stabilized without. But that same gnome will lack entirely any integrated encryption capabilities. Which is one of 2.18's MAJOR selling factors. At least that's how it's been portrayed. Which would make Gentoo one of the few if not the only distro without Seahorse or etc. Much less the only one not shipping gnupg-2. Neither of which I see as selling factors for Gentoo.
All the problems withstanding, At the moment, seahorse-1.0.1 depends on =app-crypt/gnupg-1.4* and >=app-crypt/gpgme-1.0.0 gpgme-1.1.4 depends on >=app-crypt/gnupg-1.9.20-r1 This leads to a dependency loop and blockages with gnupg-1.4.7 and gnupg-2.0.3-r1 both needed.
(In reply to comment #101) > > Which would make Gentoo one of the few if not the only distro without Seahorse > or etc. Much less the only one not shipping gnupg-2. Neither of which I see as > selling factors for Gentoo. Correction, not shipping gnupg-1
Update: [1] https://bugs.g10code.com/gnupg/issue772 [2] http://lists.gnupg.org/pipermail/gnupg-devel/2007-February/023676.html Should have been solved in gnupg-2.0.4, it may help with progress.
Is there any work on this atm? I don't like it when updates fail - and this one breaks updating for too long.
There's an ongoing discussion on the -dev mailing list at the moment.
Hello, This is the last issue we have with gnupg-2. I don't want to start a new flame here. I need someone to work with to find the root cause of this issue. And no... gnupg-2 is not a valid root cause. There are many other applications which use the gpg/gpgme interface including kmail and all are working fine. As per comment#75 at my side all is working correctly. So I need someone that can reproduce this issue and can DEBUG and find the exact cause. After we have a cause we will have a solution. 1. Install latest (~arch) of all tools: evolution, gnupg, gpgme. 2. Install seahorse as per bug#128780 with debug USE flag. 3. Open SHELL window. 4. Execute: $ eval `seahorse-agent --variables` 5. WITHIN the SAME shell, run evolution. 6. Try whatever seahorse interaction. Thank you for your cooperation.
I have been told (although I haven't tried myself) that seahorse-2.19.4 works with gnupg-2. It's available in the gnome overlay: http://overlays.gentoo.org/proj/gnome/wiki/WikiStart
The only change I can see that maybe related is the following one. There is another one in seahorse-2.19.4/libseahorse/seahorse-util.c::seahorse_util_gpgme_to_error but it looks like it only for error parsing. --- --- seahorse-1.0.1/libseahorse/seahorse-gpg-options.c 2007-03-17 21:36:55.000000000 +0200 +++ seahorse-2.19.4/libseahorse/seahorse-gpg-options.c 2007-06-16 01:57:03.000000000 +0300 @@ -248,7 +248,8 @@ gpg_options_init (GError **err) * around with the configuration file. */ g_return_val_if_fail (engine && engine->version && engine->file_name && - (g_str_has_prefix (engine->version, GPG_VERSION_PREFIX1)), + (g_str_has_prefix (engine->version, GPG_VERSION_PREFIX1) || + g_str_has_prefix (engine->version, GPG_VERSION_PREFIX2)), (seahorse_util_gpgme_to_error (GPG_E (GPG_ERR_INV_ENGINE), err), FALSE)); /* Now run the binary and read in the home directory */
ok, just tested it with a full 2.19.3 desktop and gnupg-2.0.4. launching from the console works ok and now passphrases are properly cached. I have yet to find how to call seahorse-agent to have the proper variables set for the whole session. It seems my previous trick doesn't work so well anymore. More on that later.
(In reply to comment #110) > ok, just tested it with a full 2.19.3 desktop and gnupg-2.0.4. Thank you! Just curios... Are you sure that seahorse-1.0.1 does NOT work with same configuration?
for some strange reasons, try old methods I can come up with (3), GPG_AGENT_INFO is not set correctly. What I mean (and as strange as it may look) is that I start my session and evolution picks up seahorse-agent as it should even if GPG_AGENT_INFO points to nowhere and gpg.conf doesn't have gpg-agent-info set. For the moment I'm using the following method : add /etc/X11/xinit/xinitrc.d/70seahorse-agent as an executable script. ==== #!/bin/bash unset GPG_AGENT_INFO seahorseagent="`which seahorse-agent 2> /dev/null`" eval `$seahorseagent --variables` ==== if somebody would like to confirm I'm not crazy, I would be relieved :) anyway, in reply to comment #111, I didn't tried yet, but I'm planning to. Will keep you posted
Well... gnome... I see nobody cares. This is unfortunate, especially due to the long CC list.
6+ months later what do you expect? I gave up on this long ago. I have gnupg-2 masked and have been sticking with gnupg-1. Now that it's no longer a depgraph issue. I imagine many others are happy with that route, and not looking to waste any more time on this. I did all I can, was willing to, and them some. I have my own problems to solve and things I want to do in Gentoo with my little free time. I will leaving chasing tails and going in circles to others.
wltjr: Have you read comment#110, comment#111, comment#112? IT IS WORKING!!! I am still waiting for some kind of progress on eva side to try and find the root-cause of current version. And please please please don't start flamewar again, this will not help.
(In reply to comment #115) > wltjr: Have you read comment#110, Launched from command line, NOT GNOME SESSION > comment#111, Your reply to 110? hardly any proof > comment#112? Has nothing to do with Gnome sessions. They have some script they are using which to my knowledge is not current part of the ebuild, provided by, or installed by anything. > IT IS WORKING!!! Has it been committed to tree? So I can just emerge it and use as I am now and things will all be fine? How the hell do you consider that working? If it's working why is this bug open? What are you still waiting on? > I am still waiting for some kind of progress on eva side to try and find the > root-cause of current version. There has been no progress on this. Due to stubbornness of package maintainers. > And please please please don't start flamewar again, this will not help. This entire situation exists because of your actions, and flat out stubbornness and refusal to slot and provide both. Just as upstream intends, all other distros do, and every upstream release note on gnupg states. Your the one who lit the bonfire. Want me to go away. Fix the problem you created, or come up with a temporary solution TODAY. Not next year. That is if stabilizing gnupg-2 is one of your goals. Robing me and users of a choice over gnupg-1 vs gnupg-2 by forcing me to have just one or the other. When both are current, actively maintained and etc. Completely pointless from day one.
I there, I know I'm late and I still didn't looked at the 2.18 version but... but I finaly found what was wrong with my setup and I can now say that seahorse does integrate well with gnome and gpg2 only (or gpg2+gpg1 slotted) and that you can even tie it to keychain (ssh only and with a trick for the moment). For instructions please see http://live.gnome.org/Seahorse/SessionIntegration. I'll now look it reviving an ebuild for 2.18 with gpg2 support.
seahorse-2.20 will support gpg2 (just need to wait for the 2.20 push into the tree).
oops, closed the wrong bug.
Hello, Can anyone confirm seahorse-2.20.0 is working so we can close this? Thanks!
I can confirm seahorse works with gpg2 in gnome-2.20
Thanks! Closing.
*** Bug 231640 has been marked as a duplicate of this bug. ***
