<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 13, 2017 at 8:00 AM, Andreas Stieger <span dir="ltr"><<a href="mailto:astieger@suse.com" target="_blank">astieger@suse.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<span class="gmail-"><br>
<br>
On 10/13/2017 06:44 AM, Matthew Summers wrote:<br>
> This is following up on an issue that started around in the 2.1.17<br>
> days, and I have been carrying a small patch addressing this for my<br>
> team since we figured it out. This is all documented in an earlier set<br>
> of threads to this ML.<br>
><br>
> Would you consider increasing SECMEM_BUFFER_SIZE to 1048576 in the<br>
> case where the configure option `large_secmem` = yes, please?<br>
><br>
> The patch itself is a super trivial in both configure and/or<br>
</span>> <a href="http://configure.ac" rel="noreferrer" target="_blank">configure.ac</a> <<a href="http://configure.ac" rel="noreferrer" target="_blank">http://configure.ac</a>>.<br>
><br>
<br>
You haven't explicitly referenced the rationale for this. Is this about<br>
RSA keys in excession of 4096 bits?<br></blockquote><div> </div><div>Yes, we are using 4096bit RSA keys, and generally recommend/require that internally at this stage in the game.</div><div><br></div><div>Here is the start of the 1st thread: <a href="https://lists.gnutls.org/pipermail/gnupg-devel/2017-January/032486.html">https://lists.gnutls.org/pipermail/gnupg-devel/2017-January/032486.html</a></div><div><br></div><div>Here is the start of the 2nd thread: <a href="https://lists.gnupg.org/pipermail/gnupg-devel/2017-June/032894.html">https://lists.gnupg.org/pipermail/gnupg-devel/2017-June/032894.html</a></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I would like to point out that this creates an issue on systems with the<br>
max locked memory size (ulimit -l) is limited to 64k:<br>
gpg: Warning: using insecure memory!<br>
mlock(0x7f5814308000, 262144) = -1 ENOMEM (Cannot allocate memory)<br>
Thus exposing private key material to being swapped out to permanent<br>
storage. I am not sure if a mere warning is sufficient here.</blockquote><div><br></div><div>I have been adjusting this ulimit as a matter of course, so it's not been an issue. It appears that 64k 'default' max locked memory and/or max memory size may vary from distro to disto as well.</div><div><br></div><div>I would like to stress that this is not a theoretical problem we are dealing with, but rather an issue that were we not able to patch the SECMEM_BUFFER_SIZE we would not be able to use GnuPG to protect sensitive data as we currently do (via saltstack).<br></div><div><br></div><div>What about an extra arg in <a href="http://configure.ac">configure.ac</a> that would let us either specify the SECMEM_BUFFER_SIZE or set it with `--extra-large-secmem`? I'd be happy to provide a patch for that, of course.</div><div><br></div><div>Thanks,<br>Matt Summers</div></div></div></div>