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.

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.

OK, based on my findings, I have to clarify that it is the environment of the
agent program that is cached, thus rendering the pinentry program oblivious to
the further changes of the environment, even though it is those changes that
"guide" it in the retrieval of the correct passphrase.

Attached is a test program. I apologize that it is TCSH, but that is what we use
in our shop (for portability). Running test.csh should produce an output like
this:

    > test.csh < /dev/null
    ---------------------------------------------------
     GPG version:
    ---------------------------------------------------
    gpg (GnuPG) 2.1.9
    libgcrypt 1.6.3
    Copyright (C) 2015 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.
    
    Home: /tmp/gpg-caching/.gnupg
    Supported algorithms:
    Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
    Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
            CAMELLIA128, CAMELLIA192, CAMELLIA256
    Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
    Compression: Uncompressed, ZIP, ZLIB, BZIP2
    
    ---------------------------------------------------
     Available keys:
    ---------------------------------------------------
    /tmp/gpg-caching/.gnupg/pubring.kbx
    -----------------------------------
    pub   dsa1024/E65831AC 2015-11-24
    uid         [ultimate] user1 <user1@email.com>
    sub   rsa2048/95F85202 2015-11-24
    
    pub   dsa1024/B0731F16 2015-11-24
    uid         [ultimate] user2 <user2@email.com>
    sub   rsa2048/67841B64 2015-11-24
    
    
    ---------------------------------------------------
     Key 1 decrypted using gpg2 directly:
    ---------------------------------------------------
    gpg: encrypted with 2048-bit RSA key, ID 95F85202, created 2015-11-24
          "user1 <user1@email.com>"
    32-bit-long key for user1 (ONE).
    
    ---------------------------------------------------
     Key 2 decrypted using gpg2 directly:
    ---------------------------------------------------
    gpg: encrypted with 2048-bit RSA key, ID 67841B64, created 2015-11-24
          "user2 <user2@email.com>"
    gpg: public key decryption failed: Broken pipe  
    gpg: decryption failed: No secret key
    
    
    ---------------------------------------------------
     Key 1 decrypted using gpgme:
    ---------------------------------------------------
    32-bit-long key for user1 (ONE).
    
    ---------------------------------------------------
     Key 2 decrypted using gpgme:
    ---------------------------------------------------
    Error while accessing key file user2.key: Decryption failed

This test creates two private/public key pairs in the same keyring; the password
to the private key of the first is "password1"; that of the second is
"password2". It then generates two files (user1.key and user2.key), one encrypted
with the first public key, the other with the second. The contents of those files
are "32-bit-long key for user1 (ONE)." and "32-bit-long key for user2 (TWO).",
respectively. The test also involves a simplistic pinentry program that returns
the value of $password to the agent. The point is to demonstrate that once the
gpg agent is started, it caches the environment, such that even updating
$password to the right value is of no use. And that is why only user1.key is
decrypted successfully (the agent was started to decrypt it).

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.

OK, here are the outputs:

  $ /usr/bin/gpgme-config --version
  1.4.3
  $ ./gpgme-version
  Version from header: 1.4.3 (0x010403)
  Version from binary: 1.4.3
  Copyright blurb ...:

  This is GPGME 1.4.3 - The GnuPG Made Easy library
  Copyright (C) 2000 Werner Koch
  Copyright (C) 2001--2013 g10 Code GmbH

  (d788c35 2014-12-06T04:06+0000)

GnuPG version is 1.4.19, as reported by gpg --version, but gpg2 is, in fact, also installed:

  $ gpg2 --version
  gpg (GnuPG) 2.1.4
  libgcrypt 1.6.3
  ...

We have seen this problem on various OSs, but in this particular case it is Fedora 22. And we always install GnuPG from package
managers.

Here are all the gpgme files I see:

$ rpm -ql gpgme | grep \.so

/usr/lib64/libgpgme-pthread.so.11

/usr/lib64/libgpgme-pthread.so.11.11.0

/usr/lib64/libgpgme.so.11

/usr/lib64/libgpgme.so.11.11.0