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.