Description of problem: When I use gpg, this prints:
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 this warning exists for a reason, but I can't guess why. It implies that GNOME's GPG agent somehow breaks GnuPG -- how so?
The warning is problematic for two reasons:
1) The GPG agent is active by default. If the GPG agent is a problem then the default needs to be changed. (That would be super unlikely, though, since GNOME's GPG agent is really nice. :)
2) The GPG agent is a low-level technical detail, not some user-configurable thing that can be changed, so telling the user to disable it is really dumb because there is literally no user-visible way to do so. (In 3.10 it's kind of configurable in that if you know the magic command-line incantation to start gnome-session-properties, you can probably find GNOME's GPG agent on the list and turn it off, but it's unlikely anyone except a GNOME developer or very experienced user could possibly figure that out. This has been removed in 3.12, so in F21 you will be completely out of luck.)
Version-Release number of selected component (if applicable): Started with 2.0.23
How reproducible: Always
Steps to Reproduce:
1. In a git repo, git tag -s
Actual results: No warning
Expected results: Warning prints
Please discuss this issue with GnuPG upstream.
My understanding is generally that (gnome) seahorse-agent esentially *replaces* gpg-agent, see
This is possibly gpgme upstream reaction to bug reports about it. :-/
for a suggestion on how to disable it.
And (in comments),
(In reply to Rex Dieter from comment #2)
> My understanding is generally that (gnome) seahorse-agent esentially
> *replaces* gpg-agent, see
> This is possibly gpgme upstream reaction to bug reports about it. :-/
Would be curious to see them. I've never had a problem.
> See also,
> for a suggestion on how to disable it.
Er, that involves symlinking desktop files to /dev/null... I'm sure that will work, but a bit of a stretch to suggest it's "configuring"
(In reply to Rex Dieter from comment #3)
> And (in comments),
Startup Applications is gnome-session-properties, which has been removed as mentioned above. We don't let users configure startup applications anymore.
(In reply to Tomas Mraz from comment #1)
> Please discuss this issue with GnuPG upstream.
Fair enough, but I'm not planning to :)
Whatever upstreams think, I don’t think we should be shipping a distribution with two components that fight like this.
A harmless warning would be slightly annoying, but this is user-visible: reportedly it causes spurious “decryption failed” errors in Enigmail.
Either there are legitimate problems with gnome-keyring, and it either should be fixed or modified to stop providing the agent services, or the system works fine and we should disable the warning message.
I am not planning to remove the message unless somebody agrees to thoroughly test the compatibility of gnome-keyring with gnupg2.
FWIW the relevant upstream discussions: https://lists.gnupg.org/pipermail/gnupg-devel/2014-August/028689.html . None of the directly applicable upstream bug reports point to this.
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 20 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
I think this bug is gone. Can anyone confirm that and close this bug report?
Yeah, this is long since fixed.