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.

Following the calling chain, we eventually call the OS itself using select(2).
This happens twice. The first call works. The 2nd call hangs in a loop, with
select(2) returning <0 and errno set to EINTR (call was interrupted).

That is actually a gpg*sm*.log. However, I am not sure whether a gpgme log will
be helpful. I need to replicate the problem first.

Thank You werner for the explanations.

As a workaround I copied to C:\GNU\GnuPG\ and this helped.
Now I have other issues but this one is solved.

Thanks again and bye.
me.

Some autoconf tests may choke on spaces in file names. Of course it is
possible to avoid this problem, but for development tools, it is not really
justified. Hacker's don't have spaces in there file names - they lead to all
kind of problems. Sometimes there is even a check for this problem:

1. Reject unsafe characters in $HOME, $tsdir and cwd. We consider spaces
2. as unsafe because it is too easy to get scripts wrong in this regard.

am_lf='
'
case pwd in

*[\;\\\"\#\$\&\'\`$am_lf\ \	]*)
  echo "unsafe working directory name"; DIE=yes;;

esac

But most packages don't have these checks, yet.

You should try to install into another directory - without strange characters
like spaces or parentheses.

D159: 359_gpgme_op_encrypt_sign-symmetric.patch

I discover patch for gpgme in gpg4win source. (patches/gpgme/01-gpg2.patch)
Claws-mail uses libgpgme-11.dll in gpg4win binary, which includes string
'gpg2.exe'.

I recognize gpgme in gpg4win is official version (on Windows).
We will use this version. Thank you.

1. Claws-mail is based on Sylpheed. but, it doesn't work my environment.

gpgme comes with gpg4win - use this version only.

You should also consider to use Claws-mail because CM has a better GnuPG
integration and best of all is part of gpg4win.

Hi, I changed your role from Provisional User to User - you may now update other
reports.

The gpgme-config scripts goes along with the gpgme.m4 code. A .pc file won't be
able to do what we can do with this combination.

Please disregard my stupid comments about GPA. I was on the wrong track.

You mean there is a useless process running which should better be killed, right?

This won't add a dependency on pkg-config. The reporter requests, that you
ship a .pc file, so packages dependening on gpgme can use pkg-config to
determine compiler and linker flags when building against gpgme. There is no
request to make gpa use pkg-config.

Right. Commit e7aeaeb.

I have another work item for gpgme and plan to do a new release next week.

In general I don't like pkg-config because it adds an extra dependecy above the
required libraries and introduces other problems. However, for GPA we already
have lot of dependencies and thus I would accept a patch.

Fixed in master will go into 1.3.2. Thanks.

We did some work on ttyname_r portability and close this report. If there are
still issues, please create a new report. Thanks!

IDEA warnings pop up ofthe enough, so that a special treatmeant is justified.

The exit code alone is not sufficient to return a useful error status. Thus
Marcus is right that we can't do much and gpgconf should be used to validate the
configuration.

I reassign this to gnupg, because this does not seem to be related to gpgme at
all. Maybe it can be closed due to age, don't know.

Fixed in repository.