trustdb calculations

[Neil Williams]

gpg: checking at depth 0 signed=23 ot(-/q/n/m/f/u)=0/0/0/0/0/2

I understand this line to mean gpg found 2 keys set to ultimate trust (I have 
two keys of my own with matching secret keys) that have, in turn signed 23 
other keys. Is that right?

gpg: checking at depth 1 signed=85 ot(-/q/n/m/f/u)=0/0/0/1/22/0
gpg: checking at depth 2 signed=224 ot(-/q/n/m/f/u)=0/0/0/60/16/0

That jump to 224 - is that expected? Have I perhaps been too generous 
'as-a-rule'? I tend to set keys at marginal trust during a run of 
--update-trustdb - gpg only lists those that it can fully trust but which 
have no trust value set. 

Up until now, I've been happy to consider these as keys belonging to people 
who have a reputation for good key management (to collect the signatures from 
the strong set that allow my gpg installation to trust the key) and that it 
is reasonable to set these to marginal trust unless I have reason to set full 
trust or have reason not to trust.

Could this have led to an artificial increase in keys further down the chain 
becoming trusted when perhaps there isn't a good reason? i.e. it would enable 
someone to become fully trusted when 3 marginal keys have signed it, even 
though each of those 3 is as much as 3 links down the chain from me. 

The problem is that it is very hard to visualise these chains and to tell from 
the update-trustdb output just how far away you are from the key being 
queried.

I've got to the stage now that trustdb checks have to be run manually because 
my mail client was waiting many minutes for the results of importing a new 
key. Now I've set no-auto-check-trustdb in gpg.conf and I run update-trustdb 
once all mail has been previewed (and new keys imported).

Have I over-complicated my trustdb with trusted keys too far down the chain?
(possibly by over-zealous use of the KGpg function "import missing keys from 
keyserver" on a trusted Debian developer key? - it requests and imports all 
keys that have signed the selected key but which are not already in the 
keyring. Up until now, I've only done it with keys with 5-8 missing 
signatures. Last night I did it with a stronger key and imported a lot more 
keys, most of which also became trusted.)

Latest run of --check-trustdb gives:
neil at garfield:~$ date
Thu Apr 29 23:04:29 BST 2004
neil at garfield:~$ gpg --check-trustdb
gpg: checking at depth 0 signed=23 ot(-/q/n/m/f/u)=0/0/0/0/0/2
gpg: checking at depth 1 signed=85 ot(-/q/n/m/f/u)=0/0/0/1/22/0
gpg: checking at depth 2 signed=224 ot(-/q/n/m/f/u)=0/0/0/60/16/0
gpg: checking at depth 3 signed=224 ot(-/q/n/m/f/u)=0/1/0/113/11/0
gpg: checking at depth 4 signed=154 ot(-/q/n/m/f/u)=0/0/0/84/4/0
gpg: next trustdb check due at 2004-05-14
neil at garfield:~$ date
Thu Apr 29 23:09:22 BST 2004

Almost exactly 5 minutes. (This after a previous run of --update-trustdb and 
with no further changes to the keyring.)

neil at garfield:~$ gpg --list-key | grep -c pub
471

471 keys after running my usual 'untrusted/expired/revoked' clear-out script.

I'm now considering adding 'marginal' to the clear-out script - when a key is 
deemed by gpg to be of marginal trust, my email client still classifies it as 
untrusted. Am I right in thinking that until a key becomes fully trusted by 
gpg, it has no bearing on the trustdb calculations? 

If I delete all keys that are m/[m|-|n|q] will some of my fully trusted keys 
suddenly become untrusted?

If I delete these keys, will it improve the trustdb speed at all? I'd suspect 
that the speed is down to the sheer number of verifiable signatures on the 
trusted keys - is that correct? Some of these are currently only marginal 
trust (trust m/m).

-- 

Neil Williams
=============
http://www.codehelp.co.uk/
http://www.dclug.org.uk/
http://www.isbn.org.uk/
http://sourceforge.net/projects/isbnsearch/

http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
Url : /pipermail/attachments/20040429/15d322bf/attachment.bin