Follow-up to Crashes with gpg-agent 2.1.18

[Shah, Amul]

-----Original Message-----
From: Gnupg-devel [mailto:gnupg-devel-bounces at gnupg.org] On Behalf Of Matthew Summers Sent: Tuesday, June 06, 2017 1:43 AM

>On Mon, Jun 5, 2017 at 3:40 PM, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
>> On Sun 2017-06-04 22:35:59 -0500, Matthew Summers wrote:
>>> It's probably true that for most users, highly parallelized
>>> decryption operations are rare. However, it's not difficult to
>>> demonstrate use cases where it's important to handle highly
>>> parallelized requests to gpg-agent.
>>
>> It would really help this conversation to document a few of these
>> real-world use cases.  I appreciate that your demonstration scripts
>> are narrow and targeted because it helps to isolate the problem, but
>> having clear real-world cases will help in motivating the fix to
>> actually get deployed.
>>
>> Where are highly-parallelized requests to gpg-agent likely to happen?
>
[snip Matt's response and thanks to him for his investigation]

Certainly! Sorry for the late reply. GT.M (http://fis-gtm.com/) is a high performance cooperatively managed database engine with ACID transaction support and MUMPS language compiler and runtime. GT.M leverages GnuPG for both encryption and encryption key management (thank you for the tools and your hard work).

When I say that GT.M is a cooperatively managed database, I mean that GT.M processes cooperatively manage a shared memory cache. There is no primary daemon that starts and stops the database. Each process calls out to GnuPG for access to encrypted resources. During testing with GnuPG 2.1.18 and above, when our automated tests started more than 20 processes at once, we would face intermittent inexplicable failures in acquiring encryption keys. The example that I provided illustrates the bug with hundreds of process that we see with fewer processes.

At database startup, our customers typically start somewhere between 10 and hundreds of processes. One customer goes up into the tens of thousands by the time they reach a steady state. These are real world use cases (http://www.fisglobal.com/solutions/banking-and-wealth/services/database-engine/sample-users).

Please let me know if you have any questions or need more information from me.

Regards, Amul

PS: Please excuse the abominable reformatting by Outlook.


The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.