[RFC PATCH] enable configurable SECMEM_BUFFER_SIZE

[Matthew Summers]

On Wed, Nov 22, 2017 at 2:47 AM, Werner Koch <wk at gnupg.org> wrote:
> Hi!
>
> On Tue, 21 Nov 2017 19:12, matthew.summers at syapse.com said:
>
>> id. This is a severe issue for us that seems pretty easy to remedy
>> with a patch like this.
>
> Can you please explain the problem you try to solve.
>
> Any problems creating or using more keys is either due to a memory leak
> in gpg-agent or because you have a lot of active connections to the
> gpg-agent using private keys.

We have a lot of active connections to the gpg-agent using a single
private key. I outlined our use case in more detail here [1].

> For that latter case there are two solutions:
>
>  1. Enlarging the secure memory area.  This has the problem that you
>     will never known how much is sufficient.

We are enlarging the secmem_buffer using the patch attached
previously. We are determining the size using a simple empirical test
we constructed based on our known use case and concurrency
requirements. This is a fairly standard tuning process we have to go
through now so we are able to continue using GnuPG (we love it). This
test is outlined here [2].

This is the reason why we would love to see the secmem_buffer size
configurable, per the patch. It is perhaps notable that we needed to
go from ~1mb to 2mb when moving from 2.1.23 to 2.2.0.

Thanks for taking the time to reply and investigate this issue. I know
how busy it is maintaining OSS, and want you all to know how much we
all appreciate your efforts all these years. Many many thanks.

Cheers!
Matt Summers

aka quantumsummers at gentoo dot oh arrrrr geeeee

[1]  https://lists.gnupg.org/pipermail/gnupg-devel/2017-June/032913.html
[2] https://lists.gnutls.org/pipermail/gnupg-devel/2017-November/033227.html