[#60404] is RB_GC_GUARD needed in rb_io_syswrite? — Eric Wong <normalperson@...>
I haven't gotten it to crash as-is, but it seems like we need to
4 messages
2014/02/01
[#60682] volatile usages — Eric Wong <normalperson@...>
Hi all, I went ahead and removed some use of volatile which were once
5 messages
2014/02/13
[#60794] [RFC] rearrange+pack vtm and time_object structs — Eric Wong <normalperson@...>
Extracted from addendum on top of Feature #9362 (cache-aligned objects).
4 messages
2014/02/16
[#61139] [ruby-trunk - Feature #9577] [Open] [PATCH] benchmark/driver.rb: align columns in text output — normalperson@...
Issue #9577 has been reported by Eric Wong.
3 messages
2014/02/28
[ruby-core:61096] [ruby-trunk - Feature #9569] [Rejected] SecureRandom should try /dev/urandom first
From:
akr@...
Date:
2014-02-26 01:36:44 UTC
List:
ruby-core #61096
Issue #9569 has been updated by Akira Tanaka.
Status changed from Open to Rejected
/dev/urandom is not suitable to be used to generate directly session keys
and other application level random data which is generated frequently.
random(4) on GNU/Linux:
The kernel random-number generator is designed to produce a small
amount of high-quality seed material to seed a cryptographic pseudo-
random number generator (CPRNG). It is designed for security, not
speed, and is poorly suited to generating large amounts of random data.
Users should be very economical in the amount of seed material that
they read from /dev/urandom (and /dev/random); unnecessarily reading
large quantities of data from this device will have a negative impact
on other users of the device.
/dev/urandom should be used as "seed" for CPRNG.
OpenSSL do it.
/dev/urandom usage in securerandom.rb is not a good way.
So OpenSSL should be used at first.
----------------------------------------
Feature #9569: SecureRandom should try /dev/urandom first
https://bugs.ruby-lang.org/issues/9569#change-45484
* Author: Corey Csuhta
* Status: Rejected
* Priority: Normal
* Assignee:
* Category: lib
* Target version: current: 2.2.0
----------------------------------------
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
--
http://bugs.ruby-lang.org/