Thanks. I applied the two patches.

D373: 849_0002-dirmngr-Try-ldap-protocol-V3-as-fallback.patch

D374: 848_0001-dirmngr-Print-ldap-error-if-bind-fails.patch

I've analyzed the Problem dirmngr_ldap failed with a Protocol Error which was
hidden because the error output used errno instead of the ldap error.

Attached patch fixes the error output.

The Protocol error was because:
"historical protocol version requested, use LDAPv3 instead"

I'm not sure if dirmngr should try LDAPv3 first and fall back to LDAPv2 but the
Patch I'll attach in the next message adds a fallback to LDAPv3 if the ldap_bind
with the default protocol leads to a protocol error.

The endless activity / failing to notice that the dirmngr_ldap has already died
after the failure I leave for someone else (another issue I guess) as I've
already failed to fix this once :-)

Ah, I see. The GUI interface affects the S/MIME algorithm, not the general
one. I don't know why I didn't put that together sooner. Well, I'm glad that
it revealed the minor bug anyway.

We can't easily solve this. For now I pushed a fix to return an error instead
of crashing. (commit 8173c4f). Thanks for reporting.

@aheincke an myself observed different behaviour on two ldap server versions
(openldap).
Our new openldap server fails for old dirmngr 1.1.0 Version: 1.1.0+r347-0kk2
and 2.1.11 and master.

Internall we can still access the old ldap server for testing purposes.

Next step see on the wire what the differences could be.

scdaemon is part of GnuPG.
OpenSC is entirely unrelated to GnuPG.

Please take this to a mailing list (e.g. gnupg-users)

D372: 847_libgpg-error-20160613.diff

I think that it is (long standing) bug in estream.c. Please see the attached
patch for a possible fix.
The enhancement in gnupg, the commit of 12af263 does READ then WRITE with
estream, and it reveals this bug.

Finally, I managed to reproduce the same (I suppose) situation.
Please see: https://lists.gnupg.org/pipermail/gnupg-devel/2016-June/031211.html
It is READ vs. WRITE race condition.

I think that this patch improve the situation.
It moves the creation of the hash table to the place where it creates version
record (holding the lock).

D205: 846_gpg14-create_hashtable-fix.diff

Sorry for going AWOL on this, Werner. Do you still need a backtrace from me, or is the
one from 2371 enough?

Thank you for update.
msg8431 seems to be another race condition. I only fixed one race in 2015.

My saying in T1675 (gniibe on May 25 2015, 07:38 AM / Roundup) sounds wrong (now, for me).
For example, create_hashtable does lseek to SEEK_END.
When some another process is adding new entry (say, also calling
create_hashtable), we have a valid race condition here.
I mean,

(1) process A calls lseek with SEEK_END, seek goes to a point.
    Then, context switch.
(2) process B calls lseek with SEEK_END. seek goes same point as A.
(3) process B update info using the point.  context switch to A.
(4) process A wrongly overrides info using the point.
    It results inconsistent data.

It was fixed in db1ecc8212defdd183abbb6b1407fcc8d2dc9552 for 2.1.
In 2.1, HDRLEN=0 for all callers, so, there will be no same "Ohhhh jeeee" any more.

In 1.4 and 2.0, HDRLEN is used as a hint. There is no need to change 1.4 and
2.0. Detail is described in:
https://lists.gnupg.org/pipermail/gnupg-devel/2016-June/031178.html

I would except that config.sub already validates such names as 'armv7a-hardfloat-
linux-gnueabi' so there is nothing to fix. It is libgpg-error that doesn't. If
you feel it should invalidate such names please report that to the GNU config
folks instead. Their repo is at git://git.sv.gnu.org/config.git. Otherwise
pleases fix libgpg-error.

So, how do we proceed? Release 2.1.13 and wait for potential problems?

No, that is not acceptable for libgpg-error. Please report that to the GNU config
folks instead. Their repo is at git://git.sv.gnu.org/config.git

Seem to be a regression in 2.0. 2.1 works as expected.

If you decide to change your mind, this patch places the logic in configure.ac.

D370: 845_libgpg-error-link-valid-header.patch

The host naming scheme accepted by this project is really just Debian oriented.
There is nothing saying you have to aid other distro's hostnames but I have yet to
witness a project more unfriendly to non-Debianesque distros that libgpg-error.
You don't have to accept the patch. Understandable, since mkheader would not
ideally be the way to go. But you should at least be open to the idea of
supporting the more liberal host naming schemes that other distros employ.

I'm still able to make this fail, though quite less often.
Example is here.

$ wget https://bugs.gnupg.org/gnupg/file443/show-race.sh -O show-race.sh
$ chmod 755 show-race.sh
$ dpkg-query --show gnupg
$ gnupg --version
gpg (GnuPG) 1.4.20
Copyright (C) 2015 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, RSA-E, RSA-S, ELG-E, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,

CAMELLIA128, CAMELLIA192, CAMELLIA256

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

$ sed -i.dist -e 's,precise-updates,precise,' -e
's,20101020ubuntu136.15,current,' show-race.sh
$ diff -u show-race.sh.dist show-race.sh

• show-race.sh.dist 2016-06-06 16:37:25.845783450 -0400

+++ show-race.sh 2016-06-06 16:37:26.645771713 -0400
@@ -37,7 +37,7 @@

mkdir "$GNUPGHOME" && chmod 700 "$GNUPGHOME"

fi

-url="http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/20101020ubuntu136.15/images"
+url="http://archive.ubuntu.com/ubuntu/dists/precise/main/installer-amd64/current/images"
kr=/usr/share/keyrings/ubuntu-archive-keyring.gpg
for f in SHA256SUMS SHA256SUMS.gpg; do

   [ -f "$f" ] && continue

$ i=0; while i=$(($i+1)); do rm -Rf out*; echo -n "$i "; ./show-race.sh ||
break; done
1 max=100 cmd=gpg --verify args:
2 max=100 cmd=gpg --verify args:
3 max=100 cmd=gpg --verify args:
4 max=100 cmd=gpg --verify args:
...
67 max=100 cmd=gpg --verify args:
68 max=100 cmd=gpg --verify args:
69 max=100 cmd=gpg --verify args:
3 failed: out.3 [2]

$ cat out.3
gpg: Signature made Mon 23 Apr 2012 03:52:09 PM EDT using DSA key ID 437D05B5
gpg: error opening lockfile `/tmp/xt/out.gnupghome/trustdb.gpg.lock': No such
file or directory
gpg: lockfile disappeared
gpg: 12: read expected rec type 10, got 0
gpg: lookup_hashtable failed: trust database error
gpg: trustdb: searching trust record failed: trust database error
gpg: Error: The trustdb is corrupted.
gpg: You may try to re-create the trustdb using the commands:
gpg: cd /tmp/xt/out.gnupghome
gpg: gpg2 --export-ownertrust > otrust.tmp
gpg: rm trustdb.gpg
gpg: gpg2 --import-ownertrust < otrust.tmp
gpg: If that does not work, please consult the manual

Ah sorry I understood you were saying the bug is in OpenSC. Where can I report
to scdaemon? I can't find it.

FireFox is not GnuPG and does not support the OpenPGP card.

As I said, the card may work with gpgsm because I once developed support for the
Belgian eID card. But it is likely to need some tweaking (gnupg/scd/app-p15.c)

I saw that it says not supported, but DNIe is actually supported. I can use it
flawlessly with Firefox for instance.

Please see:
https://github.com/OpenSC/OpenSC/wiki/DNIe-%28OpenDNIe%29#update-2013-08-27
https://github.com/OpenSC/OpenSC/issues/774#issuecomment-222468916

Thanks!

Please ask on the gnupg-users mailing list for help.

Some quick hints:
Is your pinentry properly installed? Is gpg-agent running? Does gnome-keyring
interfere with gpg-agent?

D375: 844_20_posix-lock-obj.patch

Debugging a bit more in the source code suggests, that the problem could
be still related to the misalignment resolved in the bug 2144 [1].

There seem to be two problems with the fix [2].

1. the fix causes that two identical gpg-error.h header files could be

generated based on what the current compilation target platform is,
32/64bit. Instead of generating two distinct header files, only one
header file should be generated (or better to say, the
gen-posix-lock-obj can be called twice - once for 32bit platform, once
for the 64-bit one, but it should always return the same content).
The particular decision whether the alignment item will be added to the
struct should be solved in the header file - not at the header file
generation time. In that case, the decision whether the alignment item
is added will be made at the libgpg-error consumer's compilation time
(like libgcrypt).

2. the fix updates only the external gpgrt_lock_t; it's internal

counterpart _gpgrt_lock_t is not updated. This causes that functions
working with the POSIX mutexes (gpgrt_lock_*()) could access misaligned
addresses - that results in Bus Errors on SPARC.

Referecences:
[1] T2144
[2]
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=commit;h=f7a77c5c236ecec846de9be46703026f9b01008f

libgcryp-1.7.0 t-lock and random test cases consistently crash on
SPARCv7 platform. On other platforms like x86/amd64/SPARCv9 the tests
succeed.

• 8< ---

PASS: t-mpi-point
PASS: curves
/bin/bash: line 5: 6557 Bus Error (core dumped)
GCRYPT_IN_REGRESSION_TEST=1 ${dir}$tst
FAIL: t-lock
PASS: prime

[...]

PASS: fips186-dsa
PASS: aeswrap
PASS: pkcs1v2
random: running './random --in-recursion --early-rng-check' failed
FAIL: random
PASS: dsa-rfc6979

256 of 1026 tests done
512 of 1026 tests done

• 8< ---

Hi, thanks for testing master.

I can semi reproduce this. For me it works the first time but a second call to
getpin fails.

$ ./pinentry-gtk-2
OK Pleased to meet you
getpin
D hello
OK
getpin

• (pinentry-gtk-2:29090): CRITICAL **: could not grab keyboard

ERR 83886179 Operation cancelled <Pinentry>

And indeed this goes away with f4b5049c68a79d5e4faba06447db5440936cefeb~1

Looking at the code I don't see a reason for this. Maybe the dialog?
The code without the dialog 71b51e02cf20174ba7144765e985f7e889eaa429 also allows
me to repeatedly call getpin.

Werner: Any idea? I'm a bit clueless which change in the patch could have caused
that.

In 1.4 and 2.0, --import just copies the block, so the bug doesn't hit. In 2.1,
when it tries to write to keybox, the bug hits.

The check what Neal introduced is somehow orthogonal to the change of mine.

The key in question, there is a User ID packet of length >= 256 (because he
include ssh key string in his User ID).
In the code of build-packet.c, gpg assumed the length of User ID is < 256 and it
is hard coded to have header length 2.
With the check (in gpg 2.1), it causes an error. I think that, in gpg 1.4 and
2.0, gpg creates malformed packet with incorrect length (LSB of the length).

fwiw, i first encountered this by doing a full-keyring refresh from the
keyservers. Dying rather than adjusting or accomodating the malformed header
meant that all keys after this one failed to refresh.

In general, dying outright seems likely to make an observed problem worse than
it needs to be.

I can confirm one defect with 2.1.11:
The ability to export a secret key without passphrase available in gnupg2.0
is gone. My use case is to write a testcase that automatically imports the key.

Duplicate of T2324

I am resolving this issue as duplicate of T2324
in the case of intented empty passphrase for the exported key.
(the export-reset-subkey-passwd flag should be taken to an entirely different
issue.)

Both 2.1.11 and 2.1.12 are not in the index, so the update
was missed during the release process.
Werner, you probably know best where to place it in the release process,
so that it is not forgotten. An alternative would be to use a directory listing
module of the webserver which does this more dynamically (and caches the result).

Let us use T2305 for the index update.

FWIW, I added the stricter check. Previously, we specified the header size, but
didn't check that it was respected. When discussing this with Werner, he said
that respecting the header size was important, which is why I chose to die
rather than silently change the header size.

Ian may have a different opinion on that (now) but the GNU build system defines
it in the way I described it.

$ gpg mBank17044.asc
pub rsa2048/375EB336C8086B9E 2015-01-19
uid AR17044 <XXXXXXXXXXXX@mbank.pl>
sub rsa2048/75E684B9017985DF 2014-12-29 [expires: 2016-01-20]

[uid redacted]
As you can see, the encryption subkey expired in January. Thus the holder of
the key does not want you to encrypt to this key after that date. We know that
GPA should give a better error message. I'll change your report to a wish to
implement this.

Bernhard: Please do not assign bugs to me without my consent.

Yes "unusable public key" (original message was not in English and obviously I
failed at translation...).
The key is valid (created at 2015-01-19, no expiration date) - you can see it
yourself, it's attached to this thread.

This is not a bug; gpg tells you that this card is not supported:

  gpg: OpenPGP card not available: Not supported

In case this is an X.509 based card gpgsm _might_ be abale to use it but in most
cases dedicated support for eID cards needs to be added to the scdaemon component.

FWIW, PKCS#11 is not a certificate but a protocol on how some software
interfaces with each other.