I have to disagree. Unless I am completely confused the modified functions use automatic buffer variable and then basically return it.

Oops, I am sorry for the confusion. This patch is the correct one. The patch originally attached contains also revert of the commit I've reported in the other bug report today.

Any progress on this one?

Also I suppose the 2.1.20 version above is typo and 2.2.20 is actually meant.

Can you please clarify? Let's assume I am using current gnupg version (2.2.20) and /run/user/$UID exists. Everything should work seamlessly, should it?

Yes. With LTO turned on the object files must not contain the same data blocks.

Ping?

Good to know that - I'll include scdaemon in the base gnupg2 package.

Sorry for misleading you, gpg-agent seems to be called properly from the build tree.

It is recent regression in 2.1.21 - probably in 2.1.20 scdaemon was not run at all.

You're right this function is the culprit. The

This is what I see in gdb after the host resolution is called:

The machine is x86_64 qemu-kvm virtual on x86_64 host.

Yes, this fixed the segfault.

print x
$1 = (pointer) 0xa200b8868
(gdb) print *x
Cannot access memory at address 0xa200b8868

Just running gpgscm crashes with segfault. Is this backtrace sufficient or do
you need me to investigate further?

(gdb) run
Starting program: /root/rpmbuild/BUILD/gnupg-2.1.19/tests/gpgscm/gpgscm
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.25.90-1.fc27.ppc64
Error: init.scm:785: eval: unbound variable: define-macro

Program received signal SIGSEGV, Segmentation fault.
oblist_find_by_name (name=name@entry=0x20071a50 "args",
slot=slot@entry=0x3fffffffe680, sc=<optimized out>, sc=<optimized out>) at
scheme.c:1128
1128 s = symname(car(x));
Missing separate debuginfos, use: dnf debuginfo-install
libgcrypt-1.7.6-2.fc26.ppc64 libgpg-error-1.25-2.fc26.ppc64
ncurses-libs-6.0-8.20170212.fc26.ppc64 readline-7.0-5.fc26.ppc64
(gdb) bt
#0 oblist_find_by_name (name=name@entry=0x20071a50 "args",
slot=slot@entry=0x3fffffffe680, sc=<optimized out>, sc=<optimized out>) at
scheme.c:1128
#1 0x000000002001cd4c in mk_symbol (sc=sc@entry=0x20070660, name=0x20071a50
"args") at scheme.c:1384
#2 0x000000002001de6c in mk_atom (sc=sc@entry=0x20070660, q=<optimized out>) at
scheme.c:1496
#3 0x0000000020021114 in opexe_5 (sc=0x20070660, op=<optimized out>) at
scheme.c:5012
#4 0x000000002001d770 in Eval_Cycle (sc=sc@entry=0x20070660,
op=op@entry=OP_T0LVL) at scheme.c:5392
#5 0x000000002002712c in scheme_load_named_file (sc=0x20070660, fin=0x200d4de0,
filename=0x20038d30 "ffi.scm") at scheme.c:5782
#6 0x000000002000d590 in load (sc=0x20070660, file_name=0x20038d30 "ffi.scm",
lookup_in_cwd=<optimized out>, lookup_in_path=1) at main.c:180
#7 0x000000002000cf88 in main (argc=<optimized out>, argv=<optimized out>) at
main.c:268

More info from our evolution maintainer Milan Crha:

I would rather like to see a fallback on the gnupg2 to instruct the caller that
the password is missing, like it does when gpg-agent is turned off (there was a
use-agent option in the past, maybe only in gpg1?).

The --passphrase-fd option works only with conjunction with --batch command in
gpg2, but the libcamel uses --batch only if no password is needed. There is used
the --command-fd to provide passwords, which worked for years. Really, the
problem is that gpg2 doesn't claim that it requires password, it simply fails,
because gpg-agent failed when it was supposed to ask for the password.

See also https://bugzilla.redhat.com/show_bug.cgi?id=1362477

Yes, that patch fixed the problem for me.

Also the pinentry.sh script does not look like being called during the opengpg
tests at all because I've added 'exit 1' directly to the beginning of it and
nothing changed even with the gnupg-2.1.10 make check which passed.

This is what I see in strace log from the gpg-agent during the test - so it is
related to addition of the progress messages.

26074 read(4, "PRESET_PASSPHRASE 50B2D4FA4122C2"..., 1002) = 69
26074 getrusage(RUSAGE_SELF, {ru_utime={0, 0}, ru_stime={0, 2622}, ...}) = 0
26074 clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {0, 2652041}) = 0
26074 write(4, "S PROGRESS open_dev_random X 1 0", 32) = 32
26074 write(4, "\n", 1) = 1
26074 open("/dev/urandom", O_RDONLY) = 5
26074 fcntl(5, F_GETFD) = 0
26074 fcntl(5, F_SETFD, FD_CLOEXEC) = 0
26074 write(4, "S PROGRESS need_entropy X 60 120", 32) = -1 EPIPE (Broken pipe)
26074 --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=26040, si_uid=1000} ---
26074 poll([{fd=5, events=POLLIN}], 1, 0) = 1 ([{fd=5, revents=POLLIN}])
26074 read(5,
"\224l\240\r\205PGH:;\227\370pv\355\202df\24\201\250\272p\257\334\2\304Z\177W\244Q"...,

60. = 60

26074 write(4, "S PROGRESS need_entropy X 120 12"..., 33) = -1 EPIPE (Broken pipe)
26074 --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=26040, si_uid=1000} ---
26074 write(4, "S PROGRESS need_entropy X 60 120", 32) = -1 EPIPE (Broken pipe)
26074 --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=26040, si_uid=1000} ---
26074 poll([{fd=5, events=POLLIN}], 1, 0) = 1 ([{fd=5, revents=POLLIN}])
26074 read(5,
"\222\251\303;\247\377\302Z\t[\10\354\217\236\357?\323\246\210]+\330\341\335*7\315\17\230\3141\211"...,

60. = 60

26074 write(4, "S PROGRESS need_entropy X 120 12"..., 33) = -1 EPIPE (Broken pipe)
26074 --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=26040, si_uid=1000} ---
26074 write(4, "S PROGRESS need_entropy X 60 120", 32) = -1 EPIPE (Broken pipe)
26074 --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=26040, si_uid=1000} ---
26074 poll([{fd=5, events=POLLIN}], 1, 0) = 1 ([{fd=5, revents=POLLIN}])
26074 read(5,
"}\37\0267k\343DGi\372\r&\3El\305\223\312|\307\200U6\24RI\6\214\4H\273\377"...,

60. = 60

26074 write(4, "S PROGRESS need_entropy X 120 12"..., 33) = -1 EPIPE (Broken pipe)
26074 --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=26040, si_uid=1000} ---
26074 write(4, "S PROGRESS need_entropy X 60 120", 32) = -1 EPIPE (Broken pipe)
26074 --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=26040, si_uid=1000} ---
26074 poll([{fd=5, events=POLLIN}], 1, 0) = 1 ([{fd=5, revents=POLLIN}])
26074 read(5,
"\21%\26k\326\1\232\204K\r\33\216\211\1\253;\324\346\362\203?g\22\315\205\203G\344AZ\272\270"...,

60. = 60

26074 write(4, "S PROGRESS need_entropy X 120 12"..., 33) = -1 EPIPE (Broken pipe)
26074 --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=26040, si_uid=1000} ---
26074 getrusage(RUSAGE_SELF, {ru_utime={0, 0}, ru_stime={0, 2971}, ...}) = 0
26074 clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {0, 2978843}) = 0
26074 write(4, "OK", 2) = -1 EPIPE (Broken pipe)
26074 --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=26040, si_uid=1000} ---
26074 write(2, "gpg-agent[26040]: Assuan process"..., 55) = 55
26074 write(2, "\n", 1) = 1
26074 close(4) = 0

I have the same problem when building gnupg2 on Fedora 23. Let me know if I can
help with debugging it.

The issue is that when the gpg starts the agent by itself (that is there is no
agent currently running) it does not forward the --homedir option.

And another issue is that the homedir can not be specified as relative path.
(OK, that could be accepted as security feature).

Can you please at least acknowledge whether these are bugs or not?

Well actually it is a bug. :) The homedir specification should work.

There are actually two bugs:

1. the homedir is not forwarded to gpg-agent when it is started from gpg2

2. even if I start gpg-agent manually the homedir must be specified as absolute

path, not relative - this is very inconvenient

Actually not a bug - the --homedir ./.gnupg causes it.

D145: 321_gnupg-2.0.16-review-fixes.patch

D133: 302_libgcrypt-1.4.5-release.patch

I am sorry but this is really misfeature rather than a feature. So you basically
say, that if caller of libgcrypt does not want to having it mess with uids and
capabilities it has to copy over about 600 lines from the secmem.c just to
delete the few calls?

See for example here:
http://code.google.com/p/cryptsetup/issues/detail?id=47