Not much QA can do here.

Can't find a mail - closing the ticket. Feel free to reopen or send me a mail to werner dot koch at gnupg.org but replace the org by com.

Now also with support for --quick-add-adsk in 2.6. This will work also for gpgme without further changes.

Let us drop the option to select the ADSK and instead take them from the gpg.conf configured ADSK for new keys. Thus a simple dialog with a confirmation will be sufficient. We add some magic to gpgme to allow this with the adsk API. This solves the use-case to add ADSK to alread-existsing keys in the same way as they are added to new keys.

Done for 2.6.

This is related to T6818

Recall that on windows you have a current working directory per drive. Thus only LETTER:\foo is a full patch - or an UNC (\\SERVER\foo).

Do not use the pcscd but the integrated CCID driver. This is actually the default form Unix. Or are you on Windows?

All fine. I just noticed it while checking the patch. All applied and more fun with cherry picking in the future ;-)

In more than 25 years of OpenPGP we only had a few new implementations which got it wrong. I see no need to fix it here - maybe import could indeed reject such a key, though.

Right away the first patch:

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.