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 700eb415
Recipients 700eb415, alex, rpointel, vstinner
Date 2014-10-14.17:28:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1413307699.96.0.815000623263.issue22542@psf.upfronthosting.co.za>
In-reply-to
Content
> I'm not sure that arc4random() can be considered as coming from the "OS".

We really have a couple options here. (1)Include a high quality pseudorandom number function for every platform that doesn't provide the proper call (very tedious and lots of places of mistakes - see: OpenSSL failing at this horribly), (2)get the OS venders to fix their software (not likely on this timescale), (3)use lots of #ifdef's to do platform detection (yuck), or (4)ignore broken calls provided by the system in hopes that the developers fix the issue.

Bob beck has a nice dialog on this problem in FreeBSD here: https://github.com/libressl-portable/portable/issues/17

It's ugly, but I'm leaning towards an "#ifdef __OpenBSD__" in this case since it seems to be the only platform at this time with a sane implementation other than the latest Linux kernel.

> If you really want arc4random(), IMO you should add a *new* function, but it would not be portable: only available on OpenBSD (and maybe other BSD including Mac OS X), not available on Windows nor Linux. I'm not sure that it fits Python portability policy, even if we have many functions which are only available on some recent platforms, like many Linux-specific functions (in the os module).

I think this would be a bad idea based on how easy this is to get wrong. The logic:

if /dev/urandom
    ...
else if os_has_proper_rand()
    ...
else
    fail

seems to be the best way to handle this IMO until OS venders provide viable fixes.


Alternatively if the consensus is to reconvene at a later time, I could work on a patch for the OpenBSD port and we can ignore the problem here for now. However, I think the Python community is a great place to bring this issue to light much as was done with LibreSSL.
History
Date User Action Args
2014-10-14 17:28:20700eb415setrecipients: + 700eb415, vstinner, alex, rpointel
2014-10-14 17:28:19700eb415setmessageid: <1413307699.96.0.815000623263.issue22542@psf.upfronthosting.co.za>
2014-10-14 17:28:19700eb415linkissue22542 messages
2014-10-14 17:28:19700eb415create