Good idea. Thanks. Goes onto 2.3 and 2.2

Use a gpg 2.3 version:

• No we can't because current GnuPG 2.2 versions are able to decrypt such AEAD data.

See also T5537 and commit rG7d1215cb9cba2 for 2.2.

There is actually a much easier fix here. Thanks for pointing out the problem. For histroical reasons we have several places where we create the homedir.

Packet 20 is the new AEAD packet which GnuPG 2.3 can generate and does generate if all recipients have new keys generated with such a versions. However, the version of gpg you use now does not support AEAD and thus fails.

Sorry, HOME and ~/ are not standard on Windows and applying your patch may break existing installations.

Turned into a feature request because native building on Windows is not supported.

The original plan was to source copy dns.c from upstream and thus we tried to avoid any changes. Unfortunately we never achieved to push things upstream and thus our own changes got it. Eventually we will cleanup the code and use our own framework.

Using an armor header would allow for this. But well, this blows up the data and frankly, I fear that it can lead to unexpected side effects. Better to use a respective file name or MIME header.

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.