[#86787] [Ruby trunk Feature#14723] [WIP] sleepy GC — ko1@...
Issue #14723 has been updated by ko1 (Koichi Sasada).
13 messages
2018/05/01
[#86790] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/01
ko1@atdot.net wrote:
[#86791] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Koichi Sasada <ko1@...>
2018/05/01
On 2018/05/01 12:18, Eric Wong wrote:
[#86792] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/01
Koichi Sasada <ko1@atdot.net> wrote:
[#86793] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Koichi Sasada <ko1@...>
2018/05/01
On 2018/05/01 12:47, Eric Wong wrote:
[#86794] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/01
Koichi Sasada <ko1@atdot.net> wrote:
[#86814] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Koichi Sasada <ko1@...>
2018/05/02
[#86815] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/02
Koichi Sasada <ko1@atdot.net> wrote:
[#86816] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Koichi Sasada <ko1@...>
2018/05/02
On 2018/05/02 11:49, Eric Wong wrote:
[#86847] [Ruby trunk Bug#14732] CGI.unescape returns different instance between Ruby 2.3 and 2.4 — me@...
Issue #14732 has been reported by jnchito (Junichi Ito).
3 messages
2018/05/02
[#86860] [Ruby trunk Feature#14723] [WIP] sleepy GC — sam.saffron@...
Issue #14723 has been updated by sam.saffron (Sam Saffron).
6 messages
2018/05/03
[#86862] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC
— Eric Wong <normalperson@...>
2018/05/03
sam.saffron@gmail.com wrote:
[#86935] [Ruby trunk Bug#14742] Deadlock when autoloading different constants in the same file from multiple threads — elkenny@...
Issue #14742 has been reported by eugeneius (Eugene Kenny).
5 messages
2018/05/08
[#87030] [Ruby trunk Feature#14757] [PATCH] thread_pthread.c: enable thread caceh by default — normalperson@...
Issue #14757 has been reported by normalperson (Eric Wong).
4 messages
2018/05/15
[#87093] [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase — ko1@...
Issue #14767 has been updated by ko1 (Koichi Sasada).
3 messages
2018/05/17
[#87095] [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase — ko1@...
Issue #14767 has been updated by ko1 (Koichi Sasada).
9 messages
2018/05/17
[#87096] Re: [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase
— Eric Wong <normalperson@...>
2018/05/17
ko1@atdot.net wrote:
[#87166] Re: [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase
— Eric Wong <normalperson@...>
2018/05/18
Eric Wong <normalperson@yhbt.net> wrote:
[#87486] Re: [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase
— Eric Wong <normalperson@...>
2018/06/13
I wrote:
[ruby-core:87161] [Ruby trunk Bug#14773][Rejected] SecureRandom.alphanumeric Uses Insecure Underlying Implementation
From:
nobu@...
Date:
2018-05-18 04:52:21 UTC
List:
ruby-core #87161
Issue #14773 has been updated by nobu (Nobuyoshi Nakada).
Status changed from Open to Rejected
You misread random.c.
When those methods are called on `SecureRandom`, as it is not an instance of `Random` but a `Module`, `trn_get_rnd(obj)` in `rand_random_number()` returns `NULL`.
Next, calling `rand_random()` -> `rand_int()` -> `random_ulong_limited()`.
and then `obj_random_bytes()` -> `rb_funcallv_public(obj, id_bytes, 1, &len)` as `!rnd`.
Finally, it reaches `SecureRandom.gen_random` in securerandom.rb.
If in doubt, you can try with breaking at `SecureRandom.gen_random_urandom` (or a debug print).
----------------------------------------
Bug #14773: SecureRandom.alphanumeric Uses Insecure Underlying Implementation
https://bugs.ruby-lang.org/issues/14773#change-72151
* Author: wintermute_77@yahoo.com (Steven Hay)
* Status: Rejected
* Priority: Normal
* Assignee:
* Target version:
* ruby -v: 2.5.1
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
I believe that the implementation of SecureRandom.alphanumeric uses an underlying PRNG that is not the same as the one selected by the SecureRandom module. This is because the alphanumeric method uses the :choose method (line 291 in 2.5.1) which in turn uses the :random_number method (line 254,261).
The :random_number method is defined in the Random::Formatter module in random.c (The function is rand_random_number (Line 1369 and associated on line 1647). At any rate, once it is in random.c, it ends up using the insecure PRNG built into random.c.
I have a patch, but probably not one that is production quality. It it pretty simple--it overrides the random_number provided in Random::Formatter to use the :bytes method already defined.
~~~ ruby
module SecureRandom
def self.random_number max_range
b = SecureRandom.bytes 1
n = b.ord/256.0*max_range
n.to_i
end
end
~~~
At any rate, it may be a bad idea to extend SecureRandom with Random::Formatter in general, since it allows paths to use of the insecure underlying PRNG in random.c.
--
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>