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.

Thanks.

See also T1502

Duplicate of T1493

Please see T1493 - it is very likely the same reasons. I am not abale to
replicate it, though. The workaround is to configure gpgme with
--disable-fd-passing

The lsof looks as expected.

You mean --disable-fd-passing...

Correct it works.

Attached lsof output for the process when does not work.

I don't think it has to do with hardened kernel... as the initial report was
without. I will try to contact the original user.

Thanks. GPGME is waiting for an EOF on the fd used to receive data from gpgsm.
The data is send by the GETAUDITLOG command and afaics all data has been
received. There is a one second timeout in the select which you can see at the
end of the log file.

File descriptor passing is used between gpgme and gpgsm which usually works
nice. We have an problem on Mac OS with that for yet unknown reasons. lsof
might give some insight here. I suggest to configure gpgme with
--disable-fd-logging ro check whether this is really the culprit.

What are the special features of the hardened gentoo kernel?

Thanks for the patch. I slighly modified it and pushed it to master. Will go
into 1.4.2.

Attached.

1.0.2 is more than 8 years old. The code chnaged a lot in the meantime. Feel
free to re-open if the problems persists with 1.4.x?

Too much changed in the last 3 years, it does not make sense to follow up on
this bug. Feel free to re-open if you can replicate it with current releases.

Thanks. Can you please cd to the build directory gpgme/tests/gpgsm and run
this on the command line (after having canceled the make check):

GPGME_DEBUG=9:/tmp/gpgme.log GNUPGHOME=$(pwd) GPG_AGENT_INFO= ./t-verify

and post the gpgme.log file?

Did not get an email with your comment... just happened to peek.

I am sorry, I forgot to place the link to the bug.

My system:
System uname:
Linux-3.8.6-hardened-x86_64-Intel-R-_Core-TM-_i7-3520M_CPU_@_2.90GHz-with-gentoo-2.2
sys-kernel/linux-headers: 3.7 (virtual/os-headers)
sys-libs/glibc: 2.15-r3
app-shells/bash: 4.2_p45

Attached is my config.log.

At the bug link you will find the user's details.

Please provide complete bug reports. Foe example the OS you are using.

We need to see whether we can re-use the code from GPA for this purpose.

For 1.4.1 I reverted the default for to --disable-fd-passing. This should fix
the immediate problem. If you can find the actual reason for this problem,
please follow up and change the status back to chatting.

Given that recent versions of GnupG support IDEA and won't emit such a status
line anymore, I do not think it is justified to fix this for old gpg versions.