Issue #21448 has been updated by k0kubun (Takashi Kokubun). Backport changed from 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED to 3.2: REQUIRED, 3.3: REQUIRED, 3.4: DONE ruby_3_4 commit:508daebdcd730e34d5fb750880249deae8025b80 merged revision(s) commit:1181a682a6c314c92686e3701defa1eb44068c4e, commit:d84a811f31a65821642b165d712f380c0cc060e0. ---------------------------------------- Bug #21448: Random.urandom may fail to fall back to reading /dev/urandom on Linux < 3.17 https://bugs.ruby-lang.org/issues/21448#change-114045 * Author: rhenium (Kazuki Yamaguchi) * Status: Closed * Backport: 3.2: REQUIRED, 3.3: REQUIRED, 3.4: DONE ---------------------------------------- Origianlly reported for tmpdir: https://github.com/ruby/tmpdir/issues/50 On Linux, `Random.urandom` is expected to first attempt the `getrandom(2)` syscall (Linux >= 3.17), and fall back to reading from `/dev/urandom` if it is not supported. In Ruby 3.1, commit commit:54c91185c9273b9699693910fa95383c86f2af22 replaced the fallback routine that read from `/dev/urandom` with a call to `getentropy(3)`, if available at compile time. On Linux, glibc 2.25 and musl 1.1.20 started to provide a `getentropy(3)` implementation based on `getrandom(2)`. If Ruby is compiled with such a libc version but run on Linux 3.16 or earlier, both `getrandom()` and `getentropy(3)` fail. As a result, `Random.urandom` becomes unusable, even though `/dev/urandom` is still available. I couldn't find the orignal issue the commit was intended to address, except that it appears to related to macOS. Is there a scenario on macOS where `CCRandomGenerateBytes()` or `SecRandomCopyBytes()` might fail, while `getentropy()` will still succeed? -- https://bugs.ruby-lang.org/