This is not yet fixed. KDE still applies a patch to gpgmepp (and gpgmeqt) to ifdef a few GCCisms.

@werner I added an implementation https://dev.gnupg.org/D622
that matches Linux behavior and avoids the message about secure memory not being supported on Windows. The change is scoped to the pinentry tool and intentionally follows Linux behavior. Does this approach look reasonable to you?

Reconsidering this all I don't think it makes any sense to distinguish between (-1) and GPG_ERR_INV_PACKET. We use (-1) for a too short read of the hashed or unhashed area (premature eof). INV_PACKET is for unknown versions, too much data (arbitrary limit), bad parameters, and underflow. Let's forget my previous comment and always use INV_PACKET.

I think "O" is a better key:

We need to change the accelerator. Right now gpg-agent uses

I don't think that we will implement that any time soon. Today we too often require more mlock-able memory than available and in this case Libgcrypt resorts to allocating new memory arenas which are not locked. This is not as worse as one might think: the majro advantage with secmem is that a free() on secmem allocated memory will also wipe that memory. A better solution has always been to use an encrypted swap/paging file. 25 years ago, it was not easy to configure but today there should be no problem and hopefully already the default.

Please run with --debug 0 which should show you which confiration files are read in which order. Is there anything in a common.conf file? A log-file statement tehre would overwrite the command line option.

While key generation works now with an expiry date up to 2106-02-04, the representation on the command line is a bit ugly.

Current state needs to be tested

We should keep in mind that we set an arbitrary limit for the [un]hashed areas. They are actually allowed to be larger. At some point in the future we might want to lift that limit again or add another algorithm. We need to take care that we don't drop the signature packet but merely don't use it. The packet needs to be storable in our keyring even if we cannot parse it now correctly. This is different from a broken packet, which is better dropped.

@ikloecker: Is this fixed?

Current state needs to be tested as soon as T7509: gpg4win: Make the AppImage build work with the new Docker-based build script is resolved

@werner: Is this resolved?

We need to test the current state

this seems obsolete

I see your point. I am afraid adding skipme causes a larger changes.

Fixed and backported for VSD 3.4

Backported for VSD 3.4

I have split out the "Tab navigation in the Smartcard Dialog is broken" issue because it's unrelated to this ticket: T8051: Kleopatra: Tab navigation in smartcard table is broken

I definitely prefer 0004. I am not so sure on the use of -1 as return code. I know that we use it for legacy reasons but it does not feel correct. Maybe add an arg int *skipme to the function so that we can selectively skip this packet. Note that I have not fully evaluated the patch; the -1 might just be right.

Backported for VSD 3.4

I think this is a very good idea. Go ahead an backport, I'll change the ticket description accordingly.

Here are changes to fix the behavior:

Fixed in: rC2c1d41b5f86f: fips,cipher: Fix the regression with disabled public-key algo.

Re-opened because a regression is reported.