On 23 June 2016 at 06:54, Donald Stufft <don...@stufft.io> wrote: > >> On Jun 23, 2016, at 8:48 AM, Barry Warsaw <ba...@python.org> wrote: >> >> On Jun 22, 2016, at 06:31 PM, Nick Coghlan wrote: >> >>> try: >>> my_random = os.getrandom >>> except AttributeError: >>> my_random = os.urandom >> >> Once Python 3.6 is widely available, and/or secrets is backported and >> available on PyPI, why would you ever do that rather than just get the best >> source of randomness out of the secrets module? > > Because projects are likely going to be supporting things other than 3.6 for > a very long time. The “typical” support matrix for a project on PyPI currently > looks roughly like 2.6, 2.7, and 3.3+. We’re seeing some projects dropping 2.6 > finally on PyPI but it’s still a major source of downloads and 2.7 itself is > still ~86% of downloads initiated by pip across all of PyPI.
RIght, the missing qualifier on my statement is that one of the key aspects I'm specifically interested in the guidance we give to folks writing single source compatible Python 2/3 code that *also* want to use the best available initialization option given the vagaries of build platform, deployment platform, and the precise versions of those. Reasonable developer experience: * just keep using os.urandom(), Python will transparently upgrade your code to the best non-blocking-in-practice system interface the OS has to offer * if os.urandom() throws BlockingIOError, you may need to add application startup code to wait until the system random number generator is ready Dubious developer experience: * if osgetrandom() is available use that, otherwise use os.urandom() Dubious developer experience: * if the secrets module is available use that, otherwise use os.urandom() Dubious developer experience: * add a dependency on a third party library which implements one of the above dubious options For folks that don't need to worry about compatibility with old versions, the guidance will be "just use the secrets module" regardless of what we do with os.urandom(), and that's fine. 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
