improving validity calculation: external program

David Shaw dshaw at jabberwocky.com
Tue May 6 05:08:34 CEST 2014


On May 5, 2014, at 1:05 AM, Hauke Laging <mailinglisten at hauke-laging.de> wrote:

> Hello,
> 
> from time to time when changes to GnuPG's behaviour (about validity and 
> trust) are suggested, Werner responds kind of: "No, that should be done 
> on top of GnuPG." This attitude makes sense but in the current situation 
> I would ask: How? How shall that be done on top of GnuPG without causing 
> a huge mess of adaption need in the higher layer applications?
> 
> Thus I would like to suggest that – similar to gpg-agent's option 
> "pinentry-program" – an option is added which disables gpg's internal 
> handling of --check-trustdb / --update-trustdb and has the configured 
> external program be called for that. This would more or less be a 
> modified version of --import-ownertrust.

Believe it or not, this almost exists.  Way back in 2003, I added the concept of an "external" trustdb.  The intent was exactly for what you mention: to allow people to make up and experiment with their own ideas in trust handling without having to have GPG support them all directly.

The trustdb in GPG is essentially a frozen image of what ownertrust you've set on which keys, and which users IDs are valid, and to what degree (partial, full, etc).  When you run --check-trustdb and/or --update-trustdb, you're rebuilding the trustdb image.

An external trustdb is just like any other trustdb, except that GPG follows it directly, and does no trust calculations of its own.  So GPG is capable of reading this special trustdb that can encode any behavior you like.  The catch is that I never had time to write a generic trustdb "compiler" where you could feed it the key/user ID/validity relationships you desire, and have it spit out the resulting trustdb.  A reasonably good programmer should be able to write one in short order though.  You just need to follow the format used in tdbio.c, and tag it as TM_EXTERNAL so GPG knows to treat it as special and refuse to run check-trustdb or update-trustdb on it.

Note that while you may choose to use a nonstandard notion of trust and/or validity, that of course only applies to you.  Just like the standard trust models, just because A sees B's key as valid, it doesn't necessarily imply that B sees A's key as valid.

David




More information about the Gnupg-users mailing list