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

On Sat, Jun 11, 2016, at 22:37, Theodore Ts'o wrote: > On Fri, Jun 10, 2016 at 05:14:50PM -0400, Random832 wrote: > > So, I have a question. If this "weakness" in /dev/urandom is so > > unimportant to 99% of situations... why isn't there a flag that can be > > passed to getrandom() to allow the

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

On Sat, Jun 11, 2016 at 02:16:21PM -0700, Guido van Rossum wrote: [on the real-world consequences of degraded randomness from /dev/urandom] > Actually it's not clear to me at all that it could have happened to Python. > (Wasn't it an embedded system?) A Raspberry Pi. But don't people run Python

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace (round 3)

> From: Eric Snow > Sent: Saturday, June 11, 2016 11:02 PM > To: Émanuel Barry > Cc: Python-Dev > Subject: Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace > (round 3) > > On Sat, Jun 11, 2016 at 7:51 PM, Émanuel Barry wrote: > >> From: Eric Snow > >> 1. if

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace (round 3)

On Sat, Jun 11, 2016 at 7:51 PM, Émanuel Barry wrote: >> From: Eric Snow >> 1. if ``__definition_order__`` is defined in the class body then it >> must be a ``tuple`` of identifiers or ``None``; any other value >> will result in ``TypeError`` > > Why not just any

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace (round 3)

> From: Eric Snow > Sent: Saturday, June 11, 2016 10:37 PM > To: Python-Dev; Guido van Rossum > Subject: [Python-Dev] PEP 520: Ordered Class Definition Namespace (round > 3) > The only change to the original proposal > has been that a manually set __definition_order__ must be a tuple of >

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

On Fri, Jun 10, 2016 at 05:14:50PM -0400, Random832 wrote: > On Fri, Jun 10, 2016, at 15:54, Theodore Ts'o wrote: > > So even on Python pre-3.5.0, realistically speaking, the "weakness" of > > os.random would only be an issue (a) if it is run within the first few > > seconds of boot, and (b)

[Python-Dev] PEP 520: Ordered Class Definition Namespace (round 3)

I've updated the PEP to reflect feedback up to this point. The reception has been positive. The only change to the original proposal has been that a manually set __definition_order__ must be a tuple of identifiers or None (rather that using the value as-is). All other updates to the PEP have

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

[Sebastian Krause] > ... > Ideally I would only want to use the random module for > non-secure and (in 3.6) the secrets module (which could block) for > secure random data and never bother with os.urandom (and knowing how > it behaves). But then those modules should probably get new > functions to

Re: [Python-Dev] writing to /dev/*random [was: BDFL ruling request: should we block ...]

On 06/11/2016 05:16 PM, Stephen J. Turnbull wrote: Use a Raspberry-Pi, or other advanced expensive hardware. There's no real excuse for not having a hardware generator if the Pi has one! Intel CPUs added the RDRAND instruction as of Ivy Bridge, although there's an ongoing debate as to whether

[Python-Dev] writing to /dev/*random [was: BDFL ruling request: should we block ...]

This is related to David Mertz's request for backward compatible initialization, not to the bdfl decision. Steven D'Aprano writes: > I don't think that's something which the Python interpreter ought to do > for you, but you can write to /dev/urandom or /dev/random (both keep > their own,

Re: [Python-Dev] Stop using timeit, use perf.timeit!

On Fri, Jun 10, 2016, at 21:45, Steven D'Aprano wrote: > If you express your performances as speeds (as "calculations per > second") then the harmonic mean is the right way to average them. That's true in so far as you get the same result as if you were to take the arithmetic mean of the times

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

Fortunately, 3.6 feature freeze isn't until September, so we can all cool off and figure out the best way forward. I'm going on vacation for a week, and after sending this I'm going to mute the thread so I won't be pulled into it while I'm supposed to be relaxing. -- --Guido van Rossum

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

On 06/11/2016 01:48 PM, Guido van Rossum wrote: So I still don't see why we need os.getrandom() -- it has nothing to recommend it over the secrets module (since both won't happen before 3.6). I have two reasons, neither of which I think are necessarily all that persuasive. Don't consider

Re: [Python-Dev] PEP 468

I am. I was just wondering if there was an in-progress effort I should be looking at, because I am interested in extensions to it. P.S.: If anyone is missing the relevance, Raymond Hettinger's compact dicts are inherently ordered until a delitem happens.[1] That could be "good enough" for many

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

> On Jun 11, 2016, at 5:16 PM, Guido van Rossum wrote: > > On Sat, Jun 11, 2016 at 1:48 PM, Donald Stufft > wrote: > >> On Jun 11, 2016, at 3:40 PM, Guido van Rossum > > wrote: >> >>

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

[Guido] > ... > An alternative would be to keep the secrets module linked to SystemRandom, > and improve the latter. Its link with os.random() is AFAIK undocumented. Its > API is clumsy but for code that needs some form of secret-ish bytes and > requires platform and Python version independence it

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

On Sat, Jun 11, 2016 at 2:16 PM, Donald Stufft wrote: > > On Jun 11, 2016, at 4:48 PM, Guido van Rossum wrote: > > But I find an os.getrandom() that only exists on those (few?) platforms > that support it a nuisance too -- this just encourages cargo cult code

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

On Sat, Jun 11, 2016 at 1:48 PM, Donald Stufft wrote: > > On Jun 11, 2016, at 3:40 PM, Guido van Rossum wrote: > > Yeah, but we've already established that there's a lot more upset, > rhetoric and worry than warranted by the situation. > > > Have we? There

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

> On Jun 11, 2016, at 4:48 PM, Guido van Rossum wrote: > > But I find an os.getrandom() that only exists on those (few?) platforms that > support it a nuisance too -- this just encourages cargo cult code that's > unnecessarily complicated and believed to be secure without

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

On Sat, Jun 11, 2016 at 12:53 PM, Larry Hastings wrote: > > On 06/11/2016 11:30 AM, Donald Stufft wrote: > > The problem is that someone writing software that does > os.urandom(block=True) or os.urandom(exception=True) which gets some bytes > doesn’t know if it got back

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

> On Jun 11, 2016, at 4:26 PM, Brett Cannon wrote: > > Only issue I can think of that we're missing is one to track reverting > os.urandom() to 3.4 semantics (any doc updates required for the random > module?). Am I missing anything? It’s already been reverted to 3.4

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

> On Jun 11, 2016, at 3:40 PM, Guido van Rossum wrote: > > On Sat, Jun 11, 2016 at 11:30 AM, Donald Stufft > wrote: > >> On Jun 11, 2016, at 1:39 PM, Guido van Rossum > > wrote: >> >>

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

http://bugs.python.org/issue27288 covers updating the secrets module to use getrandom(). http://bugs.python.org/issue27292 covers documenting the drawbacks of os.urandom() http://bugs.python.org/issue27293 covers documenting all of the issues pointed out in this discussion. Only issue I can

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

On 06/11/2016 11:30 AM, Donald Stufft wrote: The problem is that someone writing software that does os.urandom(block=True) or os.urandom(exception=True) which gets some bytes doesn’t know if it got back cryptographically secure random because Python called getrandom() or if it got back

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

On Sat, Jun 11, 2016 at 11:30 AM, Donald Stufft wrote: > > On Jun 11, 2016, at 1:39 PM, Guido van Rossum wrote: > > Is the feature detection desire about being able to write code that runs > on older Python versions or for platforms that just don't have

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

On Sat, 11 Jun 2016 at 11:31 Donald Stufft wrote: > On Jun 11, 2016, at 1:39 PM, Guido van Rossum wrote: > > Is the feature detection desire about being able to write code that runs > on older Python versions or for platforms that just don't have getrandom()?

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

> On Jun 11, 2016, at 1:39 PM, Guido van Rossum wrote: > > Is the feature detection desire about being able to write code that runs on > older Python versions or for platforms that just don't have getrandom()? > > My assumption was that nobody would actually use these flags

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

You can add me to the list of people who feel like disappearing. On Sat, Jun 11, 2016 at 10:28 AM, Terry Reedy wrote: > On 6/11/2016 11:34 AM, Guido van Rossum wrote: > >> In terms of API design, I'd prefer a flag to os.urandom() indicating a >> preference for >> - blocking >>

Re: [Python-Dev] Current Python 3.2 status?

On Sun, Jun 12, 2016 at 1:02 AM, Berker Peksağ wrote: > On Sat, Jun 11, 2016 at 8:59 AM, Chi Hsuan Yen wrote: > > Hello all, > > > > Georg said in February that 3.2.7 is going to be released, and now it's > > June. Will it ever be released? > > Hi, >

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

Is the feature detection desire about being able to write code that runs on older Python versions or for platforms that just don't have getrandom()? My assumption was that nobody would actually use these flags except the secrets module and people writing code that generates long-lived secrets --

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

On 6/11/2016 11:34 AM, Guido van Rossum wrote: In terms of API design, I'd prefer a flag to os.urandom() indicating a preference for - blocking - raising an exception - weaker random bits +100 ;-) I proposed exactly this 2 days ago, 5 hours after Larry's initial post. ''' I think the 'new

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

> On Jun 11, 2016, at 11:34 AM, Guido van Rossum wrote: > > In terms of API design, I'd prefer a flag to os.urandom() indicating a > preference for > - blocking > - raising an exception > - weaker random bits If os.urandom can’t block on Linux, then I feel like it’d be saner

Re: [Python-Dev] Current Python 3.2 status?

On Sat, Jun 11, 2016 at 8:59 AM, Chi Hsuan Yen wrote: > Hello all, > > Georg said in February that 3.2.7 is going to be released, and now it's > June. Will it ever be released? Hi, It was delayed because of a security issue. See Georg's email at

Re: [Python-Dev] Current Python 3.2 status?

On Sat, 11 Jun 2016 at 08:05 Chi Hsuan Yen wrote: > Hello all, > > Georg said in February that 3.2.7 is going to be released, and now it's > June. Will it ever be released? > > pip [2], virtualenv [3] and setuptools [4] have all dropped Python 3.2 > support, and there's no

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

In terms of API design, I'd prefer a flag to os.urandom() indicating a preference for - blocking - raising an exception - weaker random bits To those still upset by the decision, please read Ted Ts'o's message. On Saturday, June 11, 2016, Steven D'Aprano wrote: > On Thu,

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

On 2016-06-11 16:37, Victor Stinner wrote: >> I repeat for like the fifth time: > > So, is there a candidate to write a PEP? > > I didn't read the thread. As expected, the discussion restarted for the > 3rd time, there are almost 100 emails in this thread. Sorry, I'm out. I simply lack the

[Python-Dev] Current Python 3.2 status?

Hello all, Georg said in February that 3.2.7 is going to be released, and now it's June. Will it ever be released? pip [2], virtualenv [3] and setuptools [4] have all dropped Python 3.2 support, and there's no new commits since 2016/01/15 on CPython's 3.2 branch. I'd like to know CPython's

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

> On 11 Jun 2016, at 09:24, Larry Hastings wrote: > Only Linux and OS X have never-blocking /dev/urandom. On Linux, you can > choose to block by calling getrandom(). On OS X you have no choice, you can > only use the never-blocking /dev/urandom. (OS X also has a

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

> I repeat for like the fifth time: So, is there a candidate to write a PEP? I didn't read the thread. As expected, the discussion restarted for the 3rd time, there are almost 100 emails in this thread. Victor ___ Python-Dev mailing list

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

On 2016-06-10 20:42, Chris Jerdonek wrote: > On Fri, Jun 10, 2016 at 11:29 AM, David Mertz wrote: >> This is fairly academic, since I do not anticipate needing to do this >> myself, but I have a specific question. I'll assume that Python 3.5.2 will >> go back to the 2.6-3.4

Re: [Python-Dev] Stop using timeit, use perf.timeit!

On Fri, Jun 10, 2016 at 1:13 PM, Victor Stinner wrote: > Hi, > > Last weeks, I made researchs on how to get stable and reliable > benchmarks, especially for the corner case of microbenchmarks. The > first result is a serie of article, here are the first three: > >

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

Steven D'Aprano wrote: >> it seems to me that you'd want such a solution to have code that >> causes the initialization of the entropy pool to be sped up so that it >> happens as quickly as possible (if that is even possible). Is it >> possible? (E.g. by causing the machine

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

On Fri, Jun 10, 2016 at 11:42:40AM -0700, Chris Jerdonek wrote: > And going back to Larry's original e-mail, where he said-- > > On Thu, Jun 9, 2016 at 4:25 AM, Larry Hastings wrote: > > THE PROBLEM > > ... > > The issue author had already identified the cause: CPython was

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

On 06/11/2016 12:49 AM, Steven D'Aprano wrote: Will there be platforms where os.getrandom doesn't exist? If not, then secrets can just rely on it, otherwise what should it do? if hasattr(os, 'getrandom'): return os.getrandom(n) else: # Fail? Fall back on os.urandom? AFAIK: * Only

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

On Fri, Jun 10, 2016 at 01:06:45PM -0700, Larry Hastings wrote: > > On 06/10/2016 01:01 PM, David Mertz wrote: > >So yes, I think 3.5.2 should restore the 2.6-3.4 behavior of os.urandom(), > > That makes... five of us I think ;-) (Larry Guido Barry Tim David) > > > >and the NEW APIs in secrets

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

On Thu, Jun 09, 2016 at 07:52:31PM -0700, Nikolaus Rath wrote: > On Jun 09 2016, Guido van Rossum wrote: > > I don't think we should add a new function. I think we should convince > > ourselves that there is not enough of a risk of an exploit even if > > os.urandom() falls back.