I wasnt aware of this either, but it would be good since we currently don't have a file extension listed explicitly for pgp keys, even though we register one and have the strings already to handle downloading keys where the server transfers application/pgp-keys as information. While https://support.microsoft.com/en-us/windows/common-file-name-extensions-in-windows-da4a4430-8e76-89c5-59f7-1cdbbc75cb01 recognizes it as Microsoft Publisher file wikipedia says PGP Public key but without a citation. If AllowSilentDefaultTakeover is not set, the following code will not automatically change .pub to kleopatra. Instead in microsoft publisher is installed, it will ask you for the first time when a .pub file is opened after installing Kleopatra if you want to keep opening the files with Microsoft Publisher or if they should be opened from now on with IKleopatra,.

Also fixed for 2.4. Don't use the uninstaller on the command line, you should use the Windows method to do this.

Fixed with rG4c830b240c for gpd5 but after the release. Will fix it for 2.4 too.

Really. I do this for PGP files but I have not seen that elsewhere.

Not sure about gpg4win 4.2.0 but we had a bug in 4.3.0 which has been resolved with T6985

Closing since the cause for this was identified.

tested with Gpg4win 4.4

Gpg4win 4.4.0 has just been released. Creation of encrypted archives has been completely reworked with Gpg4win 4.3.0 already. I could create an encrypted archive containing the two files with GpgEX without problems.

Christoph refers to this post here:
https://forum.gnupg.org/t/readme-4-3-1-en-txt-currently-missing-from-files-gpg4win-org/5845/4

Gpg4win 4.4.0 has just been released. I cannot reproduce unexpected results when doing a lookup on server. Unfortunately, many keyservers do not publish the user IDs (i.e. name and/or email address) anymore. Kleopatra does not list results without user IDs because GnuPG won't import them anyway.

This has been fixed in the meantime. If you should still experience this problem with Gpg4win 4.4.0 then reopen this ticket.

Gpg4win 4.4.0 has just been released. I assume that this has been fixed in the meantime. In particular, "General error" should happen a lot less. If the problem still occurs with Gpg4win 4.4.0 then reopen the ticket.

This ticket is obsolete

This doesn't look like a problem in Kleopatra.

Kleopatra now let's gpg deal with I/O directly. This makes decryption with Kleopatra as fast (or slow) as with gpg on the command line. Hence I'll remove the Kleopatra tag.

Then please upload whatever README you want there. My release checklist does not mention any README.

tested with Gpg4win-Beta-75++

If 7z is used to create a tarball that tarball is then 7z compressed. At least this is how I understand the case.
When gpgtar now tries to extract the file it sees a 7z file and thus emits the octal number warnings because it assumes a tarball (after decryption by gpg).

This problem was also reported at https://bugs.kde.org/show_bug.cgi?id=479567#c1

This ticket is obsolete, we did some work on gpgtar since then. Should the issue still occur, please reopen or create a new ticket

Yes, the fix is included in the Gpg4win 4.3.1.

Was the fix part of a stable release? The beta was 4.2.1b55. Stable download on https://gpg4win.de/ is 4.3.1. Am I correctly assuming, that 4.3.1 includes the fix and this issue here can be closed?

This is a super old bug report, this is likely fixed with a new version of Kleopatra, so I am closing this. If this happen again in the future, feel free to reopen this bug report.

This is no longer possible. The sign/encrypt button is disabled and an info box is displayed.

No reply for a very long time, so I am closing this ticket. This is likely fixed now. Feel free to reopen if this happen again.

No reply for a very long time, let's close this.

gpg4win 4 has been released with unicode support. Closing.

closing this ticket as duplicate as adding and changing expiry works.
Revocation of a single subkey is not yet possible in Kleopara, though

This still seems to be a problem. I was using Outlook 365 version 2408 and the current GpgOL and moving a signed email didn't work correctly. But there seems to be a difference when I move it by using the context menu or by using drag 'n' drop.

Fixed together with T6864

My suspiction with this is that here the exchange server / outlook parses the mail attachment into MAPI and somehow handles mails differently then other attachments. This automatic conversion regarding attached mails is why we always ask users in Support to send us a problematic mail as a file in a zip archive. Otherwise Exchange will convert an attached Outlook MAPI mail to MIME and on the receiving side we can no longer see the original strucutre. Similar things are probably happening on the receiving side where the MIME eml "file" is converted into a MAPIOBJECT holding the forwarded mail which then confuses our internal knowledge about the attachments causing this error.

Still no news? :c @aheinecke

I am observing strange beavior on WIndows 10 22h2 and OL 16.0.17830.200056 even if no mail is displayed in the reading pane and the selection returns no selected mails, Outlook loads mails which are e.g. right clicked. I think a way which could prevent some problems and allow it again to change flags and categories for unselected mails would be for us to check in the Read event if the mail has some inspector and abort in that case. This could also increase compatibility with other addins. I will do some experiments with it.

Yes, the function to load the user-configured language on application start is very well hidden in kxmlgui. :-)

I mean the system configuration of Windows is just strange and messy. I am only noticing this now more because for my latest Test VMs I used VIrtual Box unattended installation, which installs the system according to the Hosts locale and then you can change the language for your user in Windows. And I ended up with this setting here where the preferred languages differ from the Windows UI language. And we are not alone in a confusion, on this system also Paint is in english, and the Microsoft Calculator, but not Powershell or CMD 🙄 But as GetUserPreferredUILanguages should return (and does according to my tests) the display langue chosen in the drop down as Language[0] and the others with lower priority I think the correct behavior here is to be in German.

In T3733#189355, @ikloecker wrote:

Don't change the existing KDE behavior for loading the correct Qt translations which is the same as gettext's behavior. It took quite some time to get it right on Windows for KDE.

In the past I have also seen quite often that the Qt Translations with standard actions like OK and Cancel were translated differently then KDE Strings. So there is also some difference with that on Windows.

KConfig uses the default locale instead of the system locale by default it seems:
https://invent.kde.org/frameworks/kconfig/-/blob/master/src/core/kconfig.cpp?ref_type=heads#L118
This should probably also use a copy of ki18n's getSystemLocale() instead. Or we set Qt's default locale to this value to get KConfig to use it.

Don't change the existing KDE behavior for loading the correct Qt translations which is the same as gettext's behavior. It took quite some time to get it right on Windows for KDE. The important bits for making the language configured by the user work are in
https://invent.kde.org/frameworks/kxmlgui/-/blob/master/src/kswitchlanguagedialog_p.cpp?ref_type=heads#L64
where the user-configured languages are prepended to LANGUAGE and in
https://invent.kde.org/frameworks/ki18n/-/blob/master/src/i18n/main.cpp?ref_type=heads#L65
where we make sure that we load the correct Qt translations also on non-Linux systems (where Qt doesn't respect LANGUAGE).

With debug output I have confirmed that KConfig uses the defaultLocale at this point to read the VS-NfD name. So one issue here is that KConfig needs to use the Language configured for translations when reading out the config from which we take the VS-NfD name.

Followup: Using edge and a restart did not trigger the installation of of CN=ISRG Root X1,O=Internet Security Research Group,C=US.

I notices this again, even though my display language is german and Kleopatra is german the GnuPG system is using english (gpg-error --locale says en_IE). en_IE was set by virtualbox during windows installation. No environment variables are set related to language.

I've checked the windows configuration and the automatic update of root certificates is not switched off.
Looking into the windows events view I did not see the certificate update, but after a while I did (restarts, edge attempts installation of firefox). So probably the edge view may have triggered this update, but it did not show directly in the cert store and thus not for Gnupg.

next I'll turn up dirmngr's logging

Since only https fails for you.

Hi Bernhard,

That fixed it.

Uhm this is a task I have with High priority. I do not know what to do here or what it is really about. -> Invalid.

No next work item here. So resolved.

As there does not seem to be a problem here anymore -> Resolved.

I don't think this ticket is up to date. Especially since we now have more components. Auto update or Microsoft Store integration would be much more important then a single click installer.

are there any news about the problem with the control file?

works, tested with Gpg4win-4.3.2-beta23

Was anything done here apart from en-/decoding filenames to/from UTF-8 on Windows?

What is the current status of this issue?

This was done by Tobias.

Sorry, I did not know (or had forgotten, I did search the tracker first).
What is the rationale for not signing the uninstallers?

This is long known and we won't fix this for gpg4win.

With Gpg4win-4.3.1 I consider this solved: