Processes invoking gpgme_op_decrypt() should not incur a delay due to the invocation of gpg-agent
Closed, ResolvedPublic

Description

Every GPG version that makes use of gpg-agent for keyring keys' passphrase
retrieval adds up to one second of delay to a process that tries to decrypt a
file with a passphrase-protected key. The function used for decryption is
gpgme_op_decrypt(). Note that the callback mechanism that gpg-agent came to
replace had no such issue.

Details

Version
1.4.16+
ivansopin set Version to 1.4.16+.Aug 13 2015, 9:21 PM
ivansopin added a project: Bug Report.
ivansopin added a subscriber: ivansopin.
werner added a subscriber: werner.Aug 14 2015, 1:12 PM

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.

neal added a subscriber: neal.Nov 20 2015, 10:30 PM

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.

werner added a project: In Progress.

(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).

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

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.

gduzan added a subscriber: gduzan.Jan 20 2016, 3:37 PM

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

werner added a comment.May 6 2016, 8:27 PM

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

werner closed this task as Resolved.
werner claimed this task.

2.0 reached eol in 2 months so need to check it. For 1.4 I assume it has been fixed ;-)