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 larry
Recipients Lukasa, christian.heimes, dstufft, georg.brandl, larry, ned.deily, steven.daprano, vstinner
Date 2016-06-11.18:07:16
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1465668437.91.0.0696837239674.issue27292@psf.upfronthosting.co.za>
In-reply-to
Content
I don't think this is necessary, as the documentation for os.urandom() is already pretty good.  Here's the relevant bit:

    This function returns random bytes from an OS-specific randomness
    source. The returned data should be unpredictable enough for
    cryptographic applications, though its exact quality depends on
    the OS implementation. On a Unix-like system this will query
    /dev/urandom, and on Windows it will use CryptGenRandom().

ISTM that the Python documentation doesn't generally indulge in warning users about specific shortcomings of particular platforms; if it did it would be littered with such warnings.

Personally I'd approve of making the existing statements a little more forceful, like pulling it out into a red "warning" box and making it explicit that os.urandom() isn't any more sophisticated than the platform-specific technologies it uses.  But that's as far as I'd go.  I wouldn't add all the specifics you suggest.

Technically I think this actually is my call, as I'm the "platform expert" for the posix module:
  https://docs.python.org/devguide/experts.html
But really I think it's the call of the "Documentation Expert" for the relevant releases.  This is a stylistic concern--should the Python docs delve into these sorts of details?--and that's really the domain of the DE.

Georg Brandl is the DE for all currently-supported versions of Python.  (Well, 2.7 has no official DE, but I think Georg is de facto DE for that release too.)  I've nosied him here; hopefully he can tell us the standard Python doc aesthetic when it comes to these sorts of concerns.


By the way, the Raspberry PI does have hardware RNG:
  http://scruss.com/blog/2013/06/07/well-that-was-unexpected-the-raspberry-pis-hardware-random-number-generator/
It required loading an extra driver, at least as of 2014.  I concede I don't know what current crypto best-practices are on the PI.

That's one good reason why I think the Python documentation doesn't indulge in these laundry lists of platform failings--such information has a tendency to become out-of-date without anyone noticing.
History
Date User Action Args
2016-06-11 18:07:18larrysetrecipients: + larry, georg.brandl, vstinner, christian.heimes, ned.deily, steven.daprano, dstufft, Lukasa
2016-06-11 18:07:17larrysetmessageid: <1465668437.91.0.0696837239674.issue27292@psf.upfronthosting.co.za>
2016-06-11 18:07:17larrylinkissue27292 messages
2016-06-11 18:07:16larrycreate