Yay. Got it.

Dear Andre , all , T4020 does not even well-define the symptom and I
do not agree T4020 is a duplicate of T4079 . I'd close T4020 in favor
of T4079 . Many thanks . Mirko

Hi Mirko,

Nothing special at all. Using sysvinit, not systemd.
Ran gpg and gpa as a regular user a few times. Then, after logging out, I found those processes still running.

There should be only one instance of gpg-agent running per GNUPGHOME directory (i.e per user). Is this a systemd system where you started gpg-agent in supervised mode (e.g. Debian) or a regular system. What is special in your setup?

if that is the case config.{guess,sub} needs to support this and we should be able to handle this the same way as other Unix platforms.

You seem to have reached the wrong page when searching for msys2

To clarify: I would like to see the targeting of keys be unified.
I see the following options:

The matching error message and the similar keywords let me to miss that - indeed.

You are mixing gpgsm and gpg - they have different semantics: That github mirror under the top name of "gpg" might
be a reason for that confusion.

Done for npth.

There were two things here:

This was a very clear crash that is fixed now. Length was > 76 characters. This caused an improper realloc.

Some times I a curious and it seems that GnuPG can be used on 32 bit Cygwin. Thus I wonder what is going on on 64 bit Cygwin (which I don't know). It might be a HANDLE/socket issue where Windows is still using values which fit into a 32 bit integer but Cygwin might have changed that. Eventually we need to remove that assumption in GnuPG's code and this is why I won't have a problem to keep this bug open.

Given that Cygwin is not supported I would understand if the bug is
closed or should I open a feature request to have Cygwin officialy
supported.
I would never the less appriciate any help/hint on how to be successfull
installing "gnupg" on Cygwin.

Note that Cygwin is not a supported platform. Seems that the exec functions don't work on this 64 bit variant.

No problem. I am glad that it works.

Boh. I've retried today, and seems to work as expected:

@Breach I was analyzing T4056 and wondered where I had seen the error from there before. And I found it in your log.

Actually the --locate-key command differs from the implicit use of locate key code when encrypting to a mail address.
After importing the expired key and running for example

Slight addendum: MSYS2 isn't even part of MinGW at all, see the commentary in this bug report. Nor is it a part of Cygwin, but apparently it is a part of a fork of Cygwin.

Not only is this not supported, but I've now confirmed that MSYS2 isn't even supported by its own project and they direct all downloaders to their MinGW-get installer.

We have a workaround thus lowering the priority.

It won't import that keyblock. We can fixup some trivial cases but there will always be ways to create a garbled keyblock and that is nothing we can fix. Better restore the keyblock from a backup or write a dedicated tool fsck-like tool.

What happens, if other bad packets beside PKT_USER_ID, PKT_ATTRIBUTE, PKT_OLD_COMMENT, and PKT_COMMENT are found?

Thank you for your prompt response and your suggestion for a workaround.

Got it. The reason was a broken translation. I've opened T4054 to fix in general that broken translations can cause crashes.

I can reproduce it with a german windows

Thank you for your detailed report!

Fixed for master and 2.2.9.

Will be released with 2.2.9

Fix will also go into 2.2.9

Do you have Tor or the Tor Browser running? Dirmngr will use them instead of a direct or proxy network connection. Di disable this behaviour put

no-use-tor

into dirmngr.conf. If that is not the case we need some more debug info. Put

log-file SOMEFILE
verbose
debug network,dns

into dirmngr.conf and post the log file (or send privately to wk@gnupg.org mentioning T4044 in the subject - no HTML please).

This is really minor, just wanted to report it so it did not get forgotten.

I don't think that this was ever working the Outlook 2007 code has been pretty much unchanged since 2013.
According to T1137 a workaround seems to be to enable the S/MIME Support in GpgOL.

Thanks very much for your help! Could you please tell me the latest version, that is running without any mistakes on outlook 2007?

Outlook 2007 is no longer supported. Neither by Microsoft nor by GpgOL. Sorry for that. But the 2010 and later GpgOL had a completely different codebase and we had to remove the support at some point.

Fixed in master and 2.2 branch.

I found two more cases. Those are included in the fix.

Maybe a first step would be a "KEYLIST_MODE_WKD" which sets "auto-key-locate clear,nodefault,wkd" (Would be nice for T3910 ) or just a ctx_flag "auto-key-locate" so that the caller can decide?

I'm pretty sure that the running command ist the reloadkeyscommand.

Good catch. Thank you.

The cause is: ! in nsswitch.conf
This was fixed (2.2 branch) by rGd4c0187dd931: libdns: Hack to skip negation term. for GnuPG in Jan 2017.
I found it was fixed in the original libdns, and this fix is merged into rG20c289606f89: libdns: Sync to upstream. to GnuPG.

Werner please give an opinion / triage.

Good news! :)

Just as a note as you were the first to report this: I've finally found a solution. In the next version it will be possible to move around crypto mails. Hopefully your wife can then use GpgOL :-)

The new idea worked! It is now possible to move mails even while their decrypted content is shown!