The set_bit is obvious but we should cross check with the specs. In the non-fips mode we also try w/o a limit.

The fix is from 2018 but was not picked up widely; see
https://github.com/madler/zlib/commit/5c44459c3b28a9bd3283aaceab7c615f8020c531

Sorry, that was a misunderstanding. My fault.

In fact, decent 2.2 versions (>=2.2.21) have the ability to decrypt AEAD packets - this has been implemented exactly for the case that some things get wrong at the user site. But we can't change old versions - we are not the Sirius Computer Corporation. I close this ticket because we can can't do anything if you are not able/willing to update to the latest version of the respective branch. Sorry.

There is also the very simple pinentry-tty

I don't like it either but the browser vendors don't like SRV records.

I still think that redirecting to another catch-all domain is contrary to the original goal and weakens the security model. We need to see what we can do about this.

Not in the way it is used by gpg. See T5880

The ECDHE_ECDSA suites are not yet implemented in ntbtls and thus we can't agree on a common cipher suite. Will be solved in the next Windows version.

Are you using 2.3.4 also on Windows?

see rC67b36154f88e for master.

Will add it. The reason I added Brainpool was due to a question on the performacne between Brainpool and other NIST.

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 ;-)