GNOME Bugzilla – Bug 366798
slowness on key properties trust tab
Last modified: 2009-03-17 23:56:49 UTC
Please describe the problem: This is from debian bug #395814 (http://bugs.debian.org/395814) Simple operations are ridiculously slow. For example, merely asking for Properties on a key results in a one minute delay, while *three* competing gpg processes are started (one --import and two --list-keys). Steps to reproduce: I click on the Trust tab, and no sigs are chosen because the "Only display signatures of people I trust" box is checked. Well, I want to see anyway, so I click the clickie. There is no visible response, but now *four* competing gpg processes start, one --import, and three --list-keys. After a bit the bottom part of the display with the signatures area *vanishes entirely*. We are waiting for minutes, indeed, I have sat and waited for *one hour* for some operations, and nothing happens. gpg does not work well when you create multiple processes and watch them compete. And this behavior is all entirely prohibited by the Gnome UI guidelines, which require *less than 0.1 second response* for things like click boxes, *less than one second response* for things like bringing up windows, and *less than ten second responses* for things for which a user might expect delay. A response of a full minute is hopeless; waiting an hour for the UI to even reflect the input is *entirely unacceptable*. Actual results: Expected results: Does this happen every time? Other information:
Can't duplicate this. What version of GPG is being used? Also what kind of computer is this? It it an unusually slow computer?
I can duplicate this. It's been present since the code to auto download signing keys was added. I'm using gpg 1.4.5. This is on my laptop.
Ok. I'll add progress boxes for some of the operations.
Viewing signatures of people I don't trust on Werner Koch's key is my test for this. Here's the output of ps on which gpg processes have been launched. ps aux |grep gpg sadam 5957 67.1 0.0 3596 1844 ? RL 09:38 0:37 gpg --batch --no-sk-comment --status-fd 18 --no-tty --charset utf8 --enable-progress-filter --import sadam 5990 26.0 0.1 4264 2540 ? RL 09:39 0:00 gpg --batch --no-sk-comment --status-fd 20 --no-tty --charset ps aux |grep gpg sadam 5957 67.1 0.0 3596 1844 ? RL 09:38 0:37 gpg --batch --no-sk-comment --status-fd 18 --no-tty --charset utf8 --enable-progress-filter --import sadam 5990 26.0 0.1 4264 2540 ? RL 09:39 0:00 gpg --batch --no-sk-comment --status-fd 20 --no-tty --charset utf8 --enable-progress-filter --with-colons --fixed-list-mode --with-fingerprint --with-fingerprint --list-keys -- sadam 5992 22.0 0.1 4264 2476 ? RL 09:39 0:00 gpg --batch --no-sk-comment --status-fd 18 --no-tty --charset utf8 --enable-progress-filter --with-colons --fixed-list-mode --with-fingerprint --with-fingerprint --list-keys -- utf8 --enable-progress-filter --with-colons --fixed-list-mode --with-fingerprint --with-fingerprint --list-keys -- sadam 5992 22.0 0.1 4264 2476 ? RL 09:39 0:00 gpg --batch --no-sk-comment --status-fd 18 --no-tty --charset utf8 --enable-progress-filter --with-colons --fixed-list-mode --with-fingerprint --with-fingerprint --list-keys -- This is the one that continues running after closing seahorse and eats 90+% of cpu time. gpg --batch --no-sk-comment --status-fd 18 --no-tty --charset utf8 --enable-progress-filter --import
I can confirm it. I have once (automatically) downloaded keys of people who have signed another key. This way my pubring grew to about 7 MB size. Simple operations like navigating key properties or deleting keys can take minutes. I can also observe multiple competing gpg processes. The GUI is blocking with no progress indicator atm. This makes seahorse quite unusable for key management. My processor is an Athlon running at 1666 MHz As an example: I've chosen to delete multiple keys. There are 3 concurrent gpg instances for the most time: 15950 ? RL 0:00 gpg --use-agent --batch --no-sk-comment --status-fd 18 --no-tty --charset utf8 --enable-progress-filter --delete-key -- 6C44DB3E0BF3EAF5B433239A5FEE05E6A56E15A3 15952 ? R 0:00 gpg --use-agent --batch --no-sk-comment --status-fd 19 --no-tty --charset utf8 --enable-progress-filter --with-colons --fixed-list-mode --with-fingerprint --with-fingerprint --list-keys -- 15954 ? R 0:00 gpg --batch --no-sk-comment --status-fd 22 --no-tty --charset utf8 --enable-progress-filter --with-colons --fixed-list-mode --with-fingerprint --with-fingerprint --list-keys -- They start, live for like 2 or 3 seconds and new processes of this kind are started.
Is it possible to disable this function? Whenever I view the properties of a key, seahorse seems to try to download the entire web of trust into my public keyring. I very quickly end up with hundreds of unwanted keys on it. I don't think *any* keys should be downloaded without the user's explicity command to do so.
Added a patch to trunk (will be in 2.19.1) to disable auto-retrieval of keys. This bug still needs work to fix the source of the slowness, however. Commit: 1731
*** Bug 413573 has been marked as a duplicate of this bug. ***
In trunk this seems much better than it was. The canonical key I use to test this bug is Werner Koch's. Could someone else verify if when auto-downloading is on this isn't a problem any longer?
Well. No news so far and no duplicates either. So I assume this is not a problem anymore. However, I don't want to close this bug as comment #7 suggests to leave this issue open. I do wonder, though, how one could investigate on this if the slow code path has been patched out.
I believe the code refactoring that has gone on in seahorse has helped this greatly. Obviously we'll always be working to make things faster. However, I believe this bug can be closed.