[#88240] [Ruby trunk Feature#14759] [PATCH] set M_ARENA_MAX for glibc malloc — sam.saffron@...
Issue #14759 has been updated by sam.saffron (Sam Saffron).
3 messages
2018/08/01
[#88251] Re: [ruby-alerts:8236] failure alert on trunk@P895 (NG (r64134)) — Eric Wong <normalperson@...>
[email protected] wrote:
3 messages
2018/08/01
[#88305] [Ruby trunk Bug#14968] [PATCH] io.c: make all pipes nonblocking by default — normalperson@...
Issue #14968 has been reported by normalperson (Eric Wong).
4 messages
2018/08/06
[#88331] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — samuel@...
Issue #13618 has been updated by ioquatix (Samuel Williams).
3 messages
2018/08/08
[#88342] [Ruby trunk Feature#14955] [PATCH] gc.c: use MADV_FREE to release most of the heap page body — ko1@...
Issue #14955 has been updated by ko1 (Koichi Sasada).
3 messages
2018/08/08
[#88433] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — ko1@...
SXNzdWUgIzEzNjE4IGhhcyBiZWVuIHVwZGF0ZWQgYnkga28xIChLb2ljaGkgU2FzYWRhKS4KCgpX
4 messages
2018/08/10
[#88467] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Eric Wong <normalperson@...>
2018/08/14
a28xQGF0ZG90Lm5ldCB3cm90ZToKPiBJc3N1ZSAjMTM2MTggaGFzIGJlZW4gdXBkYXRlZCBieSBr
[#88475] [Ruby trunk Misc#14937] [PATCH] thread_pthread: lazy-spawn timer-thread only on contention — ko1@...
Issue #14937 has been updated by ko1 (Koichi Sasada).
3 messages
2018/08/14
[#88491] Re: [ruby-cvs:71466] k0kubun:r64374 (trunk): test_function.rb: skip running test — Eric Wong <normalperson@...>
[email protected] wrote:
5 messages
2018/08/15
[#88495] Re: [ruby-cvs:71466] k0kubun:r64374 (trunk): test_function.rb: skip running test
— Takashi Kokubun <takashikkbn@...>
2018/08/15
SSBzZWUuIFBsZWFzZSByZW1vdmUgdGhlIHRlc3QgaWYgdGhlIHRlc3QgaXMgdW5uZWNlc3Nhcnku
[#88496] Re: [ruby-cvs:71466] k0kubun:r64374 (trunk): test_function.rb: skip running test
— Eric Wong <normalperson@...>
2018/08/15
Takashi Kokubun <[email protected]> wrote:
[#88523] [Ruby trunk Bug#14999] ConditionVariable doesn't reacquire the Mutex if Thread#kill-ed — eregontp@...
Issue #14999 has been updated by Eregon (Benoit Daloze).
4 messages
2018/08/17
[#88524] Re: [Ruby trunk Bug#14999] ConditionVariable doesn't reacquire the Mutex if Thread#kill-ed
— Eric Wong <normalperson@...>
2018/08/18
[email protected] wrote:
[#88549] [Ruby trunk Bug#14999] ConditionVariable doesn't reacquire the Mutex if Thread#kill-ed — eregontp@...
Issue #14999 has been updated by Eregon (Benoit Daloze).
3 messages
2018/08/19
[#88676] [Ruby trunk Misc#15014] thread.c: use rb_hrtime_scalar for high-resolution time operations — ko1@...
Issue #15014 has been updated by ko1 (Koichi Sasada).
5 messages
2018/08/27
[#88677] Re: [Ruby trunk Misc#15014] thread.c: use rb_hrtime_scalar for high-resolution time operations
— Eric Wong <normalperson@...>
2018/08/27
[email protected] wrote:
[#88678] Re: [Ruby trunk Misc#15014] thread.c: use rb_hrtime_scalar for high-resolution time operations
— Koichi Sasada <ko1@...>
2018/08/27
On 2018/08/27 16:16, Eric Wong wrote:
[#88716] Re: [ruby-dev:43715] [Ruby 1.9 - Bug #595] Fiber ignores ensure clause — Eric Wong <normalperson@...>
Koichi Sasada wrote:
4 messages
2018/08/29
[#88723] [Ruby trunk Bug#15041] [PATCH] cont.c: set th->root_fiber to current fiber at fork — ko1@...
Issue #15041 has been updated by ko1 (Koichi Sasada).
3 messages
2018/08/29
[#88767] [Ruby trunk Bug#15050] GC after forking with fibers crashes — ko1@...
Issue #15050 has been updated by ko1 (Koichi Sasada).
7 messages
2018/08/31
[#88769] Re: [Ruby trunk Bug#15050] GC after forking with fibers crashes
— Eric Wong <normalperson@...>
2018/08/31
Koichi Sasada <[email protected]> wrote:
[#88770] Re: [Ruby trunk Bug#15050] GC after forking with fibers crashes
— Koichi Sasada <ko1@...>
2018/08/31
[#88773] Re: [Ruby trunk Bug#15050] GC after forking with fibers crashes
— Eric Wong <normalperson@...>
2018/08/31
Koichi Sasada <[email protected]> wrote:
[#88774] Re: [ruby-alerts:8955] failure alert on trunk@P895 (NG (r64594)) — Eric Wong <normalperson@...>
[email protected] wrote:
3 messages
2018/08/31
[ruby-core:88781] [Ruby trunk Bug#15039] Random.urandom and SecureRandom arc4random use
From:
naruse@...
Date:
2018-08-31 08:19:30 UTC
List:
ruby-core #88781
Issue #15039 has been updated by naruse (Yui NARUSE). Freaky (Thomas Hurst) wrote: > naruse (Yui NARUSE) wrote: > > Freaky (Thomas Hurst) wrote: > > > naruse (Yui NARUSE) wrote: > > > > For example, ruby can't read /dev/urandom if it runs in jail. > > > > > > If the OS can't provide entropy to a process through urandom or an equivalent syscall, how is it going to safely seed a fallback CSPRNG? > > > > There's /dev/random and getentropy. > > ... but you've just described concerns over situations where such APIs are unavailable. If you have no /dev/urandom why would you have a /dev/random? If you have no non-blocking syscall for entropy why would you have a blocking one? Even if /dev/random is not accessible, it can use getentropy(2). > > But the size of those entropy is limited. > > Entropy's not really limited, the entire point of CSPRNGs is that you can stretch 256 bits of entropy out practically forever because the effort required to recover those bits and predict anything *exceeds the physical limitations of the universe*. Yes. But Random.urandom shouldn't be limited. > > > Both the existing /dev/urandom *and* getrandom() paths have to support calling their respective syscalls enough times to fill the requested bytes. > > > Why is it suddenly unacceptable when it's a guaranteed cap of 256 bytes instead of an arbitrary dynamic cap? > > > > > > getentropy() on OpenBSD is certainly a lot simpler to support than getrandom() on Linux. > > > > Linux's getrandom has flags argument. > > By default it behaves like getentropy and /dev/random, but if GRND_NONBLOCK is given it behaves like /dev/urandom. > > http://man7.org/linux/man-pages/man2/getrandom.2.html > > No it doesn't. "*By default, getrandom() draws entropy from the urandom source*". > > GRND_NONBLOCK's only affect is to return an error instead of blocking if the urandom source hasn't been seeded - i.e. very early in the boot sequence, which I'm not sure Ruby should be caring about. /dev/urandom also blocks like this on most platforms. Ah, you are correct. But I mean GRND_RANDOM. getentropy(2) always behaves as GRND_RANDOM and Random.urandom with getentropy(2) will require userspace CSPRNG. But getrandom without GRND_RANDOM behaes as /dev/urandom, and Random.urandom with getrandom works without userspace CSPRNG. ---------------------------------------- Bug #15039: Random.urandom and SecureRandom arc4random use https://bugs.ruby-lang.org/issues/15039#change-73826 * Author: Freaky (Thomas Hurst) * Status: Open * Priority: Normal * Assignee: * Target version: * ruby -v: * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- Random.urandom defaults to arc4random() on a lot of platforms, including FreeBSD. On all currently released versions of FreeBSD, arc4random() is, as the name suggests, a dubious ARC4-based userspace PRNG dating from circa 1997. Given the entire point of #9569 was that using the userspace CSPRNG in OpenSSL over /dev/urandom or equivalent is a bad idea, this seems to mean it's regressed to an *even worse* state on these platforms. Even in cases where it's using something more modern (FreeBSD 12, OpenBSD), it's still a userspace CSPRNG. If that's fine, we might as well *pick a known-good one* and use that everywhere. Like, say, OpenSSL's. Since the conclusion of #9569 seems to have been otherwise, I'd suggest dropping arc4random() as a potential source for Random.urandom due to it not matching the desired semantics. Rust's OsRng seems a good template for alternative _syscall implementations: https://docs.rs/rand/0.5.5/rand/rngs/struct.OsRng.html#platform-sources -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>