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.

I don't see a reason backing off the original commit. A fix for macOS is now available (rCfa21ddc158b5) and will be in the next release. No reason for other changes.

Closing. A small change in Kleopatra (T6472) should help to avoid using this hack in common cases.

Why can't we keep the signed int? Do we ever need such a long timeout. We could for example define -1 as use default timeout.

This has been fixed for gnupg24 and gpg4win.

!ebo: Did you set a log-file into gpg.conf or common.conf ?

That is basically the key signing party scheme we developed at the keyserver convention in Utrecht in 2000. Sometimes also known as Sassaman or over-the-lunch protocol. Gnupg used to come with a tool named ring-a-party which did the paperwork. However, experience has shown that it is too hard to explain and get right - even to key signing party geeks.

Funny enough that Python seems not to allow to set the permission with open. Low priority because a proper umask must anyway be used on a multi-user system.