Fixed this morning with
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=b200e636ab20d2aa93d9f71f3789db5a04af0a56

1.25 or 1.26 does not matter. In 1.25 we improved the nPth support and made the
mutex used by Libgcrypt's RNG actual work as expected.

However, this seems to reveal another problem and thus I upgraded this to a real
bug.

Sorry, this is not a help line. Please ask on the gnupg-users mailing list for help

Note that ff you have the secret key you can set the preferences.

Can't be fixed in 1.4 or 2.0. Has been fixed in 2.1.

Steps to reproduce:

1. raspberry pi: create one master keypair(Certify) and three subkeys (Sign,

Encrypt, Authenticate). (I will still refer to these three subkeys as just subkeys)

2. raspberry pi: backup ~/.gnupg
3. insert hardware token yubikey1 and keytocard subkeys and eject the yubikey1
4. raspberry pi: delete ~/.gnupg and restore ~/.gnupg from backup
5. insert hardware token yubikey2 and keytocard subkeys and eject the yubikey2
6. repeat steps 4, 5 for remaining gnuk, nitrokey or yubikeys.
7. Now keep yubikey1 with you, give yubikey2 to your spouse, yubikey3 to your child.
8. encrypt backup with gnupg using symmetric cipher.
9. export public key.
10. wipe ~/.gnupg
11. Insert new formatted usb drive and copy public key.
12. shared family laptop: import the public key from usb. insert yubikey1 and

fetch the subkeys to let gnupg know that the private keys are on hardware token.

13. shared family laptop: encrypt and decrypt a file successfully with yubkey1.
14. shared family laptop: insert spouses yubikey2 try decrypt the file encrypted

before. gnupg will not just ask but insist to insert card with a yubikey1 serial
number while you have yubikey2 which in this case also has the same subkeys that
can be used to decrypt the file.

Bug: gnupg does not let shared key usage while using hardware tokens on a shared
laptop.

expected: gnupg should be able to decrypt using any of the yubikeys having
required subkeys.

Please consider: not all hardware tokens have serial numbers printed on them,
consider gnuk or nitro key. It is smart to put a stiker or use permanent marker
to mark keyid on the token incase of having multiple tokens. Another plus about
gnuk is that choose/change my serial number at will.

So, Please ask for a card with a keyid than serial number.

Thank you for thinking on this.

Can user be asked "Please insert hardware token containing 0xXXXXXXXX key". I
guess users are smart enough (considering they are using gnupg) and would write
the keyid on their tokens if needed. If they only own one token which is most of
the time they just insert that. If they own multiple they will recognize by
color or a persoanlized sticker on the key or a permanent marker markings on
their card.

Sorry, I used the word ccid just to mean a hardware token.

I believe many want to have backup hardware tokens. Again this allows a family
share a laptop and still own the shared key in their own hardware tokens.

Here is the version information:
gpg (GnuPG) 2.1.11
libgcrypt 1.6.5
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,

CAMELLIA128, CAMELLIA192, CAMELLIA256

Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

I'm using libgpg-error 1.26, though I'm sure it also happened with 1.25 (I get
libgpg-error from Debian unstable, which went to 1.25 on Nov 16th, and then 1.26
on Dec 24th, and I saw the symptoms at both of those times). I'm happy to
experiment with another version if you have suggestions.

See also T2895 (nimbius on Dec 27 2016, 04:49 AM / Roundup)

Duplicate of T1828

Please comment on T1828 (I just granted you permissions)

D405: 934_libdns.patch

would this patch[0] be acceptable for inclusion in branch?

note from patch composer:

"""
Comment by Gaetan Bisson (vesath) - Friday, 23 December 2016, 07:22 GMT
So I came up with a fix that does two things:

• fallback on the old, standard resolver code
• if no SRV record is found, use CNAME (as expected but some weird error code

apparently broke this)
"""

[0] fetched from
https://git.archlinux.org/svntogit/packages.git/tree/trunk/libdns.patch?h=packages/gnupg

From my network, when I input:

KEYSERVER --clear hkps://oteiza.siccegge.de

It results the error, because the network to the host is unreachable.
It is likely that it is an error of the network or the server.
And --standard-resolver thing is fixed by my commit.

I think that this bug is related to libdns. Unfortunately, it is not
reproducible for me.

Well, somehow related, I pushed my change:

commit d26c51825e2255fe58305cbc1cd74fa43f80d93e

In my environment, compiling with --disable-libdns or --standard-resolver at
runtime for dirmngr, it works fine. Before the fix, I confirmed that it failed
with --standard-resolver.

Thanks for the report.

This is fixed in commit 6e96cdd41a0e55b672309431062f37c4a4a9f485, but there is
no release with that version. Sorry for the inconvenience.

FWIW, I doubt that 2.1.17 fixes the issue. But, I've improved the debugging
out, so if you would try to reproduce the problem, it would still be useful.
Thanks!

2.1.17 has been released. I would suggest to try it first so that we do not
need to evaluate an older version.

That seems to be a regression due to commit 02eb9fc9d5863abcfed6af704e618f8cac7cc2e8

    If the user's CFLAGS include -Werror, then some configure tests fail.
    To avoid this, we only add the user's CFLAGS after all of the
    configure tests have run.

That patch was obviously wrong because configure now has a different picture on
the build system than make. A better solution to the -Werrror problem would be
to pass -Werror only to the make invocation - or more robust to add an
--enable-werror configure flag.

GnuPG 2.1 requires the agent and thus the Pinentry. --use-agent is thus a
no-op. The Pinentry can be replaced by the --pinentry-mode=loopback but I don't
think that this is a good idea.

2.1.17 along with pinentry 1.0 does much better error reporting for badly
configured system (e.g. an incomplete installed GCR when using pinnetry-gnome,
or a missing GPG_TTY for the curses fallback.)

Too much time has passed since I worked with Jeffrey to fix gpg problems in Evo.
I can't even remember whether Evo uses GPGME (which I would strongly suggest).
Anyway, Milan may ask for advice on gnupg-devel and I take care that the GnuPG
teams helps him to get things fixed. he might also chime in on gnupg-devel at
conference.jabber.gnupg.org

Indeed, that is a problem. I have created T2879 to track this.

$ gpg2 --keyserver hkps://hkps.sks-keyservers.net --search-keys 2071B08A33BD3F06
gpg: no keyserver known (use option --keyserver)
gpg: keyserver search failed: No keyserver available

WHAT?! I just specified --keyserver!!!??

Relax. You forgot the '.pool' in the url.

:facepalm: ... Apparently I need more coffee -- persistent failure state in user
encountered.

Sorry for the noise.

I do wonder about fault-tolerance, though, if a e.g. non-responsive host creeps
in to the pool.

At any rate, this is mainly a cosmetic issue at this point, and this bug report
probably contains sufficient information to help someone who "encounters" the
condition to resolve the protocol error quickly.

Ok profiles are now there and look workable, but it looks like they are only
supporting configuration values that are currently accessible through gpgconf:

[gpg]
trust-model tofu+pgp
keyserver-options auto-key-retrieve
auto-key-locate local,wkd,pka,cert,dane

Leads to:

gpgconf: /opt/gnupg/etc/gnupg/automated.profile:7:0: error: unknown option
'trust-model' in section 'gpg'
gpgconf: /opt/gnupg/etc/gnupg/automated.profile:8:0: error: unknown option
'keyserver-options' in section 'gpg'

So we need more options promoted to gpgconf. Which I think is ok, we can just
mark them as Expert / Invisible and GUI's should respect that.

For the records, the suggested way to kill dirmngr is

gpgconf --kill dirmngr

this makes sure that dirmngr will not be started if it is not running.

Makes sense, but it is still a problem in that --delete-secret-subkeys doesn't
work if you don't have the secret identity key. Which means that it's impossible
to delete the secret subkeys except by getting their keygrip and deleting them
in the private-keys-v1.d directory, though I suppose this is for a different bug
report.

tl;dr: HKPS handler will die when used with non-HKPS hosts in a given pool.

I think dying is reasonable. Maybe it should return a nicer error
than 'general error' and it shouldn't take 10 seconds to figure out
the protocol error.

Using setup directions from
https://sks-keyservers.net/overview-of-pools.php I assumed that
configuring my GnuPG client to use ipv4.pool.sks-keyservers.net
would provide an appropriate response. It took me quite some time to
determine that HKPS is totally incompatible with the ipv4 (or other)
server pools.

This is further confused by the fact that an older version of the
GnuPG skeleton files which includes a clause with examples that mix
HKPS and hkp servers (skel may not necessarily be updated in a
user's directory):

Sorry about that. I think the current skeleton file is clearer on
this.

As a result, I kept encountering the errors reported in
T1792

I don't see a connection to this bug.

Here's a simple demonstration of the failure case

$ gpg2 --keyserver hkps://ipv4.pool.sks-keyservers.net --search-keys
2071B08A33BD3F06
gpg: error searching keyserver: General error
gpg: keyserver search failed: General error

Contrast with:

$ gpg2 --keyserver hkps://hkps.pool.sks-keyservers.net --search-keys
2071B08A33BD3F06
gpg: data source: https://mud.stack.nl:443
(1) NIIBE Yutaka (GnuPG Release Key) <gniibe@fsij.org>

 	  2048 bit RSA key 2071B08A33BD3F06, created: 2014-10-29, expires: 2020-10-30

PERSISTENT FAILURE CASE:
Now, once the failure condition is encountered, further queries FAIL:

$ pkill dirmngr

A nicer way to kill the dirmngr is:

  gpg-connect-agent --dirmngr 'killdirmngr' /bye

$ gpg2 --keyserver hkp://pool.sks-keyservers.net --search-keys 2071B08A33BD3F06
gpg: error searching keyserver: No route to host
gpg: keyserver search failed: No route to host

This is strange, and looks like it should work. Works over here. Maybe it is
bad luck and you got a bad host from the roundrobin.

$ gpg2 --keyserver hkps://hkps.sks-keyservers.net --search-keys 2071B08A33BD3F06
gpg: no keyserver known (use option --keyserver)
gpg: keyserver search failed: No keyserver available

WHAT?! I just specified --keyserver!!!??

Relax. You forgot the '.pool' in the url.

Let's see if this can be rectified with clearing the keyserver:

$ gpg-connect-agent --dirmngr keyserver
> keyserver --clear
OK

$ gpg2 --keyserver hkps://hkps.sks-keyservers.net --search-keys 2071B08A33BD3F06
gpg: no keyserver known (use option --keyserver)
gpg: keyserver search failed: No keyserver available

Likewise.

1. Try this with other VALID --keyserver combinations. Bang head against wall. The ONLY command that seems to fix this persistent failure case: $ gpg2 --search-keys 2071B08A33BD3F06 Suddenly, I can use --keyserver again, after this.

I'm pretty sure you just messed up the urls.

This is a misunderstanding. 'delkey' only operates on public keys. I have
updated the documentation to make that clear.

Fixed in a76fe9e86d7802e67373218bd1759168585e92ab.

Unfortunately, it is currently not possible to delete secret subkeys while
keeping the secret identity key. You can use gpg --delete-secret-keys to delete
the whole secret key though.

The problem still occured after the update of Libgcrypt, but Im pretty sure now
that I determine the origin of the problem. In the end it is somehow my fault: By
time I got more and more email accounts which are synchronized with offlineimap and
the passwords for each account are encrypted with gpg.
Offlineimap offers an option for multitheading, which synchronize the accounts in a
prallel manner. By changing to a strict serialized synchronistaion the problem
seems to vanish. My guess is, it was simply to much at once.
For those, who encounter the same problem try the '-1' option of offlineimap.

Thanks for your time and work (in general)!

I went over the other programs, and did not see any glaring problems. I have
decided to ignore the socket configuration for now. I'm quite happy with the
changes, but feel free to reopen this bug.

Fixed in ca02a8b78fca8815388a859962584d75169ae3ee.

I'm going to write some documentation about the programmatic use of GnuPG.

Fixed for gpg as of 6b16b02109f4bb5b934e456667ff4c0ba7bc85fd.

@werner, have you looked into the patch?

AC_CHECK_FUNCS([mmap]) on Fedora fails to find mmap() due to missing -fPIC.
/usr/bin/ld: /tmp/ccvNyAcN.o: relocation R_X86_64_PC32 against undefined symbol
`mmap@@GLIBC_2.2.5' can not be used when making a shared object; recompile with
-fPIC

We have -fPIC somewhere in default CFLAGS, so just resotre user CFLAGS
before making checks for functions.

A bug tracker is not a support forum. Nevertheless, you need to look into your
configuration file and see what line 143 says. Also, a configuration file that
long looks suspicious, maybe it just got corrupted somehow.

I'm glad that git has this fixed. Well, then the actual problem is that it is
broken in release.

Even being gentoo user, I cannot install gnupg from git easily (there's no live
ebuild for gnupg yet). So users will suffer from this until you make next
release and distros maintainers update packages.

So regarding functional tests for shell utils... Any suggestion how to arrange
that? Or would you review whatever I come up with?