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

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?

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.

Glad you duplicated it. I sure hope you can fix it. Good luck.

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

Hi，aheinecke。my kleopatra version is "kleopatra Version 3.1.4-gpg4win-3.1.5".and when change expiry date, i enter a wrong passphrase or choose "cancle". it shows successfully. what can i do for solve this question. thanks.

Ok, yeah trying to import separately did not work, still refuses the
secret key. The key should be valid because it was created a few days
ago in the pgp desktop 10.3.2 program. BUT if I import the entire
keyring (.skr) file ALL my secret keys are imported with no problem
which cannot be done for keys I make for others.

All the other info you told me is like greek to me, I do not understand
a bit of it.

So is there a way you can make gpg accept it? Since apparently the pgp
desktop is probably being used by a lot of people and it is only a
matter of time until someone tries to import it into Thunderbird and
faces the same problem. I used to us Microsoft Outlook and their
openpgp plugin "Encryptomatic" accepts the key with no problem. So is
there a way you can come out with a new version that will accept these keys?

The test.asc is the concatenation of two armored PGP keyblocks. The first is a secret key block and the second a public key block. The secret key block includes all information from the public key block and thus only the secret key block is required. BUT: The secret key block is not standard conform because it does not include any binding signature (neither for the user-id nor for the subkey).

And attached is a test key.

Ok here is the output:

C:\Users\croll>gpg --import "Desktop\Charles Rollins.asc"
gpg: key C7EE3D25FF2E5EF5: no valid user IDs
gpg: this may be caused by a missing self-signature
gpg: key C7EE3D25FF2E5EF5: failed to re-lookup public key
gpg: key C7EE3D25FF2E5EF5: public key "Charles Rollins
<crollinsphoto@gmail.com>" imported
gpg: Total number processed: 2
gpg: w/o user IDs: 1
gpg: imported: 1
gpg: secret keys read: 1
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 4 signed: 9 trust: 0-, 0q, 0n, 0m, 0f, 4u
gpg: depth: 1 valid: 9 signed: 0 trust: 1-, 0q, 0n, 0m, 8f, 0u
gpg: next trustdb check due at 2019-11-05

C:\Users\croll>

What is meant by missing self signature? I signed it before exporting it.

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.

Something to add: This also affects deleted drafts. If I write a new email and decide to delete & not send it, Outlook saves the aborted draft in the trash without encryption.

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.

If there is a way to disable sychronisation of the draft folder in Outlook 2019 when using IMAP, it could mentioned in the meantime, but I couldnt find it.

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.

Hello in the meantime thank you for the help I sent the command and I come out the same as the example you sent me change only rsa4096 that I set voluntarily when creating the key. I realized now read well that I mistakenly indicated the wrong e-mail address is it possible to correct it? if I can send you a screenshot. let me know

Does gpa show that your key has a public and secret part?
Open a command shell (cmd.exe) and enter: gpg -v -K
This list all you secret keys - Do you see it something like

I have everything on the same machine until last week everything worked now does not allow me to decrypt only that my pc had a forced shutdown of windows I would not have been the one I tried to uninstall and reinstall pgp4win yesterday but the problem remains

You don't have the secret key part matching the public key part which was used to encrypt the message. You must decrypt on the same machine and account on which you created the key. Or you need to copy the secret key from the first machine to your current machine. GPA as export and import options for this. Please read the Gpg4win compendium to learn about the details

i can t decrypt message!!!

The other option would also work for me. Thank you!

I agree! THANKS

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.

The dialog is improved and simplified now.

As a workaround you could also forward the mail to yourself and remove the attachments in the forwarded mail. This would basically work the same as I've described in the previous message.

The next version will have a "decrypt permanently" option. Afterwards you could remove the attachments. Will this help in your use case? You could for example copy the mail into a local folder and remove the attachments then.

Hi, thanks for the report.

(Changing this to invalid as it is more a question and not a bug report per se) You can still comment.

Thanks for the report. Indeed a bug. Will be fixed in the next release.

Will be released with 1.12.1

Thank you!

I could reproduce the problem (by chance) now, because I started a VM I didn't use for a while:

yikes. Sorry for that one,..

Fixed. Needs to go into the next gpg4win release.

No. Pinentry is always 32 bits for us.

Could it be possible that it's a 32/64 bit issue?

Is this with the /MINIMAL flag?

Strange, even if they are missing in the Gpg4win insttall dir they should be picked up from GnuPG which is added to PATH.

I think we might accept this with low priority. As this is an unusual way to create a key.

I can't tell whether this bug report is about all the ways that we wish that GnuPG's default password process was better, or whether it's about one specific change.

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.

I don't think that we are going to change this. All data is utf-8 including the *conf files.

See also T4013 which is about ed25519 key support