Re: [Python-Dev] Our responsibilities (was Re: BDFL ruling request: should we block forever waiting for high-quality random bits?)

2016-06-16 Thread Random832
On Thu, Jun 16, 2016, at 07:34, Donald Stufft wrote: > python-dev tends to favor not breaking “working” code over securing > existing APIs, even if “working” is silently doing the wrong thing > in a security context. This is particularly frustrating when it > comes to security because

Re: [Python-Dev] Our responsibilities (was Re: BDFL ruling request: should we block forever waiting for high-quality random bits?)

2016-06-16 Thread Nick Coghlan
On 16 June 2016 at 05:50, Paul Moore wrote: > On 16 June 2016 at 12:34, Donald Stufft wrote: >> [1] I don’t think using os.urandom is incorrect to use for security sensitive >> applications and I think it’s a losing battle for Python to try and fight >> the rest of the world that urandom

Re: [Python-Dev] Our responsibilities (was Re: BDFL ruling request: should we block forever waiting for high-quality random bits?)

2016-06-16 Thread Sven R. Kunze
I also think it’s a great module for providing defaults that we can’t provide in os.urandom, like the number of bytes that are considered “secure” [1]. What I don’t think is that the secrets module means that all of a sudden os.urandom is no longer an API that is primarily used in a security se

Re: [Python-Dev] Our responsibilities (was Re: BDFL ruling request: should we block forever waiting for high-quality random bits?)

2016-06-16 Thread Donald Stufft
> On Jun 16, 2016, at 8:50 AM, Paul Moore wrote: > > On 16 June 2016 at 12:34, Donald Stufft wrote: >> [1] I don’t think using os.urandom is incorrect to use for security sensitive >>applications and I think it’s a losing battle for Python to try and fight >>the rest of the world that u

Re: [Python-Dev] Our responsibilities (was Re: BDFL ruling request: should we block forever waiting for high-quality random bits?)

2016-06-16 Thread Paul Moore
On 16 June 2016 at 12:34, Donald Stufft wrote: > [1] I don’t think using os.urandom is incorrect to use for security sensitive > applications and I think it’s a losing battle for Python to try and fight > the rest of the world that urandom is not the right answer here. > > [2] python-dev t

Re: [Python-Dev] Our responsibilities (was Re: BDFL ruling request: should we block forever waiting for high-quality random bits?)

2016-06-16 Thread Theodore Ts'o
On Thu, Jun 16, 2016 at 03:24:33PM +0300, Barry Warsaw wrote: > Except that I disagree. I think os.urandom's original intent, as documented > in Python 3.4, is to provide a thin layer over /dev/urandom, with all that > implies, and with the documented quality caveats. I know as a Linux developer

Re: [Python-Dev] Our responsibilities (was Re: BDFL ruling request: should we block forever waiting for high-quality random bits?)

2016-06-16 Thread Barry Warsaw
On Jun 16, 2016, at 07:34 AM, Donald Stufft wrote: >Well, I don’t think that for os.urandom someone using it for security is >running “counter to it’s original intent”, given that in general urandom’s >purpose is for cryptographic random. Someone *may* be using it for something >other than that, b

Re: [Python-Dev] Our responsibilities (was Re: BDFL ruling request: should we block forever waiting for high-quality random bits?)

2016-06-16 Thread Donald Stufft
> On Jun 16, 2016, at 7:07 AM, Barry Warsaw wrote: > > On Jun 16, 2016, at 06:04 AM, Donald Stufft wrote: > >> Regardless of what we document it as, people are going to use os.urandom for >> cryptographic purposes because for everyone who doesn’t keep up on exactly >> what modules are being add

[Python-Dev] Our responsibilities (was Re: BDFL ruling request: should we block forever waiting for high-quality random bits?)

2016-06-16 Thread Barry Warsaw
On Jun 16, 2016, at 06:04 AM, Donald Stufft wrote: >Regardless of what we document it as, people are going to use os.urandom for >cryptographic purposes because for everyone who doesn’t keep up on exactly >what modules are being added to Python who has any idea about cryptography at >all is going