file size change in trustdb.gpg after recovery

[Daniel Kahn Gillmor]

On Sat 2017-02-25 07:23:39 -0500, Michal Novotny wrote:

> I have got a trustdb that gives the following output on --check-trustdb:
>
>   gpg: public key of ultimately trusted key 3ADE2987ABBFDB66 not found
>   gpg: public key of ultimately trusted key 831FE43EDDD16F3D not found
>   gpg: marginals needed: 3  completes needed: 1  trust model: pgp
>   gpg: depth: 0  valid: 6468  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 6468u
>   gpg: next trustdb check due at 2021-01-18

I don't know about the size change of the trustdb.gpg -- hopefully
someone else can weigh in on that.

But i want to point out that 6468 ulimately-trusted keys is a *very*
unusual arrangement.  any one of these keys can certify any other key
and gpg will rely on those certifications.  You should think of ultimate
ownertrust in the same way that you think of adding a new root CA to
your X.509 certificate validation stack (e.g. for your web browser).
Anyone with this capacity can pretty easily inject itself in your
communications stream by adding OpenPGP public keys ("OpenPGP
certificates") that your tools will happily believe are valid for the
identities they claim.

I'm not saying that this is *never* what anyone would want to do, but
i've never seen a use case present itself where this was what the user
actually wanted to enable > 6K parties to be able to do.

Regards,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170225/258c5305/attachment.sig>