I have this regularly. Sometimes waiting helps and it loads after several minutes, sometimes shutting down Kleopatra is the only remedy (because after an hour and more it feels like it ended up in an infinite loop).

Please note that my test was not on an USB Device. I will keep this issue with your analysis and reopen a different one with my error and details on how to reproduce that one. Pretty sure it was disk full.

I don't think this is a regression or something we can do anything about. Note that we see the same thing also on the command line. Actually I have seen the very same thing pretty often with USB devices. Thus lowering priority.

Gpg4win doesn't include libexpat anymore (since it doesn't include gpa and pinentry-gtk anymore).

With the recent commit the old workaround works reliably again.

works, no KIO error. Gpg4win-4.1.1-beta317

Starting to understand KIO architecture a bit better. We can easily add more protocols if we want to. For now I have just added the file plugin. I tested with moving.

The code for the file Job etc. is definetly in there. I think it somehow tries to intospect supported protocols maybe even through dbus and this fails then. My current expectation is that we need to identify where this happens and then to hardcode some supported jobs / workers etc.

Yes most definetly I am looking it at next

Setting priority to high because this should be fixed before the next release.

As far as I understand the problem, all content-ids are lost during processing of an email.
This process happens during the signing/encryption of an email.

Fixed by rGfcbb849c26e9: speedo: Fix regression due to switching from gcc 8.3 to 10.2 for zlib build.

Problem 2 comes from the fact, that gpg4win packages gpg 2.4.0, but the new archive code needs gpg 2.4.1.

Hello All,

I checked it: There was an empty bin/gpgconf.ctl, and there still is.
Trying it again today, I still get error messages most notably about failed self-tests, but surprisingly the window is no longer empty.
Instead it seems to take an eternity (minutes, actually still not finished after three minutes) until the certificate cache is loaded.
Maybe the problem is the "Check Point Endpoint Security" being active on the client. It looks as if it prevents use of Kleopatra.
As I don't have administrator rights ("for security reasons"), I cannot analyze what's actually going on.

Seeing that there are "groups" in Kleopatra, I read the docs, and they suggested that the groups are for addressing multiple recipients.

Settings -> Configure Groups.

It seems that you are missing the step "Create a new file called gpgconf.ctl in the folder Gpg4win_Portable/bin."

I am closing this as a duplicate of T6117 even though it is not really a duplicate. But for me it does not make sense to keep this as a different issue because simplifying the dialog is directly related to making it more accessible.

The timestamp problem may be fixed by moving the line

File ${prefix}/share/icons/breeze/icon-theme.cache

(and any other lines installing an icon-theme.cache) at the end of inst-breeze-icons.nsi (or the corresponding inst-*.nsi file).

I just learned that

Qt will make use of GTK's icon-theme.cache if present to speed up the lookup.

https://doc.qt.io/qt-5/qicon.html#fromTheme

So on Linux, this looks quite differently.

I am pretty sure that this was related to issues we found when analyzing another crash / hang with Kleopatra. In T5478 we are currently reworking how we handle archives completely. This will fix this issue, too.

Some timings, timed with procmon and not by decorating the calls in the code. Just looking at was process does.

Putting up for grabs and removing Kleopatra tag since for Kleopatra users this has been fixed (unless they manage to trigger multiple separate concurrent imports in Kleopatra).

I do not think that this is an issue after analyzing procmon timings. It is only an installation time issue. For that there is no real reason to spend much effort on this.

Note to self after spending some time searching again for the documentation I saw previously about this: https://learn.microsoft.com/en-us/windows/win32/shell/context-menu-handlers#suppressing-verbs-and-controlling-visibility

The followup of this issue for libassuan is: https://dev.gnupg.org/T6324

As you might have seen from the commits mkportable has been removed from Gpg4win.

@ikloecker You are right, I only thought of public key import. Then lets serialize this. Might even make for a nicer Progressbar if we count the outstanding files.

In T4505#166463, @aheinecke wrote:

I have an Idea. Can't we read all data into memory in Kleopatra (for Certificates this should be ok) and then give this to GPGME as a single data object. So that only one process imports multiple files?

In T4505#166390, @ikloecker wrote:

I really don't want to bypass gpgme and then parse the import results and all other status output of gpgsm ourselves. I'll go for Andre's suggestion and serialize imports of multiple files.

For testing I have created a Gpg4win installer and only selected minimal installation and gpgme-json was there. Both in /bin and /bin_64.

I really don't want to bypass gpgme and then parse the import results and all other status output of gpgsm ourselves. I'll go for Andre's suggestion and serialize imports of multiple files.

I meant bypass the gpgme engine and call gpgsm directly. Maybe using gpgme's spawn engine. But I am not sure whether this is really a good idea. If we can find a way to pass multiple filenames to gpgsm --server that would be better. But requires updates to gpgsm.

Only just noticed that this was added incompletely, it was added to the build system but not linked in.

@werner Do I understand correctly that by "It might be easier to bypass the gpgsm and run gpgsm directly" you mean using gpgsm in server mode? Or what do you mean with "bypass gpgsm and run gpgsm" (which seems contradictory).

With 100 concurrently running gpgsm processes they all try to get the lock for the keyring. And they need to do this several times and often also for the same certificate (fetched from an external resource to complete the chain). Not good. It might be easier to bypass the gpgsm and run gpgsm directly instead of adding a feature to gpgsm to directly import from many files.

Sure, we could do this. Shouldn't make the ImportCertificatesCommand much more complex than it already is.

Reopening this as there still seem to be ways to run into a deadlock as was reported in RT#13361. While I still think this points to some issue in gpgsm, when Testing this I found the behavior of Kleopatra to be wrong.

Has been remedied. We should have noticed before the release but the heavy warnings you get only appear if the binary is downloaded from the internet.

This was an accident. Will be fixed ASAP.

Hello ...

It is not really helpful if you publish that fact anyway on a public tracker.

We sometimes grant our customers the privilege of receiving updates a few days earlier than the community. It is not really helpful if you publish that fact anyway on a public tracker. BTW, there is no community version gpg4win 3.1.26.

works

Fixed by reverting to 2.5.5

The same problem will very likely occur with any file dialog opened by Kleopatra because file dialogs are always modal. It may not be nice that people can maneuver themselves in such a situation, but how likely is it that a normal user (and not just a good test engineer who is looking for such problems) will run into this problem.

Support for multiple smart cards has been vastly improved in the last few years. I will tentatively close this as resolved because it's very likely that the problems have been resolved.

Wild guess: Since creating a local certification seems to work, but creating an exportable certification fails, maybe the problem occurs when trying to promote an existing local certification to an exportable certification.

Closing. Not a bug in pinentry. The user ID of the key is encoded incorrectly and pinentry just displays the incorrectly encoded user ID.

It's irrelevant whether you can trick the combination of gpg and PowerShell to show the wrong encoded user ID correctly. The user ID is still encoded wrongly and every standard-compliant implementation of OpenPGP will show garbage when displaying the user ID.