Thanks a lot for your testing. So, apparently, the PC/SC behavior is different between GNU/Linux and Windows.
Thus, I pushed another change: rG1e27c0e04cd3: scd: More fix with PC/SC for Windows.. Please test this. (Both of previous version and this version work well on GNU/Linux for operations not including suspend/resume with Yubikey and Gnuk Token, while my Yubikey with PC/SC doesn't work well for suspend/resume.)

Thanks, this version of scdaemon executes.

I think the problem is more that NSIS uses this arcane build system which makes it hard to cross compile.
NSIS 3.0 is also not in experimental.

About Debian: Stable releases are only updated for bug fixes and not for new features. This is an important for almost all production systems. Rolling release distros do not provide a platform which can be used to replicate use cases or problems.

there is only NSIS 2.51 in debian

Cool! Thanks for testing :-)

Thanks for the help,

I can't reproduce this. I sent myself a Mail with capitalized "Andre.Heinecke@intevation.de" while my key only has an identity for "andre.heinecke@intevation.de" and it worked as expected:

Mh, that is strange and indeed a bug if that is so. GpgOL should do some simple normalisation which should prevent exactly such a problem. I'll look into it.

At some point we really need to look at better error handling so that such an error would be more visible in the UI.

Thanks for your help / report.

With Gpg4win 3.1.0 ( https://files.gpg4win.org/Beta/gpg4win-3.1.0-beta-current.exe ) GpgOL no longer uses Kleopatra for signing. So this problem can no longer exist.

I'm lowering the priority to Normal. I've done a lot of GpgOL work and Testing for the upcoming 3.1.0 release and have not seen this problem.

Leaving this open until we have a new version of GnuPG in the installer. While Kleopatra should no longer crash it won't properly work without the patch to GnuPG.

Got confirmation In Bugs.kde.org that this is fixed https://bugs.kde.org/show_bug.cgi?id=389792 as my tests also showed this -> resolved.

We have this now. There might be bugs but in general this works.

Sorry, my build was not good even if it's for x86_64 (I used development version of libassuan, etc.).

I installed 3.1.0-beta and tested all use cases, everything is working properly now.

A Beta of 3.1.0 is now available:
https://files.gpg4win.org/Beta/gpg4win-3.1.0-beta-current.exe

Yes sorry, I decided against a release specially for that is it is not super critical, no data loss.

A beta of the next version where this is fixed is available now: https://files.gpg4win.org/Beta/gpg4win-3.1.0-beta-current.exe

I've uploaded a beta for the upcoming 3.1.0 Version: https://files.gpg4win.org/Beta/gpg4win-3.1.0-beta-current.exe

Version 3.1.0 now supports sign & encrypt and sign only for G Suite accounts as long as there are no attachments on the mail.

Great.
I'll wait for v3.1.0 then.

From the log I can see that GpgOL picks up the wrong "Sender" address. It thinks that you sent the mail yourself and then the mail address <> signature does not match. So it is not flagged as Trusted.

When we detect GnuPG > Version 2.1.15 Kleopatra now offers (and has it as default for ECC) to use cv25519 / EdDSA

@gniibe it seems the patched scdaemon.exe is 64 bit executable and it requires libassuan6-0.dll. However I got installed 32 bit version of gpg that only has incompatible libassuan-0.dll. I scanned whole computer for the missing lib, skimmed your ftp for 64 bit binaries and looked into gpg4win installer to find it, but no luck. There is also libassuan github repo, but I would like to avoid building the dll myself; there would probably be more than one dll to build anyway.

If possible, please try with this (patched version of scdaemon):

It looks like you're having the same issue that I reported: T3761.

Hey, @uwestoehr. It looks like you're having the same issue that I reported: T3761.

Hi Andre

This issue is not concrete enough to have some kind of "done" so ->invalid

This issue is invalid.

C:\Users\XavierFRUTON>gpg --gen-key
gpg (GnuPG) 2.2.4; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

rW981a6fae5355 Fixes the problem with Kleopatra's config files.

Is it possible that your %APPDATA% directory is redirected? Maybe you are running into T3818 I also got "General Error" when trying to generate a key because of that bug.

With the attached commit gpgconf works. Key generation in Kleopatra also handles the case now that gpgconf does not work.

The underlying problem is that gpgconf does not work in such an environment.

Could you please try on the command line. (If you don't know how, see: https://www.wikihow.com/Open-the-Command-Prompt-in-Windows )

Hi aheinecke,
I did some tests with 2.0.7-beta10 and still found some issues.
The message I attached as a test case in previous comment is now properly handled, I see no "signature.asc" attachment and message is correctly tagged as trusted sender; this test message was sent from Evolution and I sent it to myself (sorry for not pointing this out before).

Thanks for the test and the example mail. Should also be fixed now.
While testing I also noticed that the sender email address was also not parsed correctly for these kind of mails and added some code to fix that.

I just tested version 2.0.7-beta8 x64 and I can confirm the bug is fixed, GpgOL can decrypt messages properly. Messages also appear to be properly signed.

Thank you. With that message I could reproduce the problem and have a fix. I now get to decryption failed / no secret key as it should be.

You can find the message attached.
Message has been saved from Outlook 2013.

Thanks for your report and analysis.

Note that there is no standard for this. In particular the encoding of filenames with special characters are different in almost all implementations. I tried to find a common ground for our implementation.

Just to be clear I think this issue is valid and we should add more checksum tools in the future. But I would want them to use libgcrypt and confirm to the standard *sum command line arguments like -c.

On saturday I could observe the problem with a fresh Windows 10 Home edition.

Kleopatra can still be used without UI Server connectivity. But this might point to a bigger issue.

Here is the firefox warning

This is coming along nicely. It might take longer then with Kleopatra if the key is large (as the new resolver does a full keylisting on every start) but that should be OK and we have plans to optimize that anyway.

We confirmed in a remote session that the Titus Data Classification plugin ( https://www.titus.com/data-classification-product-collection.php#tmc ) interfered with GpgOL.

Another observation: Just opening the file from the explorer is not enough, but once I was on the details of the digital signature, opening works. So for whatever reasons Firefox and Chromium do not trigger the security check.