Scute returning a full chain is confusing signing applications

[Werner Koch]

Hi!

I am currently using the t6002 branch which has a couple of small fixes.
For example commit ca9b9a4d9eed avoids hangs due to broken certificate
chains (it happens that I have some on my keyring).  I am in general
satisfied wit the current state of things and that branch will soon be
merged.  In particular osslsigncode works now every well with that
version.  I could not fully test PDF signing because NSS does not
support Brainpool (which are used in Germany for qualified signatures).
Gniibe is working on getting a fix to NSS into Debian's version of NSS,
though.

On Thu, 15 Sep 2022 00:25, Damien Goutte-Gattat said:

> In fact, of the applications I tested, pdfsig is the only one who works
> correctly (it generates a valid signature).

Interesting because it seems to use NSS as well.

> is on the token, then Scute returns only that certificate; if not, Scute
> returns the full chain obtained from GpgSM. What is the rationale for
> this difference of behaviour?

I can't tell anymore; its too long ago:

    2008-09-29  Marcus Brinkmann  <marcus at g10code.com>
    
            * src/gpgsm.c (struct search): New member WITH_CHAIN.
            (search_cb): Only load chain if WITH_CHAIN is true.
            (scute_gpgsm_get_cert): Call search_cb in the agent code path.


I would suggest that for now we use a new option (/etc/gnupg/scute.conf)
to either enable or disable chain lookups.


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: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220915/52b99728/attachment-0001.sig>