When I apply the patch:

patch -p1 -i npth.aix.patch

patching file configure.ac
patching file src/npth.c
patching file tests/Makefile.am
Hunk #1 FAILED at 40.
1 out of 1 hunk FAILED -- saving rejects to file tests/Makefile.am.rej
patching file tests/t-fork.c

1. cat tests/Makefile.am.rej
   • 40,45 **** AM_CPPFLAGS = -I../src -D_POSIX_C_SOURCE=200112L AM_LDFLAGS = LDADD = ../src/libnpth.la $(LIBSOCKET) $(LIB_CLOCK_GETTIME) endif noinst_HEADERS = t-support.h
   • 40,46 ---- AM_CPPFLAGS = -I../src -D_POSIX_C_SOURCE=200112L AM_LDFLAGS = LDADD = ../src/libnpth.la $(LIBSOCKET) $(LIB_CLOCK_GETTIME)

+ TESTS += t-fork

  endif

  noinst_HEADERS = t-support.h

I make the lib and compile gnupg but the gpg-agent don't start and the tests
failed.

#/develop/gnupg-2.1.13/agent/gpg-agent --version
gpg-agent (GnuPG) 2.1.13
libgcrypt 1.7.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later https://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.

But the Agent dont start as daemon.

statx("/root/.gnupg/S.gpg-agent", 0x2FF22848, 76, 0) Err#2 ENOENT
bind(3, 0x20013A38, 26) = 0
chmod("/root/.gnupg/S.gpg-agent", 0700) = 0
listen(3, 5) = 0
kfcntl(0, F_GETFL, 0x111D00E9) = 67110922
kfcntl(1, F_GETFL, 0x111D00E9) = 67110922
kfcntl(2, F_GETFL, 0x111D00E9) = 67110922
sigprocmask(0, 0xF02E6968, 0xF02E6970) = 0
kfork() = 5767248
thread_setmymask_fast(0x00000000, 0x00000000, 0x00000000, 0xD0551900,
0x00000000, 0x111D00E9, 0x111D00E9, 0x00000000) = 0x00000000

Received signal #20, SIGCHLD [default]

close(3) = 0
sigprocmask(2, 0x20003AC8, 0x00000000) = 0
__loadx(0x04400000, 0x2FF22080, 0x00000800, 0xD05516A4, 0x00000000) = 0x00000000
kfcntl(1, F_GETFL, 0x111D00E9) = 67110922
kfcntl(2, F_GETFL, 0x111D00E9) = 67110922
_exit(0)

We got it for 2.1: -f or --recipient-file

The only reason I can see that scdaemon is not started by gpg-agent are
processes which run before a login, for example from PAM. But then the
autostart feature probably not needed.

Fixed in the repo STABLE-BRANCH-1-4.
Forward ported to STABLE-BRANCH-2-0.
It's not in master (2.1).

hm, if there's a guarantee that scdaemon will only ever be launched as a
subprocess from gpg-agent, then maybe we don't need it.

If there's ever any expectation that some other program will launch scdaemon,
then it would be nice to use the unified launch mechanism provided by gpgconf.

Thank you for your checking of libs.
Failure of gpg-agent causes many errors.
One possible cause of gpg-agent's error is Npth. I have a patch for AIX:
https://lists.gnupg.org/pipermail/gnupg-devel/2016-June/031264.html

I'm pushing this change today to Npth repository.

There isn't an NFS file System on the Server.
It's possible that the lib's have issues but I compile the requsite lib's new
and I receive no Errors when I run the Tests.
I think the LIBPATH is OK, e.g. ./g10/gpg can find all lib's:

ldd ./g10/gpg
./g10/gpg needs:

/usr/lib/libc.a(shr.o)
/usr/lib/libpthread.a(shr_xpg5.o)
/usr/local/lib/libgpg-error.a(libgpg-error.so.0)
/usr/lib/libintl.a(libintl.so.1)
/usr/local/lib/libgcrypt.a(libgcrypt.so.20)
/usr/local/lib/libassuan.a(libassuan.so.0)
/usr/lib/libbz2.a(libbz2.so.1)
/unix
/usr/lib/libcrypt.a(shr.o)
/usr/lib/libpthreads.a(shr_comm.o)
/opt/freeware/lib/libgcc_s.a(shr.o)
/usr/lib/libiconv.a(shr4.o)

I looked T1779, and it failed just like this
report, with an NFS-v3 mounted file system.
Socket to gpg-agent doesn't work if it's on NFS file system.

I think that your installation of libgcrypt, libgpg-error, etc. has some issues.
Please check the installation of libgcrypt, libgpg-error, etc.

You would need to setup LIBPATH environment variable, if it's not installed to
the standard place.

Reference:
https://www.postgresql.org/message-id/52EF20B2E3209443BC37736D00C3C1380A6E79FE%40EXADV1.host.magwien.gv.at

Yes - the HOME was / but I change it to /root and now I recieve the following
Output (only failed):
.
.
.
make[3]: Entering directory '/develop/gnupg-2.1.13/tests/openpgp'
version.test: starting the gpg-agent failed
FAIL: version.test

> Hash algorithm MD5 is not installed (not an error)

PASS: mds.test
FAIL: decrypt.test
FAIL: decrypt-dsa.test
FAIL: sigs.test
FAIL: sigs-dsa.test
FAIL: encrypt.test
FAIL: encrypt-dsa.test
FAIL: seat.test
FAIL: clearsig.test
FAIL: encryptp.test
FAIL: detach.test
FAIL: armsigs.test
FAIL: armencrypt.test
FAIL: armencryptp.test
FAIL: signencrypt.test
FAIL: signencrypt-dsa.test
FAIL: armsignencrypt.test
FAIL: armdetach.test
FAIL: armdetachm.test
FAIL: detachm.test
FAIL: genkey1024.test
FAIL: conventional.test

> IDEA FAIL: conventional-mdc.test

multisig.test: valid is invalid (sig_sl_valid)
FAIL: multisig.test
verify.test: verify of msg_ols_asc failed
verify.test: verify of msg_cols_asc failed
verify.test: verify of msg_sl_asc failed
verify.test: verify of msg_olsols_asc_multiple failed
verify.test: verify of msg_oolss_asc failed
verify.test: verify of msg_cls_asc failed
verify.test: verify of msg_clss_asc failed
verify.test: verify of msg_clsclss_asc_multiple failed
FAIL: verify.test
armor.test: the armored_key_8192 bug is back in town
FAIL: armor.test
import.test: ./bug894-test.asc: import failed (bug 894)
FAIL: import.test
FAIL: ecc.test
PASS: 4gb-packet.test
SKIP: gpgtar.test
use-exact-key.test: : import failed
FAIL: use-exact-key.test
FAIL: default-key.test

> D74C5F22 FAIL: export.test

PASS: finish.test

31 of 34 tests failed
(1 test was not run)

Please report to https://bugs.gnupg.org

Makefile:650: recipe for target 'check-TESTS' failed
make[3]: * [check-TESTS] Error 1
make[3]: Leaving directory '/develop/gnupg-2.1.13/tests/openpgp'
Makefile:773: recipe for target 'check-am' failed
make[2]: * [check-am] Error 2
make[2]: Leaving directory '/develop/gnupg-2.1.13/tests/openpgp'
Makefile:527: recipe for target 'check-recursive' failed
make[1]: * [check-recursive] Error 1
make[1]: Leaving directory '/develop/gnupg-2.1.13/tests'
Makefile:580: recipe for target 'check-recursive' failed
make: * [check-recursive] Error 1

Do you really want to use it? The problem is that you won't have a Pinentry and
some other minor goodies. The better way is to let gpg-agent route command to
scdaemon. For example

  gpg-connect-agent "scd help" /bye

shows scdaemons help.

If I understand correctly, you ran 'make check' by root and root's HOME is '/'.
It is unexpected by the test program. If it works with HOME=/root or some other
value, it's not real failure.

t-stringhelp.c:428: test 2 failed
FAIL: t-stringhelp
PASS: t-timestuff
PASS: t-convert
PASS: t-percent
PASS: t-gettime
PASS: t-sysutils
PASS: t-sexputil

> Known envvars: GPG_TTY(ttyname) TERM(ttytype) DISPLAY(display)
> XAUTHORITY(xauthority) XMODIFIERS GTK_IM_MODULE DBUS_SESSION_BUS_ADDRESS
> QT_IM_MODULE INSIDE_EMACS PINENTRY_USER_DATA(pinentry-user-data)

PASS: t-session-env
PASS: t-openpgp-oid
PASS: t-ssh-utils
PASS: t-mapstrings
PASS: t-zb32
PASS: t-mbox-util
PASS: t-iobuf
PASS: t-strlist
PASS: t-private-keys
PASS: t-ccparray

PASS: t-exechelp

1 of 18 tests failed

Please report to https://bugs.gnupg.org

make: The error code from the last command is 1.

Stop.
make: The error code from the last command is 2.

Stop.
make: The error code from the last command is 2.

Stop.
make: The error code from the last command is 1.

Stop.

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$

Talked to werner about it. The way something like trust-model should be
switchable would be best to handle with profiles.

There is at least one profile planned for EasyGPG. Something like "Silent" or
automated. Riseup and VSNFD will probably also want to create profiles.

I think apply-defaults could be extended for this with a defaults file for each
profile.
Then something like:

gpgconf --list-defaults

    List all available default files.

Where the output format could be similar to list-components.
name:description:filename:

filename is the path to the config file.

Then --apply-defaults could be extended to take an optional filename as an
argument. (Like --list-config, --check-config)

With --dry-run it should only check if all the settings marked as no-change are
set correctly and indicate it through the return code.

For EasyGPG I think a config file could be:

• gpg-agent max-cache-ttl [change] 30758400 gpg-agent default-cache-ttl [change] 30758400 gpg trust-model [no-change] tofu+pgp gpg auto-key-retrieve [change] gpg auto-key-locate [change] local,wkd,dane,pka,cert,keyserver

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

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.

Fixed in 2.1.13.

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.

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

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

(that last comment was with 2.1.13)

fwiw, when i'm on a network that doesn't support IPv6, i get this:

0 dkg@alice:~$ gpg --send $KEYID
gpg: sending key REDACTED to hkps://hkps.pool.sks-keyservers.net
gpg: keyserver send failed: Invalid argument
gpg: keyserver send failed: Invalid argument
2 dkg@alice:~$

in dirmngr's logs:

2016-06-17 19:30:17 dirmngr[27999.2] DBG: gnutls:L3: ASSERT: mpi.c:246
2016-06-17 19:30:17 dirmngr[27999.2] DBG: gnutls:L5: REC[0x7f61f400fc10]:
Allocating epoch #0
2016-06-17 19:30:17 dirmngr[27999.2] can't connect to '2001:ba8:1f1:f2d4::2':
Invalid argument
2016-06-17 19:30:17 dirmngr[27999.2] error connecting to
'https://[2001:ba8:1f1:f2d4::2]:443': Invalid argument
2016-06-17 19:30:17 dirmngr[27999.2] DBG: gnutls:L5: REC[0x7f61f400fc10]: Start
of epoch cleanup
2016-06-17 19:30:17 dirmngr[27999.2] DBG: gnutls:L5: REC[0x7f61f400fc10]: End of
epoch cleanup

I think this instance of dirmngr was started on a network that has both IPv4 and
IPv6.

if i do:

     gpg-connect-agent --dirmngr killdirmngr /bye

and then try the --send again, it goes through fine.

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

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

thank you

then wikipedia must be corrected too

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.

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.

Fixed for master (2.1) with commit 5ddccf4

OpenPGP uses "Elgamal" and Taher Elgamal wants his name and the
algorithm to be spelled with lowercase 'g'.

You are right with the inconsistencies between "key server" and
"keyserver".

from wikipedia
ElGamal encryption, an asymmetric key encryption algorithm for public-key cryptography
ElGamal signature scheme, a digital signature scheme
Taher Elgamal (born 1955), Egyptian cryptographer

you are right, but i was and am referring to his cryptography work

gpg --help
--send-keys export keys to a key server
--recv-keys import keys from a key server
--search-keys search for keys on a key server
--refresh-keys update all keys from a keyserver