Understanding --status-fd output

[Werner Koch]

On Wed, 24 Aug 2011 19:58, bjh21 at cam.ac.uk said:

> signatures on Git tags.  Git runs "gpg" internally, and I can
> manipulate its environment to point GNUPGHOME at somewhere with an
> options file containing a "status-fd" option so I can get
> machine-readable output. This is good, but I'm having some trouble

Please consider to use gpgme.  It takes care of all the fairy details.

> 1: Is the signature cryptographically valid (i.e. does it match the
> signed data and the purported key)?

Right.

> 2: What UIDs are associated with that key?

No.  You can't tell which UID made the signature.  This signature is
made by a key and the key have have several associated UIDs.

> 3: Can we form a chain of trust from an ultimately-trusted key to that
> UID/key relation?

Or in short:  Is the key valid.

> 4: Does that UID name the person whom we expected to be signing this
> message?

Obvioulsy the person in front of the display has to decide this.

> As far as I can tell, GOODSIG corresponds to steps 1 and 2 above -- it
> indicates that we've found a key in the keyring and the signature
> matches it.  TRUST_* corresponds to step 3, and obviously it's my job
> to deal with step 4.  The problem I've got is to understand how the

Right.

> UID in GOODSIG relates to the trust in TRUST_*.  As far as I can tell
> from my testing, GOODSIG always includes the primary UID of the key,

The UID is merely a hint.  You may better use the VALIDSIG status line
which gives more detailed information.

> the key in question has _a_ valid UID.  Is this correct?  So if I want
> to know which of the UIDs on the key are trusted, I have to resort to
> --list-keys --with-colons or similar?

Right.  You need to do a key listing for that.  Thus the fingerprint
printed with VALIDSIG comes handy.  See gpgme/src/verify.c implements
what we know about the gpg output; use it as an example.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.