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.

D369: 860_0001-Core-Add-file_size-support-to-gpgme_data.patch

Since Kleopatra is using data callbacks the total is always 0 so I can't use the
way to calculate percent.

Previously kleopatra used the filesize as total value. This does not work if
total is always 0 and the progress switches based on the current file size. E.g
for a large file the prgress decreases after 1024*1024 bytes have been processed.

I could probably add some weird "if gnupg > 2.1.14 and the file size is >
1024*1024 and the progress is < 1024*1024 expect it to be bytes and otherwise
expect it to be kilobytes." But this is not nice to use API.

My attached patch solves this by giving data callback users the opportunity to
provide GnuPG with the information how much input size it can expect. This makes
total / current workable from the start and everything is fine.

But as we jabbered about you do not like this patch :'-(

Problem not resolved for me as I think the weird handling currently imposed by
GnuPG is definitely not "Easy"

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

I see. We use system() in the random test to re-execute itself. This involves
the shell and thus the problem. Need to uses fork/exec or CreateProcess calls
for that test. I guess this needs to wait until we have moved that to code to
libgpg-error as our portability layer.

This is still a problem on OS X 10.11.5. OS X's System Integrity Protection
"feature" is causing that test failure. If S.I.P is disabled there's no problem.

A similar-looking test failure happens in perl
(https://rt.perl.org/Public/Bug/Display.html?id=126706). Perhaps the diagnosis is
the same here.

The only messing I want to do is to a) not tamper with the user's homedir and b)
not leak any files after I'm done.

For a) a homedir sounds fine. But then I can't use the user's secret keys to
sign other keys.
For b) I tried to rely on existing infrastructure to make my life easier. I
expected it to work because it did for the primary keyring. But GnuPG behaves
inconsistently regarding the primary keyring and the trustdb file. Even more
so, because running gpg a second time just appears to work. That makes gpg not
intuitive to use, I think.

And this is, I guess, the main issue I'm seeing.

You may want to test 1.7.2 instead.

1.7.2 with the fix has been released

2.4.3 has been released and I assume that this works now. Feel free to re-open
if it is not the case.

Please do not mess around with file managed by GnuPG. It is not your business ;-).

I'd strongly suggest to use a temporary home directory and use --import and
--import-ownertrust to add keys.

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.

commit 3f98b1e adds a better fatal error message. Will be released with 1.7.2.

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

Patch applied with commit c52829e for 2.4.3.
Thanks.

Had you a chance to run the suggested test?

Thanks. Changed with commit 678f606 for 2.4.3

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

It has been fixed with commit 4a983e3.

To make it clear: I'm not even trying to sign or encrypt, just send a plaintext
message with attachment also in the clear.

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

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)