I'm putting this back to triage because I cannot act on this ticket. There's way too much text and the outcome what should be done is unclear. Either rewrite the description so that it tells the reader concisely what should be changed and how it should be changed. Or, maybe better, create a new ticket referring to the discussion in this ticket and close this ticket.

I don't understand what your comments about the (missing) success window mean. The screenshot that you added to this task is the success window reporting "The key was copied to the card.". It even has the title "Success". As far as I can tell this window is exactly what you describe with

Would it be possible to move the success window to the start? Ideally combine it with the window asking what should be done with the key on disk. Then "copied" would be correct, as the original still exists and we do not need additional code paths for the other combinations.

In T6708#181592, @werner wrote:

I would also suggest that we show the git last git commit in Kleo's About dialog. That makes it far easier to see what we are testing. The Kleo version numbers are a bit arbitrary.

The problem mentioned in T6095#173465 no longer occurs with the changes made for T6662: Kleopatra: improve useability of group configuration , neither if the Help button is shown nor if the Help button isn't shown.

Regarding T6662#174484, this was already implemented this way. Of course, it still works this way.

To be clear: This ticket is only about GnuPG (more precisely dirmngr) and the changes are included in VSD and Gpg4win.

In D545#6031, @bnavigator wrote:

The patch already updates to the current version + the GnuPG specific changes. Make a diff to http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_python_devel.m4;hb=df506ec920751087985f322e9b60d263c828661c and see for yourself.
What did you do additionally?

I have updated m4/ax_python_devel.m4 to the current version and changed the call in configure.ac to set optional to true (which this patch didn't do causing the build to fail).

Looks good except for one thing. There's also a deprecation warning, but let's fix this with the next commit.

Looks simple enough. Shit it!

Ship it!

All icons that are available in normal/light mode should now also be available in dark mode.

With KMail 5.23.1 the attachment icon is shown as icon. It's also show in the header (I don't see a way to disable this).

This has most likely been fixed already with https://invent.kde.org/pim/messagelib/-/commit/70f39256784280d2034aa7bf1c4765f606c22d56. Please retest with KMail 5.23.1 or later.

And another note: In KF6 icon inverting happens automatically in ksvg or so, so that we don't need to ship breeze-dark anymore. And there will be a BreezeIcons library including the icons that can be used instead of the RCC file. This means we just need a quick fix for VSD and not a general solution for upstream.

One more data point: breeze-icons installs a copy of all breeze icons that do not exist in breeze-dark in the breeze-dark icons folder. So, with icon files on disk breeze-dark has all icons that breeze has even without using breeze as fallback icon theme. Looks like an oversight that the breeze-dark RCC generated by breeze-icons doesn't include missing breeze icons.

KIconTheme sets the fallback theme name to breeze, but those icons cannot be found because we only load the icon theme RCC for breeze-dark. I think we need to load both RCC files in dark mode. No, that doesn't work.

Possible reason: There's a kleopatra.svg in breeze-icons/icons, but there's none in breeze-icons/icons-dark.

The problem has been addressed for all OpenPGP crypto operations on files.

This is currently not possible (blocked by T6927: gpgsm: Accept file names for input and output in server mode).

I was wondering whether "Exec=pinentry" should be "Exec=pinentry-qt" because "pinentry" could be a symlink to another pinentry. On the other hand, we probably want to use the same icon also for pinentry-gtk, etc.

Fixed in gpgme and gnupg 2.2/2.4.

Taking over

In T6833#181135, @werner wrote:

The fix should go into gpgme to spawn dirmngr with a proper home directory (i.e with forward slashes).

I think the double backslash quoting happens because _gpgme_io_spawn quotes the backslashes and calls gpgme-w32spawn and then gpgme-w32spawn quotes the backslashes again and calls gpgconf. I haven't seen anything in gpgme-w32spawn that would unquote the quotes backslashes. But maybe that's supposed to happen in the background. A comment in the code reads "We have to quote some things because under Windows the program parses the commandline and does some unquoting.", but maybe that's no longer true.

Looks good.

This is actually fixed already for the next version (with commit https://dev.gnupg.org/rKLEOPATRA655abf9a75e5f1cce8bc52b1cda21440970edfd7). The fix will just not be backported to VSD 3.2 to minimize the risk of another regression.

All non-archive jobs have been extended to allow reading the input directly from files and to allow writing the output. directly to files.

Looks good except for a nitpick and some documentation.

In a first commit, I have switched back to the simple check done by QFileInfo::isWritable() (see https://doc.qt.io/qt-5/qfileinfo.html#isWritable).

Looks good.

• Document the new flag/functionality in gpgme.texi
• Extend run-genkey.c, so that one can easily test this. (This also gives an example how it's used correctly.)

Done. I have verified with the test runner run-verifyopaquejob that verification still works and that the warning is gone.

In T6880#180682, @TobiasFella wrote:

In the C++/Qt parts:
I think we then don't really *need* anything, since we can just set the fingerprint in the context for the job, but it would make sense to introduce a function that wraps this into a nice API.

For the similar task to add an existing subkey to a key we have GpgAddExistingSubkeyEditInteractor. This uses the much more complicated gpg --edit-key interface. Maybe we want to avoid this.

Just a quick first comment: We usually commit core changes and cpp/qt/etc. changes separately. So please split this commit before merging it to master.

My hypothesis about what happens:

• I enter a folder with some new messages. KMail starts a sync.
• I read some of the new messages. They are marked as read in KMail and (hypothesis) Akonadi records the status changes for later because a sync is running.
• The sync finishes. KMail shows the new messages again as unread which (hypothesis) is what the sync reports.
• In the background Akonadi syncs the deferred status changes to the server. (hypothesis)

It seems I'm using Exchange (account at my old university and o2mail.de).

We should sell this as AI or at least as "smart file drop". ;-)

I'm seeing this on an inbox with about 4,000 messages. It may depend on the server (speed) because I'm not seeing this on larger folders on another server. But it does happen for more than one server. I'm not using "Ignore thread". Just the plain old mailing-list style message list. I'll keep an eye on when it happens for which folders.

I would experiment with replacing the flat keylist model with a flat userid keylist model. For places where we only want to see the primary user IDs we could simply put a filter proxy on top. Obviously, that's a big architectural change so I'd expect some breakage. Maybe we start with adding a new model but keep in mind to replace the old model. Or we immediately replace the old model with a primary-user-ids-proxied new model.