I have the same problem too English language and Italian language

A workaround which (currently) works for flagging and categories both is:

Check https://community.kde.org/Get_Involved/translation for information how to contact the translators and/or become active in translation.

Hi, you have "compliance de-vs" in your %APPDATA%\gnupg\gpg.conf. But have installed Gpg4win. The default key pair algorithm of Gpg4win is not VS-NfD compliant, in fact the whole Gpg4win version was not approved for VS-NfD. So just remove that compliance line from your config and everything should be fine. Otherwise the forbidden indicates that you are trying to generate a non-compliant key with a version configured for compliant operation.

gpgconf -X in cdm.exe

1. I use Windows 10 Pro (19045.3996 22H2).
2. I don't use gpg-agent on a remote machine (e.g. over an ssh connection) I'm not capable!
3. I don't understand how to get "gpgconf -X" and "gpgconf -V". Can you explain the procedure better to me?

Please post the output of "gpgconf -X" and "gpgconf -V".

Is this issue resolved?

Closing this outdated ticket

That is an old bug report with a couple of fixes introduced over the years. As of now we sometimes see hangs on Windows on our test VMs. The common cause here seems to be USB card reader issues. Let's close this bug and wait for another bug report with current software versions.

Why the limitation to a single OpenPGP keyserver?

Because otherwise the UI will get confusing if you get the same key
e.g. from multiple keyservers And it is AFAIK a limitation of GnuPG.
We could use a keyserver with a DNS entry again which randomly selects
a keyserver? To avoid always using the same one.

Actually, when having multiple keyservers, the following would work:

My suggestion would be the following:

I renamed the task accoringly.

Oh These are good points

This is not the first time I saw that users are confused by this. My wish would be to change the label of the Group at least to "S/MIME (X509) Directory Services"

Is the lack of display of entries in the listbox proper functionality?

Under "X.509 Directory Services" you can add "key servers" for X.509 certificates (aka CMS certificates, vulgo S/MIME certificates). For OpenPGP only a single OpenPGP server can be entered. The suggestion is the Ubuntu key server because it is/was one of very few reliable key servers.

In T4127#170518, @aheinecke wrote:

With the recent commit the old workaround works reliably again.

For the record. The code used to detect early on if the dark or bright icon theme should be loaded as a resource caused a crash during startup on at least Windows Server 2016 Enterprise. Our new fix avoids such API but I have created T6921: Kleopatra / Qt6: Improve accessibility detection for "Desert" high contrast scheme and fix it upstream to keep track of this since our fix is not fully complete in that it does not properly detect the Bright (Desert) High contrast mode and it should either be merged into KIconThemes or fixed in / with Qt6.

In T5709#180540, @bernhard wrote:

Would it be a workaround idea to double the attachments, so that the original ones would be used as reference for embedded viewing? And the other to be shown?

Yes they can, the workaround, which GpgOL even suggests in the error message is that the mail may not be visible as plain text while changing flags or categories. This usually means that you have to select a different mail and then use right click on the mail you wish to mark for followup or add a category to. The whole problem is that while the plaintext is visible in Outlook we have to prevent changes to the mail from beeing synced to the server or otherwise it will also sync the plaintext.

A user also report this problem with Microsoft365 and Outlook Versions 2302 and 2208. (Exchange is the latest online-Version.
Assuming current Gpg4win v4.2.0)

A user also report this problem with Microsoft365 and Outlook Versions 2302 and 2208. (Exchange is the latest online-Version.)

Would it be a workaround idea to double the attachments, so that the original ones would be used as reference for embedded viewing? And the other to be shown?

I have yet to reproduce this so I had not yet triaged this. The usual case to forward attached mail in Outlook is with .msg files but I recently noticed that Outlook on the web allows you to save mail also as .eml. Also .eml should in theory be much simpler to handle.

I just rechecked we are actually not including the root certificate but we are including the intermediate certificate. Since there never were any complaints about this let us not change this. The original reporter must have somehow deleted the intermediate certificate or it was with an older certificate from us.

I do not think it could cause any harm, if a certificate is re-issued we can adapt and worst case we would ship a very small obsolete intermediate. And it would be just one less of a potential problem when verifying our signature that on this PC at the time the intermediate certificate is not available. Having a self contained chain in the signature is also helpful for scripted verification checks where you would then just need to check that the root CA is trusted and then can check everything offline.
And we take a bit of pride in the fact that we can easily be run on offline systems and there this might actually create a bit of a hassle to get the certificate in there. This would also allow for a more easy verification using osslsigncode itself independent of Microsoft tools.

I don't think that it is a good idea to include the chain. Sometimes certificates are re-issued - they are still valid but signed by another top level cert. The certificate also has the URL from where to fetch the intermediates. Let's close this.

For Kleo I think we have it handled, different subtasks for the Appimage and Gpg4win do not make sense IMO since both rely on the same packaging and I feel confident enough to also update the AppImage. A subtask for Okular will make sense though since Sune already spent some time on it and that way we can keep an eye on it.

At the moment, I don't see any subtasks to add unless we want to have separate tasks for gpg4win and the appimage. It's just a matter of updating all packages to Qt 6 and the KDE packages from the beta release, add new dependencies, check/update all patches. Other possible subtasks could be kleopatra and okular.

Ingo could you add more subtasks here that need to be done? So that we might assign them to Tobias.

This does not need to be checked again for Gpg4win since the installation of this file is generated from the Gpg4win installation script.

I did this. da403fe8e4bbc5701ae1d65dd4b0a7267ab43892

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: