After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 662088 - seahorse takes forever to start up because it's checking signatures for all keys in the gpg keyring
seahorse takes forever to start up because it's checking signatures for all k...
Status: RESOLVED FIXED
Product: seahorse
Classification: Applications
Component: general
3.2.x
Other Linux
: Normal normal
: ---
Assigned To: Seahorse Maintainer
Seahorse Maintainer
: 664029 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-10-18 12:43 UTC by Pedro Villavicencio
Modified: 2011-11-16 20:23 UTC
See Also:
GNOME target: ---
GNOME version: 3.1/3.2



Description Pedro Villavicencio 2011-10-18 12:43:48 UTC
this bug has been filed here:

https://bugs.launchpad.net/ubuntu/+source/seahorse/+bug/876813

"When I try to launch seahorse from the commandline, it takes forever to run because it's trying to check signatures on each key in my public keyring one by one using commands like this:

vorlon 25930 24.0 0.0 30892 2024 pts/2 RL 12:55 0:00 gpg --use-agent --batch --no-sk-comment --lc-messages en_US.UTF-8 --lc-ctype en_US.UTF-8 --status-fd 21 --no-tty --charset utf8 --enable-progress-filter --display :0 --ttyname /dev/pts/2 --ttytype xterm --with-colons --fixed-list-mode --with-fingerprint --with-fingerprint --check-sigs -- 85B99075C2910E41

This is a completely unacceptable regression that makes seahorse unusable for what I actually *want* to use it for. I have over 1500 public keys in my local gpg keyring, and I don't need seahorse's help with any of them, thankyouverymuch. What I need is a tool that can be used to manage *secret* keys; both the in-memory cache of gpg keys, as well as network passwords and the like. seahorse can no longer be used for this because of its unreasonable start-time checks."

"The timing of this behavior change in oneiric makes me suspect an upstream regression sometime between 3.1.91 and 3.2.0."
Comment 1 Stef Walter 2011-10-20 08:00:38 UTC
That's strange, when I load seahorse 3.2.0 I see a command line like this:

gpg --use-agent --batch --no-sk-comment --lc-messages en_US.UTF-8 --lc-ctype en_US.UTF-8 --status-fd 14 --no-tty --charset utf8 --enable-progress-filter --display :0 --ttyname /dev/pts/1 --ttytype xterm --with-colons --fixed-list-mode --with-fingerprint --with-fingerprint --list-keys --

The command line seen above, looks like the user is viewing a specific key, in which case seahorse does check signatures so that it can present validity.
Comment 2 Stef Walter 2011-10-20 08:20:15 UTC
Committed this fix to gnome-3-2 branch, which will probably alleviate the problems somewhat:

commit 0cb0d5abe4af9160bafe753296ff1dca46e54866
Author: Stef Walter <stefw@collabora.co.uk>
Date:   Thu Oct 20 10:17:36 2011 +0200

    With gpg2 key loading takes longer, so adjust behavior
    
     * Load in a low priority idle handler, and load smaller batches
    
    https://bugzilla.gnome.org/show_bug.cgi?id=662088
Comment 3 Stef Walter 2011-10-24 09:14:02 UTC
Please provide information for at what point the above command line is being executed. It doesn't seem the sort of command line listed on start up.

In addition, are you using gpg2?
Comment 4 Steve Langasek 2011-10-24 18:16:11 UTC
This is gnupg 1.4.11.

> The command line seen above, looks like the user is viewing a
> specific key, in which case seahorse does check signatures so that
> it can present validity.

I have not asked to "view" any keys at all; I'm just trying to get the GUI to start, which leads to gpg being spawned separately for every single key in my keyring.
Comment 5 Stef Walter 2011-11-14 08:31:59 UTC
Okay, thanks. Managed to find the issue. Committed fix to gnome-3-2 branch, and will be merging into master later.
Comment 6 Stef Walter 2011-11-16 20:23:35 UTC
*** Bug 664029 has been marked as a duplicate of this bug. ***