Re: [Python-Dev] Smoothing the transition from Python 2 to 3

Nick Coghlan writes: > - even if there is a test suite, sufficiently pervasive [str/bytes] > type ambiguity may make it difficult to use for fault isolation Difficult yes, but I would argue that that difficuly is inherent[1]. Ie, if it's pervasive, the fault should be isolated to the whole

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

On Wed, Jun 15, 2016 at 11:45 PM, Barry Warsaw wrote: > On Jun 15, 2016, at 01:01 PM, Nick Coghlan wrote: > >>No, this is a bad idea. Asking novice developers to make security >>decisions they're not yet qualified to make when it's genuinely >>possible for us to do the right

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

On Wed, Jun 15, 2016 at 10:25 PM, Theodore Ts'o wrote: > On Wed, Jun 15, 2016 at 04:12:57PM -0700, Nathaniel Smith wrote: >> - It's not exactly true that the Python interpreter doesn't need >> cryptographic randomness to initialize SipHash -- it's more that >> *some* Python

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

Nathaniel Smith pobox.com> writes: > On Wed, Jun 15, 2016 at 10:25 PM, Theodore Ts'o mit.edu> wrote: > > In practice, those Python ivocation which are exposed to hostile input > > are those that are started while the network are up. > > Not sure what you mean about the vast majority of Python

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

On Jun 15, 2016, at 11:52 PM, Larry Hastings wrote: >Well, 3.5.2 hasn't happened yet. So if you see it as still being broken, >please speak up now. In discussion with other Ubuntu developers, several salient points were raised. The documentation for os.urandom() in 3.5.2rc1 doesn't make sense:

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

On 06/16/2016 01:03 AM, Barry Warsaw wrote: *If* we can guarantee that os.urandom() will never block or raise an exception when only poor entropy is available, then it may be indeed indistinguishably backward compatible for most if not all cases. I stepped through the code that shipped in

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

I'll reformulate my argument: Ordered class namespaces are a minority use case that's already covered by existing language features (custom metaclasses) and doesn't warrant the extension of the language (i.e. making OrderedDict a builtin type). This is about Python-the-Language, not

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

On Jun 16, 2016, at 07:26 PM, Robert Collins wrote: >Which is a contract change. Someone testing in E.g. a chroot could have a >different device on /dev/urandom, and now they will need to intercept >syscalls for the same effect. Personally I think this is fine, but assuming >i see Barry's point

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

> On Jun 16, 2016, at 4:46 AM, Barry Warsaw wrote: > > We can educate them through documentation, but I don't think it's appropriate > to retrofit existing APIs to different behavior based on those faulty > assumptions, because that has other negative effects, such as breaking

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

On Jun 16, 2016, at 01:40 AM, Larry Hastings wrote: >As Robert Collins points out, this does change the behavior ever-so-slightly >from 3.4; Ah yes, I misunderstood Robert's point. >if urandom is initialized, and the kernel has the getrandom system call, >getrandom() will give us the bytes we

Re: [Python-Dev] Why does base64 return bytes?

On Wed, 15 Jun 2016 11:51:05 +1200, Greg Ewing wrote: > R. David Murray wrote: > > The fundamental purpose of the base64 encoding is to take a series > > of arbitrary bytes and reversibly turn them into another series of > > bytes in which the eighth bit is not

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

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

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

Cory Benfield lukasa.co.uk> writes: > python-dev cannot wash its hands of the security decision here. As I’ve said many times, I’m pleased to > see the decision makers have not done that: while I don’t agree with their decision, I totally respect > that it was theirs to make, and they made it

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

> 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

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

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. >

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

> On 16 Jun 2016, at 09:19, Stefan Krah wrote: > > This should only concern code that a) was specifically written for > 3.5.0/3.5.1 and b) implements a serious cryptographic application > in Python. > > I think b) is not a good idea anyway due to timing and side channel >

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

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?)

> 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

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

On Thu, Jun 16, 2016, at 04:03, Barry Warsaw wrote: > *If* we can guarantee that os.urandom() will never block or raise an > exception when only poor entropy is available, then it may be indeed > indistinguishably backward compatible for most if not all cases. Why can't we exclude cases when only

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On Thu, Jun 16, 2016 at 12:56 PM, Martin Teichmann wrote: > I am looking forward to a lot of comments on this! I'd be glad to give feedback on this, probably later today or tomorrow. In particular, I'd like to help resolve the intersection with PEP 520. :) -eric

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

Yes 'secrets' is one-liners. However, it might grow a few more lines around the blocking in getrandom() on Linux. But still, not more than a few. But the reason it should be on PyPI is so that programs can have a uniform API across various Python versions. There's no real reason that someone

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

On Jun 16, 2016, at 01:01 PM, David Mertz wrote: >It seems to me that backporting 'secrets' and putting it on Warehouse would >be a lot more productive than complaining about 3.5.2 reverting to (almost) >the behavior of 2.3-3.4. Very wise suggestion indeed. We have all kinds of stdlib modules

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On Thu, Jun 16, 2016 at 3:36 PM, Nick Coghlan wrote: > I don't think that's a side note, I think it's an important point (and > relates to one of Nikita's questions as well): we have the option of > carving out certain aspects of PEP 520 as CPython implementation > details. >

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

On 16 June 2016 at 13:09, Barry Warsaw wrote: > On Jun 16, 2016, at 01:01 PM, David Mertz wrote: > >>It seems to me that backporting 'secrets' and putting it on Warehouse would >>be a lot more productive than complaining about 3.5.2 reverting to (almost) >>the behavior of

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On Fri, Jun 17, 2016 at 2:36 AM, Nick Coghlan wrote: > On 16 June 2016 at 14:17, Martin Teichmann wrote: > An implementation like PyPy, with an inherently ordered standard dict > implementation, can just rely on that rather than being obliged to >

Re: [Python-Dev] PEP 487: Simpler customization of class creation

Hi Eric, hi List, > I'd be glad to give feedback on this, probably later today or > tomorrow. In particular, I'd like to help resolve the intersection > with PEP 520. :) Thanks in advance! Let me already elaborate on the differences, so that others can follow: You chose the name

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On 16 June 2016 at 14:17, Martin Teichmann wrote: > As a side note, you propose to use OrderedDict as the class definition > namespace, and this is exactly how I implemented it. Nonetheless, I > would like to keep this fact as an implementation detail, such that > other

Re: [Python-Dev] Discussion overload

Hi Kevin, I often feel the same way. Are you using GMail? It combines related messages in threads and lets you mute threads. I often use this feature so I can manage my inbox. (I presume other mailers have the same features, but I don't know if all of them do.) There are also many people who read

Re: [Python-Dev] Discussion overload

Hi Guido, From: on behalf of Guido van Rossum Reply-To: Date: Thursday, June 16, 2016 at 5:27 PM To: Kevin Ollivier Cc: Python Dev Subject: Re: [Python-Dev] Discussion

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

On Jun 16, 2016, at 09:51 AM, Random832 wrote: >On Thu, Jun 16, 2016, at 04:03, Barry Warsaw wrote: >> *If* we can guarantee that os.urandom() will never block or raise an >> exception when only poor entropy is available, then it may be indeed >> indistinguishably backward compatible for most if

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

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

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

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,

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

On 16 June 2016 at 10:01, David Mertz wrote: > It seems to me that backporting 'secrets' and putting it on Warehouse would > be a lot more productive than complaining about 3.5.2 reverting to (almost) > the behavior of 2.3-3.4. "Let Flask/Django/passlib/cryptography/whatever

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

Thanks for raising these good points, Nikita. I'll make sure the PEP reflects this discussion. (inline responses below...) -eric On Tue, Jun 14, 2016 at 3:41 AM, Nikita Nemkin wrote: > Is there any rationale for rejecting alternatives like: > > 1. Adding standard metaclass

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

On 16 June 2016 at 10:40, Nathaniel Smith wrote: > On Jun 16, 2016 10:01 AM, "David Mertz" wrote: >> Python 3.6 is introducing a NEW MODULE, with new APIs. The 'secrets' >> module is the very first time that Python has ever really explicitly >> addressed

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

Nathaniel Smith pobox.com> writes: > In practice, your proposal means that ~all existing code that uses > os.urandom becomes incorrect and should be switched to either secrets > or random. This is *far* more churn for end-users than Nick's > proposal. This should only concern code that a) was

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

On Jun 16, 2016, at 12:53 AM, Nathaniel Smith wrote: >> We have introduced churn. Predicting a future SO question such as "Can >> os.urandom() block on Linux?" the answer is "No in Python 3.4 and earlier, >> yes possibly in Python 3.5.0 and 3.5.1, no in Python 3.5.2 and the rest of >> the 3.5.x

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

On Jun 16, 2016, at 12:36 AM, Nathaniel Smith wrote: >Basically this is a question of whether we should make an (unlikely) error >totally invisible to the user, and "errors should never pass silently" is >right there in the Zen of Python :-). I'd phrase it differently though. To me, it comes

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

On Jun 16, 2016 10:01 AM, "David Mertz" wrote: > Python 3.6 is introducing a NEW MODULE, with new APIs. The 'secrets' module is the very first time that Python has ever really explicitly addressed cryptography in the standard library. This is completely, objectively untrue. If

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

On Thu, Jun 16, 2016, at 10:04, Barry Warsaw wrote: > On Jun 16, 2016, at 09:51 AM, Random832 wrote: > > >On Thu, Jun 16, 2016, at 04:03, Barry Warsaw wrote: > >> *If* we can guarantee that os.urandom() will never block or raise an > >> exception when only poor entropy is available, then it may

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

On Thu, Jun 16, 2016 at 1:04 PM, Donald Stufft wrote: > In my opinion, this is a usability issue as well. You have a ton of third > party documentation and effort around “just use urandom” for Cryptographic > random which is generally the right (and best!) answer except for

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

On Jun 16, 2016 1:23 AM, "Stefan Krah" wrote: > > Nathaniel Smith pobox.com> writes: > > In practice, your proposal means that ~all existing code that uses > > os.urandom becomes incorrect and should be switched to either secrets > > or random. This is *far* more churn for

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

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 >>

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

On 16 June 2016 at 16:58, Nathaniel Smith wrote: > The word "cryptographic" here is a bit of a red herring. The guarantee that > a CSPRNG makes is that the output should be *unguessable by third parties*. > There are plenty of times when this is what you need even when you aren't

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

On 16 June 2016 at 09:39, Paul Moore wrote: > I'm willing to accept the view of the security experts that there's a > problem here. But without a clear explanation of the problem, how can > a non-specialist like myself have an opinion? (And I hope the security > POV isn't

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

On Thu, Jun 16, 2016 at 11:58 AM, Nathaniel Smith wrote: > [...] no one else be able to predict what session cookie I sent [...] In > python 2.3-3.5, the most correct way to write this code is to use > os.urandom. The question in this thread is whether we should break that in >

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

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] PEP 520: Ordered Class Definition Namespace

On Thu, Jun 16, 2016 at 5:11 AM, Nikita Nemkin wrote: > I'll reformulate my argument: > > Ordered class namespaces are a minority use case that's already covered > by existing language features (custom metaclasses) and doesn't warrant > the extension of the language (i.e. making

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

On Jun 16 2016, Nick Coghlan wrote: > On 16 June 2016 at 09:39, Paul Moore wrote: >> I'm willing to accept the view of the security experts that there's a >> problem here. But without a clear explanation of the problem, how can >> a non-specialist like

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

On Thu, Jun 16, 2016 at 10:26:22AM -0700, Nick Coghlan wrote: > meta-guidance. However, there are multiple levels of improvement being > pursued here, since developer ignorance of security concerns and > problematic defaults at the language level is a chronic problem rather > than an acute one

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

On 16 June 2016 at 18:03, Nick Coghlan wrote: > On 16 June 2016 at 09:39, Paul Moore wrote: >> I'm willing to accept the view of the security experts that there's a >> problem here. But without a clear explanation of the problem, how can >> a

[Python-Dev] PEP 487: Simpler customization of class creation

Hi list, using metaclasses in Python is a very flexible method of customizing class creation, yet this customization comes at a cost: once you want to combine two classes with different metaclasses, you run into problems. This is why I proposed PEP 487 (see

[Python-Dev] Discussion overload

Hi all, Recent joiner here, I signed up after PyCon made me want to get more involved and have been lurking. I woke up this morning again to about 30 new messages in my inbox, almost all of which revolve around the os.urandom blocking discussion. There are just about hourly new posts showing

Re: [Python-Dev] Discussion overload

Yes, it most certainly was. :( Sorry about that! From: on behalf of Guido van Rossum Reply-To: Date: Thursday, June 16, 2016 at 8:25 PM To: Kevin Ollivier Cc: Python Dev

Re: [Python-Dev] Discussion overload

More likely your post was too long... :-( On Thu, Jun 16, 2016 at 7:00 PM, Kevin Ollivier < kevin-li...@theolliviers.com> wrote: > Hi Guido, > > From: on behalf of Guido van Rossum < > gu...@python.org> > Reply-To: > Date: Thursday, June 16, 2016 at 5:27

Re: [Python-Dev] Why does base64 return bytes?

Steven D'Aprano wrote: I'm satisfied that the choice made by Python is the right choice, and that it meets the spirit (if, arguably, not the letter) of the RFC. IMO it meets the letter (if you read it a certain way) but *not* the spirit. -- Greg

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

On Jun 15, 2016, at 01:01 PM, Nick Coghlan wrote: >No, this is a bad idea. Asking novice developers to make security >decisions they're not yet qualified to make when it's genuinely >possible for us to do the right thing by default is the antithesis of >good security API design, and os.urandom()

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

On 06/15/2016 11:45 PM, Barry Warsaw wrote: So we very clearly provided platform-dependent caveats on the cryptographic quality of os.urandom(). We also made a strong claim that there's a direct connection between os.urandom() and /dev/urandom on "Unix-like system(s)". We broke that

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

On 16 Jun 2016 6:55 PM, "Larry Hastings" wrote: > > > Why do you call it only "semi-fixed"? As far as I understand it, the semantics of os.urandom() in 3.5.2rc1 are indistinguishable from reading from /dev/urandom directly, except it may not need to use a file handle. Which