Walt Mankowski on Wed, 26 Feb 2003 23:40:29 -0500


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] GnuPG 1.2.1 trustdb checks for every pubkey import?


On Wed, Feb 26, 2003 at 10:38:51PM -0500, gabriel rosenkoetter wrote:
> Every time a key is added to my public keyring, GnuPG forces a
> trustdb check. Is anyone else experiencing this aberrant behavior?

Yeah, it's annoying.  I find that running gpg --rebuild-keydb-caches
periodically helps a bit, but only very briefly.

> Using --no-auto-check-trustdb makes reading mail with mutt practical
> again.

I just finally got around to setting that the other day, after getting
fed up with the long delays every time I add a new key.

> There is no sane explanation for needing to do a trustdb check with
> every imported key. If that were going to be necessary, then it
> shouldn't ever have been modularized out.

It's particularly annoying when you import a key that's only been
self-signed, but gpg *STILL* spends over a minute rechecking the
entire trust db.  A month or so ago I saw something on the gpg-users
list that someone had added a patch to the development version to
prevent that behavior.

> For reference, here's what a --check-trustdb looks like for me these
> days:
> 
> uriel:~% time gpg --check-trustdb
> gpg: checking at depth 0 signed=46 ot(-/q/n/m/f/u)=0/0/0/0/0/1
> gpg: checking at depth 1 signed=84 ot(-/q/n/m/f/u)=0/0/0/17/29/0
> gpg: checking at depth 2 signed=288 ot(-/q/n/m/f/u)=0/0/0/72/7/0
> gpg: checking at depth 3 signed=181 ot(-/q/n/m/f/u)=0/74/0/22/1/0
> gpg: checking at depth 4 signed=0 ot(-/q/n/m/f/u)=0/0/0/0/1/0
> gpg: next trustdb check due at 2003-03-07
> gpg --check-trustdb  109.24s user 20.77s system 80% cpu 2:40.70 total

Wow, I'm only going to depth 2.  I wonder what the difference is.

> This is on a PowerPC G3 (a 750, running, I believe, at 300 MHz,
> but it's been a long time since I thought about it and NetBSD/macppc
> doesn't report cycle speed in dmesg(8)) with 288 MBs (says dmesg(8);
> I don't recall exactly what DIMMs I've got in there) of memory.
> The disk isn't the fastest around, but this process is clearly
> (based on zsh's time builtin's output and also observation of top(1)
> while the thing is running) cpu-bound, so that doesn't matter
> here. I'm using:

Yes, it's also my impression that this is a cpu-bound process, too.  I
really don't understand what it could possibly be doing that it could
suck up the cpu of a modern machine for over a minute.  You'd think
this would be a fairly simple tree traversal algorithm we all learned
back in our computer science classes.

Walt

Attachment: pgpUQNeFyUvG2.pgp
Description: PGP signature