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.

Similar issue with ntbtls:

I meant the abbreviations. PGP is based on a code base dating back to 1992; for example we mostly used the term keyblock instead of certificate in the code.

I reviewed the multibyte handling in GnuPG and you are right, there is a general problem because we use ReadConsoleA and basically GetCommandLineA, so there is no way for multibyte input unless a parameter file is used. Output is also broken, but that is easier to fix iff the input case has been fixed.

FWIW:
The first config.log is from a gnutls build.
The second for libassuan 2.5.3 and has been configured:

./configure --enable-shared --prefix=/var/tmp --libdir=/var/tmp/lib64

Libassuan 2.5.3 has a similar problem:

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

Changes backported to 2.2

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

Those terms are not arbitrary, they are in the RFC.

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.

Applied to 2.2 and master. Thanks.

Thanks. [I wonder why the looong established terms public-keyblock and key-signature must be replace by arbitrary new terms.]

• TPK: transferable public key (an "OpenPGP certificate")
• TPS: Third-party signature (any certification within a TPK that is not made by the primary key, and is not a cross-sig made by a subkey over the primary)

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

TPK ?
TPS ?