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

Donald Stufft writes: > I guess one question would be, what does the secrets module do if > it’s on a Linux that is too old to have getrandom(0), off the top > of my head I can think of: > > * Silently fall back to reading os.urandom and hope that it’s been > seeded. > * Fall back to

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

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

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

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

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

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

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 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 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 invocations need unguessable randomness (to first > approximation: all those which

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

On 15 June 2016 at 16:12, Nathaniel Smith wrote: > On Wed, Jun 15, 2016 at 1:01 PM, Nick Coghlan wrote: >> Victor has some additional technical details written up at >> http://haypo-notes.readthedocs.io/pep_random.html and I'd be happy to >> formalise this

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

On Wed, Jun 15, 2016 at 1:01 PM, Nick Coghlan wrote: [...] > For 3.6+, we can instead make it so that the only things that actually > rely on cryptographic quality randomness being available are: > > - calling a secrets module API > - calling a random.SystemRandom method > -

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

On 06/15/2016 01:01 PM, Nick Coghlan wrote: For 3.6+, we can instead make it so that the only things that actually rely on cryptographic quality randomness being available are: - calling a secrets module API - calling a random.SystemRandom method - calling os.urandom directly However, we

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

[whew, actually read the whole thread] On 11 June 2016 at 10:28, 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 >> - raising an exception >> -

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

On Sun, Jun 12, 2016 at 06:53:54PM -0700, Nathaniel Smith wrote: > > Speaking of full-stack perspectives, would it affect your decision if > Debian Stretch were made robust against blocking /dev/urandom on > AWS/GCE? Because I think we could find lots of people who would be > overjoyed to fix

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

On Sun, Jun 12, 2016 at 4:28 PM, Theodore Ts'o wrote: > P.S. BTW, I probably won't change the behaviour of /dev/urandom to > make it be blocking. Before I found out about Pyhton Bug #26839, I > actually had patches that did make /dev/urandom blocking, and they > were planned to

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

On Sun, Jun 12, 2016 at 09:01:09PM +0100, Cory Benfield wrote: > My problem with /dev/urandom is that it’s a trap, lying in wait for > someone who doesn’t know enough about the problem they’re solving to > step into it. And my answer to that question is absent backwards compatibility concerns,

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

On Sun, Jun 12, 2016 at 11:07:22AM -0700, Nathaniel Smith wrote: > But for example, if a process is actively blocked waiting > for the initial entropy, one could spawn a kernel thread that keeps the > system from quiescing by attempting to scrounge up entropy as fast as > possible, via whatever

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

> On 12 Jun 2016, at 14:43, Theodore Ts'o wrote: > > Well, it can only happen on Linux because you insist on falling back > to /dev/urandom --- and because other OS's have the good taste not to > use systemd and/or Python very early in the boot process. If someone > tried to run

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

On Jun 11, 2016 11:13 PM, "Theodore Ts'o" wrote: > > On Sat, Jun 11, 2016 at 05:46:29PM -0400, Donald Stufft wrote: > > > > It was a RaspberryPI that ran a shell script on boot that called > > ssh-keygen. That shell script could have just as easily been a > > Python script that

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

On Sun, Jun 12, 2016 at 11:40:58AM +0100, Cory Benfield wrote: > > Of this set, only cloud-init worries me, and it worries me for the > *opposite* reason that Guido and Larry are worried. Guido and Larry > are worried that programs like cloud-init will be delayed by two > minutes while they wait

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

On Sun, Jun 12, 2016 at 01:49:34AM -0400, Random832 wrote: > > The intention behind getrandom() is that it is intended *only* for > > cryptographic purposes. > > I'm somewhat confused now because if that's the case it seems to > accomplish multiple unrelated things. Why was this implemented as a

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

On 11 June 2016 at 22:46, Donald Stufft wrote: > I guess one question would be, what does the secrets module do if it’s on a > Linux that is too old to have getrandom(0), off the top of my head I can > think of: > > * Silently fall back to reading os.urandom and hope that it’s

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

> On 12 Jun 2016, at 07:11, Theodore Ts'o wrote: > > On Sat, Jun 11, 2016 at 05:46:29PM -0400, Donald Stufft wrote: >> >> It was a RaspberryPI that ran a shell script on boot that called >> ssh-keygen. That shell script could have just as easily been a >> Python script that

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

On Sat, Jun 11, 2016 at 05:46:29PM -0400, Donald Stufft wrote: > > It was a RaspberryPI that ran a shell script on boot that called > ssh-keygen. That shell script could have just as easily been a > Python script that called os.urandom via > https://github.com/sybrenstuvel/python-rsa instead of

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

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

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

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

> On Jun 10, 2016, at 5:21 PM, Tim Peters wrote: > > Isn't that precisely the purpose of the GRND_NONBLOCK flag? It doesn’t behave exactly the same as /dev/urandom. If the pool hasn’t been initialized yet /dev/urandom will return possibly predictable data whereas

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

[Random832] > 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 same behavior? Isn't that precisely the purpose of the GRND_NONBLOCK flag?

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

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) os.random is used to directly generate a > long-term cryptographic

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

On 06/10/2016 12:54 PM, 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) os.random is used to directly generate a long-term cryptographic secret. If you

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

On 10.06.2016 20:55, Donald Stufft wrote: > Ok, so you’re looking for how would you replicate the blocking behavior of > os.urandom that exists in 3.5.0 and 3.5.1? > > In that case, it’s hard. I don’t think linux provides any way to externally > determine if /dev/urandom has been initialized or

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

I will observe that feelings have gotten a little heated, so without making any suggestions to how the python-dev community should decide things, let me offer some observations that might perhaps shed a little light, and perhaps dispell a little bit of the heat. As someone who has been working in

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

On Jun 10, 2016, at 12:05 PM, David Mertz wrote: >OK. My understanding is that Guido ruled out introducing an os.getrandom() >API in 3.5.2. But would you be happy if that interface is added to 3.6? I would. >It feels to me like the correct spelling in 3.6 should probably be

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

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 should use the "best available randomness (even if it blocks)" I'm not

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

[Tim] >> secrets.token_bytes() is already the way to spell "get a string of >> messed-up bytes", and that's the dead obvious (according to me) place >> to add the potentially blocking implementation. [Sebastian Krause] > I honestly didn't think that this was the dead obvious function to > use. To

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

On 06/10/2016 11:55 AM, Donald Stufft wrote: Ok, so you’re looking for how would you replicate the blocking behavior of os.urandom that exists in 3.5.0 and 3.5.1? In that case, it’s hard. I don’t think linux provides any way to externally determine if /dev/urandom has been initialized or not.

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

On Fri, Jun 10, 2016 at 12:55 PM, Larry Hastings wrote: > On 06/10/2016 12:29 PM, David Mertz wrote: > > I believe that secrets.token_bytes() and secrets.SystemRandom() should be > changed even for 3.5.1 to use getrandom() on Linux. > > Surely you meant 3.5.2? 3.5.1 shipped

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

> On Jun 10, 2016, at 3:33 PM, Brett Cannon wrote: > > If that's the case then we should file a bug so we are sure this is the case > and we need to decouple the secrets documentation from random so that they > can operate independently with secrets always doing whatever is

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

Tim Peters wrote: > secrets.token_bytes() is already the way to spell "get a string of > messed-up bytes", and that's the dead obvious (according to me) place > to add the potentially blocking implementation. I honestly didn't think that this was the dead obvious function

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

On 06/10/2016 12:29 PM, David Mertz wrote: I believe that secrets.token_bytes() and secrets.SystemRandom() should be changed even for 3.5.1 to use getrandom() on Linux. Surely you meant 3.5.2? 3.5.1 shipped last December. //arry/ ___ Python-Dev

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

On 10.06.2016 21:17, Donald Stufft wrote: On Jun 10, 2016, at 3:05 PM, David Mertz > wrote: OK. My understanding is that Guido ruled out introducing an os.getrandom() API in 3.5.2. But would you be happy if that interface is added to 3.6? It

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

David Mertz wrote: > It feels to me like the correct spelling in 3.6 should probably be > secrets.getrandom() or something related to that. Since there already is a secrets.randbits(k), I would keep the naming similar and suggest something like: secrets.randbytes(k, *,

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

On Fri, 10 Jun 2016 at 12:20 Donald Stufft wrote: > > On Jun 10, 2016, at 3:05 PM, David Mertz wrote: > > OK. My understanding is that Guido ruled out introducing an > os.getrandom() API in 3.5.2. But would you be happy if that interface is > added to 3.6? >

  1   2   >