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

[David Shaw]

On Tue, Jan 14, 2003 at 01:02:35PM -0500, Michael Young wrote:
> >> 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?

Hadn't really thought about it.  Is there a need to export the trustdb
in a text format (aside from --list-trustdb, which is a human readable
text format)?  I can't really see a use for it, except perhaps to see
what the built-in trust models did before tweaking it?

> [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.]

Using 1.2.2 (when it is released), you can do this with a very short
perl script.  Just do a --with-colons --list-keys and note the index
of each uid you want to delete.  Then do a --edit and deluid them.
Somewhere in the 20-30 line range of perl is my guess.

> > 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 calculation.

Actually GnuPG takes these into account as well.  That's why there is
the "gpg: next trustdb check due at xxxx-xx-xx" message after a trust
check.  That is the date of the next event that permutes the web of
trust (i.e. expiring signature, expiring key).  You are correct about
how it applies to the external trust model (it's now called "external"
rather than "direct") however.

> 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 :-).

I agree with that.

David

-- 
   David Shaw  |  dshaw at jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson