I've checked: this issue is reproducible in Kleopatra 3.1.11 / Win10
I have installed version of Gpg4win, not portable

Also see Issue #10, Add Travis testing in the GnuPG GitHub. The PR adds Travis testing to the entire GnuPG suite.

The problem itself is fixed (in T4495: UBsan finding "certdump.c:695:3: runtime error: null pointer passed as argument 2"). The variable buffer cannot be NULL at memcpy.

thanks!

Done; will go into 2.2.21 (T4897).

Thanks.

This bug is linked to restoring window size in case of multi-monitor multi-DPI setup.
There is QT bug report: https://bugreports.qt.io/browse/QTBUG-77385

Of course it is important, that's why it it printed by default.

This is an important information to know because it can help to avoid bug reports.

FWIW, a log of the decryption process will always show the sender's key because a message is usually also encrypted to that one (--encrypt-to).

I think that what you want is adding --batch option. In the gpg manual, we have:

--passphrase-file file
       Read  the passphrase from file file. Only the first line will be
       read from  file  file.  This  can  only  be  used  if  only  one
       passphrase is supplied. Obviously, a passphrase stored in a file
       is of questionable security if other users can read  this  file.
       Don't use this option if you can avoid it.

Hello Team,

For operations which require private key, it is needed to unlock private key.

From where did you downloaded it? Did it show a valid issuer for the software (Intevation GmbH)?

Thanks for the quick fix, @werner!

Fixed.

Hello,
Sorry for the late reply but with your help we found a bug in our code and it has been fixed. Thanks for your assistance!

Arggh, this code is a whole mess (e.g. it uses its own logging code). I spent the last week to rework large parts of it for master. I am going to look into this case now.

If you want OCSP you need to enable it. CRLs or OCSP are a MUST under the profile we developed gpgsm. This is why --disable-crl-checks by default is not possible. There are lot of interesting things you will come across if you start to use S/MIME. For example you also need to care about the algorithms used for intermediate certificates used to sign CRLs - they need to comply to the policy as well. Or the rarely used PSS padding we encounter sometimes and which is not supported and will probably not be supported

Okay. Thanks.

You forwarded me an email, which said it went well.

Created https://dev.gnupg.org/source/gnupg/history/gniibe%252Fscd-watch/

I thought i'd try with other certificates. I started with the one from this website. It also fails to validate unless i supply --disable-crl-checks, apparently because the immediate issuer (the Let's Encrypt CA) doesn't offer CRLs, only OCSP responders. Perhaps --disable-crl-checks should be the default, or at least if there is no CRL available there shouldn't be a failure by default:

Aha, i can get it to say f if i use --disable-crl-checks:

i didn't know that, thanks. i'm now seeing i (which i think means "invalid") in the same configuration:

Add --with-validation to check the validity of a certificate in a listing.

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.