On Jun 16, 2016, at 01:40 AM, Larry Hastings wrote:
As Robert Collins points out, this does change the behavior ever-so-slightly from 3.4;
Ah yes, I misunderstood Robert's point.
if urandom is initialized, and the kernel has the getrandom system call, getrandom() will give us the bytes we asked for and we won't open and read from /dev/urandom. In this state os.urandom() behaves ever-so-slightly differently:
* os.urandom() will now work in chroot environments where /dev/urandom doesn't exist. * If Python runs in a chroot environment with a fake /dev/urandom, we'll ignore that and use the kernel's urandom device. * If the sysadmin changed what the systemwide /dev/urandom points to, we'll ignore that and use the kernel's urandom device.
But os.urandom() is documented as calling getrandom() when available in 3.5... though doesn't detail how it calls it or what it uses the result for. Anyway, I feel these differences were minor, and covered by the documented change in 3.5, so I thought it was reasonable and un-broken.
If this isn't backwards-compatible enough to suit you, please speak up now!
It does seem like a narrow corner case, which of course means *someone* will be affected by it <wink>. I'll leave it up to you, though it should at least be clearly documented. Let's hope the googles will also help our hypothetical future head-scratcher. Cheers, -Barry