Actually the specs does not say anything about the valid range of the values.

However, gpg uses unsigned long for CURRENT and TOTAL in the progress status
lines for decryption. Unfortunatley the WHAT value is set to the filename and
thus there is no easy way to determine in GPGME how CURRENT and TOTAL are used.

The best solution I can see is to keep CURENT and TOTAL in gpg below 2^31. This
can be done by switching from bytes to KiB and MiB before the 2^31 limit is
reached. I checked GPA and it should not chnage anything, due to

    gtk_progress_bar_set_fraction (GTK_PROGRESS_BAR (pbar),
				   (gdouble) current / (gdouble) total);

CRL detection is not really important. But detection of binary data is so that I
can properly handle .pgp and .gpg file extensions.

Detached signatures are also important so that I can look / guess for the signed
data and setup the verify operation accordingly or handle it in the GUI if no
Data is found. Maybe we can use flags for this so we don't break the current
behaviror that does not distinguish between detached signatures?

Fixed in 4711a1e1.

Quoting Ben McGinnes (2016-05-11 19:54:21)

On Wed, May 11, 2016 at 12:44:00PM +0000, Justus Winter via BTS wrote:

Justus Winter <justus@g10code.com> added the comment:

I have integrated the Python bindings into our build system. See branch
'justus/pyme3'.

Open issues:

• (API) Change the name of the Python module. Currently it is named 'pyme',

shouldn't we use 'gpgme' instead?

No, simply because other (abandoned) attempts at writing wrappers for
GPGME already exist in the Python ecosystem. If we rename a module to
match the name of an existing one this will break things somewhere.
It also makes us no different from poor Isis Lovecruft who selected
the name gnupg for her fork of python-gnupg, but the original was
always imported as just gnupg so when she increased the version number
of her fork she broke a *lot* of things in other people's code.

That's also why the entirely new thing I've called GPyGME, not just to
play word games with Pygmy, but also because the name is not used by
any existing Python module.

I have integrated the Python bindings into our build system. See branch
'justus/pyme3'.

Open issues:

• (API) Change the name of the Python module. Currently it is named 'pyme',

shouldn't we use 'gpgme' instead?

• (API) One has to hand 'bytes' objects to pyme where 'char *' is expected. We

should make SWIG magically encode strings as utf-8 instead.

• Documentation. Needs to be build, likely updated, and installed. Ben was

thinking about using another tool for this. Needs investigation.

• No test suite.
• 'lang/python/examples/simple.py' segfaults.

Hmm, it is not about the maintainer mode...

Justus, can you take care of this?

Thank you! All set.

GnuPG 2.1.11 will print PROGRESS lines which allows in connection with
--exit-on-status-write-error to use that correctly. We should add that option
to gpg invocation of gpgme, though.

I've just disabled the unit tests in Kleopatra that expose this bug.
The tests should be renabled depending on a version check for a version of gpgme
where the problems are fixed.

I've searched for the context in question and it turns out the last 1000 lines
are not nearly enough to follow it.

So here is the full log of that run.

I can still see the asserts and segfaults when running the tests in gdb or with
logging enabled. So it's not a heisenbug ;-) (Although I was never able to get a
backtrace from kleopatras unit test. That test passed when running in gdb)

Do you want me to provide you with logs?

Here is an example segfault:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffe50f01700 (LWP 25135)]
0x00007ffff7babfe3 in _gpgme_wait_on_condition (ctx=ctx@entry=0x7fff6c0070e0,
cond=0x6a8844002920, cond@entry=0x7fff6c007f20,

op_err_p=op_err_p@entry=0x0) at wait-private.c:155

155 if (cond && *cond)
(gdb) bt
#0 0x00007ffff7babfe3 in _gpgme_wait_on_condition
(ctx=ctx@entry=0x7fff6c0070e0, cond=0x6a8844002920, cond@entry=0x7fff6c007f20,

op_err_p=op_err_p@entry=0x0) at wait-private.c:155

#1 0x00007ffff7bb3236 in gpgme_op_keylist_next (ctx=0x7fff6c0070e0,
r_key=r_key@entry=0x7ffe50f00ef8) at keylist.c:996
#2 0x00000000004010de in start_keylist (arg=<optimized out>) at
t-thread-keylist-verify.c:62
#3 0x00007ffff798c0a4 in start_thread (arg=0x7ffe50f01700) at pthread_create.c:309
#4 0x00007ffff76c104d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Attached is the corresponding gpgme-log (issue-2092-gpgme-log-1.txt)

Needs to be run under GPMGE_DEBUG but I bet that this well defeat the bug.

Sorry, we can't change the type because that would be an ABI break. Well, on
platforms with sizeof(time_t) == sizeof(long) we could use time_t there but for
the application programmer that does not help because assigning to a time_t var
first will still be required for portability.

You are right that this is a bug because internally we use time_t and at least
for Windows we will evntually run into problems.

Back in 2003 we went with long int because that is on all 32 bit platforms
sufficient to express OpenPGP timestamps which are 32 bit. Fortunately on
almost all 64 bit Unix platforms a long int is 64 bit and would also allow us to
express timestamps after 2106 and avoid ABI problems due to different time_t
like we have with off_t. Later, when we came up with gpgsm we gave up our hope
for a 64 bit time_t on 32 bit glibc systems and started to use a string instead
of a scalar. With 64 bit Windows things got even more complicated becuase tehre
a long is still 32 bit. Thus there is no clear way forward even if we decide to
break the ABI: Use time_t or a string?

With the current gpgme and gnupg master things should be a bit better.

Can you please ask on gnupg-devel for help?

ANy news?

Debug message are for debugging and thus you need access to the source.
I'll see what I can do regarding better error messages for signing.

Ok I found why it did not work on a system:

[pid 6507] write(7, "OPTION pinentry-mode=loopback", 29) = 29
[pid 6507] write(7, "\n", 1) = 1
[pid 6507] read(7, "ERR 67108924 Not supported <GPG Agent>\n", 1002) = 39
[pid 6507] brk(0x7f87645c0000) = 0x7f87645c0000
[pid 6507] write(2, "gpg: setting pinentry mode 'loopback' failed: Not
supported", 59) = 59

This is caused by a gpg-agent running with DISPLAY=... set.

Imho there's room for improvement regarding error messages/trace messages:
'general error' is unusable.
Also all those hex-codes in the tracing with no explanations and pointers to
objects that tell you nothing is not helping.

Werner Koch <wk@gnupg.org> added the comment:

A brief check shows that the pinentry mode is passed to the egine for decrypt
and sign. Please double check your code that you set the pinentry mode for

the

conext before signing. You should also set GPGME_DEBUG=4:/foo/bar/logfile for

a

log.

I found that on some systems it works and on some it doesn't.

working:
ii gnupg 1.4.18-7
ii gnupg-agent 2.1.4-1
ii gnupg2 2.1.4-1
ii libgpgme++2 4:4.14.2-2+b1
ii libgpgme11:amd64 1.5.5-2
ii libgpgme11-dev 1.5.5-2
ii python-gnupginterface 0.3.2-9.1

failing:
ii gnupg 1.4.18-4
ii gnupg-agent 2.1.6-1
ii gnupg2 2.1.6-1
ii libgpgme++2 4:4.14.2-2+b1
ii libgpgme11:amd64 1.5.5-3
ii libgpgme11-dev 1.5.5-3

Tested it on 3 different debian systems.

When doing an strace, I see the following:

write(1, "85:1060269507::::::e::::::\nfpr::"..., 4096) = -1 EPIPE (Broken pipe)

• SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=25365, si_uid=1000} ---

write(1, "85:1060269507::::::e::::::\nfpr::"..., 4096) = -1 EPIPE (Broken pipe)

• SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=25365, si_uid=1000} ---

write(1, "85:1060269507::::::e::::::\nfpr::"..., 4096) = -1 EPIPE (Broken pipe)

• SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=25365, si_uid=1000} ---

write(1, "85:1060269507::::::e::::::\nfpr::"..., 4096) = -1 EPIPE (Broken pipe)

• SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=25365, si_uid=1000} ---

write(1, "85:1060269507::::::e::::::\nfpr::"..., 4096) = -1 EPIPE (Broken pipe)

• SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=25365, si_uid=1000} ---

write(1, "85:1060269507::::::e::::::\nfpr::"..., 4096) = -1 EPIPE (Broken pipe)

• SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=25365, si_uid=1000} ---

...ad infinitum

So it looks like gpg2 tries to send more data to gpgme but maybe it
closed the file descriptor? Maybe some timeout?

The trace also speaks about an error but I don't know what the number
means:

GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_new: enter: r_ctx=0x7ffce1a86a18
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_new: leave: ctx=0x6a2b40
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_set_passphrase_cb: call: ctx=0x6a2b40,
passphrase_cb=(nil)/(nil)
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_set_pinentry_mode: call: ctx=0x6a2b40,
pinentry_mode=4
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_set_passphrase_cb: call: ctx=0x6a2b40,
passphrase_cb=0x4130c0/0x6a6488
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_new: enter: r_ctx=0x7ffce1a869b8
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_new: leave: ctx=0x694a30
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_op_keylist_start: enter: ctx=0x694a30,
pattern=9101D24C869F57E712BCB6BC435F59B679A28EB6, secret_only=0
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_add_io_cb: call: ctx=0x694a30, fd
5, dir=1 -> tag=0x697670
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_add_io_cb: call: ctx=0x694a30, fd
7, dir=1 -> tag=0x6977d0
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:gpg_io_event: call: gpg=0x6a3bd0,
event 0x7fb66f730eb0, type 0, type_data (nil)
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_op_keylist_start: leave
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_op_keylist_next: enter: ctx=0x694a30
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x697800,
need to check
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x697800,
handler (0x6a3bd0, 7)
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:keylist_colon_handler: call:
ctx=0x694a30, key = (nil), line = tru::0:1437598451:1438634760:3:1:5
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:keylist_colon_handler: call:
ctx=0x694a30, key = (nil), line = pub:u:4096:1:435F59B679A28EB6:1437562181:::-
:::scESC::::::
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:keylist_colon_handler: call:
ctx=0x694a30, key = 0x697830, line =
fpr:::::::::9101D24C869F57E712BCB6BC435F59B679A28EB6:
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:keylist_colon_handler: call:
ctx=0x694a30, key = 0x697830, line =
uid:u::::1437562181::67B02486BE612BD1F799DD1EF250DA9FDB9C601C::pgf test key (pgf
test key) <test@vanheusden.com>:
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:keylist_colon_handler: call:
ctx=0x694a30, key = 0x697830, line =
sub:u:4096:1:3B7DB05915752DE2:1437562181::::::e::::::
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:keylist_colon_handler: call:
ctx=0x694a30, key = 0x697830, line =
fpr:::::::::1D4A144B830EBD875B3A17D73B7DB05915752DE2:
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:keylist_colon_handler: call:
ctx=0x694a30, key = 0x697830, line =
pub:u:4096:1:435F59B679A28EB6:1437562181:::-:::scESC::::::
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:gpg_io_event: call: gpg=0x6a3bd0,
event 0x7fb66f730eb0, type 2, type_data 0x697830
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:keylist_colon_handler: call:
ctx=0x694a30, key = 0x697a70, line =
fpr:::::::::9101D24C869F57E712BCB6BC435F59B679A28EB6:
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:keylist_colon_handler: call:
ctx=0x694a30, key = 0x697a70, line =
uid:u::::1437562181::67B02486BE612BD1F799DD1EF250DA9FDB9C601C::pgf test key (pgf
test key) <test@vanheusden.com>:
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:keylist_colon_handler: call:
ctx=0x694a30, key = 0x697a70, line =
sub:u:4096:1:3B7DB05915752DE2:1437562181::::::e::::::
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:keylist_colon_handler: call:
ctx=0x694a30, key = 0x697a70, line =
fpr:::::::::1D4A144B830EBD875B3A17D73B7DB05915752DE2:
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_op_keylist_next: leave: key=0x697830
(9101D24C869F57E712BCB6BC435F59B679A28EB6)
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_release: call: ctx=0x694a30
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_remove_io_cb: call: data=0x697670,
setting fd 0x5 (item=0x6976a0) done
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_remove_io_cb: call: data=0x6977d0,
setting fd 0x7 (item=0x697800) done
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_signers_clear: call: ctx=0x6a2b40
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_signers_add: enter: ctx=0x6a2b40,
key=0x694bc0 (387FB9C2DE84B200436962A0207A035AD316FA65)
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_signers_add: leave
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_op_encrypt_sign: enter: ctx=0x6a2b40,
flags=0x1, plain=0x695240, cipher=0x696290
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_op_encrypt_sign: check: ctx=0x6a2b40,
recipient[0] = 0x697830 (9101D24C869F57E712BCB6BC435F59B679A28EB6)
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_sig_notation_get: call:
ctx=0x6a2b40, ctx->sig_notations=(nil)
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_add_io_cb: call: ctx=0x6a2b40, fd
5, dir=1 -> tag=0x693e10
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_add_io_cb: call: ctx=0x6a2b40, fd
9, dir=1 -> tag=0x693f70
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_add_io_cb: call: ctx=0x6a2b40, fd
12, dir=0 -> tag=0x693fd0
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:gpg_io_event: call: gpg=0x6a3bd0,
event 0x7fb66f730eb0, type 0, type_data (nil)
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x694000,
need to check
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x694000,
handler (0x695240, 12)
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_data_outbound_handler: enter:
dh=0x695240, fd=0xc
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_data_outbound_handler: leave
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x694000,
need to check
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x694000,
handler (0x695240, 12)
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_data_outbound_handler: enter:
dh=0x695240, fd=0xc
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_remove_io_cb: call:
data=0x693fd0, setting fd 0xc (item=0x694000) done
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_data_outbound_handler: leave
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693e40,
need to check
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693e40,
handler (0x6a3bd0, 5)
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693e40,
need to check
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693e40,
handler (0x6a3bd0, 5)
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693fa0,
need to check
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693fa0,
handler (0x696290, 9)
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_data_inbound_handler: enter:
dh=0x696290, fd=0x9
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_data_inbound_handler: leave
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693e40,
need to check
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693e40,
handler (0x6a3bd0, 5)
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693e40,
need to check
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693e40,
handler (0x6a3bd0, 5)
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693fa0,
need to check
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693fa0,
handler (0x696290, 9)
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_data_inbound_handler: enter:
dh=0x696290, fd=0x9
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_data_inbound_handler: leave
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693e40,
need to check
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_run_io_cb: call: item=0x693e40,
handler (0x6a3bd0, 5)
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_cancel_with_err: enter:
ctx=0x6a2b40, ctx_err=117440513, op_err=0
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_remove_io_cb: call:
data=0x693e10, setting fd 0x5 (item=0x693e40) done
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_remove_io_cb: call:
data=0x693f70, setting fd 0x9 (item=0x693fa0) done
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme:gpg_io_event: call: gpg=0x6a3bd0,
event 0x7fb66f730eb0, type 1, type_data 0x7ffce1a86910
GPGME 2015-07-22 23:18:39 <0x66f2> _gpgme_cancel_with_err: leave
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_op_encrypt_sign:178: error: General
error <GPGME>
GPGME 2015-07-22 23:18:39 <0x66f2> gpgme_release: call: ctx=0x6a2b40

Huh?
GPA uses GPGME and allows to delete and import keys.

A brief check shows that the pinentry mode is passed to the egine for decrypt
and sign. Please double check your code that you set the pinentry mode for the
conext before signing. You should also set GPGME_DEBUG=4:/foo/bar/logfile for a
log.

Did an strace (with fork-follow) of my code and saw the following:

The first is a sign + encrypt:

[pid 19904] execve("/usr/bin/gpg2", ["gpg2", "--enable-special-filenames", "--
batch", "--no-sk-comments", "--lc-messages", "C", "--lc-ctype", "C", "--status-
fd", "4", "--no-tty", "--charset", "utf8", "--enable-progress-filter", "--
display", ":0.0", "--encrypt", "--sign", "--always-trust", "-r",
"E96F346A94A761F898F9DA35D8CD7D21B2A93EF9", "-u", "D8CD7D21B2A93EF9", "--
output", "-", "--", "-&7"], [/* 30 vars */]) = 0

The second is a decrypt:

[pid 19907] execve("/usr/bin/gpg2", ["gpg2", "--enable-special-filenames", "--
pinentry-mode=loopback", "--no-sk-comments", "--lc-messages", "C", "--lc-ctype",
"C", "--status-fd", "4", "--no-tty", "--charset", "utf8", "--enable-progress-
filter", "--display", ":0.0", "--command-fd", "5", "--decrypt", "--output", "-",
"--", "-&9"], [/* 30 vars */]) = 0

Now the decrypt does a --pinentry-mode=loopback while the sign, which also
requires password interaction, does not!

I had not. But when I do:

2015-07-10 12:10:07 (gpgme_test) my_key: D8CD7D21B2A93EF9
encrypt: 0
error: gpgme_op_encrypt failed: General error (117440513)

folkert@travelmate:~/Projects/PGF/trunk$ cat ~/.gnupg/gpg-agent.conf
allow-loopback-pinentry

Do you have 'allow-loopback-pinentry' option in your .gnupg/gpg-agent.conf?
It is not enabled by default, since allowing loopback mode gives easier access
to private keys.

1.5.5 has been released.

Thanks. Fixed in 1.5.5 (and als in master of course).

1.5.5 has been released. Closing.

Thanks for the log. This reveals a bug which has been with us since the support
for gpgsm: If there is no status line handler but a status line is received
anyway the command handling loop terminates and thus the command/answer order
gets out of sync. In this concrete case this is triggered by sending an option
which starts the agent and that starting emits a "PROGRESS" status line.

My solution is not to stop reading after a status line but record a possible
error code and return that only after OK or ERR.

This will go into 1.5.5 which I am already preparing.

I am unsure I understand, this causes gpgme to fail.

GPGME 2014-12-26 01:12:58 <0x5f44> _gpgme_run_io_cb: call: item=0xd2e804f5b00,
handler (0xd2e804f5970, 13)
GPGME 2014-12-26 01:12:58 <0x5f44> chan_12 <- ERR 50331822 Unknown option <GpgSM>

GPGME 2014-12-26 01:12:58 <0x5f44> gpgme:status_handler: call:
gpgsm=0xd2e804f5970, fd 0xd: ERR line - mapped to: Unknown option

Did you asked on the GUIX list whether they have a similar problem?

The error return from sending this option is not checked on purpose. We do the
same for all such options.

Oops. Long standing bug.

Fix in commit
0d28a696163677d6b34a802b6beddecd805d0fc7

Sorry, I don't understand why you have a ENOMEM problem there. You are using
Linux and thus you have copy-on-write which should not lead to such problem.
Right there are some corner cases but I doubt that they kick in here.

What kind garbage collector are you using? Can you check with the guix folks
whether they have a similar problem? IIRC, Guile also uses gpgme

You can't use SIGCHLD in a library.

My point is not speed of forking, but memory pressure. We have problems with
Nix package manager forking any apps, unless it uses vfork() (either
directly, or indirectly via posix_spawn).

If zombies are the only reason for double forking, there are other ways
around, e. g. ignoring SIGCHLD.

And speaking of bugs, don't we have tests? :-)

That would be a large change which for sure would introduce a lot of new bugs.
In comparison to other operations required for gpg startup the pissible speedup
between fork and vfork will be minor. In any case vfork is an ugly hack which
is not required on modern OSes with MMU. Using posix_spawn is not possible
because we do double forking.

If you have a real problem with the performance, we should first evaluate the
problem and then find a solution. Thus: Please describe the use case and why
you think that the process creation is the performance hog. GPGME has been
designed to overcome such performance problems by eventually introducing
co-porcesses so to fork gpg only once for many operations. We do this with
gpgsm already but have not yet seen an urgent need to also also change this for
gpg. However, if there is a real need for it we can do that.

Old plain fork is expensive, even on Linux, maybe because of garbage
collector.

https://github.com/zalora/defnix/commit/987a49aa77be5596ec2a352c1c758bce532b
5818
https://github.com/zalora/nix-
exec/commit/ea6eb396f0fa67df6568e1bf5dada41fb70a6ca2

Can you give a reason why you need this?

Patch attached. I left the previous behavior intact in case it's needed for
backward-compat.

D290: 590_0001-GPGME_SIGSUM_KEY_REVOKED-not-set-on-revoked-key.patch

I guess that is possible. gpgsm does not get much attention these days.