Hi Werner,
after I enabled more detailed logging, I found that the issue is whithin an "old" file what was encyrpted using an outdated key. Somehow the gpg-agent got stuck here while trying to decrypt the file. After removal of the file the issue is gone, thank you for your input!

Are you using the keyboxd - that is, is this a new installation with gpg 2.4.3 or an old installation w/o keyboxd enabled?

I am heavily tending towards tagging this ticket as invalid as it sounds super individual, but I would like to understand the reason. Not sure how to triage this. Maybe lets give it a low.

No, I didn't make any special localization settings or environment variables on my computer. The only multi-lingual use case I have is that I used for some time the spanish version of Microsoft Office.

I think it's something special in Kleopatra in combination with your system. Kleopatra is deployed on loads of computers in Germany and you are the first one to report this problem. I understand that you do software development. Did you maybe set some localization settings or environment variables to test/debug things you develop? Can you try some other KDE application, e.g. Kate? You can get it from the Microsoft Store or alternatively at https://binary-factory.kde.org/job/Kate_Release_win64/.

The system language is German, the entire system is a German PC, German keyboard layout etc. Other languages used are English and Spanish.
The system is heavily used with different applications including SW development tools, etc.
Never noticed issues like this, so I am pretty sure it's something special in Kleopatra...

To me this looks more like a ki18n/Qt issue than a font issue. In particular, the key size drop down doesn't use a monospace font. The code uses the default locale to localize the number representation. What's the system language of your Windows?

Thank you for the fast response!

The numbers in this dialog come from system font setting for monospace fonts and that might be broken for you. But you should then have problems in other applications, too. There is nothing special here and it works for all our other users.

I am closing this as resolved for now. I would need a completely new client or mess with the registry keys in which outlook stores the performance data to test this. But I would bet it still lists us as responsible for the slow start of outlook. But the time it will then show should now be 0ms since we absolutely do nothing anymore in our DLLMain.

I don't really know how to test this though since it tracks this over time and history. Let us see if my change fixes this, It may be that outlook does not measure the DLLMain (which I am pretty sure it does) but the actual COM initialization, in which case my change did nothing. But I don't see any way in which my change could make things worse.

I think outlook shows any native addin there. As you can see by the empty bar we don't really do anything in there to slow it down. But let me check if I can move the extremely little code we have in there somewhere else.

On Linux, gpgme already passes the locale (set with gpgme_set_locale) to gpg which should pass it with every session to gpg-agent. No idea if this also happens on Windows because there are some ifdef's. The gpgme documentation mentions that the locale should be set immediately after gpgme has been initialized and that gpgme doesn't do it itself because it wouldn't be thread safe.

In GpgOL at least I have an API call to query the display language of outlook. I just need to pass it through to gpgme early and forgot about it. Also I don't think this would actually help completely if gpg-agent is running already.

Werner said it is ok

Some technical details:

• KDE's ki18n uses the LANGUAGE variable to set/get the language to use. On Unix, we simply use QLocale::system(), but on Windows and macOS we look directly at the LANGUAGE variable because Qt ignores this variable on those systems. See https://invent.kde.org/frameworks/ki18n/-/blob/kf5/src/i18n/main.cpp#L63
• KDE's kxmlgui reads the application-specific override language from the file QStandardPaths::GenericConfigLocation + "/klanguageoverridesrc" and sets the LANGUAGE variable accordingly (which is then picked up by ki18n). Example from my system:

[Language]
kmymoney=@ByteArray(de)

Regarding the format, =de would probably also work.
See https://invent.kde.org/frameworks/kxmlgui/-/blob/kf5/src/kswitchlanguagedialog_p.cpp#L64

Raising prio in reaction to some customer feedback

fixed in beta302

Fixed in the according repo. The sentence structure made it easy to just replace the word README with pkg-licenses.txt

Ah, forgot about the license text in the installer, I hope that I can do an easy search and replace.

I can at least confirm that in VS-Desktop-3.1.90.300-Beta a file pkg-licenses.txt is included, as mentioned in the about dialog.

So this is done now to my liking. I took the pkg-copyright from GNUPG as a baseline at the top and then went through all other packages. It is mostly about licenses though and not about copyright holders, even the license information for some packages was weird to figure out. Let alone the individual copyright holders. So I don't think we can or should say "The list of other copyright holders". I changed that now "For a complete list of licenses see: "

works, VS-Desktop-3.1.90.287-Beta

The count in procmon for kleopatra.exe when starting Kleopatra returned 26434 in VSD 3.1.26 and only 14026 for Beta-277 in my test.

We don't need that anymore in my opinion if customers do not complain that taskkill is too evil for them.

So the actual killing is now done with c5617e9f2426549cba54cb52f9faf9325f8e2929 we are using custom actions instead of CloseApplication to have more fine grained control when the steps are run. CloseApplication would only run in the main install sequence so basically only the Deferred part, but during an interactive upgrade like what one of our Entry users would do it would not avoid the first failure to kill a running gpg-agent this already would break the RestartManager support.

FWIW, the Fileversion is actually the Git revision in decimal

b) Is explained by the following documentation from: https://wixtoolset.org/docs/v3/howtos/updates/major_upgrade/

a) So with my current test upgrading from one beta to another it actually looks in the manifest and if you look there the beta230 of gnupg:

So with verbose logging /l*v inst.log (note the v) I finally saw the issue. My killing code works just fine.

The whole part with colorschemes and high contrast mode and dark mode I have already tested.

For testing I would take procmon, filter for Kleopatra start Kleopatra from an older version. Save the log, take the current beta277 kleopatra and do the same and compare the number of lines in the log.

Ok closeapplication will not work because:

Note to self.

So some research led me to believe that using taskkill from MSI is not uncommon. But most stackoverflow solutions did not work for me. I have one solution that works, though but that opens a terminal window for each process we try to kill. I don't want to use wscript to avoid that, since an installer that executes visual basic is IMO even more evil then an installer that executes taskkill. Both are not really the MSI way, but while we could fix our processes without a WindowMessage loop to die nicely this will not work for an upgrade to vsd32.

So as a replacement for what we have in Kleopatra this would work.