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.

See T4400.

That is correct according to the specs:

What terms in the man page are troublesome for you?

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

Changes backported to 2.2

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

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 ?

Thanks for fixing that.

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

ssh does nut support brainpool curves and thus GnuPG does not know how to map its internal name of the curve to the name as specified by ssh. GnuPG supports these curves:

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

Okay, this is the latest released version. I now wonder what you mean by version 1.12.1-beta43. This sounds like our current development version of the GPGME library, right? How did you install this software? Is it from Gpg4win or did you build it from source?

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

Does not happen in 2.2. Additional requirement to test this bug in master: Another connection to the scdaemon must be open. For example running scute or, easier, call "gpg --card-edit" and keep it open.

Will be released with 1.12.1

Please see the section 'Selecting Signers'.

When did you last try to login to dev.gnupg.org? What browser and OS are you using. Did you try with this account?

Please describe in more detail what you did so that we can replicate this. We also need to know your OS and the GnuPG version.