Thanks for the report. Log looks not unusual.

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.

The secret import code actually had a bug in that it silently imported the secret key anyway, so that after importing the public key the secret key showed up. That was not intended because we do not want to allow importing arbitrary keys or subkeys if the don't have a corresponding public (sub)key with the mandatory key-binding signature. This has now been fixed. A fix for the actual problem will come soon.

Additionally that workaround is a bad idea because on closing Outlook it
leads to the GPG4Win error "Not all plain text could be removed, it's
possible that plain text from decrypted mails was transferred to your
server." (roughly remembered text-wise)

Thanks.

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.

There is a solution for it:

well, Firefox DE on OSX gives same error Unhandled Exception ("HTTPFutureHTTPResponseStatus")

Hi there,

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.

The man page also needs to be updated (or reference) whats-new-in-2.1 ,especially the New format for key listings. The "missing" KeyIDs in the listing is extremely confusing to someone used to the old system. I wasted much time trying to discover what I was missing.

Reading through this issue and the related documentation: Thanks for writing this all down and adding links!

Ok. Let me know so I can try it out.

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.

Checking the OpenPGP specs again, there is actually an "exit" clause for this PGP bug. Or well, what I would consider to be a bug. A fix for this is not easy because it would require to detect this at an outer level (the ascii armor) which we don't do because gpg is build along a streaming concept as almost all Unix tools. What we can do is to allow import of a secret key in that PGP format iff a public key is already there. In practise this would mean to run the import two times and ignore the errors from the first import.

OK. Designated box wasn't a technical term, so obvious in retrospect.

Do you think you can do it with a new gnupg?

Charles

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:

i need to create a new key pair ,because of this error i cant even generate my key...plz help me to find a fix for this....

im using kleopatra as an admin user.....and why is this happening .....i moved the gnupg file to another location and the ui server issue is still not fixed... plz help

from %APPDTA% where should i move the gnupg file........to.... should i move the file from C to D

See T4400.

That is correct according to the specs:

I'm new here, therefore I'm unsure whether this posting is correct at this position.
Within my organisation we have ongoing troubles with the error described here, with windows version 3.1.3 there is no such button "force decryption" as documented here.

Hey. Are there any new regarding this ticket?

What terms in the man page are troublesome for you?

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.

Despite my previous denial, I now think that you are correct: I now think that I did indeed follow a Debian wiki entry on separating the primary key. In my defense it was many years ago :-(. I have now managed to import a primary key, although unfortunately the wrong one.

Just to note that I did import the secret key, but there was no change. I have searched for the term designated box, but I found no hits. Where is this term defined or explained?

Thanks for the prompt reply. I did not explicitly move the primary key offline. Maybe there is something in the default debian configuration that does that?
$GNUPGHOME is pointing to a .gnupg which contains secring.gpg and also a directory private-keys-v1.d/ which contains two keys.

You are keeping your primary secret key offline. You need the primary secret key for most operations because it is required to bind user ids or new subkeys to the primary key. The "pub" indicates that you have only the public part of the primary key. There are several howtos on how to move a key offline and you seem to have followed on of them. The common advise is to have a designated box with the full key (including the primary key) and use that for key maintenance. Of course you can also import the primary secret key.

I should have added, in case it wasn't obvious, that I changed some ids etc in the report just to protect precise details.