Fixed with https://commits.kde.org/kleopatra/066c6e4ca82d064437f1902838d09fa903147e40

In the folder %APPDATA%\gnupg create a file named gpg.conf (or edit it if it exists) and put the line "ignore-mdc-error" in there. This should globally set this option and gpgol will also respect this.

Thank you for your report. I can reproduce this problem. Kleopatra correctly looks for the signature file but then fails to set the protocol. This results in an internal error.

In T3714#109045, @Lloyd wrote:

I appreciate the dangers. Whilst I try and persuade the sender to deal with the issue at their end, is there anyway to include this option in GpgOL on a temporary basis?

Andre, I assign this to you. If you don't think that a better warning in Kleopatra is needed, please close the report.

OK. Thank you for that.

Thanks for asking. We may need to put this into the FAQ, so here is my answer:

Forgive me if I'm completely off the mark here. In no way do I claim to fully understand gpg etc.

The last line shows that gpg decided that to return a failure because the message does not use the MDC scheme. Since the introduction of modern algorithms with a _blocklength_ of 128 bit (e.g. AES) gpg always uses the MDC encryption system even if it is not announced by the respective key flags. The reason for theses algorithms are newer than the MDC system and thus we can expect that all applications supporting AES will also support MDC.

Fixed with: https://commits.kde.org/kleopatra/c85bc8ebbe8594be9309e3e8a0945a5dbb90828c

Also the Name and E-Mail split in the table looks ugly. While technically they are on different UserID objects it would be prettyer to combine them.

This goes to wontfix I investigated and there is no way to attach a file trough the mailto protocol with outlook. Only the parameters from https://msdn.microsoft.com/en-us/library/aa767737.aspx are supported.
Theoretically Kleopatra "could" use MAPI to achieve creating a mail with attachment but this would be overkill. Kleopatra puts up a big warning that attaching may not have worked and ok.

Case Insensitive Sorting is fixed with:
https://commits.kde.org/kleopatra/856aad228a81f542f821209ae2c796d9b7160263

Forgot to mention the revision. It's https://commits.kde.org/kleopatra/0428c744fbd56a305d3e249215d74fe6ad811acf

I implemented a text export action that uses the details of a certificate as comments. This will bring back the old copy & paste able details and has the additional advantage of a nice and quick export.

I checked the mingw runtime and did not found any allocation of a new console. Thus I don't understand why a console pops up when gpgconf is used. gpgconf spawns gpg et. al to read its options and it does this without using DETACHED_PROCESS. Thus all these subprocesses inherit the parents console - which is for gpgme started process no console (due to DETACHED_PROCESS used in gpgme_w32spwn). For a GUI application like Kleopatra which has no console, the use use DETACHED_PROCESS sould not make a difference because there is no console to inherit. Andre's test however show that it makes a difference.

The assuan_pipe_connect function is called with bit 7 set for example to start pinentry or scdaemon:

*cough* That change made it into Gpg4win 3.0.2 *cough*

Resolved with gpg4win-3.0.2

Added it. For now it's pretty bare but already an improvement on the old (which only showed "class") and no indication if a signature was revoked.

It's also fixed. There was a problem with the error handing. A canceled pinentry is communicated as an error with code operation canceled.

In T3577#107074, @aheinecke wrote:

So if the user had a "real" error it might have crashed instead of showing the error.

As a note: The second crash might be related in that the crash could happen on any error. So if the user had a "real" error it might have crashed instead of showing the error.

Indeed easily reproducible issue.

Hi,
this is intended behavior. KLEOPATRA_LOGDIR is a development / testing setting and it can be useful to look into which data is sent to GnuPG.
Please disable Kleopatra logging as described in:
https://www.gpg4win.org/doc/en/gpg4win-compendium_29.html

Last commit of the series: https://commits.kde.org/kleopatra/c5567d6915bb0e76284281590282d942966322b0

Implemented with https://commits.kde.org/kleopatra/3ddc062f72853738904d1e25dd2d4440e348fd43

Added with https://commits.kde.org/kleopatra/2b22bccfa852cd22e62d95c2270187c7f23b63cf

Implemented with https://commits.kde.org/kleopatra/805f5cfafe9f464de6f6a22619a74062ae781bfd

Nevermind. The keylist can be accessed by activating the line action (clicking on the button)

Fixed / Workarounded with https://commits.kde.org/kleopatra/9bef188fd2a2b820a63e9c7ed130c0990b7f3ce5
I was unable to reproduce this on Linux so no Valgrind / GDB. Fix is not pretty but works and ultimately we want to replace that dialog anyway.

Mostly done

Problem was indeed that QFile::Rename does not work across partitions.

The overhead of the start should be reduced by kleopatra as it uses a static c++ object that is only read once. Yes that might contain stale values but we don't expect users to meddle with config files while they have kleopatra open to edit the config.
Similar for GpgOL. Stuff like compliance is only queried once, (maybe twice?) during startup.

What Kind of File were you attempting to Verify (e.g. S/MIME or openpgp, detached or embedded). Ideally if it was a public file I could try to reproduce.

I need to look at the code. I remember that we used to flag executables as GUI applications so that they do not show the console at all.

While testing more I find this issue very irritating.

The problem is that gpgme-w32spawn.exe uses DETACHED_PROCESS which means that the newly created process does not inherit the console of the parent process.

Thanks for your feedback. But this is intentional. There were two problems with with this:

This is intentional with the rationale being that users either want ascii armor for some reason for all their usecases or they don't want it.
And most users won't even know what ASCII Armor means (Adding "Armor" sounds like additional protection). So we moved this setting into configuration and renamed it.

This dialog actually belongs to Kleopatra. I added the respective tag.

Since this is a bug that is related to two different parts of the gpg4win package, this bug now only cares about the GpgOL Issue, that GpgOL crashes and cant decrypt messages from the sent folder that are encrypted with S/MIME. All File Based Issues are belonging to Kleopatra are documentet in the KDE Phabricator (https://phabricator.kde.org/T7310).

1. Mails encrypted with S/MIME are stored with "No Data" in the sent EMail folder, but arrive properly at the recipients (you will recieve a readable copy, if you add yourself to the list of recipients). This Issue breaks the GpgOL Plugin after some time which is leading to the described Problem.

2. Files that are Signed and Encrypted to a S/MIME Certificate is broken. When you select a file and encrypt and sign it to a recipient, only a detached signature will be created and the Encrpyted file is missing. (Very similar to Issue 1, but file based).

https://phabricator.kde.org/D8368

So far we could recreate the following issues:

There are more Logfiles:

See T3441 for one additional screenshot with error codes.

The log file shows that gpgex (or explorer) crashes.

The output from gpgsm -K in the last quote is perfectly okay. -K works by iterating over all public keys and checking for each public key whether the private key part is also available. If the private key is not available gpg-agent returns an error.

The problem here is that libkleopatrarc did not exist. The error could be nicer but I would say this is a downstream issue that packagers have to make sure libkleopatra-data is installed when kleopatra is installed.
I've opened a debian bug for this some time ago: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869647

I think its done and released with beta-270

There is highlighting now but we don't have the fancy new keyresolver.

Commited with https://commits.kde.org/kleopatra/bfb379a204dc36e86689685b2c56727c87128cdb

One problem I see is that S/MIME doesn't standardize sign+encrypt, but requires nesting of those operations, leaving it up to the implementor to pick the order etc. From an interoperability point of view, this seems like a world of hurt if you take this out of the context of MIME.