Backported to 2.2

Okay, in 2.2 the output now looks like this:

This is closely related to T3465 which was fixed in master. Running a gpg-agent 2.3 agent and using gpg 2.2 it works; however, using a gpg 2.3 bails out with an error message that we are in batch mode. I will look at this.

Won't happen for 2.2

@gniibe: I am not sure we really continued by mail - do you have any updates on the status?

Sorry, I have not yet followed you test plan but given that we have the patch in master for a long time now I think it is okay to port it to 2.2.

The newlines are not percent escaped because that could lead to very long lines and thus break parsers. Another reason is that the error messages are easier to read this way. An empty first field is anyway not valid and parsers should skip that.

I tried to replicate that with my ~3000 keys on master and I don't see any difference. Did you tried it several times? It might be due to the signature verification cache.

I checked the code and your patch looks right. I am going to apply it.

I am not able to replicate my own bug. At least since the introduction of --locate-external-keys the code paths are identical. I am nut sure why I filed this bug.

It is easy to explain:

I'm using enigmail 1.9.9 because I'm on a mail client that doesn't use WebExtensions, so it's using gnupg for keyserver stuff. In this case that means I've been able to verify it's a gnupg issue (both Kleopatra and enigmail displaying the same issue as CLI).

Yes, i'd surmised that the ::::: lines are continuation lines of the error message. but why not just percent-escape the newline in the error message too? Where in the documentation of this API does it say to expect continuation lines of error messages? Is gpgconf expected to be used programmatically?

@Moonchild wrote:

using enigmail with the new version

Added variable value

set language
LANGUAGE=en_US

I launched the Kleopatra again. I did not notice any changes.

Just registered to report pretty much the same.
I've been using gpg 2 for a long while and it's been doing just fine, up to the point where people started using keys it didn't recognise that require a later version.

Well, I misread the output. What you see is what is expected. From the gpgconf man page:

Thanks for your report. Yes this is sadly a known issue. Our backend system has it's own localization that uses the system language and does not care about the Kleopatra configuration.

We don't consider this a security problem because the tool you used is a debug helper which we use during development (if at all). All real code needs to verify that it does not request a division by zero. The div-by-zero checks we added 8 years agot to other code paths (e.g. mpi_pow, rC2c54c4da19d3a79e9f749740828026dd41f0521a) are failstop measurements which should never be triggered.

Thanks for quick response and fixing the issue. We wanted to request for a CVE since libgcrypt is widely used and a patch has been provided. Please let us know if you have any disclosure policy.

You are providing invaldid data to this debug helper tools and run into a div-by-zero. I will add the usual test earlier in the code path so that a fatal error is triggered. Thanks for the report.

I think you mean "mix", not "fix". right?

You should not fix stdout with stderr. Granted we could fflush stdout after a line, but rsh is dead and so all software can distinguish between them.

I t could print a warning for a non-existant homedir

Sure, I personally know that GnuPG requires a homedir to operate.

As you surely known GnuPG requires its home directory; in particular when using the gpgconf to manage the config options. Thus I can't see what to do other than error out. gpgconf needs to know the location of the config file; if it is containign diretcory is not existant it will fail anyway.

I don't have a Free BSD. Can you please try out the patch that I have appended to https://bugs.kde.org/show_bug.cgi?id=415168 ?

In T4861#132936, @dkg wrote:

0005 and 0006 from the debian distribution of gpgme.

Thanks for the report. Indeed I closed this as a duplicated. Thanks @dkg for pointing out the patches.

I pushed the change to master.

I think this might be the same as T4820.

I've just pushed ad55de70930543c1681b11e4bd624be074122b23 onto branch dkg/fix-4855 as a proposed fix, to permit --trusted-key to accept a full 20-byte fingerprint.

Latest one (gnupg 2.2.19)

(I stripped the report down to its core)

Sorry but that really strange.
I need to regenerate those files.
Could you please describe what needs to be done to have proper version?

Do not use arbitary libtool versions or use autoreconf - this is maintainer-only and any problems are not considered a bug.

With the fix of T4623, this bug is now fixed.

Fixed in master, using Libs.private support.

Fixed in master.

Yeah, this can be done.

I already tried reinstalling gpg4win without first uninstalling it (I thought it might repair corrupt files) but now I uninstalled first and it is working again.

I searched through C: and D: and found it in D:\Programme\GnuPG\bin and in D:\Programme\Gpg4win\bin - both seem to be created by gpg4win. I'll try reinstalling, hopefully without deleting my private keys...

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.

Wald certificate will be fixed very soon. But as it is not fixed yet, I provided an http link, not https for you.

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!

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

I'd like to re-report this bug for version 3.1.11-Gpg4win-3.1.11
in Windows 10 version 1809 build 17763.1039 and version 1909 build 18363.657.

OK. The reason I'd posted on here was because KMyMoney was working properly until I tried to use the encryption.

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.

Hi,
Thanks for the report but, but we are not developers of KMymoney, I can only offer to help the developers if they have questions but please rather report a bug at bugs.kde.org regarding that so that they can figure out what might be wrong.