Hi Justus,

Thanks for your response. In further testing, I was able to trigger the "FAIL:
gpgtar.scm" during a make check for 2.1.13 (actually "FAIL: gpgtar.test" for
2.1.13 since it's pre-tiny-scheme). In particular, it's vanilla 2.1.13 + your
fix in 8f79c31b. So I think what may be going on is that 8f79c31b didn't
actually fully resolve that problem after all since I've now seen it occur, with
that commit included, in 2.1.13, and in 2.1.14, and in HEAD.

Tbere were two cases where a more specific error was emitted:

In one run, I saw this:

((/private/tmp/gnupg21-20160725-43964-l18ixl/gnupg-2.1.14/tools/gpgtar --gpg
/private/tmp/gnupg21-20160725-43964-l18ixl/gnupg-2.1.14/g10/gpg --gpg-args
--no-permission-warning --always-trust --tar-args --directory=. --decrypt
/tmp/gpgscm-PgAlmV/archive) failed: gpgtar: gpg: [don't know]: invalid packet
(ctb=2d)
gpgtar: gpg: [don't know]: invalid packet (ctb=2a)
gpgtar: error running
'/private/tmp/gnupg21-20160725-43964-l18ixl/gnupg-2.1.14/g10/gpg': exit status 2
) 
FAIL: gpgtar.scm

and in another run I saw this

Checking gpgtar with signature 
((/private/tmp/gnupg21-20160726-74591-maikty/gnupg-2.1.14/tools/gpgtar --gpg
/private/tmp/gnupg21-20160726-74591-maikty/gnupg-2.1.14/g10/gpg --gpg-args
--no-permission-warning --always-trust --tar-args --directory=. --decrypt
/tmp/gpgscm-0U4bUB/archive) failed: gpgtar: gpg: Fatal: zlib inflate problem:
invalid block type
gpgtar: error running
'/private/tmp/gnupg21-20160726-74591-maikty/gnupg-2.1.14/g10/gpg': exit status 2
) 
FAIL: gpgtar.scm

It's also worth noting that I've only been able to trigger the problem on
Jenkins during CI, not locally, so I don't know if the lack of TTY is relevant
or something like that.

I will do the ssh check you requested.

Thanks for letting us know. Unfortunately, we do not test on MacOS yet, but we are working
on that.

I have neither experience with debugging on MacOS, nor do I have access to such a machine.
I'm afraid you are on your own for now.

The ssh test is new, so we need to figure out why it does not work. Please do

  make -C tests/openpgp check TESTS="setup.scm ssh.scm" verbose=2

This lets us see what ssh-add prints to stderr. It might be related to the version of
OpenSSH shipped with the OS.

The API of pyme3 is almost identical to that of pyme, the former being a port to Python3,
while the latter is for Python2. We also added a more idiomatic interface on top of that, but
porting pyme applications should be easy. It is different to the API of pygpgme though.

I don't know exactly when 1.7 will be released, but it is overdue, so I'd say next month.

how different pyme3 with bindings which we will get within 1.7 release? is there
any ETA on releasing 1.7?

That is not a bad commit, that is Werner evolving our software. pygpgme is unmaintained since

2013. My guess is that it cannot cope with the new status code being emitted by GnuPG.

I ran the testsuite myself, and I can reproduce the issue, among many other failures: 24 if I'm
using the GnuPG components from Debian/unstable, 9 if I am using more recent components.

One of them is test_encrypt_to_signonly, which tries to encrypt a mail to a key only usable for
signing, and expects a general error, which all recent versions of GPGME return in this case, but
this was a bug, fixed in GPGME master, which returns the correct error.

Updating pygpgme is out of scope for us. If you merely need any binding, consider using the pyme3
bindings that we merged into GPGME proper, and will release with 1.7. You can also find it on
pypi, it requires GPGME 1.6.x to build.

The way I see it is that the pygpgme bindings and its test suite are way too unmaintained and the
test suite too noisy to demonstrate a bug in GnuPG or GPGME. Feel free to reopen this bug if you
have compelling evidence that we broke something, preferably a small test case not using pygpgme.

The document you cite also states that UID/UAT lines only use field 10.

Also, neither UID nor UAT packets encode an expiration date [0], the way an UID/UAT can expire
is that the self-signature expires [1].

0: https://tools.ietf.org/html/rfc4880#section-5.11
1: https://tools.ietf.org/html/rfc4880#section-5.2.3.3

I do no longer agree with your first problem. Key expiration is different from signature
expiration, the way to quickly generate a key that expires in one year is:

    $ g10/gpg --quick-gen-key quick_test - - 1y

I guess one could argue that if one specifies --default-cert-expire=X when adding an uid, that
the self-signature for the new uid should expire. But to be honest, I doubt that this matches
user expectations.

What would be the use case really? I know that I'll lose access to that mail address in X years
and hence want my uid to expire then.

Fixed in 4ba11251.

How did you create the key? I tried to reproduce it, and my numbers are even funnier:

% gpg2 --list-packets key2
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!

off=0 ctb=95 tag=5 hlen=3 plen=919

:secret key packet:

version 4, algo 1, created 1262304006, expires 0
pkey[0]: [2048 bits]
pkey[1]: [17 bits]
skey[2]: [2046 bits]
skey[3]: [1024 bits]
skey[4]: [1024 bits]
skey[5]: [1016 bits]
checksum: 4197
keyid: 576109131A46786C

off=922 ctb=b4 tag=13 hlen=2 plen=29

:user ID packet: "Test Keyyy <test@example.org>"

off=953 ctb=89 tag=2 hlen=3 plen=311

:signature packet: algo 1, keyid 576109131A46786C

version 4, created 1262304006, md5len 0, sigclass 0x13
digest algo 8, begin of digest 79 38
hashed subpkt 2 len 4 (sig created 2010-01-01)
hashed subpkt 27 len 1 (key flags: 03)
hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2)
hashed subpkt 21 len 5 (pref-hash-algos: 8 9 10 11 2)
hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (keyserver preferences: 80)
subpkt 16 len 8 (issuer key ID 576109131A46786C)
data: [2045 bits]

off=1267 ctb=9d tag=7 hlen=3 plen=920

:secret sub key packet:

version 4, algo 1, created 1262304006, expires 0
pkey[0]: [2048 bits]
pkey[1]: [17 bits]
skey[2]: [2047 bits]
skey[3]: [1024 bits]
skey[4]: [1024 bits]
skey[5]: [1024 bits]
checksum: 4233
keyid: 2D1354FDD1343C83

off=2190 ctb=89 tag=2 hlen=3 plen=287

:signature packet: algo 1, keyid 576109131A46786C

version 4, created 1262304006, md5len 0, sigclass 0x18
digest algo 8, begin of digest 49 47
hashed subpkt 2 len 4 (sig created 2010-01-01)
hashed subpkt 27 len 1 (key flags: 0C)
subpkt 16 len 8 (issuer key ID 576109131A46786C)
data: [2047 bits]

% GNUPGHOME=$(mktemp -d) gpg2 --import key2
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: keybox '/tmp/tmp.vt2HmFYk11/pubring.kbx' created
gpg: /tmp/tmp.vt2HmFYk11/trustdb.gpg: trustdb created
gpg: key 576109131A46786C: public key "Test Keyyy <test@example.org>" imported
gpg: key 576109131A46786C: secret key imported
gpg: Total number processed: 3
gpg: imported: 1
gpg: secret keys read: 3
gpg: secret keys imported: 2

I'd say 'Total number processed' and 'secret keys read' is off by one even if one counts the
subkeys.

Ah, I misunderstood your problem. In the future, please paste all program interactions in one chunk
in the right order. We did merge some changes related to exporting of secret keys, so it may very
well be solved by that.

Thanks for caring :)

I have a possible solution pushed to branch justus/issue1955. The idea is to try
to parse the message with PINENTRY_MODE_CANCEL first, and should that fail, we
retry with the configured pinentry mode. Not sure if that is too hacky, or what
side-effects parsing the message may have that we must not do twice. Werner,
what do you think?

ff71521d9698c7c5df94831a1398e948213af433 is the first bad commit
commit ff71521d9698c7c5df94831a1398e948213af433
Author: Werner Koch <wk@gnupg.org>
Date: Fri May 13 16:24:59 2016 +0200

    gpg: Emit new status line KEY_CONSIDERED.
    
    * common/status.h (STATUS_KEY_CONSIDERED): New.
    * g10/getkey.c: Include status.h.
    (LOOKUP_NOT_SELECTED, LOOKUP_ALL_SUBKEYS_EXPIRED): New.
    (finish_lookup): Add arg R_FLAGS.  Count expired and revoked keys and
    set flag.  Check a requested usage before checking for expiraion or
    revocation.
    (print_status_key_considered): New.
    (lookup): Print new status.
    
    Signed-off-by: Werner Koch <wk@gnupg.org>

:040000 040000 33853092f4376553defb24e39a31bdcbc13c51d2
7da8083e3f39b2fabfe0c3beab0b9f43a2a2cc32 M common
:040000 040000 468469de2419e59efddd718b7b24d5a8cead3005
d2c77b1e1bbab29cd506b29dc359d44c841dbc99 M doc
:040000 040000 044148a54b854a31a0f6ad6605a50a57cc46dfcd
e229f5d63dc27377a7fa1d50ff512a040a389f1f M g10

D378: 864_0001-configure.ac-restore-user-CFLAGS-before-checking-fun.patch

Update patch to cover libraries search (e.g. iconv).

I think the problem is that your key export fails, because you pointed
--homedir at the (presumably) empty directory "%tmp%\_tempKeyring".

The export did not use any filter and tried to export a key as can be seen in
Msg8313 "error receiving key from agent"
The import itself also stated no errors as it can be seen in T2355 (dranft on May 12 2016, 03:00 PM / Roundup), but this
imported secret key cannot be used (or exported) anymore.
Also important: This is no longer reproducible in 2.1.14 (which might be enough
to set the bug to fixed)

I don't believe this demonstrates a bug.

I think the problem is that your key export fails, because you pointed --homedir at the (presumably)
empty directory "%tmp%\_tempKeyring". This leads to the not very helpful error message about the
eof. If the export were successful, gpg would have written the key to stdout.

For reference, here is what I tried. First GNUPGHOME points to a home with the key I want to export:

    $ echo $GNUPGHOME
    /tmp/tmp.T7I4M9RIc3
    $ g10/gpg --list-keys alpha
    gpg: please do a --check-trustdb
    pub   dsa1024 1999-03-08 [SCA]
          A0FF4590BB6122EDEF6E3C542D727CC768697734
    uid           [ unknown] Alfa Test (demo key) <alfa@example.net>
    uid           [ unknown] Alpha Test (demo key) <alpha@example.net>
    uid           [ unknown] Alice (demo key)
    sub   elg1024 1999-03-08 [E]

You need some kind of pinentry program, because you may be asked for the current passphrase or an
export passphrase:

    $ cat $GNUPGHOME/gpg-agent.conf
    pinentry-program /usr/bin/pinentry-x11

Now export the key:

    $ g10/gpg --export-secret-keys alpha >/tmp/alpha.gpg

Now I create an empty home, and import the key in batch mode:

    $ export GNUPGHOME=$(mktemp -d)
    $ g10/gpg --batch --import /tmp/alpha.gpg
    gpg: keybox '/tmp/tmp.bL2caQmZri/pubring.kbx' created
    gpg: /tmp/tmp.bL2caQmZri/trustdb.gpg: trustdb created
    gpg: key 2D727CC768697734: public key "Alfa Test (demo key) <alfa@example.net>" imported
    gpg: key 2D727CC768697734: secret key imported
    gpg: Total number processed: 3
    gpg:               imported: 1
    gpg:       secret keys read: 3
    gpg:   secret keys imported: 2

Could you please check if that works for you?

Fixed in d9839c9d.

On 2016-07-19, Justus Winter via BTS wrote:

Ok, I pushed a fix related to this problem 45bb9a2a, this had the amusing effect of
reversing the behavior:

% rm -f $GNUPGHOME/tofu.db ; ( g10/gpg --verify --status-fd=1 /tmp/testmsg
)2>/dev/null | grep TOFU_STATS
[GNUPG:] TOFU_STATS 1 0 0 none
[GNUPG:] TOFU_STATS 2 1 0 auto 0 0
[GNUPG:] TOFU_STATS_LONG Verified 1 message signed by "Alpha Test (demo key)
<alpha@example.net>"%0Ain the past 0~seconds.
[GNUPG:] TOFU_STATS 2 1 0 auto 0 0
[GNUPG:] TOFU_STATS_LONG Verified 1 message signed by "Alice (demo key)"%0Ain the
past 0~seconds.

The difference stems from tofu_register setting already_verified to 0 for the first
uid, and to 1 for the second. In the former case, show_statistics is asked to ignore
the current message.

I guess the intention was to handle the very first message differently, but now we
are handling the first *uid* upon receiving the first message differently instead.
I'm not sure how to proceed, hence reassigning to Neal.

This is a GnuPG problem:

teythoon@europa ~/repos/g10/gpgme/obj/tests (git)-[master] % rm $GNUPGHOME/tofu.db && ( gpg2 --verify --with-
colons --status-fd=1 /tmp/testmsg )2>/dev/null | grep TOFU_STATS
[GNUPG:] TOFU_STATS 1 0 0 auto
[GNUPG:] TOFU_STATS_LONG Verified 0 messages signed by "Alfa Test (demo key) <alfa@example.net>".
[GNUPG:] TOFU_STATS 1 0 0 none
[GNUPG:] TOFU_STATS 1 0 0 none
teythoon@europa ~/repos/g10/gpgme/obj/tests (git)-[master] % rm $GNUPGHOME/tofu.db && ( gpg2 --verify --with-
colons --status-fd=1 /tmp/testmsg && gpg2 --verify --with-colons --status-fd=1 /tmp/testmsg && sleep 1 && gpg2 -
-verify --with-colons --status-fd=1 /tmp/testmsg )2>/dev/null | grep TOFU_STATS
[GNUPG:] TOFU_STATS 1 0 0 auto
[GNUPG:] TOFU_STATS_LONG Verified 0 messages signed by "Alfa Test (demo key) <alfa@example.net>".
[GNUPG:] TOFU_STATS 1 0 0 none
[GNUPG:] TOFU_STATS 1 0 0 none
[GNUPG:] TOFU_STATS 1 0 0 none
[GNUPG:] TOFU_STATS 1 0 0 none
[GNUPG:] TOFU_STATS 1 0 0 none
[GNUPG:] TOFU_STATS 2 1 0 auto 1 1
[GNUPG:] TOFU_STATS_LONG Verified 1 message signed by "Alfa Test (demo key) <alfa@example.net>"%0Ain the past
1~second.
[GNUPG:] TOFU_STATS 2 1 0 auto 1 1
[GNUPG:] TOFU_STATS_LONG Verified 1 message signed by "Alpha Test (demo key) <alpha@example.net>"%0Ain the past
1~second.
[GNUPG:] TOFU_STATS 2 1 0 auto 1 1
[GNUPG:] TOFU_STATS_LONG Verified 1 message signed by "Alice (demo key)"%0Ain the past 1~second.

Looks like other folks are experiencing same issues:
https://lists.gnupg.org/pipermail/gnupg-users/2016-March/055421.html

My problems are resolved. I have not encountered a problem since your last
fixes. Although I sometimes have to reenter pin so I think the errors still
occur occassionally but gnupg recovers.

Thanks.

It is handled in scdaemon (not in g10/keyedit.c).

When the keysize is different, it changes key attribute automatically.
For 2.1, it was fixed by f10b427d0e2be333776fee2df8150145da36e587 on 2015-09-07
which is in 2.1.8.

This has nothing to do with faking time one way or another.

You are reporting two problems. In the future, please create two issues.

I agree with your first problem, even though there is additional syntax for specifying the
expiration date with --quick-gen-key. This is easy to fix.

Your second problem is less clear. First of all, your command line makes no sense. --
default-sig-expire only affects signatures over data. Furthermore, user ids do not
expire, merely the (self-)signatures may do so. Do you want that?

I do consider it a bug, at least because we did not signal an error to ssh-add.
Fortunately, this was easy to fix.

Fixed in 270f7f7b.

I don't have time to look at this immediately, but it looks related to Werner's
recent change to the tofu db code.

So the key listing is enclosed in tofu_{begin,end}_batch_update:

#0 tofu_begin_batch_update () at ../../g10/tofu.c:389
#1 0x0000000000452515 in public_key_list (ctrl=0x715870, list=0x0,

locate_mode=0) at ../../g10/keylist.c:137

#2 0x000000000040e496 in main (argc=0, argv=0x7fffffffdc08)

at ../../g10/gpg.c:4153

#0 tofu_begin_batch_update () at ../../g10/tofu.c:389
#1 0x0000000000452515 in public_key_list (ctrl=0x715870, list=0x0,

locate_mode=0) at ../../g10/keylist.c:137

#2 0x000000000040e496 in main (argc=0, argv=0x7fffffffdc08)

    at ../../g10/gpg.c:4153

Then an transaction is started on the email and key db:

#0 begin_transaction (db=0x733bc0, only_batch=0) at ../../g10/tofu.c:278
#1 0x0000000000497365 in record_binding (dbs=0x71cf40,

fingerprint=0x71c980 "362D3527F53AAD1971AAFDE658859975EE37CF96", 
email=0x71cf60 "testing (insecure!)", 
user_id=0x71ab30 "Testing (insecure!)", policy=TOFU_POLICY_AUTO, 
show_old=0) at ../../g10/tofu.c:1202

#2 0x0000000000498e36 in get_trust (dbs=0x71cf40, pk=0x71a8a0,

fingerprint=0x71c980 "362D3527F53AAD1971AAFDE658859975EE37CF96", 
email=0x71cf60 "testing (insecure!)", 
user_id=0x71ab30 "Testing (insecure!)", may_ask=0) at ../../g10/tofu.c:2182

#3 0x000000000049a44d in tofu_get_validity (ctrl=0x715870, pk=0x71a8a0,

user_id=0x71ab30 "Testing (insecure!)", may_ask=0) at ../../g10/tofu.c:2946

#4 0x000000000048f4b2 in tdb_get_validity_core (ctrl=0x715870, pk=0x71a8a0,

uid=0x71aac0, main_pk=0x71a8a0, sig=0x0, may_ask=0)
at ../../g10/trustdb.c:1074

#5 0x000000000048cd9d in get_validity (ctrl=0x715870, pk=0x71a8a0,

uid=0x71aac0, sig=0x0, may_ask=0) at ../../g10/trust.c:338

#6 0x000000000048caeb in uid_trust_string_fixed (ctrl=0x715870, key=0x71a8a0,

uid=0x71aac0) at ../../g10/trust.c:154

#7 0x00000000004544bc in list_keyblock_print (ctrl=0x715870,

keyblock=0x71a9c0, secret=0, fpr=0, listctx=0x7fffffffd560)
at ../../g10/keylist.c:950

#8 0x00000000004567aa in list_keyblock (ctrl=0x715870, keyblock=0x71a9c0,
---Type <return> to continue, or q <return> to quit---

secret=0, has_secret=0, fpr=0, listctx=0x7fffffffd560)
at ../../g10/keylist.c:1604

#9 0x00000000004533bc in list_all (ctrl=0x715870, secret=0, mark_secret=0)

at ../../g10/keylist.c:556

#10 0x000000000045254e in public_key_list (ctrl=0x715870, list=0x0,

locate_mode=0) at ../../g10/keylist.c:143

#11 0x000000000040e496 in main (argc=0, argv=0x7fffffffdc08)

    at ../../g10/gpg.c:4153

... and later ended, but since !! batch_update, it is not actually committed.

Now when tofu_end_batch_update is called and batch_update drops to zero, it iterates
over db_cache and commits all transactions using end_transaction, but db_cache is
empty. This is actually not that surprising, because the only place I see db_cache
being populated is in tofu_closedbs, a few lines after the failing assertion.

Fixed in f4742493.

For the T2238, it was backported in effect (not intentional, though).

1.4: ca1fc59
2.0: 1c15136

The attached patch was lost, but is available at
https://gist.githubusercontent.com/fornwall/751acc6fbe9eb8e703c60c222a2dba33/raw/ece6b6
8fe0346b2039be6ba3323e5e29e25685ef/configure.ac.patch

You should better use --recv-key if you already know the fingerprint. Anyway,
this is a regression and will be fixed for 2.1.14 with commit 0342369. Thanks.

You are welcome. If my bad English makes it difficult, here is another document.

http://web.monkeysphere.info/doc/trust-models/
You can find the explanation:

So "full" ownertrust on a key is only meaningful as long as there is a trust
path to some User ID on that key already. "ultimate" ownertrust is meaningful
anyway, because presumably you control that key.

Ok I think I get it. I appreciate you taking the time to explain it.
Thanks.

Ok I think I get it now. Thank you for explaining it to me. I appreciate it

Adding "ultimate" trust means: you are specifying it's your own key. GnuPG
doesn't check if your own key is signed by another your own key (or you really
have corresponding private key).

Let me explain the validity of public keys.

• Start with a set of key(s) with "ultimate" trust. Ultimate keys are all valid,

put them to a set of valid keys.

• Pick a key from valid keys. Collect all keys signed by this key (locally or

globally), it's all valid. Put them to a set of valid keys.

Next, it checks "full" or "marginal" trust to a public key.

• Start with the set of public keys which are valid (by the computation so far).
• Pick a key from the set. If it has "full" trust, mark all keys which are

signed by this key as it's reachable by "full" trust.

• If it has "marginal" trust, mark all keys which are signed by this key as it's

reachable by "marginal" trust adding a point.

• Scan all marked key. If it can be reachable by "full" trust. It will be in

the set of valid keys. If it can be reachable by "marginal" trust by 3
(default) different keys, it will be also in the set of valid keys.

• Add checked keys to the set of valid keys. And apply(repeat) this procedure

recursively, to the newly added valid keys. Don't repeat too far. Stop if it
goes 5 (default) times.

In other words, adding trust (by --edit-key) to a valid key makes it possible
for another key to be validated by that key. Adding trust (by --edit-key) to an
invalid key doesn't make that invalid key valid. (If it's "full" or "marginal".)

But why does marking it as ultimately trusted ignore that it was never signed?

I forgot to apply Daiki's patch. Done now with commit 82b90ee.

I won't work on the other mentioned change now and this commit is actually about
a regression. Thus bumping to testing.

If you want to use a different home directory and a /run/user based socket, you
need to create a directory for that socket first. We don't do this on-the-fly
to avoid cluttering the /run/user with directories.

With GNUPGHOME set, you only need to run

gpgconf --create-socketdir

man gpgconf

We won't fix that bug but remove the entire file as indicated by the #warning.

In T2403 (gniibe on Jul 13 2016, 10:53 AM / Roundup), I said wrongly. It's tests/Makefile.in.
Here is tests/Makefile.am modified.

Attached is modified Makefile.in, so that 'make check' can run t-fork test program.

Yes - I install the patched Npth library into the System. Can you please give
me the expected tests/Makefile.in and tests/Makefile.am.

There are two different concepts: trust and validity.

It makes nothing when you edit a key to mark "full" trust which has unknown
validity. (A key's validity should be valid.)

Marking trust (full or marginal) to a valid key makes validation of other keys
will be possible by that key.

In the beginning, you can make a key valid by signing (sign or lsign) by your
ultimately trusted key.

This issue still stands with 2.1.13. It may be a bug or it may be a
documentation issue but I really do need this to be investigated and resolved,
please.

If this is unsupported by GnuPG 2.1 and unlikely to change, at least the
documentation should be updated.

Please manually edit tests/Makefile.in and tests/Makefile.am, so that you can
compile and run t-fork test program.
Have you install the patched Npth library into the system, so that you can use
patched Npth library with GnuPG?

Yes - I install teh patch and build the Npth library.

make check

Making check in src
make[1]: Entering directory '/develop/npth-1.2/src'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory '/develop/npth-1.2/src'
Making check in tests
make[1]: Entering directory '/develop/npth-1.2/tests'
make check-TESTS
make[2]: Entering directory '/develop/npth-1.2/tests'
PASS: t-mutex

PASS: t-thread

All 2 tests passed

make[2]: Leaving directory '/develop/npth-1.2/tests'
make[1]: Leaving directory '/develop/npth-1.2/tests'
make[1]: Entering directory '/develop/npth-1.2'
make[1]: Leaving directory '/develop/npth-1.2'

Thanks a lot.

5636336: 23330877: sem_post(0xF1299434) Err#13 EACCES

This is the problem.
Did you really got success by "make check" of Npth library?
Have you installed the patched Npth library?
Please confirm.

5636336: 23330877: sigprocmask(2, 0xF02E6968, 0x2FF1E3E0) = 0
5636336: 23330877: _sigaction(31, 0x2FF1E438, 0x00000000) = 0
5636336: 23330877: thread_setmymask_fast(0x00000000, 0x00000000,
0x00000000, 0x1164003D, 0x0001F0B0, 0x00000000, 0xE0283800, 0x00000000) =
0x00000000
5636336: 23330877: sigprocmask(2, 0xF02E6968, 0x2FF1E3E0) = 0
5636336: 23330877: _sigaction(2, 0x2FF1E438, 0x00000000) = 0
5636336: 23330877: thread_setmymask_fast(0x00000000, 0x00000000,
0x00000000, 0x1164003D, 0x0001F0B0, 0x00000000, 0xE0283800, 0x00000000) =
0x00000000
5636336: 23330877: sigprocmask(2, 0xF02E6968, 0x2FF1E3E0) = 0
5636336: 23330877: _sigaction(15, 0x2FF1E438, 0x00000000) = 0
5636336: 23330877: thread_setmymask_fast(0x00000000, 0x00000000,
0x00000000, 0x1164003D, 0x0001F0B0, 0x00000000, 0xE0283800, 0x00000000) =
0x00000000
5636336: 23330877: thread_setmymask_fast(0x60004003, 0x00000000,
0x00000000, 0x0000D032, 0x0001F0B0, 0x00000000, 0xE0283800, 0x00000000) =
0x00000000
5636336: 23330877: sem_post(0xF1299434) Err#13 EACCES
5636336: 23330877: kwrite(2, " A s s e r t i o n f a".., 18) = 18
5636336: 23330877: kwrite(2, " _ _ E X", 4) = 4
5636336: 23330877: kwrite(2, " , f i l e ", 8) = 8
5636336: 23330877: kwrite(2, " n p t h . c", 6) = 6
5636336: 23330877: kwrite(2, " , l i n e 1 4 9\n", 11) = 11
5636336: 23330877: kfcntl(1, F_GETFL, 0x1164003D) = 67108865
5636336: 23330877: kfcntl(2, F_GETFL, 0x1164003D) = 67108865
5636336: 23330877: _getpid() = 5636336
5636336: 23330877: thread_kill(-1, 6) = 0
5636336: Received signal #6, SIGABRT [default]
5636336: * process killed *
6815982: 16842893: thread_setmymask_fast(0x00000000, 0x00000000, 0x00000000,
0xD0551900, 0x00000000, 0x1101008D, 0x1101008D, 0x00000000) = 0x00000000
6815982: Received signal #20, SIGCHLD [default]
6815982: 16842893: close(3) = 0
6815982: 16842893: sigprocmask(2, 0x20003AC8, 0x00000000) = 0
6815982: 16842893: __loadx(0x04400000, 0x2FF22080, 0x00000800, 0xD05516A4,
0x00000000) = 0x00000000
6815982: 16842893: kfcntl(1, F_GETFL, 0x1101008D) = 67110922
6815982: 16842893: kfcntl(2, F_GETFL, 0x1101008D) = 67110922
6815982: 16842893: _exit(0)

Thank you for your testing. The patch is to the repository. You need manual
edit to tests/Makefile.am which add t-fork as a test program. I think that
"make check" should go successfully for Npth with the patch.

Could you please trace the gnupg-agent with children processes?
If you are using truss, -f option (follow childres), please.

That is not easy to change. By design gpg-agent generates the key and does not
return it (except for a hack to support --export-secret-key).

2,1 has the goal to replace 1.4 and thus I see the need to support creating a
key w/o string it in private-keys-v1.d/.