Thanks for a bug report. There are two parts which can ask for a password of a GPG key. One it within evolution itself, another one is with a gpg agent. The dialogs looks similar, but they are not the same. I suppose that one of your systems is using the gpg-agent, while the other not.

The gnupg2 package provides /usr/bin/gpg-agent on Fedora 21.
Then the ~/.gnupg/gpg.conf can contain a 'use-agent' key, which I have commented out here. Check also 'man gpg-agent' for some information on it.

Did this help?

No, this did not help. First off, why would the gpg-agent be picked on one system and an internal evolution one elsewhere?

Second, if I wanted to use the built-in agent, how would I do that?

Lastly, 'man gpg-agent' doesn't contain any guide on the gpg.conf and the actual gpg.conf comments don't include usage examples.

(In reply to Stephen Gallagher from comment #2)
> No, this did not help. First off, why would the gpg-agent be picked on one
> system and an internal evolution one elsewhere?

I do not know how similar the two systems are, they can have different settings, including the one for gpg-agent usage.

> Second, if I wanted to use the built-in agent, how would I do that?
> 
> Lastly, 'man gpg-agent' doesn't contain any guide on the gpg.conf and the
> actual gpg.conf comments don't include usage examples.

Okay, the settings might change meanwhile. And I'd say this is completely out of scope of evolution, because evolution only calls the gpg2/gpg binary. I can reproduce it on a command line too. Please try out (with your key's email address):

   $ gpg2 -o /tmp/test.gpg -r user\@example.com -e ~/.bashrc
   $ gpg2 -d /tmp/test.gpg

The first command encrypts the ~/.bashrc file, while the second decrypts it. When I run the second command, then I get two gpg warnings:

   gpg: WARNING: The GNOME keyring manager hijacked the GnuPG agent.
   gpg: WARNING: GnuPG will not work properly - please configure that tool
                 to not interfere with the GnuPG system!

I guess your two systems will behave differently and the reason might be that one of the required packages for the desired behaviour is not installed (or is installed and prevents the behaviour for you) on one of those systems. Which package it is I do not know, but the gpg warning gives a hint. I'd guess it's gnome-keyring-pam, though it is installed together with gdm and gnome-shell on Fedora, thus you might have it. Maybe you've it configured differently, I really do not know this piece of software.

So this is odd... as soon as I used gpg2 at the command-line, I got the same graphical prompt for my password. But subsequent usages of it did *not* prompt again. Even stranger, Evolution stopped prompting me after I did this.

So now I'm quite puzzled.

Correction, it only lasts until Evolution is restarted; then I get prompted again every time.

Just for additional information, it looks like the actual issue is described (and debated) here: https://lists.gnupg.org/pipermail/gnupg-devel/2014-August/028689.html

Due to the unfortunate conflict between GNOME and upstream, we really need to not use gpg2 for the time being. I think the short-term solution is for Evolution to never use gpg2, and always call gpg with --use-agent (which is on by default for gpg2, off by default for original gpg: users should never have to edit weird text files to make GNOME apps work properly, so we'll need to override the option). I *think* that should get things working again for Fedora 22.

(I think I was the one who suggested preferring gpg2 to gpg if gpg2 is present, so that GNOME's GPG agent will be used by default, which seemed like a good idea at the time. But clearly that plan has been foiled.)

As a real long-term solution, we have a couple students (probably for GSoC) looking into creating a GNOME pinentry, as discussed in the above thread. The problem is that it will be impossible without new API in GnuPG, so that requires cooperation from Werner, who is opposed to saving passwords, but hopefully less opposed to it than he is to the status quo... so we'll see what happens. :)

(In reply to Michael Catanzaro from comment #7)
> (I think I was the one who suggested preferring gpg2 to gpg if gpg2 is
> present, so that GNOME's GPG agent will be used by default, which seemed
> like a good idea at the time. But clearly that plan has been foiled.)

The change was done in time of evolution-data-server 3.11.5, 2014-01-21, as a reaction on (truly yours) downstream bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1055598

I do not think that reverting the change to prefer gpg over gpg2 is a good step. Once all the dependencies which require gnupg will be ported to use gnupg2 the old gpg will be gone anyway. Neither I agree with forcing to use the agent in evolution-data-server. It's user's choice, not evolution's, whether they'll use the agent or not.

I also noticed claims on command line from the gpg that gnome-keyring (or some such) stole the agent window and that some things might not work properly (I'm sorry, but I do not have exact wording of the message; Fedora 22 doesn't show it, thus maybe it's obsolete there).

I see a migration notice when running gpg2 for the first time, which might not be a problem, but anyway, once gpg2 is used, it should be kept using, no? Changing this behavior between versions looks bad.

The migration notice looks like this for gnupg2-2.1.1-2.fc22:
> gpg: starting migration from earlier GnuPG versions
> gpg: porting secret keys from '/home/mcrha/.gnupg/secring.gpg' to gpg-agent
> gpg: key 94E2DD4F: secret key imported
> gpg: migration succeeded

You can try to "fix" Fedora 22 by symlink gpg2 to gpg, right?

(In reply to Milan Crha from comment #8)
> The change was done in time of evolution-data-server 3.11.5, 2014-01-21, as
> a reaction on (truly yours) downstream bug report:
> https://bugzilla.redhat.com/show_bug.cgi?id=1055598
> 
> I do not think that reverting the change to prefer gpg over gpg2 is a good
> step. Once all the dependencies which require gnupg will be ported to use
> gnupg2 the old gpg will be gone anyway. Neither I agree with forcing to use
> the agent in evolution-data-server.
>
> It's user's choice, not evolution's,
> whether they'll use the agent or not.

TBH, without an option in the GUI, I don't think the user has any real choice. It's just not reasonable to expect the user to figure out how to edit a hidden configuration file in order for passwords to be saved. But as long as gpg2 is used, the gpg agent is guaranteed to be broken, so it's a moot point as long as Evolution uses gpg2 at all.

This situation is unfortunate. :(

> I also noticed claims on command line from the gpg that gnome-keyring (or
> some such) stole the agent window and that some things might not work
> properly (I'm sorry, but I do not have exact wording of the message; Fedora
> 22 doesn't show it, thus maybe it's obsolete there).

GNOME relies on implementation details of GnuPG (the GSoC project would be to add new GnuPG API and use it in gnome-keyring, so we can stop doing that), which changed. Distros shipping GNOME are responsible for not upgrading gpg2 past one of last summer's releases (bad since they fix security issues all the time) or ensuring that applications use only the original gpg until the situation is resolved. Fedora chose to upgrade gpg2 and force seahorse to use the original gpg to keep working, which was probably the right choice.

For Evolution, I see two sane options: (a) force Evolution to use original gpg, or (b) do nothing and accept that GPG passphrases won't be saved until the situation gets properly resolved.

(b) seems the less-desirable option to me, since it is not only a change in the default behavior (gpg2 with functional gpg agent -> passwords get saved by default; no longer saving passwords is a change in the default, even though Evolution did not change) but also effectively a removal of the feature for users who aren't familiar with gpg.conf, but neither choice is good. GPG will still be a terrible way to encrypt email regardless....

> I see a migration notice when running gpg2 for the first time, which might
> not be a problem, but anyway, once gpg2 is used, it should be kept using,
> no? Changing this behavior between versions looks bad.
>
> The migration notice looks like this for gnupg2-2.1.1-2.fc22:
> > gpg: starting migration from earlier GnuPG versions
> > gpg: porting secret keys from '/home/mcrha/.gnupg/secring.gpg' to gpg-agent
> > gpg: key 94E2DD4F: secret key imported
> > gpg: migration succeeded

Good point :-(

> You can try to "fix" Fedora 22 by symlink gpg2 to gpg, right?

Hmm... no, making gpg2 a symlink to gpg would tell programs that they can use gpg2-specific commands. The other way around -- make gpg a symlink to gpg2 -- would make sense, but also make this problem impossible to solve. (That is what SUSE has done -- since gpg2 is incompatible with GNOME, their Seahorse is seriously broken!) Besides, there's little chance of convincing the Fedora GnuPG maintainers to remove their package from Fedora over a situation that's not their fault. What we could do is have gnome-keyring conflict with gnupg2, simply to ensure it never gets installed. But that seems like the nuclear option to me, which we should only use if this is causing problems for many apps, but the guidance to use original gpg if you want password storage seems sufficient to me, especially since Evolution is the only app I'm aware of to be affected. (I imagine most use original gpg, and so never had password storage.)

> Fedora chose to upgrade gpg2 and force seahorse to use the original gpg to
> keep working, which was probably the right choice.

Do you mean that the package has a patch, or that the work was done by the Fedora maintainer only? I'm fine to do the same, I only need to know which option is preferred. Any pointers would be helpful.

(In reply to Milan Crha from comment #10)
> > Fedora chose to upgrade gpg2 and force seahorse to use the original gpg to
> > keep working, which was probably the right choice.
> 
> Do you mean that the package has a patch, or that the work was done by the
> Fedora maintainer only? I'm fine to do the same, I only need to know which
> option is preferred. Any pointers would be helpful.

seahorse was patched to force use of whatever version of GnuPG was present at build time: http://pkgs.fedoraproject.org/cgit/seahorse.git/commit/?id=32a5dd3ad58389f9573edea28b66ceb26424db28

(The change was merged upstream, so there is no longer a patch in Fedora.)

Okay, thanks. Let's switch back the preference in evolution-data-server too.

Created commit 457febf in eds master (3.17.1+)
Created commit 18239c4 in eds gnome-3-16 (3.16.2+)

(In reply to Michael Catanzaro from comment #11)
> seahorse was patched to force use of whatever version of GnuPG was present
> at build time:
> http://pkgs.fedoraproject.org/cgit/seahorse.git/commit/
> ?id=32a5dd3ad58389f9573edea28b66ceb26424db28
> 
> (The change was merged upstream, so there is no longer a patch in Fedora.)

And that had been reverted around 3.18.0 time:
http://pkgs.fedoraproject.org/cgit/rpms/seahorse.git/commit/seahorse.spec?id=41ab3d1f8f2309b63ccd2e02236219ede437a369

I forgot to add, I'm going to prefer gpg2 again, thus keys generated in seahorse are usable in the evolution-data-server. I'll do that within bug #759153. There is also added an option for 3.20.0 to override what gpg binary will be used, part of bug #759392.

I agree, it should be safe to switch back to gpg2 now.