fwiw, the documentation says:

       --try-all-secrets
              Don't look at the key ID as stored in the message  but  try  all
              secret  keys  in  turn  to  find  the right decryption key. This
              option forces the behaviour  as  used  by  anonymous  recipients
              (created  by  using  --throw-keyids  or  --hidden-recipient) and
              might come handy in case where an encrypted message  contains  a
              bogus key ID.

but that behavior is in fact not the default when used with anonymous
recipients, either:

2 dkg@alice:/tmp/cdtemp.hphmpn$ gpg --decrypt test.asc
gpg: encrypted with RSA key, ID 00000000
gpg: decryption failed: No secret key
2 dkg@alice:/tmp/cdtemp.hphmpn$ gpg --no-skip-hidden-recipients --decrypt test.asc
gpg: encrypted with RSA key, ID 00000000
gpg: decryption failed: No secret key
2 dkg@alice:/tmp/cdtemp.hphmpn$

I can confirm that this is still a problem on 2.1.13: --try-all-secrets does not
work as documented:

2 dkg@alice:/tmp/cdtemp.hphmpn$ gpg --try-all-secrets --decrypt test.asc
gpg: encrypted with RSA key, ID 00000000
gpg: decryption failed: No secret key
2 dkg@alice:/tmp/cdtemp.hphmpn$ gpg --try-secret-key test --decrypt test.asc
gpg: anonymous recipient; trying secret key 82A22A9306735B0C ...
gpg: okay, we are the anonymous recipient.
gpg: encrypted with RSA key, ID 00000000
test test
0 dkg@alice:/tmp/cdtemp.hphmpn$

Hi,

Can you please let me know if we could get hold of the older version than
1.7.1 of libgcrypt ?

Thank you for your report. Please give us more information.
Please show us the failure message, so that we can fix.

Fix commited to master with rev 643575f

BTW: Tools should not reconfigure GnuPG with the default homedir without
explicit user consent.

Can you please let me know how we can fix this bug. We are using Redhat Linux 6
and the highest version it supports for gcc is 4.4.x . If we need to go for a
higher version we need to download source code and do the rpm( which may take
more time. )

It seems that it's the bug of libgcrypt.
https://lists.gnupg.org/pipermail/gcrypt-devel/2016-June/003901.html

Hi,
the 2.1.13 announcement has
"""

• gpg: Allow export of non-passphrase protected secret keys.

"""
(from https://lists.gnupg.org/pipermail/gnupg-announce/2016q2/000390.html)
so this defect may be fixed with 2.1.13 I guess, cool!
Probably only need a test to confirm?

Fixed in e584d646. Includes a fix for the old test for those who need to
backport it.

Well it is a bug in your code and not in Libgcrypt. The md_read function is
guaranteed to always return a valid digest. However if you explicitly for SHA1
and SHA1 is not enabeld in the context we can't continue. Better use 0 as
second arg to md_read.

I will improve the error message for 1.7.2

Fixed in 2.1.13.

I think that it requires GCC version 4.6 or later for AVX instruction.
4.9 or later is better.
Ideally, configure should check GCC version.

Sorry, this is a duplicate of T2391. apparently i accidentally
double-clicked and roundup doesn't protect against that sort of thing. :/

For the few gpgsm tests we have, the --faked-system-time option is used. We
should use this here too.

uldis: Thanks for your comment. Let me show my opinion.
There are three ways (at least) to create a semaphore.
Each has different semantics, how it can be shared among different processes.

(1) sem_init with pshared=0: Not shared among processes
(2) sem_init with pshared=1: Shared among children processes of particular parent
(3) sem_open: Shared among any processes (with relevant permission)

For AIX, npth doesn't work well with (1). You suggested (3), while I proposed (2).
It is true that (2) and (3) would open up some attack vector(s),
but I believe that (2) is smaller, if any.

I fear that a LF yields other problems as well. However, the percent escaping
woyld make it easier to find.

Please first test with a current version - 2.0.30 was released in March, your
2.0.26 is close to 2 years old.

I can't find an explanation why gentoo inserts "-hardfloat". I doubt that this
is willy-nilly and as long as this has not been figured out, there is a
possibility of a different ABI and thus we can't simply alias it. Can you
please work with Kristian or someone else from gentoo to figure this out?

Thanks for binutils link.

I am not sure about the cause for this bug. However it might be fixed either be
2.1.3 (released a few days ago) or libgpg-error 1.23.

Workaround: Use
ggp --export-ownertrust >ot.txt
rm trustdb.gpg
gpg --import-ownertrust <ot.txt

Again, the host is not my invention. I linked it before and I'll do it again:
https://wiki.gentoo.org/wiki/Raspberry_Pi.

Gentoo's cross-compile tool, crossdev, suggests using "-hardfloat-" and "-
softfloat-" in the vendor field.

And here is how binutils handles this (they don't shy away from asterisks):
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/config.bfd

This shows default-cache-ttl and max-cache-ttl being ignored:

$ eval gpg-agent --daemon
$ env | grep GPG
GPG_AGENT_INFO=/tmp/gpg-NFU8a4/S.gpg-agent:17812:1
$ gpg2 -q --decrypt foo.gpg
blah
$ kill -HUP 17812
$ gpg2 -q --decrypt foo.gpg
blah
$ date
Sat Jun 18 11:15:24 JST 2016
$ cat .gnupg/gpg-agent.conf
default-cache-ttl 300
max-cache-ttl 300
$ date
Sat Jun 18 11:24:06 JST 2016
$ gpg2 -q --decrypt foo.gpg
blah

This issue may be related to: T2054

We could bail early if we see something like this.

But since percent-unescaping is supposed to be able to handle arbitrary
characters (and consumers of this data have to percent-unescape anyway), why not
escape the record separator instead of bailing?

Thanks. I apply it to 2.1.

Quite obvious. There are probably a lot of other places which will fail with a
LF in a file name. What do you think of detecting such strange directory names
early and bail out with a fatal error?

D376: 850_0001-scdaemon-add-homedir-to-the-ARGPARSE_OPTS.patch

Awesome, that did the trick!
Many thanks.

Is armv7a-hardfloat-linux-gnu guaranteed to be ABI compatible to some other arm
triplet? If that is the case, I suggest to either drop your(?) invention of
-hardfloat- or, better, to work with the config mainatiners to make sure it is
viewed as an alias.

How does binutils handle this triplet?

If you can describe the user base for that triplet, I may add an exception to
mkheader to get things done faster.

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()?