Ok. Sorry, just to avoid debugging in case it is not known, I am pretty sure the ini file is a regression from the unicode nsis switich. The timing when it was reported to no longer work matches around that time and the installer code itself hasnt changed for even longer.

In T7452#195841, @m.eik wrote:

this could also help with T5952, i was testing with ansible as well.

- name: Uninstall gpg4win from the registry
  ansible.windows.win_package:
    product_id: 'Gpg4win'
    arguments: /S
    state: absent

From a quick glance at the docs. This looks completely correct. What did this do and what didn't it do?

Just to explain, if you are executing it from the command line the command line will "lock" the uninstaller until it is finished. In GUI Mode it creates a copy in %TEMP% launches this copy and exits. When run from the command line it requires a session reset to delete the unistaller. So log out / log in and the uninstaller should be removed, but the dir might still exist. I am not sure. To workaround you need to copy the uninstaller to a temporary locationm firs and then execute and delete the copy.

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,.

I misunderstood the problem. On the receiving side this was already fixed by me in 2019 9a9fe4e7fcad92bfba49ade9a6c44373f170ccd2

I edited the task accordingly. Here I meant Notepad. But I would also add this as an idea / improvement for the clipboard if this should get improvements.

In T7362#195689, @alexk wrote:

Yes, automatic scanning of the clipboard is not good. I withdraw the idea.

I am not sure if it helps if I comment, I just saw that this is issue cropped up again, and although we might be seeing different problems since other reports like T6623: Kleopatra hangs "Loading certificate cache" on Windows 10 T4581: Kleopatra stuck in loading the certificate cache are about indefinite hangs. (Was a timeout added in a generic place recently?) I just hope that at one point the underlying cause for this is found and resolved instead of hiding the symptom each time we find a way to reproduce this a bit better. Seeing T7437 and T7438 in which I commented a bit more made me sad that this is still not treated as a GnuPG issue.

To explain why I have not changed this, even though we have observed these hangs for years. I have never been able to reproduce a hang or issue without Kleopatra and only GPGME and only through keylistings. I just looked and still had the scripts I used for testing to mimic the calling pattern of Kleopatra lying around since this code is also run each time the security approval dialog is shown in Outlook.

Closing since the cause for this was identified.

I agree here with Werner. Changing the fronted to workaround locking / timing issues in the backend like in T4505: SM, W32: GPGSM hangs up the GnuPG System T6323: Kleopatra: Import multiple certificate files one after the other might be necessary in the short term to make a release possible. But even if, like in T6323 the code which avoids the issue is better this should rather be the last resort or done after doing a fix in the backend or to avoid the issue with older versions. I just wanted to comment because I clearly remember that in T6323 I was very glad to finally have a way to reproduce a deadlock with a high probability and then very frustrated that the issue was left in the backend and only hidden in Kleo.

Additionally permanently watching the clipboard for changes can cause some password managers to detect an "attack". As it is discoverable which application accesses the clipboard on windows we had the case where a password manager would not work when Kleopatras clipboard watcher was running. T6642

Ah, ok I understood it as "we will change the soname for other reasons e.g. so that both versions are co installable but we will not break ABI". And I would prefer the break for qgpgme at least because of the mentioned problem not because I don't care about ABI stability but because I do and this is a big problem which only exists, because I didn't do it with the last repo move. There is no technical reason anymore for the abstract base classes.

If the major version for QGpgME is bumped, shouldn't we at least remove the virtual base classes. Eg: delete FooJob and rename QGpgMEFooJob to FooJob. I did regret not doing this when i moved them out of libkleo since this architecture no longer makes sense in the standalone libnrary and technically the virtual bases make it nearly impossible to maintain ABI stability when adding functions. The reason for those was only because libkleo had that idea of different backends namely gpgme and chiasmus. But a Library called QGpgME should never provide another backend then GPGME IMO.
So no behavioural change at all, just something to make future ABI compat easier.

Maybe its overthinking the problem of attachments with content-id but no reference in the HTML (btw. if mails are shown as plain text all attachments are listed regardless of their content id. ) I guess code like: if filename.endsWith(.png) || filename.endsWith(.jpg) || filename.endsWith(.jpeg) then ignore_cid=false; else ignore_cid = true. Would do the right thing 99% of the time. Core reference: rOd87848059727587be1f660283e0aeb3be16cc382

When I last talked about this ticket I had not thought of the fact that we need to have this in some kleowrap wrapper and that currently stdout and stderr are not printed in a process which forwards its call to an already running kleopatra.

I thought about this and any change here has a regression risk and the release is already overdue. If we change this now as a band aid before a release with keyboxd we really need this only for one release.

Regardless of the migration. At least we need to set GNUPGHOME early in Kleopatras main to the value returned by GpgME so that the qt.conf patch works in KF6.

I see no commits that change the behaviour or do the migration. Then this is not fixed. To clarify. For me this issue is about General config files of KDE / Qt. Not only about the kleopatragroupsrc Since the kleopatragroupsrc was fixed in the last release already.
In the state I left it for VSD 3.3 (master) qt.conf is only written for Gpg4win. And not for VS-Desktop. So testing with Gpg4win has different results. This was the underlying reason since qt.conf was written with FileWrite and not packaged. I only changed that in Gpg4win master.

The problem is that this is a just a band aid at best. The underlying problem that shows up in other places is not fixed. We should apply the band aid only if we say we don't fix the underlying problem.

Either this has super high priority or we fix S/MIME keylistings in GnuPG. I will write a mail with details as that involves customer information.

String values are stored as UTF-16, but might not even contain a terminating doublezero since it can be any binary data. Note that on Windows the registry can be used to set environment variables. There "Edit binary data" shows exactly what is in the regkey. So if you use regedit with the String functions you can see that they are converted from latin1 to UTF-16.

Btw. GpgOL also parses the mail as having a bad signature. Also gpgparsemail from gnupg. I wonder if the creation side of that mail is broken or the verification code. :)

My recommendation would be to include this change together with the other changes from today even in a minor release since any changes are behind:

I tested all scenarios I could think of with multiple embedded mails and mails which had themself embedded mails. signed, unsigned, s/mime and openpgp.

This is caused by "Mail::removeOurAttachments_o()" to avoid that when you forward an encrypted mail, that the decrypted attachments are also attached as well as the original mail. Same goes for send again.

I was not expecting a controversy about the reversion as I already said in the weekly on monday that I think we should rather revert that then try to fix it for a 3.2.3 release.

In the keylist of Kleopatra or in the recipient selection of GpgOL we needed to display if the operation with these keys can be VS-NfD compliant or not. I have an encryption subkey which is compliant and aonther one that is not compliant, both are valid. Currently GnuPG will use the "last modified" of the two. And since it is not transparent to Kleopatra which subkey is used, kleopatra could not show "Encrypting to this key is compliant". Which was a requirement. Since we only tell GnuPG the fingerprint of the primary subkey as recipient, to me we would need to either directly add the subkey we want to use as recipient (with ! ) or we cannot really show it. Well maybe with a version check if GnuPG is adding this now.

In my opinion it is better to say-> GpgOL does not handle encapsulated mails and don't show anything. Then to now create a new behaviour where something is shown but that something is broken. If we "close" the original "no attachments are shown" issue, do I as a user now have to create a new support issue with "there is a file named rfc822_email.eml shown but it is empty"? So there is another round of communication about this issue while the problem is not solved. This way we can just say that a fix for handling embedded mails in crypto mails did not make it into the 2.5.13 release. Then to create a new state where the feature is broken differently.
Users would then ask themself: If the mail is empty, is it because my mail is somewhat special, etc?

Just thinking about this, we have at least one customer configuration that uses KXMLGui to hide all smartcard actions and the view. And one other that disables certify actions everywhere. We need to check that this still works with the new details view.

Without administrator rights it does not work for me, since it then cannot write to %PROGRAMDATA% to install the VS-NfD mode config files. But the only thing for "does not work anyway" that I know and could quickly see is that "IPC connect call failed" problem with GPGEX (which we are planning to remove / replace anyway). So I don't think it is very important to remove this and addtionally we do not know if this is something that is used, we have offered it from the beginning but have no data if our customers use it. We can suspect that we would have seen more support questions about the gpgex error if it was widely used. But I always thought that the "only for me" installation option was useful for some use cases.

I think the executables also use the same values for translation.

I would say this could be treated as a duplicate or subtask of T7147: Kleopatra: Add debug information / Log handling KWatchGnuPG is in my opinion not very useful, since as a developer debugging things the command line and "watchgnupg" without the K are more then enough, KWatchGnuPG is basically just a qprocess output viewer of watchgnupg. IMO it would be similar if we would just execute CMD or Konsole with "watchgnupg" and show that window. Logging to a socket has the advantage that the entries are displayed in the order they come in while with files there is an issue of io synchronization and not all components can log in the same file. But you could use same QProcess / watchgnupg to "sync" the log entires and then write them to a file.