I think that this might have the same underlying reason as the fixed T4321 (still open because it was not yet released).

Just for history if I ever need it again here is a patch I wrote debugging QIODeviceDataprovider. I have not commited it for fear of regressions and apparently the code is correct for Linux and that it did not work as expected on Windows had other reasons.

After further debugging it showed that it had to be an issue in how we use QProcess. So I've rewritten the way we call gpgtar on Windows and replaced it with a simple anonymous pipe solution. I've tested more then ten times with various directories that the data corruption no longer occurs.
The performance is slightly better, but we still use GPGME so it's not as good as if we would pipe it directly. But not using GPGME was not really an option because otherwise I would have had to implement a full blown "how to call gpg" with error handling etc. for Kleopatra and I really did not want that.

The issue for the quality indication is: T2103

In T4346#122371, @gouttegd wrote:

Regarding the quality evaluation, several months ago I proposed to optionally delegate that task to an external tool (specified by a new gpg-agent option passphrase-checker). I posted a first draft as D442 and then submitted a proper patchset to gnupg-devel, but although @werner expressed interest it was never merged. I have just checked that the patchset still applies cleanly to both the master branch and the STABLE-BRANCH-2-2. I can re-submit it to the mailing list if needed.

FWIW I like @gouttegd 's patchset.

In T4346#122098, @werner wrote:

The quality bar is switched off by default. That feature including the quality was ordered and accepted by a client. I don't like it either and thus the new default of having it disabled is a useful solution.

thanks for the report. Yes this is a known issue. This pinentry is so basic that it does not have dynamic layout as we don't include GUI libraries in the basic installer. For a better pinentry you can install Gpg4win.
In the future we are thinking about adding a pinentry based on the small "FLTK" toolkit, with dynamic layout.

Yes, I think that if I see an import result with "secret-keys-read && w/o userId's" I can just do a second try.

By the way. As I see the domain in the screenshot ;-) let me just say that there is commercial support for GnuPG (https://gnupg.com) available and through which we could much better and quicker help you to find a solution that works for you if this is a problem in your organisation.

It's better to have a new Task for this as I explain in T4402

I think I know what the problem is. T4038 only works for "legacy algorithms" this means old ciphers where MDC was not the default are handled by this error. New algorithms like AES which should have MDC in all implementations were not affected by this because this is much rarer and points to a broken implementation / a real attack.

%APPDATA%\gnupg is a windows variable which expands to something like:

This can happen e.g. if there is a permission problem in the GNUPG home directory (%APPDATA%\gnupg) e.g. if the file S.Uiserver in there was created once with admin permissions it can not be removed or reused by a kleopatra running as a normal user.

Oh my,.. I tested it myself with the very latest PGP Desktop version and this is really what you get as output.

I'm not sure yet where the bug lives. It's either in GPGME's editkeyinteractor that ignores the error / cancel or in Kleopatra itself. I'll have to look into it. Btw. I do not think that this should have high priority because it is not a new regression and while it is a Bug and wrong it is not really harmful.

Hello,
I've opened T4395 for this to keep better track of it as this task was about another issue.

From a comment in T3990

Further testing leads me to believe that this is probably a Kleopatra / QGpgME / Qt issue. I can pretty reliably reproduce this when using Kleopatra but never have I gotten this with gpgtar only, and I tested it a lot of times.

The difference is between: 0x01035400 and 0x01034600 where 7 blocks of zero bytes are in the broken archive which are not present in the original file.

Kleopatra now shows an error in this case when extracting. So now we only need to fix that this happens at all.

We are currently not aware of any bugs that would prevent the import of valid secret keys.

Thank you very much for the analysis. I'll forward the info.

Ouch indeed. Looks like you run into a "hanging" gpg-agent situation in that case our main background process is blocked and all other processes wait for it to respond and nothing works anymore.
This should never happen and we need to fix it. But so far we have not found a way to reproduce it.

There was indeed a missing dependency. libgpg-error and libassuan were only installed if GPGME was installed, so only if Kleopatra or GPA were selected.

Somehow I thought that storing drafts locally was not only configurable but the default. But you are right, I also can't find a way to change the storage location.

Hi,
sorry for the late reply. I cannot reproduce the issue.

Also reported for Contacts in T4161.

I think that this is the same as T4388 So I'm merging it in.

Regarding 1. That is currently not possible. It is something we should have but which we did not yet implement. I'll move this out into a feature request.

Btw. I'll try to get a new release out this week. In the meantime either downgrade to 3.1.5 or use Kleopatra.

Jep that was part of Gpg4win as Gpg4win needed features / fixes from that version.

Thanks for the report.

Btw. I only noticed this now as I always had "disable-tor" in my config but recently removed it for testing.

I think this can be resolved according to the last comments. We have analyzed it and found that it is not an issue on our side.

I could reproduce the issue and fixed it similar to the code suggested.

The dialog is improved and simplified now.