Issue #4579 has been updated by Hiroshi NAKAMURA.


I think you're confusing SecureRandom's spec and ext/openssl (formerly ruby-pki) spec. ext/openssl aims to wrap OpenSSL that user's using so if OpenSSL is not 'fork-safe' as Eric expected, so ruby-pki doesn't.

So if OpenSSL can't change this behavior (I bet they can't at least in the near future), why don't we change lib/securerandom.rb?

The reason why I think you're not serious is adding ptherad_atfork() in ext is too ad-hoc-ish. We can't do it from Ruby world if I understand correctly. Adding atfork hook first?

To change (OK, 'fix') this behavior, it could be good to abandon using OpenSSL::Random.random_bytes(). We cannot use OpenSSL's engine which could provide physical random number but OpenSSL::Random.random_bytes must be enough for such user.

Tanaka-san, what do you think about the change?

----------------------------------------
Bug #4579: SecureRandom + OpenSSL may repeat with fork
http://redmine.ruby-lang.org/issues/4579

Author: Eric Wong
Status: Open
Priority: Normal
Assignee: 
Category: lib
Target version: 1.9.x
ruby -v: -


This could arguably be a bug in OpenSSL or the openssl extension, but
I think it's easier to fix in Ruby right now.

The PRNG in OpenSSL uses the PID to seed the PRNG.  Since PIDs get
recycled over time on Unix systems, this means independent processes
over a long time span will repeat random byte sequences.  This has
security implications, but fortunately very little software forks
very frequently.  I am not a security expert.

I am using OpenSSL 0.9.8g-15+lenny11 (Debian Lenny)

Attached is a script that reproduces the issue (takes a while to run).
It'll output two identical lines to illustrate the issue.



-- 
http://redmine.ruby-lang.org