> On Jun 23, 2016, at 11:27 AM, Guido van Rossum <gu...@python.org> wrote: > > On Thu, Jun 23, 2016 at 5:42 AM, Barry Warsaw <ba...@python.org > <mailto:ba...@python.org>> wrote: > On Jun 22, 2016, at 10:37 PM, Donald Stufft wrote: > > >so the question I think really comes down to whether os.urandom is something > >we want to provide the best source of (generally) non blocking CSPRNG or > >whether we want it to be a narrow wrapper around whatever semantics > >/dev/urandom specifically has. > > ... with os.getrandom() exposed on platforms that provide it. > > Personally I think it's better to have one API than two, even if it is named > after a platform-specific API. > > FWIW I don't really buy the philosophy that the os module should only provide > thin wrappers over what the platform offers. E.g. in the case of Windows most > of what's in the os module is part of Microsoft's libc emulation, and the > platform APIs have a totally different shape. os.urandom()'s past is already > another example. So I don't see a reason to offer two different APIs and > force users of those APIs to either commit to a platform or use an ugly > try/except. Especially since in Python <= 3.5 they'll only have os.urandom(). >
For what it’s worth, I agree with this sentiment, though I think calling getrandom() and either blocking or erroring is still a pretty thin wrapper over what the OS provides, it’s just using a different interface to the same underlying functionality with only two real differences (1) Lack of a File Descriptor (2) Inability to get insecure values out of the API, both of which I think are good things. As far as I know, nobody has argued that os.random should *not* use getrandom(), they just want it to fall back to the same behavior as the /dev/urandom does in the (2) case… which is actually a thicker wrapper around what the OS provides than just using getrandom() since that fall back logic needs to be added ;) — Donald Stufft
_______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig
