https://www.gpg4win.org/version3.1.3.html < beta28 has the fix. If nothing untoward happens this will be the final version to be released tomorrow.

I can't reproduce it. I don't get the Properties have changed dialog.

We have debug output now to show which commands are running.

I've tried again with different Versions to rerproduce this issue and I can't reproduce it.

I did not find any differences regarding junk mail. So I believe that this is fixed with T3459

There is no way for us to fix. It is a shell issue.

@elonsatoshi: Were you able to check this with 2.2.9 which has a fix for the resolver?

--verify-files is mostly useful for scripting and and not for manual checking. With scripting etc you always need to use --status-fd and with that you get:

I was already implementing a --no-homedir when I figured that we have --no-keyring. Using that with any homedir fulfills the requested purpose.

Hooray!

We are actually in the final release preparation and just waiting for GnuPG 2.2.10. If everything goes well it will be released this week. If not, next week.

Sweet, thank you! Any estimate on when that might come out?

yes

excellent - will this be includedin gpg4win 3.1.3?

Thanks. I can work with that. It is indeed clearly visible what the "Sent on behalf of" address is. So it makes sense to check that, too.

Sent two messages to the test mailinglist. Please let me know if you need / want more.

Will be in 2.2.10

Yes that would work for me and the pgp key is the right one. Thanks!

Actually, I can add you to a test mailinglist and send you a signed message tomorrow, would that work?

Ok! If outlook shows it we should verify it.

Hi Andre!

This was actually reported against 2.0.31 which reached EOL 8 months ago.

Without KEYLIST_MODE_WKD I also can't implement the desired behavior in a MUA using GnuPG.

Why the restriction to keyorg wkd ?

Done. To be released with 2.2.10.

T4026 is a bit related. I'm suprised that the signature check for mailman mails works at all for you ;-)

Thanks for the input. GpgOL should check against what outlook shows as the "From" Address. In your case: What does Outlook show? Is it "info@example.org" or "puppets-bounces" ?

No response so closing as invalid.

Thank you for the clarification. For now, I'll modify our implementation to use shorter length representation and close this bug as Invalid.
However, I'm still not convinced that using hard-coded arguments is the right way to handle requests. I'll do some more testing and if I discover a legitimate use-case that requires long APDUs, I'll reopen the issue.

I'm not sure if it's exactly the same case, but:

This entry was created based on the conversation at #gnupg channel.
I can't reproduce keep hanging.
I confirmed that pinentry vanished (perhaps, because of timeout).

gpg-agent has a pinentry caling timeout - doesn't that trigger?
In any case we agreed that Debian takes care of systemd support because that is not an upstream supported configuration.

We are moving to use the yat2m from gpgrt (libgpg-error); thus the additional tag.

Hi,
Can I ask if there is any update on the issue that I face?

Thanks for your answer

Ok
Thanks for your answer

I'm not sure that I understand your Problem. It might be helpful if you could provide screenshots of your problem so that we can better understand it.

We are not a CA and do not provide certificates.

There is currently no ECC key support in the S/MIME component of Gpg4win. I've edited the task a bit to reflect that. So it is impossible to generate an ECC Key for S/MIME with Kleopatra.

Thanks for the information.

In our implementation, DO 0x6E contains:

I don't understand the reason why 0x6E (Application Related Data) can be so long. What OpenPGP card implementation do you have?

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?