[Python-ideas] Globally configurable random number generation

[Steven D'Aprano]

On Mon, Sep 14, 2015 at 10:16:00AM -0400, Random832 wrote:
> 
> On Mon, Sep 14, 2015, at 09:51, Donald Stufft wrote:
> > I think this particular bit is a bad idea, it makes an official API
> > that makes it really hard for an auditor to come into a code base and
> > determine if the use of random is correct or not.
> 
> It's no worse than what OpenBSD itself has done with the C api for
> rand/random/rand48. At some point you've got to balance it with the
> realities of making backwards compatibility easy to achieve for the
> applications that really do need it with either a few lines change or
> none at all. And anyway, the auditor would *know* that if they see a
> module-level function called they need to do the extra work to find
> out what mode the module-level RNG is in (i.e. yes/no is there anywhere
> at all in the codebase that changes it from the secure default?)
> 
> It's not an "official API", it's an escape hatch for allowing a minimal
> change to existing code that needs the old behavior.

Of course it is an official API. It's a documented public function (or 
rather, it will be if Nick's suggest is accepted) in the standard 
library. That makes it an official API. The *whole purpose of it* is to 
give a standard API for what Python can already do: monkey-patch the 
random module. E.g. we can do this now:

import random
random.random = lambda: 9
random.uniform = lambda a, b: return 9


but if you do that, you know you're on thin ice.

I don't entirely agree with everything Donald has said, but I agree that 
providing this API would be harmful. It would mean that any arbitrary 
module you import (directly or indirectly) could swap out the secure 
CSPRNG you're relying on for an insecure PRNG, and you would never know.

(Yes, they could do that now, this is Python. But they won't, because 
there's no official API for swapping out the default PRNG.)


-- 
Steve