On Aug 08, 2016, at 11:59 AM, Victor Stinner wrote:
>I don't know the exact Python 3.5 version of Ubuntu Xental.
Ubuntu 16.04 LTS (Xenial Xerus) has 3.5.1-ish in the primary archive pocket,
but 3.5.2-ish in xenial-updates, which most people will have enabled. Of
course, the devil is in the detai
On 8 August 2016 at 19:59, Victor Stinner wrote:
> os.urandom() is already blocking in Python 3.5.0 and 3.5.1 :-)
>
> For example on Fedora, no need for rawhide: Fedora 24 provides Python
> 3.5.1 with a blocking os.urandom() :-)
>
Surprisingly, it doesn't, as due to the way the Fedora buildroots
os.urandom() is already blocking in Python 3.5.0 and 3.5.1 :-)
For example on Fedora, no need for rawhide: Fedora 24 provides Python 3.5.1
with a blocking os.urandom() :-) I don't know the exact Python 3.5 version
of Ubuntu Xental.
Victor
___
Security-S
On 8 August 2016 at 14:22, Nick Coghlan wrote:
> On 8 August 2016 at 13:32, Nick Coghlan wrote:
>
>> The Fedora Rawhide experiment I'm proposing in that email to the Fedora
>> Python list should give us the data we (Fedora) need to decide whether or
>> not this is one of those cases where it mak
On 8 August 2016 at 13:32, Nick Coghlan wrote:
> The Fedora Rawhide experiment I'm proposing in that email to the Fedora
> Python list should give us the data we (Fedora) need to decide whether or
> not this is one of those cases where it makes sense for us to carry a patch
> - if we get zero hit
On 8 August 2016 at 12:37, Nick Coghlan wrote:
> However, from an operations perspective, it means the discussion will move
> downstream to see whether we (Fedora) agree this is the right behaviour for
> the *system* Python, or whether we should patch that to throw the error
> instead of implicit
On 8 August 2016 at 09:41, Victor Stinner wrote:
> 2016-08-08 1:11 GMT+02:00 Guido van Rossum :
> > Sorry, PEP 524 is accepted, and PEP 522 is rejected. Let os.urandom()
> > be blocking, and let os.getrandom() be added. Congrats, Victor!
>
> Ok. I changed the status of my PEP 524 from Draft to Ac
2016-08-08 1:11 GMT+02:00 Guido van Rossum :
> Sorry, PEP 524 is accepted, and PEP 522 is rejected. Let os.urandom()
> be blocking, and let os.getrandom() be added. Congrats, Victor!
Ok. I changed the status of my PEP 524 from Draft to Accepted. I will
now start to work on the implementation.
For
Sorry, PEP 524 is accepted, and PEP 522 is rejected. Let os.urandom()
be blocking, and let os.getrandom() be added. Congrats, Victor!
On Sun, Aug 7, 2016 at 12:49 PM, Victor Stinner
wrote:
> I am sorry but I'm in holiday and I'm unable to understand if your (Guido)
> email means that the PEP 524
I am sorry but I'm in holiday and I'm unable to understand if your (Guido)
email means that the PEP 524 is accepted, or if the PEP still needs to be
reworked?
Can someone help me? I'm lost. :-(
(Why is this specific topic so much annoying? :-))
Victor
> On Aug 7, 2016, at 2:33 PM, Ethan Furman wrote:
>
> So if we work around the problem in SipHash, the issue goes away?
The issue goes away in the sense that starting the Python interpreter *at all*
no longer relies on urandom being initialized. If someone uses Python early
enough and calls
On 08/07/2016 09:33 AM, Donald Stufft wrote:
On Aug 7, 2016, at 12:28 PM, Ethan Furman wrote:
Guido, not trying to change your mind, just trying to understand.
At this point we have concrete examples of the harm caused by blocking on
os.urandom -- do we have any actual use-cases where it i
Can we stop the discussion please? I have picked a winner. The loser
may not like it, but the discussion is OVER.
On Sun, Aug 7, 2016 at 9:33 AM, Donald Stufft wrote:
>
>> On Aug 7, 2016, at 12:28 PM, Ethan Furman wrote:
>>
>> At this point we have concrete examples of the harm caused by blockin
> On Aug 7, 2016, at 12:28 PM, Ethan Furman wrote:
>
> At this point we have concrete examples of the harm caused by blocking on
> os.urandom -- do we have any actual use-cases where it is hurtful to raise
> instead?
The use cases there are basically any time it would have only blocked for sa
On 08/07/2016 09:14 AM, Nick Coghlan wrote:
On 7 August 2016 at 03:21, Guido van Rossum wrote:
There is one thing that is still really unresolved for me, and that is
a good understanding of how likely this feared event, "not having
enough entropy" actually is, for environments where Python may
On 8 August 2016 at 02:14, Nick Coghlan wrote:
> In a lot of ways, I see it as being similar to our dependency on the Linux
> platform locale being set correctly to get boundary processing right: if
> you get an exception, the problem *isn't* generally with the application,
> it's with the way Li
On 7 August 2016 at 03:21, Guido van Rossum wrote:
> There is one thing that is still really unresolved for me, and that is
> a good understanding of how likely this feared event, "not having
> enough entropy" actually is, for environments where Python may
> actually be used. My main question is,
[Guido]
> ...
> There is one thing that is still really unresolved for me, and that is
> a good understanding of how likely this feared event, "not having
> enough entropy" actually is, for environments where Python may
> actually be used. My main question is, can it occur in situations
> *other* t
> On Aug 6, 2016, at 1:21 PM, Guido van Rossum wrote:
>
>
> There is one thing that is still really unresolved for me, and that is
> a good understanding of how likely this feared event, "not having
> enough entropy" actually is, for environments where Python may
> actually be used. My main que
I apologize, Maybe I wasn't clear. I'm voting in favor of Victor's PEP
524, i.e. making os.urandom() always blocking, over introducing an
exception so rare that it's impossible to provoke without mocking
entirely.
We may be trying to steer people away from os.urandom(), but it's a
venerable API th
On 6 August 2016 at 20:23, Victor Stinner wrote:
> An alternative would be to add to my PEP 524 an *optional*
> random.SystemRandomNonblock which is basically the PEP 522 (raise if it
> would block). "Optional"... or maybe make it always available but block(!)
> on some platforms? (Bad idea IMO)
An alternative would be to add to my PEP 524 an *optional*
random.SystemRandomNonblock which is basically the PEP 522 (raise if it
would block). "Optional"... or maybe make it always available but block(!)
on some platforms? (Bad idea IMO)
I dislike the idea of adding 2 new functions to generate r
On 6 August 2016 at 18:46, Nick Coghlan wrote:
> On 6 August 2016 at 18:32, Victor Stinner wrote:
>> Le 6 août 2016 04:39, "Guido van Rossum" a écrit :
>>> 4. Bad code gets cargo-culted (e.g. through StackOverflow).
>>
>>> Re (4): With PEP 524, people worried about blocking may be driven to
>>>
On 6 August 2016 at 18:32, Victor Stinner wrote:
> Le 6 août 2016 04:39, "Guido van Rossum" a écrit :
>> 4. Bad code gets cargo-culted (e.g. through StackOverflow).
>
>> Re (4): With PEP 524, people worried about blocking may be driven to
>> unnecessarily write more complicated code using os.getr
Le 6 août 2016 04:39, "Guido van Rossum" a écrit :
> 4. Bad code gets cargo-culted (e.g. through StackOverflow).
> Re (4): With PEP 524, people worried about blocking may be driven to
> unnecessarily write more complicated code using os.getrandom(). With
> PEP 522, people worried about crashes ma
Thanks, Victor!
I've (mostly) read both PEPs and your summary.
It seems there are several risks that need to be weighed.
1. An important secret is generated using insufficient entropy.
2. An app blocks unnecessarily.
3. An app crashes unexpectedly.
4. Bad code gets cargo-culted (e.g. through Sta
Le 5 août 2016 9:42 PM, "Ethan Furman" a écrit :
> Can someone write a brief summary of the differences between the two?
Oh, it's hard to summarize. Let me try. As you may expect, my summary is
far from being fair :-D
--
The two PEPs propose a very different behaviour when os.urandom() would
bl
On 08/05/2016 12:24 PM, Victor Stinner wrote:
Would it be possible to take a decision on the PEP 522 and PEP 524?
Deadline for new features in Python 3.6 is in one month or something
like that, no?
My PEP:
https://www.python.org/dev/peps/pep-0524/
"PEP 524 -- Make os.urandom() blocking on Linux
28 matches
Mail list logo