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