Actually this is pretty obvious; we better ignore such misbehaving servers.

No need for callbacks actually. We can do it in a simpler way. See commit rGe5ef5e3b914d5c8f0b841b078b164500ea157804

That would be bad for unattended use cases. Recording the time the lock file was created might be a solution. Then cleanup only after 15 minutes or so.

Is your GPG_TTY set so that pinentry can find the right tty?

Sorry, without detailed output of gpg we can't help you here. This is definitely not a GnuPG bug because too many people are using mutt and gnupg. You should also "set crypt_use_gpgme" -it works far better.

Please run with option -v to see what's wrong with pinentry.

SWDB updated - thus the latest zlib will be part of the next Windows build.

All 4 CVEs are findings related to standard conforming compiler optimizations which OTOH break long standing assumptions on C coding. “Let us show that our compiler produces the fastes code ever and ignore any assumptions coders had made over the last 50 year”.

Right, we are not affected by these CVE because we use only the very basic core in gpg and no higher level functions. At least for GnuPG there will be no update.

Thanks for you patches. Most of them applied cleanly despite that I delayed processing them for half a year.

Gook luck on Solaris with this suggestion ;-)

Reagarding the OpenPGP specs: there is a new draft with LOTS of changes to already agreed upon formats and conducted interop tests. Almost everything we implemented in GnuPG and RNP has had rough consensus in the WG. Minor things like AEAD chunk size were the contested pieces. However, now they want to change everything with the possible outcome of discretization the long established trust in the stability and durability of the PGP data and key format.

Thanks for notifying. Will be fixed in the next release (mid Apri).

Please see T5834 which is fixed in 1.17.1

Fixed in 1.17.1

Note the ABI bug the Qt version of 1.17.0 which is fixed with 1.17.1 (T5872)

Please describe your problem in more detail. Also: Which version of GpgOl and Outlook are you using, SMTP/IMAP or Exchange?

I don't think it is justified to tag this as "unbreak now" - which we use for severe bugs inhibiting the use of a deployed version.

I tend to agree

Cool. I did some quick tests with 2.2 on my pretty old X220 and it really makes sense to apply the patch there as well.:

aheinecke: Good idea

Do you mean revoking the entire key or a user-id, or a subkey? Having a way to revoke a user-id is probably the most interesting use-case. BTW, there is no "revoke a self-signature" - this is actually a revocation of the user-id or subkey.

Works for me in the current Kleopatra.

Sorry.

Actually all changes Kleopatra does go through gpgconf. Thus is is normal that gpgconf overwrites things.

Feel free to ask me by PM if you run into problems (wk at gnupg.org). Two of my colleagues are Vim users and thus have an interest in a well working plugin :-). Thanks.

Try with hkp:// - I assume that you are missing the new Lets Encrypt CA certificates

Why are you using the log output for scripting? This is not its intended use. You need to use --status-fd. Log output is purely for human consumption it not a stable API. BTW, --fixed-list-mode has gone ages ago but it does not harm.

There is another hacker working on finishing it. I only provided the framework.

What is the problem here? Some compiler warning about fully legal code?

It seems you have replaced the scdaemon module from GnuPG by a 3rd party module (which exhibits a version number 0.10.0) - this is not supported and you will of course run into errors.

What you uploaded are files with a length of zero bytes. That is not valid data. The hang should not happen of course.