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 ?

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.

In T4393#123047, @dkg wrote:

i don't understand why "import-drop-uids" is useful --

i don't understand why "import-drop-uids" is useful -- it sounds to me like the functionality you're looking for is something more accurately named "accept-certs-without-uids". is that right?

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.

1. I'd like to suggest to include a mail alias "paypal@gnupg.org".

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

Thanks for fixing that.

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

That's my badness. In wait_child_thread, assuan_release may cause thread context switch to agent_reset_scd which accesses scd_local_list; This access should be serialized.
And... in start_scd, calling unlock_scd should be after unlocking start_scd_lock.

The creating software is broken in regard to non-ASCII characters in the UID:

Metazoa (Ingo Bläser) quote busy. Promised to send an offer with a brief concept "in March". I will ping him.

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.