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.

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.

It is actually questionable whether PSS is a better padding scheme than PKCS#1, see
https://www.metzdowd.com/pipermail/cryptography/2019-November/035449.html . PSS seems indeed be rarely used; quoting Peter from a followup on his writeup: “If I get time over the weekend, and I can find a CMS message signed with RSA-PSS, I'll create a forgery using xor256.”

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.

Okay, I recall that I have seen these Yubikeys. Can you tell me which GPG app you intended to use? I am not aware of any GnuPG ports to the iPhone.

The new Yubikey 5Ci does NOT work with NFC, this is wrong. This Yubikey is delivered with two connectors: A lightning and an USB-C, see: https://www.mtrix.de/shop/yubikey-5ci/. The key can be connected to a laptop and an iPhone by plug-in. So the new Yubikey 5Ci does not require NFC at all. You refer to the Yubikey 5 NFC. This technology is not supported by developers because they do not have experiences there. With the plug and play functionality of a lightning connector it is easier and few application already exist (e.g. Yubico authenticator and several password manager in the professional edition). Hope this information will be useful for you.

To summarize: The DGN CRL uses a the RSA-PSS Padding / Signature Scheme. ( https://de.wikipedia.org/wiki/Probabilistic_Signature_Scheme )

keyserver-URL needs to be replaced with with a keyserver URL, like

hkps://hkps.pool.sks-keyservers.net

Supporting NFC tokens requires implementing secure messaging for cards. This is on our todo list anyway but has had no priority. I have a couple of Yubikeys but not done any work on NFC.

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 my particular case, I want to find out if an email address has a publickey associated to it that is publically available anywhere. I do not want to import the key automatically. I used to use this command:

--auto-key-retrieves tries to find a key when verifying a signature. --locate-key however does the same as what -r does and locates a key for further use. If you don't what that, don't include a key discovery mechanism in the the auto-key-locate like (wkd in this case, which is anyway the default).

i'd be unlikely to ship anything as /etc/gnupg/gpg.conf or /etc/gnupg/dirmngr.conf just because of the mess that admins have to deal with when shipped config files change.

In T4861#132936, @dkg wrote:

0005 and 0006 from the debian distribution of gpgme.

Arggh, gpgconf uses its own option parser so adding the global config file there will require some extra work.

@dkg You might find this interesting. Debian could do stuff in /etc/gnupg/gpg.conf or /etc/gnupg/dirmngr.conf without patching GnuPG to change some defaults.

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

I pushed the change to master.