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.

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.