[#75687] [Ruby trunk Bug#12416] struct rb_id_table lacks mark function — shyouhei@...
Issue #12416 has been reported by Shyouhei Urabe.
3 messages
2016/05/23
[#75763] [Ruby trunk Feature#12435] Using connect_nonblock to open TCP connections in Net::HTTP#connect — mohamed.m.m.hafez@...
Issue #12435 has been reported by Mohamed Hafez.
3 messages
2016/05/28
[#75774] Errno::EAGAIN thrown by OpenSSL::SSL::SSLSocket#connect_nonblock — Mohamed Hafez <mohamed.m.m.hafez@...>
Hi all, every now and then in my production server, I'm
4 messages
2016/05/30
[#75775] Re: Errno::EAGAIN thrown by OpenSSL::SSL::SSLSocket#connect_nonblock
— Mohamed Hafez <mohamed.m.m.hafez@...>
2016/05/30
Or does MRI's OpenSSL::SSL::SSLSocket#connect_nonblock just return
[#75782] Important: Somewhat backwards-incompatible change (Fwd: [ruby-cvs:62388] duerst:r55225 (trunk): * string.c: Activate full Unicode case mapping for UTF-8) — Martin J. Dürst <duerst@...>
With the change below, I have activated full Unicode case mapping for
4 messages
2016/05/31
[ruby-core:75697] [Ruby trunk Bug#9569] SecureRandom should try /dev/urandom first
From:
delan@...
Date:
2016-05-24 06:43:36 UTC
List:
ruby-core #75697
Issue #9569 has been updated by Delan Azabani. Yui NARUSE wrote: > getrandom has some limitations like its max output (33554431), and consumes entropy. This probably won’t add much to the conversation, but getrandom(2) and /dev/random don’t “consume” entropy any more than /dev/urandom does. getrandom(2) can be told to read from either of the devices. /dev/random and /dev/urandom have separate entropy pools, but they use the same algorithm. The only difference between them is that /dev/urandom doesn’t block when its “entropy estimate” is “low” — a misleading and simplistic mistake that we’re now stuck with on Linux. The “estimate” would only matter slightly if you’re in information theoretic territory and you also believe that SHA-1 or the Linux PRNG is broken. If you don’t agree, then using /dev/urandom (or anything that’s based on it) *also* consumes entropy, but now you simply won’t be told when it’s too low. ---------------------------------------- Bug #9569: SecureRandom should try /dev/urandom first https://bugs.ruby-lang.org/issues/9569#change-58828 * Author: Corey Csuhta * Status: Open * Priority: Normal * Assignee: * ruby -v: * Backport: ---------------------------------------- Right now, `SecureRandom.random_bytes` tries to detect an OpenSSL to use before it tries to detect `/dev/urandom`. I think it should be the other way around. In both cases, you just need random bytes to unpack, so SecureRandom could skip the middleman (and [second point of failure](http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/)) and just talk to `/dev/urandom` directly if it's available. Is this a case of just re-ordering the two code chunks so that `/dev/urandom` is tried first? Relevant lines: https://github.com/ruby/ruby/blob/trunk/lib/securerandom.rb#L59-L90 -- 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>