Follow-up to Crashes with gpg-agent 2.1.18

NIIBE Yutaka gniibe at
Fri Jun 2 01:31:31 CEST 2017


Thank you for your keeping this issue.  We don't ignore problem, I work
for similar bug report of:

For original report of crash of this thread, I think that it is the same

I have been trying fix the problem of crash itself, and I fixed several
bugs in gpg-agent/npth/libgcrypt.  I believe that I identified the cause
of crash, and proposed a particular fix for libgcrypt (in D431).

So, I think that I know some.  For crash itself, the problem will be
gone, by next release of nPth (for macOS) and libgcrypt.

For "Cannot allocate memory" error, we need another approach like
throttling, I think.  I mean, we need to regulate rate of accepting

Matthew Summers <matthew.summers at> wrote:
> ```
> GPG fails with: gpg: decryption failed: No secret key
> ```
> GPG-Agent displays the following error msgs (log level guru) for ~15 -
> 25% of the decrypt operations.
> ```
> DBG: rsa_decrypt    => Cannot allocate memory
> decryption failed: Cannot allocate memory
> command 'PKDECRYPT' failed: Cannot allocate memory <gcrypt>
> DBG: chan_19 -> ERR 16810070 Cannot allocate memory <gcrypt>
> ```

For current implementation, it is (somehow) expected for many requests
(in the situation with no smartcard).

> At the time of the error there is at least 10GB of free RAM available.

The limitation comes from the fact we only have 32KB or 64KB for secure
memory; The region is mlock(2)-ed to avoid data transfer to swap
storage.  ... even if we have multiple giga bytes of memory.

> It may be notable that when using a smartcard (yubikey4 or nitrokey),
> it appears that all decrypt operations are serialized and we see no
> failures. None.


Perhaps, it would be good for libgcrypt to have an API for an
application (in this case gpg-agent) showing how much secure memory is
used (and how much left), so that an application can throttle accepting

Or, more easier, we can introduce a limitation to gpg-agent, say, only
accepts some fixed number of multiple connections simultaneously.

More information about the Gnupg-devel mailing list