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.

Or use the new --quick-sign-key command ...

I assume this is related to T1630 which has been fixed

Fix has been released.

I was using 2.0.25 at the time. I've just retried, and 2.0.26 indeed fixes this
problem. Thanks for the hint!

This is actually a gnupg problem. What version of GnuPG are you using?
GnuPG 2.0.26 creates the home directory even if gpgsm is used first.

I've overlooked your bugreport and opened a very similar one
T1685

Werner has commited a proper fix for this in gpgme master.

Thanks for the report anyway. If I had seen this earlier it would have saved me
some time debugging this and coming to the same conclusion ;-)

Tested the patch with 1.4.4 on Windows against
vm-keyserver.spline.inf.fu-berlin.de which did not work previously.

Patch is also included in gpg4win now.

Thanks!

There is no guarantee that you will see a keyid at all. The keyid and the
fingerprint are actually different objects and it is only for v4 key format that
you can compute the keyid from the fingerprint. We have to implement this
knowledge into gpgme.

Meanwhile I did this and master does now work as expected. It even returns the
fingerprint if available. You may this with the also enhanced gpgme-tool.

While working on it I also fixed the --search-key thing for gnupg master.

D209: 447_keylist-shortening.patch

Sorry, I don't know what a Basket Note Pad is. Please report there first.

D204: 442_keyserver_keyids.patch

Should be fixed with the current stable GnuPG and GPGME versions.

This has meanwhile been fixed. It actually was a GnuPG Problem.

Fixed with commit 2bb2618 for master. Will go into 1.5.0.
Thanks.

D193: 427_patch-src_posix-io_c

Fixed with commit f916ab7 to be released with 1.5.0 (hopefully this month)
Workaround is obvious.

Thanks.

Duplicate of T1535

That is a GnuPG. See T1535.
I just pushed a fix to the 2.0 branch.

Hm. The process disappears after some time. Maybe it just needs some time to
finish. Maybe not a bug anymore. Please take a look at it yourself.

Can you please take a look at it again? If I compile long_genkey.c and run it
via ./long_genkey async it leaves a process behind, which should better be killed:

ps aux | grep gpg
dl 7577 7.0 0.0 24416 1924 pts/2 SL 22:05 0:00 gpg
--enable-special-filenames --use-agent --batch --no-sk-comment --lc-messages
de_DE.utf8 --lc-ctype de_DE.utf8 --status-fd 4 --no-tty --charset utf8
--enable-progress-filter --display :0 --ttyname /dev/pts/2 --ttytype xterm
--gen-key -- -&5

Fix in master (ff84d8d). Thanks.