@werner I saw the call in _gpgme_set_engine_info at line 452 https://dev.gnupg.org/source/gpgme/browse/master/src/engine.c$452 which I think leads down to _gpgme_get_program_version in version.c which does a spawn and uses no cache.

In T6369#167642, @werner wrote:

The context cloning should not be that expensive compared to invoking gpg. Thus let us first see how to speed up this in the common case.

Output of --show-configs should also be added as a button or directly visible when the selftest of Kleopatra fails.

For testing the old version, did you use GNU Tar with Kleopatra or changed the configuration to use gpgtar?

As discussed with Werner, the initial default will be changed "guessed" in GPGME to avoid code duplication between libkleo and GPGME.

I am adding gpgcom, as a tag, the first minimal task would be to create such a page with the debug output from gpgconf -X with options to copy / or save them to a file. Not sure if that should be a subtask, because on the other hand this would be a start of this "Debug Tab"

I edited this task a bit: For compression we have T6332
For Archives passed to Gpgtar we have: T6342

Great! But as mentioned I would like to have a setting in Kleo to explicitly disable compression, GPGME_ENCRYPT_NO_COMPRESS. But that is a different task.

So on Linux, this looks quite differently.

I would like to take this on myself by creating a gpgversioninfo class which will have signal / slot based API for both the SWDB Query and the version checks, both currently delay the startup too much.

I am somehwat confused, my symantec system got faster. But there are some things like "Symantec Insight" which will whitelist often used files and applications, also signed files might get preferred treatment. I tried to get this slower by disabling the "Insight" and changing the "Bloodhound behavior" to agressive... So timings might not be comparable. I should probably do tests ohne without restarting my systems for a good comparison.

Commited with revision 1642622.

I am closing this now, as we now should have complete kleopatra translation and can just move one of them to testing.

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.

I am pretty sure that this was the issue we had analyzed with QProcess. Where the fix will be T5478 that will rework how Kleo handles archives altogether.

I am very sure that this is resolved and we support that in Kleopatra.

Commited this state with revision 1642162

This should really be in the next release.

Another thing I have noticed when turning qt debug output on is that the qt windows platformsupport fontdatabase logs over a a timespan of over two seconds that it is adding fonts to its database.

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

Currently the first call to QGpgMENewCryptoConfig::reloadConfiguration happens in the GpgSM self test. Funnily enough the selftest for gpg just returns true when the empty constructors of the cryptoconfig are called. The first component load is GpgSM.

Discussed with werner is for Wontfix as this is not really the AppImage way to do things. As you also seem to tend this way I slightly agree. I still would find it nice to have but If we have a real demand for that we can document or support people to do this.

I am changing the priority here to high as the parent task has high prio. Maybe we should close this as a duplicate of T5478

by moving the KUniqueService before this and with the change b58cf129f the priority is reduced. It will still take 200ms so we might want to do something about this but it is not prio high as the 200ms are only on first run.

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

I am closing this directly as this is an obvious removal of something that was previously disabled by configuration.

Good solution. I tested it.

Right, I think with that you could even go down to 1024 or 512 (or does gnupg block this?). Its better to block this in de-vs mode as it says in our documents somewhere that we prevent generation of non-compliant keys at least in the GUI.

My last idea with this ask was that we should reuse the Handler from GpgOL. Because that one is very simple and the difficulty is not the mime parsing, which KMIME could do but the whole complexity the objecttreeparser does.

kwatchgnupg translation commited as revision 1641797 I leave this open as ticket for the rest ?

Thanks commited this to https://websvn.kde.org/trunk/l10n-support/ja/summit/messages/libkleo/ this should then be automatically arrive in the po/jp subfolder of libkleo. But I keep it as testing to check if this actually was done.

For now that we do not want to push for more WKS support with gpgcom, as this will depend on adoption of WKS. So I am resolving this issue.

Since the issue T6328 described an issue with high pirority which would be fixed by this issue I am raising the prio here.

@ikloecker the proper fix for this would be T5478 so you do not have to spend time looking for this, we will remove the Process Input / Outputs of Kleopatra altogether.

We have discussed this and what we think would be the best solution would be to have an extension in the engine-gpg of GpgME either through a flag or through a new API to use gpgtar directly with --encrypt and decrypt. This should behave exactly like the gpg encrypt / decrypt / verify functions but would avoid the need of Piping in Kleopatra. It is a fairly recent development that gpgtar can do the crypto operations by itself so this is why this was not done initially.

Thanks! I don't understand why your fix helps as Kleopatra never calls assuan_socket_connect on the server side, but it helps. :) So this is probably called indirectly and I don't see it.

Yes this is windows. With the USB Stick I think it makes it more reproducable that bytesToWrite will return something. We also had reports that this happened on Network drives so its probably just "some added delay or something where the Windows Kernel does not do buffering".

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

I see the use to have an option to have a stricter "min-rsa-length", and which will be useful even in the future e.g. for 4096.

So the problem is occuring when the output is finalized (which happens after the GpgME Decrypt Result is signalled). And when there are still bytes to write in line 332 https://dev.gnupg.org/source/kleo/browse/master/src/utils/output.cpp$332

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

From the NEWS assuan_sock_set_sockaddr_un was only added in 2014, years after the UIServer code was really last modified.

Btw. This is how Kleopatra creates the socket: https://dev.gnupg.org/source/kleo/browse/master/src/uiserver/uiserver_win.cpp$34 which does not use a function that would set is_socket=1. My naive fix would be:

My opinion here would be add the "import key from signature" and "put key in signature" in the automatition group of the main GpgOL config page and change the wording of "Import any keys included in Mails" to "Import keys from Headers and Attachments".

o.O have overlooked this since October.

This is most likely caused by an incompatible addon. See: https://wiki.gnupg.org/GpgOL/IncompatibleAddons

If no keyserver is configured GnuPG uses its default keyserver. "disable-dirmngr" would be the option to completely disable keyserver access but that is rarely used.