https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112018-06-09T09:05:07ZRuby Issue Tracking SystemRuby master - Bug #14837: ruby blocks due to unavoidable getrandom without GRND_NONBLOCKhttps://bugs.ruby-lang.org/issues/14837?journal_id=724532018-06-09T09:05:07Zshevegen (Robert A. Heiler)shevegen@gmail.com
<ul></ul><p>Makes sense.</p>
<p>As for Gem.user_dir:</p>
<blockquote>
<p>Arguably Rubygems could provide/recommend a way to get the user GEM<br>
dir without invoking Ruby.</p>
</blockquote>
<p>The other way may be to have ruby directly support it since gems are<br>
also bundled with ruby (and bundler already is or soon-to-be is).</p>
<p>For example perhaps RbConfig.user_dir or something similar. I am not<br>
necessarily suggesting this (and in any way, it should then go into<br>
a new issue request), but I think various assumptions by rubygems<br>
were also made when rubygems was more of a separate add-on.</p> Ruby master - Bug #14837: ruby blocks due to unavoidable getrandom without GRND_NONBLOCKhttps://bugs.ruby-lang.org/issues/14837?journal_id=724572018-06-10T06:32:13Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul><li><strong>Backport</strong> changed from <i>2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN</i> to <i>2.3: REQUIRED, 2.4: REQUIRED, 2.5: REQUIRED</i></li></ul> Ruby master - Bug #14837: ruby blocks due to unavoidable getrandom without GRND_NONBLOCKhttps://bugs.ruby-lang.org/issues/14837?journal_id=724582018-06-10T06:34:13Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Closed</i></li></ul><p>Applied in changeset trunk|r63624.</p>
<hr>
<p>random.c: fix need_secure flags</p>
<ul>
<li>
<p>random.c (fill_random_seed): do not need to be secure, to get<br>
rid of blocking at the start-up time.<br>
<a href="/issues/14837">[ruby-core:87462]</a> [Bug <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: ruby blocks due to unavoidable getrandom without GRND_NONBLOCK (Closed)" href="https://bugs.ruby-lang.org/issues/14837">#14837</a>]</p>
</li>
<li>
<p>random.c (random_raw_seed): expected to be a cryptographically<br>
secure, as documented.</p>
</li>
</ul> Ruby master - Bug #14837: ruby blocks due to unavoidable getrandom without GRND_NONBLOCKhttps://bugs.ruby-lang.org/issues/14837?journal_id=724622018-06-11T01:17:50Zshyouhei (Shyouhei Urabe)shyouhei@ruby-lang.org
<ul></ul><p>Let me leave a weak concern that I do not fully understand the impact of this changeset.</p>
<p>I recommend some reviews by cryptographic experts about it.</p> Ruby master - Bug #14837: ruby blocks due to unavoidable getrandom without GRND_NONBLOCKhttps://bugs.ruby-lang.org/issues/14837?journal_id=724712018-06-11T17:02:07Zkevinoid (Kevin Locke)kevin@kevinlocke.name
<ul></ul><p>Thanks for the quick response and fix! Sorry I didn't see the changes sooner. (I didn't get an email notification, will investigate.)</p>
<p>If SecureRandom requires cryptographically random numbers, removing <code>GRND_NONBLOCK</code> will cause security issues when there is insufficient entropy, since it will get numbers which are insufficiently random. Is <a class="user active user-mention" href="https://bugs.ruby-lang.org/users/1041">@kosaki (Motohiro KOSAKI)</a> still active? Perhaps he could weigh in since this effectively reverts his change to add <code>GRND_NONBLOCK</code>? I'll email him.</p> Ruby master - Bug #14837: ruby blocks due to unavoidable getrandom without GRND_NONBLOCKhttps://bugs.ruby-lang.org/issues/14837?journal_id=724722018-06-11T17:53:56Zkevinoid (Kevin Locke)kevin@kevinlocke.name
<ul></ul><p>After re-reading the diff more closely I realized I had misunderstood. As I now understand, r63624 has the effect of adding <code>GRND_NONBLOCK</code> for <code>Random.new_seed</code> and the internal seeds and removing it for <code>Random.urandom</code>, which is probably what was originally intended in r52808. Seems like a good fix to me. The only potential issue I can see is that the internal seed is used to protect against hash table algorithmic complexity attacks (see r17465) so it might be possible to attack programs started before the system gains sufficient entropy to be unpredictable.</p>
<p>Thanks again!</p>