OK, I take this ticket.

Thanks for the tests and the report.

Ok i saw they apply custom patches to _gpgme_mkstemp which are outdated and should be revisited, sorry for the noise

Actually i have now more debug output and i think i found the issue

I close this for now, this seems a problem of the mingw packages in msys2

ping, what's the status of this bug? it has been in testing for over one year. is that the correct status?

Thanks for the report. I've commited a fix. (Returning the c_str here is ok as the data is not meant to be modified once "action" is called)
Please let us know if you find additional issues.

Or with both packages installed, could i maybe debug somehow where it searches?

BenM, msys2 uses pacman as packagemanager, all packages are build from source

There is the same bug and fix in function parse_key :

diff --git a/g10/parse-packet.c b/g10/parse-packet.c
index 0d28e7ac1..b147179e2 100644
--- a/g10/parse-packet.c
+++ b/g10/parse-packet.c
@@ -2533,7 +2533,7 @@ parse_key (IOBUF inp, int pkttype, unsigned long pktlen,
                      err = gpg_error (GPG_ERR_INV_PACKET);
                      goto leave;
                    }
-                 ski->s2k.count = iobuf_get (inp);
+                 ski->s2k.count = iobuf_get_noeof (inp);
                  pktlen--;
                  if (list_mode)
                    es_fprintf (listfp, "\tprotect count: %lu (%lu)\n",

I misunderstood your original report.

Alternatively, if they wish to keep using the Python installer from python.org then they would need to drop MSys2 in favour of the same version of Microsoft Visual Studio used to compile the that specific version of Python with and use it to compile every part of the GnuPG stack, up to and including GPGME.

If that is indeed the case and the theory regarding runtime conflicts, currently under investigation in T3505 and T4086, also proves to be true; then MSys2 users and developers will need to cease using the precompiled versions of Python available from python.org and compile their own version of Python copy with MSys2.

Was anyone successful in debugging dirmngr? I'm having the same issue. The dirmngr process gets stuck, no output at all, and this causes Kleopatra to get stuck waiting for it. I can only run Kleopatra after I have killed the dirmngr process. If I understand correctly I still need this process for network-related functionality, so I would need to fix it if I want to use all functions.

I updated the software to its latest version "gpg4win v3.1.1" and i'm still facing this issue.

Patch applied. Thanks.

I do not see the harm in this patch and it seems useful. Indeed it seems better then making a directory in tmp as this might create regressions for others.

This question and some of the answers to it on StackOverflow indicate some of the difficulties in getting SWIG generated Python modules to install at all. Essentially, though the easiest method currently available without extensive customisation of the setup.py file which would need to be done for both Python 2.7 and Python 3.x is to run /path/to/specific/pythonX.Y setup.py build and then follow that with /path/to/specific/pythonX.Y setup.py install and then follow that with renaming lang/python/build to a relevant directory and/or path name which indicates which version of python was used and the location or path it is in.

This was fixed with kleo rev 289efa360f6b15a3389ea2f2efede352711e7d7e

While performing some initial investigation regarding observed discrepancies between compiling GPGME directly and the subsequent SWIG static object for T4086, confirmed the relative ease by which multiple installations would be achievable if performed as a post-build process. This would have the added advantage of being more readily customisable by package maintainers downstream and not just for Debian, it could be made to work more easily with other distributions or other posix systems too.

I can't reproduce the problem with multiple instances of gpg-agent and scdaemon.
However, gpg-agent continues to run after the user has logged out. This is unacceptable, am I right?

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