Feature suggestion: --export-option no-include-untrusted-material

Tue Jan 14 19:03:01 CET 2003

>> Have you considered such a compiler?

> Yes, that is my plan.  Imagine something like '--import-trustdb', and
> pulling in a externally generated text representation of a trustdb
> which GnuPG will then follow. 

Excellent.  Is it your intention to use this text format for
export also?

[Even then, I am still looking for something to extract the
key material associated with valid names.  Being able to see
the trust export would be nice -- I can already get enough
information from '--with-colons --fixed' -- but it doesn't
really help prune out the material.]

> Within GnuPG, there is no danger of trust getting stale, as the trust
> system within GnuPG accounts for that automatically.  Even using the
> direct trust model, an expired or revoked key can still override the
> validity given in the trustdb.  This allows a user to set whatever

As you noted later, this only covers the case where the selected
key itself has expired.  It doesn't account for expirations of
other keys (or signatures) that were involved in the trust-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

And, there is always the (remote) possibility that the key expires
while GnuPG is running.  The key may also expire after it is used
but before the message reaches its destination.

Revocations can exist but not be available to GnuPG yet.

None of these are GnuPG's fault, of course.

My point is just that there is no sure way to avoid staleness,
so you simply have to understand the limitations and live with them.
This shouldn't be a reason not to import/export validity/trust
information.  (That's what I said you'd agree to :-).