From: kevin@... Date: 2018-06-11T17:53:58+00:00 Subject: [ruby-core:87476] [Ruby trunk Bug#14837] ruby blocks due to unavoidable getrandom without GRND_NONBLOCK Issue #14837 has been updated by kevinoid (Kevin Locke). After re-reading the diff more closely I realized I had misunderstood. As I now understand, r63624 has the effect of adding `GRND_NONBLOCK` for `Random.new_seed` and the internal seeds and removing it for `Random.urandom`, 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. Thanks again! ---------------------------------------- Bug #14837: ruby blocks due to unavoidable getrandom without GRND_NONBLOCK https://bugs.ruby-lang.org/issues/14837#change-72472 * 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: