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

This is an issue of GNOME as packaged by Red Hat. Please file a bug in Red
Hat's bug tracker instead.

I'm on T2448 (aheinecke on Sep 05 2016, 02:14 PM / Roundup).

Jochen, is T2448 (aheinecke on Sep 05 2016, 02:14 PM / Roundup) something you could do?

I don't have sufficient permission to upgrade gnome session, so if you have
any idea suggest me

@werner, if I understand the description at
https://www.gnu.org/software/tar/manual/html_section/tar_68.html
then ustar would also be able to read "posix" archives.

Thanks. I took your solution.

ustar is the format introduced by PGP 6; also for Windows. This is the only
reason we use it. PGP users demanded that we support that "pgpzip". We can't
drop it.

Use a recent gnome version and you are fine.

Sorry, I cannot reproduce this problem using 2.1.11:

% export GNUPGHOME=$(mktemp -d)
% echo "keyserver hkps://hkps.pool.sks-keyservers.net
hkp-cacert
/home/teythoon/repos/g10/gnupg-2.1.11/dirmng/sks-keyservers.netCA.pem" >
$GNUPGHOME/dirmngr.conf
% g10/gpg2 --recv-keys 99B03CE455DB476E737057B44FD0FA5528DB9E3F
gpg: /tmp/tmp.QINMXRcRqH/trustdb.gpg: trustdb created
gpg: key 28DB9E3F: public key "Justus Winter <justus@gnupg.org>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1
% g10/gpg2 --refresh-keys
gpg: refreshing 1 key from hkps://hkps.pool.sks-keyservers.net
gpg: key 28DB9E3F: "Justus Winter <justus@gnupg.org>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1

(Adding the .onion service makes no difference for me either.)

What I meant by "KArchive" is that we already have all that nice archiving code
in Kleopatra already: https://api.kde.org/frameworks/karchive/html/index.html
To work with standard formats like tar / zip / 7zip etc.

This would get us the included platform abstraction through Qt for stuff like
filenames etc. and we wouldn't have to maintain our own implementations for
these archive formats.

Can you create a new issue with the data "loss" part?

As for the default format:
I think we should use and propose a default format that is mostly compatible
over platforms (and robust in the future). tar "posix" seems to be
such a format. Am not sure how this evaluates for karchive or 7zip.