This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author christian.heimes
Recipients christian.heimes, neologix, pitrou, sbt, vstinner
Date 2013-08-15.13:35:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
Am 15.08.2013 15:14, schrieb Antoine Pitrou:
>> Python doesn't have a builtin PRNG.
> Of course it does. It's in the random module, and you can seed() it:

Now you are nit-picking. Although random is a PRNG, it is not a CPRNG.
I'm clearly talking about the integrity of a CPRNG here.

>> We use the OS's CPRNG such as /dev/urandom or CryptGenRandom().
> "We"?

Python's os.urandom() and _PyOS_URandom().

> Well, are they affected? I haven't understood your previous answer.
> ("OpenSSL uses its own PRNG to create (amongst others) session keys for SSL connections")

Yes, they are are affected. A forking HTTPS server does:

1) listen() on a TCP port
2) accept() new TCP connection
3) fork() a child process to handle request
4) do SSL handshake in the child process
5) read/write data in child process

When the OpenSSL's CPRNG is already initialized before 3) than all child
processes created by 3) will have almost the same PRNG state. According
to the PRNG will return the same
value when PID numbers are recycled.

> Note that it seems debatable whether it's an OpenSSL bug:

It probably is an OpenSSL bug but the declaration doesn't help us. It's
not the first time Python has to work around OpenSSL, e.g. #18709.
Date User Action Args
2013-08-15 13:35:18christian.heimessetrecipients: + christian.heimes, pitrou, vstinner, neologix, sbt
2013-08-15 13:35:18christian.heimeslinkissue18747 messages
2013-08-15 13:35:18christian.heimescreate