Follow-up to Crashes with gpg-agent 2.1.18

[Matthew Summers]

On Mon, Apr 10, 2017 at 3:31 PM, Shah, Amul <Amul.Shah at fisglobal.com> wrote:
>
> > Could you try with the version in debian experimental (2.1.20)?  I believe
> > the "Ohhh jeeee" crash was fixed upstream by commit
> > e175152ef7515921635bf1e00383e812668d13fc


Hello,

I have been experiencing this problem for roughly a week and a half.
Although that specific error (do_vsexp_sscan) appears intermittently,
I can very reliably crash gpg-agent, cause a race that results in a
second pin-entry, and/or cause memory allocation errors.

The trick to reproducing this is to employ a high level of parallelism
when calling `gpg -d` against some small example cipher text.
I do this sort of thing, where the recipient is a new test id I
created, 4096 bit RSA:

$ echo "test" | gpg -aer test at example.com -o gpg.txt
$ yes gpg.txt | head -100 | xargs -n 1 -P 5 gpg --decrypt -q  # 5
processes works reliably
$ yes gpg.txt | head -100 | xargs -n 1 -P 10 gpg --decrypt -q   # 10
processes fails 50% of the time
$ yes gpg.txt | head -100 | xargs -n 1 -P 100 gpg --decrypt -q  # 100
processes fails 100%

For versions, I started experiencing this problem with gnupg-2.1.18,
but only after upgrading to nettle-3.3 and glib-2.50.3 (gnutls-3.3.26
was consistent). I later upgrade gnupg to 2.1.20 and the issue
persisted. One interesting thing is that I was using 2.1.18 with great
success in handling highly parallel tasks until the time of these
upgrades. It is no small thing to track down every library that gnupg
utilizes for the agent, so any help here would be wonderful.

I am also happy to provide any further details regarding the test env
I am using here, which is based on Gentoo. I intend to continue
debugging as time permits.

Thanks!
Matt Summers