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.

With caching, did you have something like this in mind?

Back in the ancient days we allowed to dlopen algorithms so to avoid patent problems in certain countries.

Actually we are using gpgme already for 64 bit Windows; but statically linked.

I don't think we need a fallback. For the group configuration we can manually look in the old location. And for everything else it's okay to lose the configuration.

In T7036#186290, @ebo wrote:

Tested with VS-Desktop-3.2.93.391-Beta:

Tested with VS-Desktop-3.2.93.391-Beta:

It works on linux (an presumable also on windows) but is ifdef'ed out since it requires unreleased functions from gpgme

Does not work on windows at all. Seems it doesn't any more on Linux, either (info Tobias)

works, VS-Desktop-3.2.93.391-Beta

works, VS-Desktop-3.2.93.391-Beta

ok, its even on by default, VS-Desktop-3.2.93.391-Beta

tested with VS-Desktop-3.2.93.391-Beta, looks ok.