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.

I confirm this bug!

@werner Given you filed it as low priority and documentation - could you give feedback on whether that is expected behaviour or not?

Perhaps it happens because I'm asking for "Lesebestätigungen" along all mails? But still the icons for signing should not be gone!

Thanks a lot.
By this report, I was able to fix more memory leaks.

sorry, i haven't had time to test gpgme with those changes myself. i hope someone can do so.

The background of my earlier comment was that I didn't tested GPGME in this regard.

if gpgme doesn't rely on the return value, but instead on parsing the --status-fd for errors, then there will still be an ERROR printed:

Okay. So for GPGME should we add --no-keyring if --override-session-key is also enabled? I think this would be better than relying on the fact that gpgme ignores the returned error code.

I've uploaded a Gpg4win installer with this fix (3.1.4-beta3) to https://files.gpg4win.org/Beta/current/

yes, it looks like using --no-keyring does change the return code from 2 to 0 for me.

@dkg does --no-keyring solves the problem for you?

We assume that this has meanwhile been fixed.

Asked in https://github.com/google/oss-fuzz/pull/1806

I made a mistake and put the DLL in the wrong folder. After placing it into the correct one, everything is working fine and stable.

Actually it fails only when you set TERM to the empty string. Unsetting TERM still works:

Another address does not help as long as we are forced to use a Google account. That is not subject to discussion. sorry.

ok @werner
Should I change it to another mail address (@gniibe if you are interested) or should I just use mine ?

You may indeed post to gnupg-devel if that helps to raise the attention of the Travis folks. If they need support we would be glad to help.

This has always been the case and the worst thing which can happen is that (64 bit keyid clash) you might not be abale to import the "real" key. Keyserver's never promised to deliver the correct (in whatever sense) key, but are merely an anonymous and distributed stoarage systenms. This is why gpg does not trust a key by default but requires you to validate the key by other means (WoT, second channel, Web Key Directory).

I confirmed: Now, all use cases of iobuf_get check against negative value or are using iobuf_get_eof.
So, closing.

@catenacyber thanks fo this bug report.

..anybody?

Yes we had a bug in 3.1.2 that when you had a contact group as recipients gpgol would silently ignore them and don't encrypt to them.

Here's an example of a bad key: http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x4359ED62E084DAB9
which mimics the good key for R-CRAN: http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x51716619E084DAB9

First let me say; Thank you very much for your help ! :-)

I think this might be a ticket in itself. If I send a PGP signed email to someone who then responds to me, there should ideally not be issues with it - although I think it would be important to separate which parts are signed and which are not.

header of mail forwarded. looks like it says utf-8. either way, it does work with the right key.

Received. Thanks, so this is PGP Inline. Encoding handling in PGP Inline is always "Guessing" as it is no where defined which encoding is used for the message.

I've commited a fix and because this and another issue we might do a release sooner than originally planned.

If you like you can help by confirming that it also works for you by installing 2.3.1-beta11-STABLE-BRANCH-2-3 from https://files.gpg4win.org/Beta/gpgol/ as described under: https://wiki.gnupg.org/TroubleShooting#Manually_update_GpgOL_to_a_beta

interesting. email sent.

Mmh no, I can't reproduce this and my initial hunch was wrong. We do in fact handle encoding in that case.

Patch 0001 applied to master.

Thanks for your report. Applied.

I just tried the newest beta and I can confirm that sending Office attachments does work for me with this version.

Added gpgol and gpg4win project tags as this is important for these projects.

I was unable to figure out what the difference is between the handling of Office files and other files and why it comes to this error.

Thanks for the report.

I can reproduce the issue and give it high priority. This is a curious problem of Outlook triggered by the improved send code in Gpg4win 3.1.3.

Here's the debug log file.