Marc-Andre Lemburg added the comment: On 07.06.2016 16:59, Christian Heimes wrote: > > Christian Heimes added the comment: > > On 2016-06-07 16:49, Marc-Andre Lemburg wrote: >> This gives people a clear choice and doesn't cause people >> to have to reconsider using the random module or wait for >> Python hash randomization to initialize itself when using >> Python during VM/container/system startup. >> >> I don't really appreciate this approach to break Python in >> cloud setups just because some entropy pool is not initialized, >> which only a tiny fraction of users care about. It doesn't >> make Python land a better place. > > VM and cloud setup without a proper CPRNG source are plain broken. True > fact! > > Secure entropy sources are a fundamental resource for all modern > applications. Please start treating CPRNG like RAM, CPU or disks. You > wouldn't add a workaround for broken CPU instructions to math.c or > semi-functional network card to socket.c, would you?
For security relevant applications, I agree and for those I question the use of os.urandom() altogether (see my other replies), but for everything else, a PRNG is just fine. I'm repeating myself, but making users believe that an entropy source is more important that preventing a denial of service just won't work out. You're position is quite similar to the one that others have taken with the I/O encoding in Python3. Their stance was "fix your system and it'll work". Well, tell that to 9-year olds who want to learn Python. Likewise, it may be easy for you to track down the reason why Python 3.5.1 isn't working in your VM or container, but not everyone knows that there's an entropy source which needs to be connected to your VM or container to make things work - and even if they do know about the problem they may not have the means to do so. It's pretty much the same situation and the reason why we have "practicality beats purity". A hanging Python process is the worst of all user experiences. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26839> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com