gpg: return value, validity vs trust

Anish R Athalye aathalye at
Sun Dec 14 00:25:17 CET 2014

What I meant by valid is that given the key, the signature is made correctly (not forged or something like that). So I guess I’ll call that “correct” from now on.

What I mean by trusted is that the public key making the signature is trusted. This can be verified by checking explicitly assigned user trust or by checking it using a web of trust model.

When most people check signatures, they want a correct signature made by a trusted party — a signature that is “valid". That’s what many seem to expect when using the `gpg` command line tool to check signatures. However, the `gpg` tool checks only for “correct” (and outputs a message to stderr if the signature in untrusted, but still returns 0 for success). And it seems pretty difficult to check for trust (there’s no clean API for this that I found).


On Dec 13, 2014, at 4:43 PM, Hauke Laging <mailinglisten at> wrote:

> Am Sa 13.12.2014, 19:39:00 schrieb Anish R Athalye:
>> Unfortunately, valid != trusted.
>> In terms of security, validity means almost nothing.
> Once more the terminology is the problem.
> What you mean with "valid" is called "correct". Validity is a key 
> status. A "valid signature" is a signature by a valid key. A key usually 
> becomes valid by getting signed.
> "Trust" refers to owner trust (certification trust). Setting owner trust 
> to "ultimate" makes a key valid. Apart from that "trust" is not related 
> to (data) signature checking.
> A few months ago we had here a discussion about an improved terminology. 
> IIRC "accepted" was preferred over "valid".
> Hauke
> -- 
> Crypto für alle:
> OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20141213/2254f2be/attachment.sig>

More information about the Gnupg-devel mailing list