what does "back signature's usage tool" mean? can we make an addition to the test suite that ensures that bad signatures will be rejected?

The fix was not fully correct because it considered a back signature's usage tool.

Hi, Has anyone found a reason why that happens. I run into the same behavior on my Windows 10 1803 computer. I have Gpg4win version 3.1.3 freshly installed and dirmngr hangs. Thanks and best regards, Peter

Uhm. As far as I can see this has not moved the file.

ok, feel free to close this ticket then. It's disappointing that there
seems to be no sane, simple, private multi-channel communication
mechanism avaiable cross-platform that GnuPG can rely on.

I moved the location of config.h to a new "conf" subdirectory. This should solve the issue. Thanks for the report.

C++2a will have a <version> header, so some trunk libc++ headers now (indirectly) #include <version>, and on a case-insensitive file-system, when compiling a gpgme source file with "unlucky" -I../../.. switches against such trunk libc++, that can mean that such an #include <version> picks up gpgme's VERSION file.

Sorry, I am not sure whether I understand the problem. Sure we have a file VERSION in the top directory but from where and why is it included? Is that some libc++ includes a file "VERSION.h" and somehow the preprocessor includes the file "VERSION"? IS that specified in a new revision of a standard?

The problem is that the keyserver network is abused as free and
permanent data storage. We can't do much about it without larger
changes on the search capabilities of the keyservers. For more
information see the archives of the sks-devel list starting in July.

Ok. I was not aware that HKPS should already have the highest quality.

hkps pool really should be the most responsive, and it already requires clustered only servers for a couple of weeks to try to increase the responsiveness. Experience has shown that any keyserver with less than 3 nodes in a cluster should not be used towards end-users. But do you have any more debugging output as to the problem at hand?

I have this use case: A card based encryption key is used as a subkey on one of my keys but also on another key of mine. The reason for this can be that I want to have separate keys (with different fingerprints) for two user ids but still use the same card for decryption. Sure it is possible to figure out that the user ids belong together but it is not obvious on first sight. Another use case is a role account with a shared subkey with only one administering the primary key.

Thanks for your analysis and the report. The good news is that we had this already reported and have fixed it.

gpg: keydb_search failed: Provided object is too short

So these are the results for gpg -K:

This was additionally reported as https://bugs.debian.org/909755 -- it would be great to get a clear statement from the GnuPG project about handling the curated keyring use case.

Thank you for your detailed report. Seems like something strange is broken on your system and our error handling does not properly cover that.

After several experiments with attachment flags to get the same behavior outlook does for unsigned mails I could not find a way to set both the content-id and cause the attachment not to be hidden.

The reason for this appears to be the "Content-ID", this is usually set for embedded attachments like images and not for attachments like PDF's.
This leads to the attachment being hidden, e.g. if you have embedded images you do not want them to show up in the list of attachments.

Turns out that that was not the problem.

I want to be able to create an ed448 key using gpg, use it to sign things.

Please write a proper feature requests. Two words are bit too brief. You should indicate for what you want ed448 support: gpg, gpgsm, libgcrypt etc.