GPGME: What does ‘0’ (zero) ‘signature.summary’ value mean?

[Werner Koch]

On Sun,  5 May 2024 16:47, Ben Finney said:

> the Signature result attributes? Rather than "everything is zero", which
> (as you point out) just seems to be some default when the conditions
> were not as expected.

Let's have a look at the docs:

     ‘gpgme_sigsum_t summary’
          This is a bit vector giving a summary of the signature status.
          It provides an easy interface to a defined semantic of the
          signature status.  Checking just one bit is sufficient to see
          whether a signature is valid without any restrictions.  This
          means that you can check for GPGME_SIGSUM_VALID like this:

               if ((sig.summary & GPGME_SIGSUM_VALID))
               {
                  ..do stuff if valid..
               }
               else
               {
                  ..do stuff if not fully valid..
               }

VALID is not set and this is the basic informaion you need.  After all
this is a summary and does not give deatils informaion on the reason why
a signature is not valid.  The whole point here is easily see whether
you can accept a signature.  There are other flags which allow you to
further investigate thinsg.  For example:

          ‘GPGME_SIGSUM_GREEN’
               The signature is good but one might want to display some
               extra information.  Check the other bits.

Note the "might". It is not required as per the policy implemented
currently be GPGME.  Just go ahead and display the signature with a
green frame or similar.

          ‘GPGME_SIGSUM_RED’
               The signature is bad.  It might be useful to check other
               bits and display more information, i.e., a revoked
               certificate might not render a signature invalid when the
               message was received prior to the cause for the
               revocation.

Same here - the signature is definitely bad.  Display with a red frame.

There are no other colors but some MUAs will use a yellow or uncolored
frame if they don't see the green or red bit.  This is a UI decision
which for example depends on whether you expect signed messages or not.

> I make of this, that GPGME has a bug: It does not handle this normal
> condition well. The message emitted shows GnuPG understands what
> happened; but the result object from the GPGME API does not communicate

GPGME policy is not to set the green flag in this case.  If you want
something elease check out the detailed results and act upon them.

> So, please consider this thread a bug report to that effect. How do I
> formalise this so it can be addressed as such?

What should we do? Add another bit flag "other_problem"?


Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240506/6733665c/attachment.sig>