I'm going to close this due to inactivity. Feel free to reopen it with more
information.

Agreed, but i ran into this while looking at python-gnupg, which is now failing
when using GnuPG 2.1. so they're facing breakage either way. It would be
better to have all current releases doing the expected behavior than to imagine
that we can bump this variance in behavior along indefinitely.

I hesitate to fix this for 1.4 - if people are using this they are probably
working around it and a fix would break that.

There is a plethoria of reasons why a user ID is not valid. The most
common one has been a mssing self-signature, thus this note. Newer
releases of older branches actually know about new algorithms and may
print some info about this; but they are not able to handle them.

Here is what the current 1.4 prints for an ed25519/cv25519 key:

$ gpg1 --no-options -v --import <ed25519-cv25519-sample-1.asc
gpg: armor header: Version: GnuPG v2
gpg: can't handle public key algorithm 22
gpg: can't handle public key algorithm 18
gpg: pub 0?/2A020D0A 2016-06-22 patrice.lumumba@example.net
gpg: key 2A020D0A: unsupported public key algorithm on user ID
"patrice.lumumba@example.net"
gpg: key 2A020D0A: unsupported public key algorithm
gpg: key 2A020D0A: skipped user ID "patrice.lumumba@example.net"
gpg: key 2A020D0A: skipped subkey
gpg: key 2A020D0A: no valid user IDs
gpg: this may be caused by a missing self-signature
gpg: Total number processed: 1
gpg: w/o user IDs: 1

The problem is pretty obvious. You need to use -v (--verbose) to see
all these messages.

If a apply that fix to an unmodified 2.1.15, my problem is solved:
My test case (importing a PKCS#12 file with pinentry-mode=loopback if the agent
has not been started before) now works. Thank you!

If a apply that fix to an unmodified 2.1.15, my problem is solved. Thank you!

ping

lechten: I agree with justus' evaluation. Further we can't change the sematics
of --default-cert-expire in the way you want that; it would not be compatible.

Fixed with 2.1.14.

Look at what the man page says on how to specify a user id:

• By exact match on an email address. This is indicated by enclosing the email address in the usual way with left and right angles. <heinrichh@uni-duesseldorf.de>

The default however is a substring match on the entire user id. Note that
issue2359 is also about this and it may introduce a slighlty modified way on how
a key is specified by a mail address.

Should only be chnaged for master, though.

Duplicate of T2359

We track this now under T2359

It is now patched in gpg4win and I think aheinecke pushed the patch also to linux.

The Bug iteself has been resolved with that patch, but is yet unreleased.

I got my hands on a macOS box, and this particular problem is fixed in 2e64ccb0.

I still cannot compile gnupg there, but I'm working on it.

I'm going to close this issue due to inactivity. Feel free to reopen it.

Fixed in: 4e4843e735f32b5e79a51d8062da55bfaab6ad77
Please test.

Right. It is the cause.
Fixed in: 836b72363168cbb0051fc2356f61788468db211c

Fixed in: 98bc6f480ac973dccce90378dc021a2e24e58704

Thank you for your fixes and the specific test case.
Indeed, it's a bug.
I'm going to apply changes, but I think that it's better to have same code
pattern of g10/seskey.c (the part of verification).

D383: 890_0002-do_encode_dsa-make-digest-length-checks-match-those-.patch

Fix digest length check when signing for ECDSA

D384: 889_0001-do_encode_dsa-fix-incorrect-check-for-521-bit-ECDSA.patch

Fix check for 521-bit ECDSA

D382: 888_call-agent-ctx.patch

Correction (not "->" but "."): Add this line:

  inq_parm.ctx = agent_ctx;

Patch attached. Works for me for 2.1.14.
(Should work for 2.1.15, too, but I cannot test due to T2698.)

Same in current version 2.1.15 (file is identical)

Fixed in df5353b. Also added a test.

Perhaps the following change between 2.1.14 and 2.1.15 has something to do with the problem: It causes
both no-libgcrypt.o and $(LIBGCRYPT_LIBS) to be linked in.

diff -ru gnupg-2.1.14/dirmngr/Makefile.am gnupg-2.1.15/dirmngr/Makefile.am

• gnupg-2.1.14/dirmngr/Makefile.am 2016-06-16 17:23:13.000000000 +0200

+++ gnupg-2.1.15/dirmngr/Makefile.am 2016-08-18 17:00:16.000000000 +0200
@@ -94,8 +94,8 @@
dirmngr_ldap_CFLAGS = $(GPG_ERROR_CFLAGS) $(LIBGCRYPT_CFLAGS)
dirmngr_ldap_LDFLAGS =
dirmngr_ldap_LDADD = $(libcommon) no-libgcrypt.o \

• $(GPG_ERROR_LIBS) $(LDAPLIBS) $(LBER_LIBS) $(LIBINTL) \
• $(LIBICONV)

+ $(GPG_ERROR_LIBS) $(LIBGCRYPT_LIBS) $(LDAPLIBS) \
+ $(LBER_LIBS) $(LIBINTL) $(LIBICONV)
endif

dirmngr_client_SOURCES = dirmngr-client.c

There is a regression in GnuPG 2.1.15.

After building

  npth-1.2          with --prefix=/xxx --enable-static --disable-shared
  libgpg-error-1.24 with --prefix=/xxx --enable-static --disable-shared
  libassuan-2.4.3   with --prefix=/xxx --enable-static --disable-shared --with-gpg-error-prefix=/xxx
  libgcrypt-1.7.3   with --prefix=/xxx --enable-static --disable-shared --with-gpg-error-prefix=/xxx
  libksba-1.3.5     with --prefix=/xxx --enable-static --disable-shared --with-gpg-error-prefix=/xxx

I can build without any problems:

  gnupg-2.1.14      with --prefix=/xxx --with-gpg-error-prefix=/xxx --with-npth-prefix=/xxx --with-libassuan-prefix=/xxx --with-libgcrypt-prefix=/xxx --with-ksba-prefix=/xxx

But I cannot build

  gnupg-2.1.15      with the identical options.

Compilation fails with these messages:

Making all in dirmngr
make[2]: Entering directory `/aaa/gnupg-2.1.15/dirmngr'
make all-am
make[3]: Entering directory `/aaa/gnupg-2.1.15/dirmngr'
gcc -I/xxx/include -I/xxx/include -Wall -Wno-pointer-sign -Wpointer-arith -g -O2 -lrt -o dirmngr_ldap dirmngr_ldap-dirmngr_ldap.o ../common/libcommon.a no-libgcrypt.o -L/xxx/lib -lgpg-error -L/xxx/lib -lgcrypt -lgpg-error -L/xxx/lib -lldap -llber
/xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o): In function `gcry_free':
/aaa/libgcrypt-1.7.3/src/visibility.c:1554: multiple definition of `gcry_free'
no-libgcrypt.o:/aaa/gnupg-2.1.15/dirmngr/no-libgcrypt.c:111: first defined here
/usr/bin/ld: Warning: size of symbol `gcry_free' changed from 18 in no-libgcrypt.o to 5 in /xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o)
/xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o): In function `gcry_xstrdup':
/aaa/libgcrypt-1.7.3/src/visibility.c:1548: multiple definition of `gcry_xstrdup'
no-libgcrypt.o:/aaa/gnupg-2.1.15/dirmngr/no-libgcrypt.c:100: first defined here
/usr/bin/ld: Warning: size of symbol `gcry_xstrdup' changed from 75 in no-libgcrypt.o to 5 in /xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o)
/xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o): In function `gcry_xrealloc':
/aaa/libgcrypt-1.7.3/src/visibility.c:1542: multiple definition of `gcry_xrealloc'
no-libgcrypt.o:/aaa/gnupg-2.1.15/dirmngr/no-libgcrypt.c:73: first defined here
/usr/bin/ld: Warning: size of symbol `gcry_xrealloc' changed from 29 in no-libgcrypt.o to 5 in /xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o)
/xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o): In function `gcry_xcalloc':
/aaa/libgcrypt-1.7.3/src/visibility.c:1524: multiple definition of `gcry_xcalloc'
no-libgcrypt.o:/aaa/gnupg-2.1.15/dirmngr/no-libgcrypt.c:90: first defined here
/usr/bin/ld: Warning: size of symbol `gcry_xcalloc' changed from 29 in no-libgcrypt.o to 5 in /xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o)
/xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o): In function `gcry_xmalloc':
/aaa/libgcrypt-1.7.3/src/visibility.c:1518: multiple definition of `gcry_xmalloc'
no-libgcrypt.o:/aaa/gnupg-2.1.15/dirmngr/no-libgcrypt.c:48: first defined here
/usr/bin/ld: Warning: size of symbol `gcry_xmalloc' changed from 29 in no-libgcrypt.o to 5 in /xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o)
/xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o): In function `gcry_strdup':
/aaa/libgcrypt-1.7.3/src/visibility.c:1512: multiple definition of `gcry_strdup'
no-libgcrypt.o:/aaa/gnupg-2.1.15/dirmngr/no-libgcrypt.c:57: first defined here
/usr/bin/ld: Warning: size of symbol `gcry_strdup' changed from 68 in no-libgcrypt.o to 5 in /xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o)
/xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o): In function `gcry_realloc':
/aaa/libgcrypt-1.7.3/src/visibility.c:1506: multiple definition of `gcry_realloc'
no-libgcrypt.o:/aaa/gnupg-2.1.15/dirmngr/no-libgcrypt.c:68: first defined here
/xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o): In function `gcry_malloc_secure':
/aaa/libgcrypt-1.7.3/src/visibility.c:1494: multiple definition of `gcry_malloc_secure'
no-libgcrypt.o:/aaa/gnupg-2.1.15/dirmngr/no-libgcrypt.c:43: first defined here
/xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o): In function `gcry_calloc':
/aaa/libgcrypt-1.7.3/src/visibility.c:1488: multiple definition of `gcry_calloc'
no-libgcrypt.o:/aaa/gnupg-2.1.15/dirmngr/no-libgcrypt.c:85: first defined here
/xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o): In function `gcry_malloc':
/aaa/libgcrypt-1.7.3/src/visibility.c:1482: multiple definition of `gcry_malloc'
no-libgcrypt.o:/aaa/gnupg-2.1.15/dirmngr/no-libgcrypt.c:37: first defined here
/xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o): In function `gcry_set_log_handler':
/aaa/libgcrypt-1.7.3/src/visibility.c:1470: multiple definition of `gcry_set_log_handler'
no-libgcrypt.o:/aaa/gnupg-2.1.15/dirmngr/no-libgcrypt.c:144: first defined here
/usr/bin/ld: Warning: size of symbol `gcry_set_log_handler' changed from 2 in no-libgcrypt.o to 5 in /xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o)
/xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o): In function `gcry_set_fatalerror_handler':
/aaa/libgcrypt-1.7.3/src/visibility.c:1464: multiple definition of `gcry_set_fatalerror_handler'
no-libgcrypt.o:/aaa/gnupg-2.1.15/dirmngr/no-libgcrypt.c:137: first defined here
/usr/bin/ld: Warning: size of symbol `gcry_set_fatalerror_handler' changed from 2 in no-libgcrypt.o to 5 in /xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o)
/xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o): In function `gcry_set_outofcore_handler':
/aaa/libgcrypt-1.7.3/src/visibility.c:1458: multiple definition of `gcry_set_outofcore_handler'
no-libgcrypt.o:/aaa/gnupg-2.1.15/dirmngr/no-libgcrypt.c:130: first defined here
/usr/bin/ld: Warning: size of symbol `gcry_set_outofcore_handler' changed from 2 in no-libgcrypt.o to 5 in /xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o)
/xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o): In function `gcry_create_nonce':
/aaa/libgcrypt-1.7.3/src/visibility.c:1351: multiple definition of `gcry_create_nonce'
no-libgcrypt.o:/aaa/gnupg-2.1.15/dirmngr/no-libgcrypt.c:149: first defined here
/usr/bin/ld: Warning: size of symbol `gcry_create_nonce' changed from 16 in no-libgcrypt.o to 90 in /xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o)
/xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o): In function `gcry_cipher_algo_name':
/aaa/libgcrypt-1.7.3/src/visibility.c:800: multiple definition of `gcry_cipher_algo_name'
no-libgcrypt.o:/aaa/gnupg-2.1.15/dirmngr/no-libgcrypt.c:162: first defined here
/usr/bin/ld: Warning: size of symbol `gcry_cipher_algo_name' changed from 6 in no-libgcrypt.o to 5 in /xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o)
/xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o): In function `gcry_control':
/aaa/libgcrypt-1.7.3/src/visibility.c:74: multiple definition of `gcry_control'
no-libgcrypt.o:/aaa/gnupg-2.1.15/dirmngr/no-libgcrypt.c:123: first defined here
/usr/bin/ld: Warning: size of symbol `gcry_control' changed from 3 in no-libgcrypt.o to 163 in /xxx/lib/libgcrypt.a(libgcrypt_la-visibility.o)
collect2: ld gab 1 als Ende-Status zur&uuml;ck
make[3]: * [dirmngr_ldap] Fehler 1
make[3]: Leaving directory `/aaa/gnupg-2.1.15/dirmngr'
make[2]: * [all] Fehler 2
make[2]: Leaving directory `/aaa/gnupg-2.1.15/dirmngr'
make[1]: * [all-recursive] Fehler 1
make[1]: Leaving directory `/aaa/gnupg-2.1.15'
make: * [all] Fehler 2

Most probably /aaa/gnupg-2.1.15/dirmngr/no-libgcrypt.c is being used where it shouldn't.

Do you need further information?

Thank you

Thanks - attached please find the results of the grep command on the arpa directory...

Thanks. I believe the relevant part is:

checking whether the resolver is usable... no
checking whether I can make the resolver usable with BIND_8_COMPAT... no

The latter is indeed a MacOS X specific thing.

Would you be so kind to execute the following commands on your machine, and
report the results back?

grep COMPAT /usr/include/arpa/*
grep PACKETSZ /usr/include/arpa/*

I pushed Ueno's patches for gpgme. In particular
dee56820cabde60c43c9bf8281b8d411cb2ad644

I agree that this is a practical problem.

I think it would be the right thing.

I'm developing Schleuder, the OpenPGP-featuring mailing list manager.
If I'm receiving an empty list of public keys from GPGME I currently don't know
if there are no keys, or if the keyring couldn't be read. Thus I can't properly
decide what to do: try to fetch keys? I would run into the same problem when
trying to import them. Return an error message? Which one?

This has led repeatedly to confusion e.g. when people imported a key into a
schleuder-list's keyring in the shell as root, which results in changed
ownership of the keyring-files by gpg. Next Schleuder couldn't read the keyring
anymore and maybe refused operation because it couldn't verify any incoming
email any more — instead of giving a helpful error message that points to the
cause: lacking filesystem permissions.

Currently my only chance is to manually check the permissions of all files that
might be involved in an operation. That is working around a bug, in my eyes.

actually it was a feature request that a trustdb is not created in case of
--always-trust. But sure, it should not error out.

You mean you want something like EACCES instead of an empty listing? I am not
sure whether this is the right thing to do. Can please you describe your use case?

Oops; forgot to add the fix to 1.7.0

Do you have an idea when you would try to fix this? Within the next weeks or
rather months?

Thanks for reply - I discovered the MacPG installer, which worked, so no urgency on
this but I provide the output from ./configure in case it helps others. It's in
RichTextFormat (.rtf) -- if you require plain text just let me know.

This has been fixed in July with c49c43d7.

Thanks for the report. Please attach the full output of configure.