Thanks. Actually the same as arm7-unknown-linux-gnueabihf. I have added it to the alias table to be released with 1.36.

Please show an example regarding something else than a failed access to a pool of keyservers. I explained why it can't work for pools for you.

This file is readable. You must have changed the former one's visibility so that only you can view it.

No we can't we need to know the IP addresses to handle the pools. I have given a workaround for you in my previous comment. You can also use install Tor which we can use for DNS resolving.

We can't replicate that and got no more response for 9 months.

That was an intermediate commit on master - it is likely that there are memory leaks.
Moving the test around is not a solution. BTW {F630817} is not accessible.

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.

Thanks.

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: