I think it would be cleaner to create a separate ticket for making gpg fetch the requested key from LDAP.

Any chance this could also be fixed in the 2.2.x series, where it seems to have been introduced in 2.2.42?

Although it is implemented in gnupg-2.2 we should add another feature: Iff this option is configured, gpg shall try to load the requested key from LDAP in the same manner as it does for a trusted-key.

This should not be configured in Kleopatra but an option to gpg because this is a core crypto functionality. Thus is now a gpg task.

this has been implemented since february 2023 in all gnupg versions

Looks good

great, thanks!

Assigning to Carl since he's working on this already.

Setting same priority as T6799.

We shouldn't change the name of the config file. The syntax is different from GnuPG's .conf files. Therefore it's better not to use the same file suffix.

I'm re-opening this ticket because I think this ticket only partially overlaps with T6799. T6799 is specific for g10 Code's releases of Kleopatra (especially for Windows) while this ticket makes sense for every version of Kleopatra.

correct, this only affects encryption

I assume you only implement this for encryption and not decryption. The latter should always be possible.

Right, thats my understanding from reading of the RFC that the padding should be strictly < 8B. We can reword though.

Well, but if the padding is indeed limited to 7 bytes the fix should be applied anyway.

The report went like this

Error: OVERRUN (CWE-119):
libgcrypt-1.10.3/cipher/cipher-aeswrap.c:303: cond_at_most: Checking "plen > 8U" implies that "plen" may be up to 8 on the false branch.
libgcrypt-1.10.3/cipher/cipher-aeswrap.c:305: cond_between: Checking "plen" implies that "plen" is between 1 and 8 (inclusive) on the true branch.
libgcrypt-1.10.3/cipher/cipher-aeswrap.c:309: assignment: Assigning: "i" = "0".
libgcrypt-1.10.3/cipher/cipher-aeswrap.c:310: overrun-local: Overrunning array "t" of 16 bytes at byte offset 16 using index "8U + plen + i" (which evaluates to 16).
#  308|   
#  309|                 for (i = 0; i < 16 - (8+plen); i++)
#  310|->                 if (t[8+plen+i])
#  311|                     {
#  312|                       err = GPG_ERR_CHECKSUM;

but looking again, it is wrong as it did not reflect the end condition for the cycle, which obviously means the cycle does not run. Sorry for the noise.

Can you give a hint where there is a buffer overrun in the first patch? Padding limit might be correct but I can't see an overrun.

Thanks for running the analyzer. We need to have a closer look at the suggested fixes. For example initializing a variable needs a reason and should not be done as a general precaution because that may hide other errors.

Thanks for running the analyzer. We need to have a closer look at the suggested fixes. For example initializing a variable needs a reason and should not be done as a general precaution because that may hide other errors.