Is that about gpgme or about GnuPG: Can you provide an exmaple by using gpg from
the command line? What OS are you using?

Isn't gpgme a part of GnuPG? Anyway, the problem as I understand it is internal
to GnuPG libraries. When a program makes a gpgme_op_decrypt() call to gpgme, it
in turn uses libassuan (and, I am guessing libgpg-error; correct me if I'm
wrong) to eventually inivoke gpg-agent. This process takes up to one second. We
have tested it on SunOS, AIX, and Linux. The delay times are slightly different,
but the common thing is that it only started happening in the versions that use
the agent instead of a callback mechanism for passphrase retrieval.

I don't have a command-line example as our code uses the gpgme API. I could
perhaps create a simplified C program to demonstrate the point if you wish. It
would take me some time to figure out the build options, prepare the keyring and
encrypted files, and to write the actual code, so I am hoping that it is
unnecessary, though.

Ivan: it would be very helpful if you could create a small example demonstrating
the problem. Thanks!

Ivan: Did you create the key on a fast machine and then moved it to a slower
one. Each use of a passphrases takes about 100ms for security reasons. Use
"gpg --passwd KEYID" to change the passphrase and adjust it to the speed of your
system.

A correctly installed system will start the agent either on the fly only the
first time or you need to start gpg-agent manually. See the man page for details.

No, keys were never moved. I have a test case ready, but I am trying to get a
hold of a newer AIX box to test it there. I will upload it shortly.

UPDATE: The latest gpg on an AIX box that I could get my hands on does not work
at all, so until that problem is resolved I cannot really test further.

When we invoke gpgme a process just hangs, but as far as we can tell from the
strace, gpg is busy closing file descriptors in the entire file descriptor
range! If we limit the file descriptor range to a smaller number (by, say,
"limit descriptors 4096 ; limit -h descriptors 4096"), we get a fast failure.

The gpg versions we have installed are 2.0.26 and 1.4.18. It seems that the
pinentry program never even gets invoked. Attached is a program you can test with.

(newer?) AIX versions have the bug that sysconf returns INT_MAX32 for the number
of max. open file descriptors. That leads to a long delay due to closing all
possible open file descriptors. See T1778.

That bug has been fixed in GnuPG 2.1 but not in libassuan. I have fixed it with
commit 7101fcb for libassuan which wilk go into libassaun 2.4.3. This might
also help with GnuPG 2.0.26 but I need to check that.

Indeed the sysconf patch had not been backported to gnupg 2.0. Please
try the attached patch for 2.0.x (sorry for the trailing white space changes).

D323: 752_0001-common-Cope-with-AIX-problem-on-number-of-open-files.patch

Just in case you are not using /dev/random, the "Fix-posssible..." patch may
help for 1.4.

D322: 753_0001-Fix-possible-AIX-problem-with-sysconf-in-rndunix.patch

D321: 754_0001-Fix-possible-_SC_OPEN_MAX-max-problem-on-AIX.patch

Given that you are using gpgme, the problem might already be there. if my
assumption is right the "...SC_OPEN_MAX-max-prob..." patch should fix this for
gpgme.

Please see T1778 (gduzan on Jan 20 2016, 03:41 PM / Roundup) on T1778 for a workaround.

We still need to check whether has been fixed for 1.4 and 2.0.