*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.

Ok this looks nice already. My plan is the following:

Andre merged this already.

Merged.

Merged.

Merged.

3DES is indeed an allowed cipher, so that is not a concern. Changing the cipher to something that is not allowed does not work.

In T3236#99866, @aheinecke wrote:

In T3236#99865, @justus wrote:

The whole "GnuPG System" section?

No, only the options that are marked as "advanced" by gpgconf.

Actually, Andre has some uncommitted changes that do implement the wanted behavior. AIUI those mainly needs a little fix to so that it wont break with old GPGME versions. Once merged, I will amend it further if necessary.

"aheinecke (Andre Heinecke)" <noreply@dev.gnupg.org> writes:

In T3236#99865, @justus wrote:

The whole "GnuPG System" section?

"aheinecke (Andre Heinecke)" <noreply@dev.gnupg.org> writes:

I'm not sure if this is really a thing, maybe it would be enough to just disable showing the advanced options in Kleopatra again. I only recently enabled them.

Yes, it is probably correct: the concept mockup was done a lot earlier. Whatever we have in master is most likely the current status.

The mockup in the design document shows a completely redesigned key selection dialog. I did not see anything like that currently in Kleopatra. Is that right or did I miss the new dialog somehow?

The TOFU trust model gives some more information about certificate usage. Beyond that I don't think this is well defined to be actionable in the backend.

Some details of these tasks are outline in the internal concept, including mockups.

Hi,
on which platform? (You can probably compare it to a working version and see which libraries is uses there.)

This actually uses the same infrastructure.