| David Shaw on Thu, 27 Feb 2003 23:10:34 -0500 |
|
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
|
|