gpg-agent "forgetting" keys when getting many parallel requests
Bence Ferdinandy
bence at ferdinandy.com
Mon Mar 18 13:20:43 CET 2024
On Mon Mar 18, 2024 at 09:50, Werner Koch <wk at gnupg.org> wrote:
> On Sun, 17 Mar 2024 13:09, Bence Ferdinandy said:
>
> > running out of memory. Based on a discussion I found
> > (https://dev.gnupg.org/T4255), I set `auto-expand-secmem 100M` in
>
> Right. The man page says:
>
> --auto-expand-secmem n
>
> Allow Libgcrypt to expand its secure memory area as required.
> The optional value n is a non-negative integer with a suggested
> size in bytes of each additionally allocated secure memory area.
> The value is rounded up to the next 32 KiB; usual C style
> prefixes are allowed. For an heavy loaded gpg-agent with many
> concurrent connection this option avoids sign or decrypt errors
> due to out of secure memory error returns.
>
> You should not append the 'M' - it is simply ignored. That is a bug in
> the option parser but we can't fix that because it would break too many
> configs which falsely assume that a letter can be used for some kind of
> unit.
>
> The value is actually irrelevant becuase any value will enable the
> auto-expand behaviour. Larger chunks can make maneory allocation a biut
> faster because every free() call needs to check the linked list of
> secure memory pools. I am not sure whetehr this is measurable, though.
Thanks for the clarification!
Best,
Bence
More information about the Gnupg-users
mailing list