Backported to 2.4 and relevant parts also to 2.2

I can replicate that and it works if you disable the use of the CRT. Looking at the key:

pkey[0]: BC9E1CD66676208956B35357210C220508F9F883FE32F4D682CD36BFB4E8055938D4BA21C341D9F48527E420F951B80335B24DF6710F01C4364D554AF659FC35D322061B67CC2F303DC878076059E4F266CFAEF6AB7A29124E969B9C15B1FC2FBA0F0F90E6B059E36B5E3C9BEC4174162689108A1E0EF6D5DDEE61B6B48327A259746288A517B1D78A0E24F5EFF6E880FF39C0BEDDC464B66F787B559EC5487F248196C2CFB15730BD9695C48355DFB2839FA23D8A37FBD48C741F6BE19F9D48BF844C5147591E1E06803DA40BEA1186B3B39CDCBC0E7DAC9DACDBB60A20E56B7E6631E47A45989A256743FDD83C591CFD4110DEA1B04ADE91CCB575FB858C13
 pkey[1]: 010001
 skey[2]: 512FB977EB9872FECA8BDB96884A01A6AB2B7575D307B9ED4F55E777F2F55FBFFCBF4BF2D669D4D7F42CAC7C28F4ACC0ECEEF7B1D90E3D936850372352107F87E77E20A4D133C927F99FFD52277DEA17107BDA72A072AF950AB0B70023327E3B48D9CCB871237D3D6F6C9BA7FDB45AB46217E33FA01A8ED295795323E26505BC9471CAE4DDA94DBF4F35ED915B0CD025805DCA796EB6B208D8D3F63DBE52BC0045CF4CF9B128356359C7E55B661D7B9DCA57F8984095C5AD3FE4DBD19228B281D66609A154DD7E3EE940CFC66CC180DDC4DD00C45A52D5789286D89D49CA34E5F3C4E798D90955074DAE3D99F7F004CDFFBC9B8428E8EB603E240AE07BEE8D71
 skey[3]: F57D9F597750967DF272D9AC661DDC212D7C5CA4C6E91573A80756281351CDC3A2532B155D9251029F89A0A0807DF2BD177DC30FC6A847E07738B55606DF032ADAD8361E0AFEE9C0CF7D566793834977FAAE9C4B87132B94F665EFF463777CDE7EB89113FA3AAC194B6F2D30C40BE7C0DDE36A5855277C1E4D0204FC4C737BCB
 skey[4]: C4B135296B8F4390B953DDA84249FC8467CFF81FC715D1B5F3E01FCC8DC770813630AEA93982F2004705C4D272E07A10B1882AC5C09A45E88B14A1446B4C639B549420CE3BF90947E6E86503E426A8FDAC4C5CFC2809F5F0A1647ED5EE2457C054A40AA1F0666B28B2C970BE2093AE7B095A688B2D713CA8885826F23AFB37D9
 skey[5]: 0790A8E260C6CADC353FB3961D798EFD4F15F96752DA20B86841334C38861743DD7A1FEB2B750D0864F5901BE541B6C8FB63649B18FDC4A32A1233EF90872DCD35704A4B4063DB62752CF6A7FD00F086C6B1042A2B0CB6FB36B7D5269671DACF55242A838E60D514BA868354910CEB1C41FB9A43BF932B5036A6EFE35236FFC7

We discussed this forth and back with the RedHat people at our jour-fix to explain that the Kairo fix is done at the wrong layer - this needs to be done at the protocol layer and not in the building blocks. This is not covered by our security policy and @gniibe already came up with some extra support to help at the protocol layer. There are only a few use cases where this side-channel or the Minerva one (for ECDSA) should be considered (e.g. time stamping services). Generally required protection against DoS are also pat of the mitigation.

All except the above mentioned applied to master - will be backported to 2.4

In PATCH GnuPG 12/15] sm: Avoid use of uninitialized variable I can't see where ERR was not initialized.

I do not understand why there should be an integer overflow:

For OpenPGP cards >= v2.0 there is no PUK due to updated ISO standards but we use the term in Kleopatra for the Reset-Code.

This is not a bug. We changed it as a convenience for some Emacs users.

Sorry, no. The change is too large to back port it w/o risking a regression. As mentioned in T6481#170366 I don't consider this a bug. We are anyway working towards version 2.6 which will be the next LTS version.

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.

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

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.

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.

Pretty outdated, but I add it nevertheless to 2.4
s/gnupg-2.4/po/nl.po: 1320 translated messages, 625 fuzzy translations, 268 untranslated messages.

Done for gpg. Needs to be done for gpgsm.

Looks good to me. Thanks.

Please, we need a fix here for 3.3.

I still spotted a grammar glitch in corrections. Thus if we apply this we need to proofread it.

Yes, I think we should support this. Also X448. Thanks for the report and the samples.

I noticed this recently too on some boxes. Thanks for the good decription. This support for pkg-config style .pc files for our config scripts seems to be a never ending story. The alternative name for libgpg-error-config does not make it easier.

pwd is not a standard Windows command. It is availabe in powershell but there I get

Can we close this?

Breaks them how?

This breaks existing 32 bit systems with the 64 bit types. Thus a test for off64_t is required which redefines it to int64_t if it does not exist.

Let me remark, that we don't need a general migrator. We only need to make sure that the kleogroups are somehow migrated. Maybe we should do this along with the change of these group files (signing, v5 fingerprints). In any case it is important to get this into vsd33

Seems it was a kernel / USB bug

RL discussion result: