The patch adds a new RAND engine for OpenSSL. The engine uses the system's entropy source (/dev/urandom, CryptGenRandom(), getentropy() ...). The engine is automatically installed with OpenSSL as default RAND engine. The new engine fixes the fork() bug once and for all (https://gist.github.com/tiran/a9ba8c51cc7d1b75d3bc1d3f24411b4c)

The engine is a reimplementation of https://cryptography.readthedocs.io/en/latest/hazmat/backends/openssl/?highlight=engine#os-random-engine and a new take on #18747.

I have added a couple of private helper methods to the _ssl module. I'm not sure if we should keep them, remove them or make them public.

What are the helper methods good for? I don't think we want to expose them for now.

I have used the helper methods during development. They are also used in unit tests.

Then I'd say just keep them private.

I have to replace _PyOS_URandom with a variant that doesn't need the GIL, https://mail.python.org/pipermail/cryptography-dev/2016-May/000595.html

> I have to replace _PyOS_URandom with a variant that doesn't need the GIL

Please don't replace it, but add a new function which report errors differently. Which kind of granularity do you expect for the error reporting? Just a boolean (success or failure)?

Most implementations of _PyOS_URandom() already has a private "int raise" parameter to specify how errors are reported: raise an exception or call Py_FatalError().

My remark was ambiguous. I meant that I have to create an second implementation of _PyOS_URandom and use it in _ssl_osrandom_bytes.

Let's discuss the details on IRC after PyCon. I'm busy with preparations.

Christian, is this still a change you'd like to make for 3.6?

(I don't recall seeing it in your list of pending ssl modules patches)

No, it won't make it into 3.6. My patch is far from ready.

Let's not overcomplicate Python's ssl module any more.

I was part of an effort to provide an osrandom engine for PyCA cryptography. I'm going to port the engine to OpenSSL.

stage: patch review -> resolved