I am not sure whether this is related but when using Libgcrypt master and verifying a signature created with an ed25519 key, I get the error below with valgrind. Both with 2.2. current and 2.3. It does not happen with the current Libgcrypt 1.8.

For reference, here's an error message from openssl smime when it is trying to verify an e-mail message with no embedded certificate at all (despite it knowing about the relevant certificate):

There are likely some bugs in the new code and I also want to do some improvements; see rGb4f1159a5bd7. But things should basically work as before and thus I set this again to testing

This is now implemented

Fixed in master.

A program like tests/t-mpi-point assumes gcry_mpi_print can do that.
We have a sort of regression with --debug option with t-mpi-point, the point q is not printed out correctly.

ftr, here is the thread I had in mind but couldn't recall above. @aheinecke is that your thinking, or a more pgp/mime bound mechanism as @dkg assumed?

"log" and "lock" are easy typo/confusions to make, @aheinecke was just trying to understand your report better, since there wasn't much information in it.

This requires re-evaluation of Libgcrypt to match the current FIPS specs.

@wiktor-k, "just extend the spec" doesn't necessarily work with existing clients, which might be surprised to find unexpected packets in the signature section of an e-mail. It seems more likely to me that they'd be able to handle (meaning: ignore) an unknown subpacket (as long as it's well-formed) than to handle additional packets. But all of these surmises require testing with existing clients, of course. Has anyone done any of that testing?

At no point did I mention log files ? So not sure where that is coming from.

apologies but I do not understand this issue. Please clarify. Were you having issues with "log" files or "lock" files?
What was your issue?

This is a nice idea and although it overlaps with Autocrypt it has other uses too: for example verification of signed files that can be vastly simplified (just get the file and the signature, no key fetching needed, downside: the key attached to the signature could be stale).

Ah, thanks for pointing out the subpacket option (i guess it could be hashed or unhashed). i don't think any of the subpackets currently defined in RFC4880 supports this use case -- but i guess you could mint a new one, or use a notation.

Werner said that it's possible in OpenPGP to also put the pubkey into the signature. (...) The nice advantage is that this will also work for files.

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

Hi @aheinecke, thanks for thinking about this, and thanks for tagging me here too. I'm definitely interested.

This is an important fix for a sensible S/MIME use case. Thanks for working on it!

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.