Sorry, my near sight. I only fixed cofactor support, in a case where "h" is
provided.
I should have fixed other parts, too. Now, I fixed in master:

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commitdiff;h=0f3a069211d8d24a61aa0dc2cc6c4ef04cc4fab7;hp=fa917d2e24b0c98143a079ab4889ad8f69bee446

It is backported to 1.7 branch too.

libaacs should work with this patch.

I'm sorry if your understanding of valid hostnames, acceptable by GNU projects, is
two decades old but this project happens to be the only one that assumes there
exists a finite list of valid hostnames without using pattern matching.

Using https://wiki.gentoo.org/wiki/Raspberry_Pi and a hostname of armv7a-
hardfloat-linux-gnu, with the notable exception of libgpg-error, I have been able
to compile and install all other GNU utilities included the core set of Gentoo
Linux, whether via the package's giving configure script or by use of autoreconf.

Hare are just a few of such GNU packages that I have personally been able to build
and install using the hostname "armv7a-hardfloat-linux-gnu":

coreutils-8.25
bash-4.3_p42
diffutils-3.3
findutils-4.6.0
grep-2.25
groff-1.22.3
gzip-1.8
tar-1.29
glibc-2.23
less-483
gawk-4.1.3
which-2.21
nettle-3.2
glibc-2.23
gcc-5.3.0
readline-6.3_p8
nano-2.5.3

The only other GNU package that doesn't compile for me is autogen. But that's due
to a lack of cross-compile support. It otherwise builds just fine natively on
armv7a-hardfloat-linux-gnu.

I would appreciate it if you could provide a specific GNU package using autotools
that you assert should fail to support such a hostname, other than this one, so
that I may provide a build log demonstrating that it indeed does.

Well, I still get a "Missing object" error in libaacs, and I'm not sure how to
fix it. But the patch is in, so I think the bug can be closed.

It seems the problem is around the code here:
http://git.videolan.org/?p=libaacs.git;a=blob;f=src/libaacs/crypto.c;h=4db7641ec8e9af3cdf056562de39a39e3fa0c09b;hb=HEAD#l308

And the error I get when I try to scan a disc with aacs_info is as follows:
crypto.c:587: _aacs_verify: gcry_pk_verify failed. error was: Missing item in object
aacs.c:1502: invalid signature in cached hrl

If you have any hints, I'd be very grateful. Thanks!

1.23 has meanwhile been released.

Can we close this bug? (1.71 has been released)

Fixed. The index is now re-created daily for all directories.

Fixed with commit 7ed1502 for 1.23. I used your method.

What is smartgit? What OS are you using?

[gpg-error version seems to be 1.21]

Sorry, if _you_ want support for your _new target_ you should make sure that it
is supported by the GNU autotools which is used by a lot of software. This will
the soon be used by GnuPG etc.

It is entirely fine to point us new config versions with support for your
target. We will the update them in our packages - this is how we have done it
for close to 2 decades.

Re T2378 (jf on Jun 04 2016, 07:04 PM / Roundup): We consider a 32 bit and a 64 bit system different platforms and
thus you get different header files.

I applied your patch (commit 28fd0ab) and will do a new release soon.

Thanks for applying them.

@bernhard
I did not change it to LDAPv3 first to be conservative regarding maximum
compatibility with the least regression risk. And because I don't have a v2 Only
server available against which I could test.

Afaik LDAPv2 vs. v3 is pretty much irrelevant for the calls Dirmngr does.

Imo once OpenLDAP client libraries change behavior to use V3 by default this
should be enough for dirmngr.

Hi,
without having checked it, I think that dirmngr should try ldapv3 first.
The 2.1 versions for sure. For the others, a fallback should be good enough.
(Would it help if I go digging into specs somewhat to back that up?)

Note: the comment 2) in T2378 (jf on Jun 04 2016, 07:04 PM / Roundup) [https://bugs.gnupg.org/gnupg/msg8416]
is not correct. The original text says:

1. • 8< ---
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.

• 8< ---

The fact is that _gpgrt_lock_t already contains pthread_mutex_t thus it
is correctly aligned (alignes on 8B boundary). The problem pops up if
the outer gpgrt_lock_t is aligned on 4 bytes boundary, while the
internal _gpgrt_lock_t in aligned on 8 bytes.

Please, find below the preliminary suggested fix:

• ./src/gen-posix-lock-obj.c.orig Mon Jun 13 08:07:53 2016

+++ ./src/gen-posix-lock-obj.c Mon Jun 13 08:08:40 2016
@@ -42,21 +42,8 @@
#endif
#endif

-/* Special requirements for certain platforms. */

• define USE_LONG_DOUBLE_FOR_ALIGNMENT 0

-#if defined(sun) && !defined (LP64__) && !defined(_LP64)
-/* Solaris on 32-bit architecture. */

• define USE_DOUBLE_FOR_ALIGNMENT 1

-#else

• define USE_DOUBLE_FOR_ALIGNMENT 0

-#endif
-#if defined(hppa)

• define USE_16BYTE_ALIGNMENT 1

-#else

• define USE_16BYTE_ALIGNMENT 0

-#endif

-#if USE_16BYTE_ALIGNMENT && !HAVE_GCC_ATTRIBUTE_ALIGNED
+#if defined(hppa) && !HAVE_GCC_ATTRIBUTE_ALIGNED

1. error compiler is not able to enforce a 16 byte alignment #endif

@@ -122,12 +109,14 @@

"\n"
"#define GPGRT_LOCK_INITIALIZER {%d,{{",
SIZEOF_PTHREAD_MUTEX_T,

• if USE_16BYTE_ALIGNMENT

+/* Special requirements for certain platforms. */
+# ifdef (hppa)

"    int _x16_align __attribute__ ((aligned (16)));\n",

• • elif USE_DOUBLE_FOR_ALIGNMENT
• " double _xd_align;\n",
  • elif USE_LONG_DOUBLE_FOR_ALIGNMENT
• " long double _xld_align;\n",

+# elif defined(sun)
+ "#if (defined(sparc) || defined(sparc)) && \\\n"
+ " !defined (LP64) && !defined(_LP64)\n"
+ " double _xd_align;\n"
+ "#endif\n",

1. else "",
2. endif

poll is not available on all platforms and has other semantics. Thus we will
introduce new bugs. We are planning to move some of the lower level I/O stuff
to libgpg-error and in the course of this we will fix this problem.

I think that for this particular use case of gnupg with external keyring, the
expected usage doesn't need to use trustdb at all. In such a case, we can use
--trust-model always (like gpgv), or we can use gpgv.
Then, original problem is gone, since it doesn't touch trustdb.
Anyway, fixing a race condition is good thing.
Note that there are more race conditions left, but those can be only triggered
by multiple processes accessing trustdb and a process is writing to trustdb.

For a particular hash table race condition, it is
fixed in master which will be released as 2.1.13.
Fixed in the repo of 1.4 and 2.0.

Just curious, why can you not start using poll() instead of select()?

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