The fix actually does the same as my suggested workaround.

There is an easy workaround: Append an exclamation mark to the adsk key. This way gpg will only search for this subkey.
An example with my test keys:

secring.gpg is only used by unsupported legacy versions of GnuPG. Since 2.1 it is not anymore used.

Should be fixed now; see commit above.

FWIW: WriteFile and write are more different than in using a HANDLE vs. a libc file descriptor. Despite that a HANDLE might be a 64 bit pointer, it is guaranteed that the value fits into a 32 bit variable. But they still index different objects. The return code and error values are also different.

Much simpler: write is only used in the callbacks and over there gpgme_io_writen[n] shall be used anyway.

Hmm, for the latter this:

Kleopatra test case (similar to gpg):

Seems it gets a record but is not able to parse it (gnupg/dirmngr/dns-stuff.c:getsrv-standard) in your setup. Not sure why it loops - need to debug it.

Fixed in 2.4

I see the problem: The Qt Pinentry does not implement the BUTTON_INFO status and thus we don't get a fully canceled error back (gpg-agent maps the cancel error to fully-cancel if the close button was used). Should be easy to fix in pinentry (set pinentry->close_button in the close eventhandler).

For me it works if I fully cancel (i.e. close the Window at the first prompt):

Just let me note that we used to have such an API : the former gcry_ac_ functions. However, it turned out that they were more complicated to use.

FWIW, we should anyway move on Widnows to the gpgrt provided setenv and getenv which are directly based on the W32API. The problem here is only that we have a lot of getenv in out code and need a wrapper. That wrapper would then also need to provide a static string as getenv does. A first step would be to wrap all getenv into gnupg-getenv calls.

GnuPG is and can't be FIPS-140-3 compliant due to the way it is implemented. We may eventually employ the new hash-and-sign API of Libgcrypt to move into this direction but that has not yet been done. However, this also requires the use of the new indicator API and the, well, a RedHat kernel.

--openpgp means the current OpenPGP standard as implemented by GnuPG. This was important in the first few years of OpenPGP but not anymore today. The option --rfc4880 might be what you want. Please keep also in mind that the preference list declares what a concrete implementation supports and not necessary what's in an RFC.

This is a standard C pattern to declare that one is not interested in the return value. In this case a return value won't help us because we can't log that anyway because we are in a signal handler.

You are right, it is a bad habit not to check this. Thanks for your patch.

We need the 64 bit version for the GpgOL because there are 32 and 64 bit versions of outlook. Thus we also need a 64 bit gpgme and in turn a 64 bit libassuan and libgpg-error. I can't remember why we don't append the 6 to the gpgme dll, though.

Guessing that it works now.

Meanwhile fixed.

We have new box meanwhile.

We do manual approvals.

backported to 2.2

Will be in 2.4.2

Well okay, then I have no workaround. However, I won't consider this a bug because BEGIN_ENCRYPTION marks the start of the actual encryption process but not when it starts to read input data.

I have not yet experienced that although I am using Gnus with encrypted mail all the time. My guess is that this is due to the improved compressed input detection in gpg. You might be able to work around it by adding compress-level 0 to gpg.conf

If you experience build problems on macOS see T6442

There are pros and cons for both key generation versions. I can't remember whether or why I decided that --quick-gen-key should behave different. Maybe because the creation of the subkey was added a bit later or because a new internal API is used here.

I will review the issue. A likely outcome will be to follow your suggestion but to add an option for the old behaviour to avoid further security discussions.

The user tried to sneak in an ad link and he has thus been banned. Here is his probably AI generated comment for documentation:

That comment was used to sneak in an ad. For documentation here is the comment w/o the link:
The changes made to the code have improved the workflow when verifying detached signature [redacted] without a corresponding signed file from Kleopatra's UI, which should make the process more intuitive for users. It is possible that users who experienced this issue in the past may express their satisfaction with the fix in the comments, while others may provide feedback on the usability of the updated workflow.