On 24 June 2016 at 06:48, Barry Warsaw <ba...@python.org> wrote: > > If secrets is backported and available in PyPI, then we can start immediately > changing the os.urandom() meme to something more secure. Sure it takes a long > time to change minds, but I still think it's better to give users a blessed, > near universally agreed upon, secure alternative immediately.
It's not that simple, as secrets relies on the os module to provide access to the getrandom() syscall (by way of an upgraded os.urandom). Nothing changes from a security perspective without that additional level of access to the underlying operating system capabilities. You could potentially go the ctypes route in a PyPI module, but the performance would be abysmal, so nobody would use it. Going for a custom C extension doesn't really work either - you can't use manylinux1 for it (as the baseline glibc ABI is way too old to include getrandom), and nobody's going to want to introduce an install time compiler dependency just to address this relatively obscure concern. Even if those problems could be resolved, it isn't really a problem where I'd advocate for a "standard library only" project to add an external dependency to address it - if they're going to do that, I'd instead advocate for them to stop reinventing the wheel, and instead reach for a third party library that solves their *actual* problem (like cryptography, passlib, or one of the web frameworks). This is why I think it makes sense to focus the immediate discussion on "Given getrandom() as an operating system API, can we improve the semantics of Python's os.urandom()?". The wider discussion around "How do we educate Python developers on the difference between simulated uncertainty and sensitive secrets?" that motivated the introduction of the secrets module isn't really applicable. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig