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.

I left review comments in gitlab. One additional concern is license for mpi-mul-cs.c, original code not having copyright information... "does not have any copyright information, assuming public domain".

In T7129#186556, @werner wrote:

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

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.

Fair enough. This is more theoretical and could happen only on huge reads. Using ssize_t for read() return value is safe option, but really does not make sense to adhere to it in cases where the reads must be smaller.

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.

Also required for an actium feature with UI.

Information about revocation keys can now be retrieved from a Key object (see T7118).

Information about revocation keys can now be retrieved from a Key object. Verified with internal test runners. Independent tests will be done with T7095.

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

Are you saying that concern about "risking a regression" is the reason to not fix this bug, which is itself a regression, and was introduced into the a point release in the current "long term support" branch?