The DLL libassuan-0.dll was not found or the system somehow found.
Do you have other versions of GnuPG or Gpg4win installed? Please search the system for copies of the above mentioned DLL?

Fixed in master and 2.2

Really interesting: The code didn't changed since since 2003 and the bug must have been there all the time. It does happen only for 25% of the certificates with CR and LF; the others have padding characters at the end '=' which is also an indication of the end of the base64 block. I wonder why this has not been reported more often; maybe because most people import binary certificates.

Thomas, please provide a sample certificate. I can't access the intevation site to see whether one of the links has the cert. And pretty please fix the wald certificates!

Older version of GnuPG had a rare bug in the keyring update code.

No, this depends on the version of Libgcrypt. Sorry, won't be documented or changed. Thanks for the report, though.

Building with -fno-common now works for me on 2.2 and master. Thanks for the patch.

I took your patch but modified it to define EXTERN_UNLESS_MAIN_MODULE only at one place.

Note that we have a small pactch in the queue which should be applied by distributions to 1.37unless they want to wait for 1.38. See rEd72c1ddfde09ffa69745ec2439c5a16d15e2202f

Install the zlib development package, its name is often "zlib1g-dev". The source requires the header because we plan to eventually support compression.

Committed.

Thanks. Fix goes into 1.37.

It has been fixed in the repo for nearly a year, see T4459. A new release is urgently required and will follow in the next days. I close this as a duplicate.

Funny. I looked into the history of that function: @dshaw removed the option --list-trust-path from gnupg 1.x in December 2002. He commented

In a private mail someone else reported a similar problems and explained that gcc-10 will change the default from -fcommon to -fno-common. I think this is again a bad move in compiler development. Replacing the de-facto standard C compiler behaviour with something _allowed_ by ISO-C. No industrial grade toolchain would ever do such a silly default change - too many customers would rightfully be angry with them.

You mean that common blocks can't be used anymore? The RISC-OS had this problem but it was the only architecture I was aware of that required "extern" trickery.

We briefly talked in the OpenPGP WG about the u32 problem and agreed that this is not an issue for 2440bis. The mismatch between creation date and expiration period is one of those minor PGP flaws. PGP-2 even used days to specify the expiration period.

I would like to understand why this changed. T4061 might be relevant here. This has been fixed after the 2.2.19 release.

I don't care; encryption won't work for us 6ft under. (This is a protocol problem which someone should address in a couple of decades)

That looks pretty much like another gawk regression. The easiest fix is to install another AWK version (e.g. mawk).