[#87467] [Ruby trunk Bug#14841] Very rarely IO#readpartial does not raise EOFError — mofezilla@...
Issue #14841 has been reported by hirura (Hiroyuki URANISHI).
3 messages
2018/06/10
[#87515] [Ruby trunk Bug#14841] Very rarely IO#readpartial does not raise EOFError — hirura@...
Issue #14841 has been updated by hirura (Hiroyuki URANISHI).
7 messages
2018/06/19
[#87516] Re: [Ruby trunk Bug#14841] Very rarely IO#readpartial does not raise EOFError
— Eric Wong <normalperson@...>
2018/06/19
hirura@gmail.com wrote:
[#87517] Re: [Ruby trunk Bug#14841] Very rarely IO#readpartial does not raise EOFError
— Eric Wong <normalperson@...>
2018/06/19
Sorry, I left this out: If you can reproduce it again, can you
[#87519] Re: [Ruby trunk Bug#14841] Very rarely IO#readpartial does not raise EOFError
— hirura <hirura@...>
2018/06/19
Hi Eric,
[#87521] Re: [Ruby trunk Bug#14841] Very rarely IO#readpartial does not raise EOFError
— Eric Wong <normalperson@...>
2018/06/19
hirura <hirura@gmail.com> wrote:
[#87541] [Ruby trunk Feature#14859] [PATCH] implement Timeout in VM — normalperson@...
Issue #14859 has been reported by normalperson (Eric Wong).
4 messages
2018/06/21
[#87570] [Ruby trunk Feature#14859] [PATCH] implement Timeout in VM — eregontp@...
Issue #14859 has been updated by Eregon (Benoit Daloze).
4 messages
2018/06/21
[#87605] [Ruby trunk Bug#14867] Process.wait can wait for MJIT compiler process — takashikkbn@...
Issue #14867 has been reported by k0kubun (Takashi Kokubun).
3 messages
2018/06/23
[#87614] [Ruby trunk Bug#14867] Process.wait can wait for MJIT compiler process — normalperson@...
Issue #14867 has been updated by normalperson (Eric Wong).
4 messages
2018/06/23
[#87631] [Ruby trunk Bug#14867] Process.wait can wait for MJIT compiler process — takashikkbn@...
Issue #14867 has been updated by k0kubun (Takashi Kokubun).
5 messages
2018/06/25
[#87635] Re: [Ruby trunk Bug#14867] Process.wait can wait for MJIT compiler process
— Eric Wong <normalperson@...>
2018/06/25
takashikkbn@gmail.com wrote:
[#87665] [Ruby trunk Bug#14867] Process.wait can wait for MJIT compiler process — eregontp@...
Issue #14867 has been updated by Eregon (Benoit Daloze).
4 messages
2018/06/28
[#87710] [Ruby trunk Bug#14867] Process.wait can wait for MJIT compiler process — Greg.mpls@...
Issue #14867 has been updated by MSP-Greg (Greg L).
3 messages
2018/06/30
[ruby-core:87475] [Ruby trunk Bug#14837] ruby blocks due to unavoidable getrandom without GRND_NONBLOCK
From:
kevin@...
Date:
2018-06-11 17:02:08 UTC
List:
ruby-core #87475
Issue #14837 has been updated by kevinoid (Kevin Locke).
Thanks for the quick response and fix! Sorry I didn't see the changes sooner. (I didn't get an email notification, will investigate.)
If SecureRandom requires cryptographically random numbers, removing `GRND_NONBLOCK` will cause security issues when there is insufficient entropy, since it will get numbers which are insufficiently random. Is @kosaki still active? Perhaps he could weigh in since this effectively reverts his change to add `GRND_NONBLOCK`? I'll email him.
----------------------------------------
Bug #14837: ruby blocks due to unavoidable getrandom without GRND_NONBLOCK
https://bugs.ruby-lang.org/issues/14837#change-72471
* Author: kevinoid (Kevin Locke)
* Status: Closed
* Priority: Normal
* Assignee:
* Target version:
* ruby -v: 2.5.1p57
* Backport: 2.3: REQUIRED, 2.4: REQUIRED, 2.5: REQUIRED
----------------------------------------
Following the [instructions in the Rubygems FAQ](https://guides.rubygems.org/faqs/#user-install) I added the following to `~/.bashrc`:
~~~ sh
if which ruby >/dev/null && which gem >/dev/null; then
PATH="$(ruby -e 'puts Gem.user_dir')/bin:$PATH"
fi
~~~
Unfortunately, this causes login to block for several seconds to minutes (depending on available entropy sources) because `ruby -e 'puts Gem.user_dir'` makes two `getrandom` syscalls without the `GRND_NONBLOCK` flag. On [Linux v4.17-rc2 and later](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43838a23a05fbd13e47d750d3dfd77001536dd33), this causes ruby, and therefore the login process, to block until the RNG is fully initialized.
Arguably Rubygems could provide/recommend a way to get the user GEM dir without invoking Ruby. That would solve the specific login problem reported above. However, since even `ruby -v` makes two `getrandom` syscalls, I suspect this may cause difficult to diagnose hangs in startup or login scripts for many users and that it is a desirable use case to support, which is why I am reporting it here.
Some relevant history: r51182 added `getrandom`, r51374 added `GRND_NONBLOCK` to address Bug #11395 (similar to this issue), r52808 removed `GRND_NONBLOCK` in some cases for `SecureRandom`.
Thanks for considering,
Kevin
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>