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?