--===============0758260054==
Content-type: multipart/signed; boundary=nextPart7835862.4o4jhqogCE;
	protocol="application/pgp-signature"; micalg=pgp-sha1
Content-transfer-encoding: 7bit

--nextPart7835862.4o4jhqogCE
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Sunday 19 August 2012, Hauke Laging wrote:
> Hello,
>=20
> I am trying to understand how the trust calculations work and I think
> I have made serious progress in that... ;-)
>=20
> There are at least two things I have not understood yet:
>=20
> 1) Is it possible to have the ownertrust value shown with
> --list-keys? Validity can be shown. I had expected a parameter like
> show-ownertrust for =E2=80=91=E2=80=91list-options.
>=20
> 2) I do not understand the "signed" column in the output of
> --check-trustdb. I read something about that but it doesn't make
> sense to me. It seems generally difficult to find good information
> about that.
>=20
> start cmd:> LC_ALL=3DC gpg --check-trustdb
> gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
> gpg: depth: 0  valid:  17  signed:  26  trust: 0-, 0q, 0n, 0m, 0f,
> 17u
> gpg: depth: 1  valid:  26  signed:   3  trust: 0-, 0q, 10n, 8m,
> 8f, 0u
> gpg: depth: 2  valid:   3  signed:   0  trust: 0-, 0q, 0n,
> 1m, 2f, 0u

Just looking at the numbers I'd say that "signed" is the number of keys=20
signed by the valid keys. In your example, there are 26 keys that are=20
signed in depth 0. And there are 26 keys that are valid in depth 1=20
(because they are validated by the ultimately trusted keys from depth=20
0). The same pattern repeats for signed keys in depth 1 and valid keys=20
in depth 2.

In my keyring I only see this pattern for signed keys in depth 0 and=20
valid keys in depth 1. OTOH, for depth 1 I get signed: 206, but in depth=20
2 I only get valid: 37. My guess is that "signed" counts the number of=20
all keys in the keyring that are signed by any of the valid keys in the=20
corresponding depth. In particular, this number also includes keys that=20
are valid in the same depth or a lower depth. If your test keyring is a=20
tree (or a set of unconnected trees) then this would support my=20
hypothesis.

Of course, I could be completely wrong and the "signed" number is=20
something entirely different. :-)


Regards,
Ingo

--nextPart7835862.4o4jhqogCE
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEABECAAYFAlAz/KcACgkQGnR+RTDgudgRmQCg5VXIlOqA587QBHSNpkT6/EUC
VXwAn2B30jhKYNOfvzWbyOeum9AkTu/C
=twTp
-----END PGP SIGNATURE-----

--nextPart7835862.4o4jhqogCE--


--===============0758260054==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

--===============0758260054==--