Created attachment 1429872 [details]
screenshot of seahorse with no GPG items in the left menu
Description of problem:
Cannot view, use, create or interact with GPG Keys in Seahorse
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Open seahorse
2. No GPG Keys appear in the side menu (these have previously appeared in F27 before upgrade and can be listed in the terminal with gpg and gpg2)
3. File -> New ...
4. No options appears to create GPG Key
No visual or control elements to view, use, create or interact with GPG Keys
Have menu options to create new keys and a remote tools bar to share GPG Keys to a server. Be able to view keys in seahorse which are on my system.
Upgraded OS from F27 to F28 via dnf when the problem presented.
Using the command line I can list my keys (gpg and gpg2) however they are not visible in Seahorse.
A new feature in Libreoffice to sign documents launches seahorse to select the key and none of the keys are visible.
Evolution mail works fine with the GPG keys.
I have seahorse-nautilus installed and that works fine. So it seems to be a UI issue with seahorse.
Created attachment 1429874 [details]
screenshot of seahorse with no option to create GPG Key
Same here. Previously, when trying to sign/decrypt something from the command line, a GUI dialog would pop up (which I guess is gnome-keyring/seahorse) and prompt for the password. This is no longer the case.
I can confirm the same - there is no gpg section in seahorse (3.20.0-9.fc28).
I can also confirm. GPG section vanished unexpectedly after update from F27.
Also confirming here that there is no PGP/GPG section in Seahorse (seahorse-3.20.0-9.fc28.x86_64). Even keys created using gpg2 on the command line do not appear in seahorse.
I'm also have this issue on my system Fedora 28 X64 bit Cinnamon edition with same Seahorse version 3.20
Seems to be same problem as I had in Fedora 27 reported in 1553014, --> https://bugzilla.redhat.com/show_bug.cgi?id=1553014 and as also reported in Fedora 28 in bug 1577397 -> https://bugzilla.redhat.com/show_bug.cgi?id=1577397
Same problem for me too.
This bug has been open for three months now, no progress, no fix, nothing. Is there any way to escalate this further? Is it only Fedora that is affected by this?
+1 here -- this is at least a "high" severity...
Kurt, can you change severity of this pls?
(In reply to HaJo Schatz from comment #13)
> +1 here -- this is at least a "high" severity...
> Kurt, can you change severity of this pls?
Unfortunately I am unable to change either Priority or Severity fields as they are restricted to the development team.
Somebody with the required credentials is needed to do that.
The bug seems to be in seahorse's "configure" script, which doesn't like Fedora 28's gpg2 version (2.2.8).
If I download the source package and change the GNUPG_ACCEPTED="2.0.12 2.1.4" line to GNUPG_ACCEPTED="2.0.12 2.1.4 2.2.8", I can build seahorse with GPG support.
Created attachment 1472137 [details]
Proposed patch for "configure" script.
This is only a quick fix. The real problem is more fundamental in configure.ac, but I don't want to mess with that right now.
Just got in touch with the seahorse devels @ IRC. Seems gpg is now too new for the latest seahorse release. They are thinking of a new seahorse release, but well, workload. Apparently this seems an issue that slipped through @ Fedora QC...
Yeah, I noticed that although PGP seems to be enabled in my build, it's not exactly functional. :-(
This seems to work a little better:
sudo dnf install --releasever=27 seahorse-3.20.0-6.fc27
But it's not what I would call a solution.
Upstream has a new version, 3.30, which may fix this issue.
Looks like it, indeed. I just built it and ran it. It sees my keyring and I can query and view the keys. Haven't tried anything beyond that, though, so I wouldn't call that "testing", but it looks promising.
Also built 3.30 from https://gitlab.gnome.org/GNOME/seahorse.git and was able to change picture on my GPG key, also check which signatures are on keys in my keyring, and sign a key. Not fully tested yet, but seems to be working.
There's a version for f29 & f30 in Koji as of 2018-09-07:
Perhaps we can look forward to some trickle down...
The Fedora 29 version of seahorse is usable and allows interaction with GPG keys. This issue can be closed as fixed in next release.
Matthias, given that seahorse with a small patch discussed here works on F28 and there is alreadya fix for F28, is it possible to update F28 too?
I can provide a pull request if nobody does it before.
The issue is fixed in fedora 29 workstation, we have the gpg section in seahorse.
The latest stable release of Seahorse is 3.30.1, which does not have this issue.
Fedora 29 has version 3.30.1, yet Fedora 28 still has v3.20.0, which /does/ have this critical issue.
F28 has not reached EOL, as Alexander requested, can F28 be updated as well please?
Can I re-iterate :-) Robert's request please - is there any reason why the 3.30.1 update can't be provided to f28?
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. 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' of '28'.
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 28 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.