Done for libgcrypt, finally.

ntbtls adopts the way from the beginning.

Just commited. Thanks.

The current version is 0.9.10 and the reported 0.9.5 is 4 years old. We also received no more info.

Thanks for the report I'll look into it. Won't make it into the next release though as we are currently very close to the release.

I could reproduce it at first, but when trying to make a screenshot clip
from that, I couldn't reproduce it any more, no matter what. It's either
gone (mail server update?) or needs a very specific sequence of events
that is quite unlikely.

@werner And perhaps it's worth mentioning that in my case it is gpg2 --version; gpg is 1.4.23. I have no idea whether that might play any role.

@werner Hi, the version output is as follows:

Thanks for the report. I would also like to see what

Please check your ld.so (dynamic linker) setting (/etc/ld.so.conf and/or LD_LIBRARY_PATH).

Please put

Done for gpgme.

Editor fault. The browser's editor is not like Emacs and here o my laptop the backspace key does not work as intended. I guess I was about to write ".. a back signature's usage flag".

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

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?

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:

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 ran gpgconf --kill gpg-agent and then the suggested command for i in {1..10}; do gpg -v --no-tty --verbose -o - encrypted.gpg 2>mylog.$i > /dev/null & done. (I was already running with --verbose, does -v add something else?)

In the interests of completeness I also tried it on a much larger file (1GB) which was both signed and encrypted. I also set the decryption to show the session key just to confirm it was decrypting since the plaintext was being sent to /dev/null.

I am unable to replicate this on OS X 10.9 Mavericks.

Running with -v would really be helpful.

This was a regression from 59e8a7ee3bcd16275091c9535626e49fc2a6c4af where a performance improvement to cache an object caused this problem.

Ah wait, I just remembered T4142. Maybe that is related. I'll try to reproduce that one first.

Again one of these issues I can't reproduce :-/

I made a large file for testing, but it doesn't matter. There's an arbitrary parallel limit where gpg will crash.

Please check again with a recent upstream release or report to Debian. The release from Debian is pretty old and has a couple of non-standard patches.

updated example sent.

I confirm I have the same problem but, unfortunately, the beta did not help.

The self test error message looks like it originates from https://github.com/KDE/kleopatra/blob/master/src/selftest/enginecheck.cpp

gpg -k works and displays the list of keys I expect. gpgsm -k returns nothing.

I'll try to reproduce it.

Cureently with the same machine using the old DLL I'm able to work with no problems. I tried several times to switch back to the new DLL and the problem appears immediatly.
If you need some other log I can produce it, just direct me. I used the procedure to enable gpgol logs I found on the forums.

Strange, this happens when Kleopatra is unable to launch the gpg.exe / gpgsm.exe binaries. But in the log I can see that gpgconf is found and scdaemon / gpg-agent seem to work. So your installation is apparently fine.

Thank you for the report. I can't reproduce this behavior of course :-/ and from a first glance I also don't see any problem in your log. The last line logged says "GpgOL code is done, handing it back to Outlook".

@a_p3rson : Yes. I agree that I think that cepxuo meant something differently then you.

Yes, due it uses adwaita-qt theme.
Yes, I can start it on the command line and it works, but gives a warning.

On reviewing the bug report I realized I had included the wrong section of the Kleopatra log. I cleared the log file and ran Kleopatra again to get the correct log entry for the version of gpg4win in use. Here it is:

I think the point of my request was originally missed. I will take a screen
capture of the pinentry workflow during authentication and signing tasks -
in my opinion, they should be the same. However, during signing, the window
gets display focus (Windows switches it to the active window), whereas
during authentication it does not (and has to be alt-tabbed/switched to for
pin entry).

Andre explained that we don't do that anymore on purpose. Duck and read the discussion related to this if you are intereested. A related thing is that no-grab does not work on all platforms because it was designed for standard X but nowdays toolkits have their own ideas what is right and what is wrong.

pinentry-qt giving Gtk- warnings? Very strange. Please give an example. You can start pinentry on the command line like

if you start gpg-agent in that deprecated way it sees the envvars. it will even see them if it is as suggested started on-demand by gpg. However, things are different when a gpg-agent is already running; in that case only the listed envvars are conveyed to the pinentry.

It's white due to https://dev.gnupg.org/T4144

Moreover, pinentry-qt doesn't ignore env if it runned from gpg-agent. So you are wrong about technical reason.

"partially" means it doesn't allow to input elsewhere, but in case of focus loose input will go nowhere

At least it MUST NOT grub input with no-grab option. But it doesn't allow to input elsewhere in any case.

We need a way to replicate your problem, a few questions first:

We know that. And pinentry-gtk does like that.

It's possibe to do via gtk3 directly:
https://developer.gnome.org/gtk3/stable/gtk3-General.html#gtk-device-grab-add

Yes. It's up to GCR library in GNOME.

By grabbing I mean that it's not possible to input elsewhere. Same as ssh-askpass does.

By grabbing I mean that it's not possible to input elsewhere. Same as ssh-askpass does.