[#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@...>
ko1c-failure@atdot.net 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@...
Issue #13618 has been updated by ko1 (Koichi Sasada).
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
ko1@atdot.net wrote:
[#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@...>
k0kubun@ruby-lang.org 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
I see. Please remove the test if the test is unnecessary.
[#88496] Re: [ruby-cvs:71466] k0kubun:r64374 (trunk): test_function.rb: skip running test
— Eric Wong <normalperson@...>
2018/08/15
Takashi Kokubun <takashikkbn@gmail.com> 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
eregontp@gmail.com 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
ko1@atdot.net 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 <ko1@atdot.net> wrote:
[#88774] Re: [ruby-alerts:8955] failure alert on trunk@P895 (NG (r64594)) — Eric Wong <normalperson@...>
ko1c-failure@atdot.net wrote:
3 messages
2018/08/31
[ruby-core:88721] [Ruby trunk Bug#15039] Random.urandom and SecureRandom arc4random use
From:
merch-redmine@...
Date:
2018-08-29 05:55:36 UTC
List:
ruby-core #88721
Issue #15039 has been updated by jeremyevans0 (Jeremy Evans). Freaky (Thomas Hurst) wrote: > Would rand() stop being a userspace PRNG if it automatically called srand() every 200,000 calls? If it received the argument to srand() from the kernel, then maybe. :) > > > arc4random_buf(3) is basically like fread(3), where getentropy(2) is like read(2). Would you consider fread(3) userspace I/O simply because it buffers? > > Yes, and that distinction is quite important for many IO users. > > The distinction can be important to CSPRNG users too, but `SecureRandom`/`Random.urandom` don't exactly help by saying "well, it depends on whether you're running Linux, Windows, or a BSD/Solaris derivative". If you wanted something fast with weaker state security guarantees you'd end up using something else anyway. I think in general SecureRandom doesn't need to specify how it is implemented, just that the related bytes are cryptographically random. If that isn't true on FreeBSD <12, then I agree Ruby should use a different approach in that case, but let's limit any changes to that specific case (or other specific cases known to be problematic). > > > Why not just reseed OpenSSL's CSPRNG that often, if this was sufficient to mitigate the concerns in #9569? > > > > Why do something more complex when the library function handles correctly for you (at least in OpenBSD's case)? > > Calling an OpenSSL reseed function occasionally wasn't a more complex change than reworking the Random/SecureRandom framework to favour the equivalent of /dev/urandom on popular platforms. Nor is calling getentropy() any more complex than only calling arc4random() when the implementation is sane. I think manual reseeding using the OpenSSL PRNG is significantly more complex than just calling arc4random_buf. Using getentropy instead of arc4random_buf is a little more complex, as getentropy is limited to 256 bytes (on OpenBSD). > Ultimately, the question is what do `Random.urandom`/`SecureRandom` *mean*. > > I've been using SecureRandom expecting it to use Yarrow and Fortuna (via /dev/urandom or equivalent) as provided by my kernel, only to find it's using some terrible legacy interface lurking in libc. And even if arc4random() was just fine (as it will hopefully be in FreeBSD 12), I'd still like to be able to err on the side of caution and just directly use urandom or equivalent, as repeatedly recommended by security experts. That recommendation does not necessarily apply to operating systems other than FreeBSD. > If `SecureRandom` isn't going to provide that guarantee, then maybe we need something like `OsRandom` that does. > > > If you are susceptible to a memory attack like Spectre/Cloudbleed, you probably have bigger issues than just arc4random_buf. > > Sure, and anyone with such big problems will probably appreciate not having them added to by things like "attackers can predict the next 10,000 API keys following a successful attack". If we didn't believe in defence in depth, why bother mitigating Meltdown? It sounds like you want a new feature: (SecureRandom|Random).sysrandom (analog of File#sysread, which does a system call for every method call). If you think OpenSSL is a better default than arc4random_buf, you may want to look at the OpenSSL 1.0.1 implementation (oldest OpenSSL version currently supported by ruby-openssl): https://github.com/openssl/openssl/blob/OpenSSL_1_0_1-stable/crypto/rand/rand_unix.c ---------------------------------------- Bug #15039: Random.urandom and SecureRandom arc4random use https://bugs.ruby-lang.org/issues/15039#change-73776 * 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:ruby-core-request@ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>