David Shaw on Thu, 27 Feb 2003 23:10:34 -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 Thu, Feb 27, 2003 at 10:07:50PM -0500, gabriel rosenkoetter wrote:
> On Thu, Feb 27, 2003 at 08:50:50AM -0500, David Shaw wrote:
> > Either 0 keys found in relation or the value of max-cert-depth is
> > reached.  The default max-cert-depth is 5.
> 
> Would setting max-cert-depth lower (say, 2) be a bad idea in some
> way?

No, it's personal taste.  Some people set it much higher, and some
people set it much lower than the default.  Basically, max-cert-depth
is the number of "hops" that you are willing to allow certification
chains to have.  So, you have signed Leonard Rosenthol's key, and
Leonard has signed mine, and I've signed a bunch of other people.
With a max-cert-depth of 2, all the people I've signed are considered
too distant, and would not be considered valid.  max-cert-depth of 1
is "if I didn't sign it myself, it's not valid".  Depending on how big
your web of trust is, a smaller max-cert-depth can be somewhat faster
when checking the trustdb (less work to do).

> > GnuPG won't generate Elgamal keys any more unless the user specifies
> > --expert, and then confirms the "are you crazy?  why would you want to
> > do such a thing?" question.  People still make them.
> 
> Well, so it sounds like you have your bright, red light bulb after
> all. ;^>

I think I need to go for the large hammer next.  The light bulb isn't
working. :)

Flexibility is actually a real problem.  GnuPG supports a lot of
algorithms that are optional in the OpenPGP standard.  That's a good
thing in general, but it often leads to people using them because they
are there, and not because they need them.  I sometimes envy the PGP
folks who get to lock off a lot of settings to prevent people from
shooting themselves in the foot.  GnuPG used to have a bit of a
reputation for poor interoperability with PGP, and a lot of that was
due to people picking algorithms out of thin air and expecting PGP to
work with them.

> On Thu, Feb 27, 2003 at 09:20:50PM -0500, Walt Mankowski wrote:
> > Excellent points.  I'll probably add a cron job to periodically
> > rebuild the caches to prevent these slowdowns from happening in the
> > future.  Also, it sounds like things will be even better in the next
> > release.
> 
> Fwiw, I'm thinking of something like this:
> 
> 45 7 * * 1 gpg --rebuild-keydb-caches && gpg --check-trustdb

Note that you don't need to rebuild the cache nearly that often.  In
fact, now that you've done it once you can probably not do it again
for a few months.  It depends on how much importing of new keys you
do.  Either way, don't bother to do the slower --no-sig-cache
variation of it again.  There is no need.

> 0 8 * * 2-5 gpg --check-trustdb

Do this:

  gpg --no --batch --check-trustdb

That will only do a check if it needs one.

> (That's during my drive to work. There's really no safe time on
> weekends that will keep me from potentially adding a pubkey or
> signature during a trustdb check, which may be as bad news as the
> scary moment I had while running a --no-sig-cach --rebuild-keydb-caches
> earlier today.)

I'm sort of glad it happened (not the scare part), as I was able to
fix the bug.  When 1.2.2 comes out it will be safe to rebuild the
cache and import keys at the same time.  Note that even in the current
version it is safe to do a --check-trustdb and import keys at the same
time.  The bug is only in --rebuild-keydb-caches.

David

Attachment: pgpHYWYEDeulw.pgp
Description: PGP signature