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

2016-06-11 Thread Random832
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 same behavior?
> 
> 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
system call rather than a device (or an ioctl on the existing ones)? If
there's a benefit in not going through the non-atomic (and possibly
resource limited) procedure of acquiring a file descriptor, reading from
it, and closing it, why is that benefit not also extended to
non-cryptographic users of urandom via allowing the system call to be
used in that way?

> Anyway, if you don't need cryptographic guarantees, you don't need
> getrandom(2) or getentropy(2); something like this will do just fine:

Then what's /dev/urandom *for*, anyway?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Steven D'Aprano
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 on at least some embedded 
systems? The wiki thinks so:

https://wiki.python.org/moin/EmbeddedPython

And I thought that was the purpose of µPython.


> > Actually the proposal for that was the secrets module. And the secrets
> > module would be the only user of os.urandom(blocking=True).
> >
> > I’m fine if this lives in the secrets module— Steven asked for it to be an
> > os function so that secrets.py could continue to be pure python.
> 
> The main thing that I want to avoid is that people start cargo-culting
> whatever the secrets module uses rather than just using the secrets module.
> Having it redundantly available as os.getrandom() is just begging for
> people to show off how much they know about writing secure code.

That makes sense.

I'm happy for getrandom to be an implementation detail of secrets, but 
I'll need help with that part.


> >> * If you want to ensure you get cryptographically secure bytes,
> >> os.getrandom, falling back to os.urandom on non Linux platforms and
> >> erroring on Linux.
[...]

> But what is a Python script going to do with that error? IIUC this kind of
> error would only happen very early during boot time, and rarely, so the
> most likely outcome is a hard-to-debug mystery failure.

In my day job, I work for a Linux sys admin consulting company, and I 
can tell you from our experience that debugging a process that 
occasionally hangs mysteriously during boot is much harder than 
debugging a process that occasionally fails with an explicit error in 
the logs, especially if the error message is explicit about the cause:

OSError: entropy pool has not been initialized yet

At that point, you can take whatever action is appropriate for your 
script:

- fail altogether, just as it might fail if it requires a writable
  file system and can't find one;
- sleep for three seconds and try again;
- log the error and proceed with degraded randomness or functionality;
- change it so the script runs later in the boot process.




-- 
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Émanuel Barry
> 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 ``__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 arbitrary iterable, which get converted to a tuple at
> > runtime?
> 
> An arbitrary iterable does not necessarily infer a definition order.
> For example, dict is an iterable but the order is undefined.  Also,
> I'd rather favor simplicity for this (most likely) uncommon corner
> case of manually setting __definition_order__, particularly at the
> start.  If it proves to be a problematic restriction in the future we
> can loosen it.

Point. This can always be revised later (I'm probably overthinking this as 
always ;)

> 
> -eric

-Emanuel
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Eric Snow
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 arbitrary iterable, which get converted to a tuple at
> runtime?

An arbitrary iterable does not necessarily infer a definition order.
For example, dict is an iterable but the order is undefined.  Also,
I'd rather favor simplicity for this (most likely) uncommon corner
case of manually setting __definition_order__, particularly at the
start.  If it proves to be a problematic restriction in the future we
can loosen it.

> __slots__ allows any arbitrary iterable:

Yes, but __slots__ is not order-sensitive.

>> is already complete by the time ``definition_order__`` is set, the
>
> Typo: missing leading underscores in __definition_order__

I'll fix that.

>
>> Compatibility
>> =
>>
>> This PEP does not break backward compatibility, except in the case that
>> someone relies *strictly* on ``dict`` as the class definition namespace.
>> This shouldn't be a problem.
>
> Perhaps add a mention that isinstance(namespace, dict) will still be true,
> so users don't get unnecessarily confused.

Good point.

>
>> .__dict__ as OrderedDict
>> ---
>
>  looks weird to me. I tend to use `cls` (although `klass` isn't
> uncommon). `C` might also not be a bad choice.

Yes, that is better.

-eric
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Émanuel Barry
> 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
> identifiers or None (rather that using the value as-is).


>   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 arbitrary iterable, which get converted to a tuple at
runtime? __slots__ allows any arbitrary iterable:

>>> def g():
...   yield "foo"
...   yield "bar"
...   yield "baz"
>>> class C:
...   __slots__ = g()
>>> C.__slots__

>>> C.__slots__.gi_running
False
>>> dir(C)
[, 'bar', 'baz', 'foo']

> Use of a tuple reflects the fact that we are exposing the order in
> which attributes on the class were *defined*.  Since the definition
> is already complete by the time ``definition_order__`` is set, the
> content and order of the value won't be changing.  Thus we use a type
> that communicates that state of immutability.

Typo: missing leading underscores in __definition_order__

> Compatibility
> =
> 
> This PEP does not break backward compatibility, except in the case that
> someone relies *strictly* on ``dict`` as the class definition namespace.
> This shouldn't be a problem.

Perhaps add a mention that isinstance(namespace, dict) will still be true,
so users don't get unnecessarily confused.

> .__dict__ as OrderedDict
> ---

 looks weird to me. I tend to use `cls` (although `klass` isn't
uncommon). `C` might also not be a bad choice.

Thanks!
-Emanuel
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Theodore Ts'o
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) os.random is used to directly generate a
> > long-term cryptographic secret.  If you are fork openssl or ssh-keygen
> > to generate a public/private keypair, then you aren't using os.random.
> 
> 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?

The intention behind getrandom() is that it is intended *only* for
cryptographic purposes.  For that use case, there's no point having a
"return a potentially unseeded cryptographic secret" option.  This
makes this much like FreeBSD's /dev/random and getentropy system
calls.

(BTW, I've seen an assertion on this thread that FreeBSD's
getentropy(2) never blocks.  As far as I know, this is **not** true.
FreeBSD's getentropy(2) works like its /dev/random device, in that if
it is not fully seeded, it will block.  The only reason why OpenBSD's
getentropy(2) and /dev/random devices will never block is because they
only support architectures where they can make sure that entropy is
passed from a previous boot session to the next, given specialized
bootloader support.  Linux can't do this because we support a very
large number of bootloaders, and the bootloaders are not under the
kernel developers' control.  Fundamentally, you can't guarantee both
(a) that your RNG will never block, and (b) will always be of high
cryptographic quality, in a completely general sense.  You can if you
make caveats about your hardware or when the code runs, but that's
fundamentally the problem with the documentation of os.urandom(); it's
making promises which can't be true 100% of the time, for all
hardware, operating environments, etc.)

Anyway, if you don't need cryptographic guarantees, you don't need
getrandom(2) or getentropy(2); something like this will do just fine:

long getrand()
{
static int initialized = 0;
struct timeval tv;

if (!initialized) {
gettimeofday(, NULL);
srandom(tv.tv_sec ^ tv.tv_usec ^ getpid());
initialized++;
}
return random();
}

So this is why I did what I did.  If Python decides to go down this
same path, you could define a new interface ala getrandom(2), which is
specifically designed for cryptogaphic purposes, and perhaps a new,
more efficient interface for those people who don't need cryptogaphic
guarantees --- and then keep the behavior of os.urandom consistent
with Python 3.4, but update the documentation to reflect the reality.

Alternatively, you could keep the implementation of os.urandom
consistent with Python 3.5, and then document that under some
circumstances, it will block.  Both approaches have certain tradeoffs,
but it's not going to be the end of the world regardless of which way
you decide to go.   I'd suggest that you use your existing mechanisms
to decide on which approach is more Pythony, and then make sure you
communicate and over-communicate it to your user/developer base.

And then --- relax.  It may seem like a big deal today, but in a year
or so people will have gotten used to whatever interface or
documentation changes you decide to make, and it will be all fine.
As Dame Julian of Norwich once said, "All shall be well, and all shall
be well, and all manner of things shall be well."  

Cheers,

- Ted
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Eric Snow
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 been clarification.

Guido, at this point I believe the PEP is ready for pronouncement. *
I've included the most recent copy of the text below.  Thanks.

-eric

==

PEP: 520
Title: Ordered Class Definition Namespace
Version: $Revision$
Last-Modified: $Date$
Author: Eric Snow 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 7-Jun-2016
Python-Version: 3.6
Post-History: 7-Jun-2016


Abstract


When a class is defined using a ``class`` statement, the class body is
executed within a namespace.  After the execution completes, that
namespace is copied into new ``dict`` and the original definition
namespace is discarded.  The new copy is stored away as the class's
namespace and is exposed as ``__dict__`` through a read-only proxy.

This PEP changes the default class definition namespace to ``OrderedDict``.
The long-lived class namespace (``__dict__``) will remain a ``dict``.
Furthermore, the order in which the attributes are defined in each class
body will now be preserved in the ``__definition_order__`` attribute of
the class.  This allows introspection of the original definition order,
e.g. by class decorators.


Motivation
==

Currently the namespace used during execution of a class body defaults
to ``dict``.  If the metaclass defines ``__prepare__()`` then the result
of calling it is used.  Thus, before this PEP, if you needed your class
definition namespace to be ``OrderedDict`` you had to use a metaclass.

Metaclasses introduce an extra level of complexity to code and in some
cases (e.g. conflicts) are a problem.  So reducing the need for them is
worth doing when the opportunity presents itself.  Given that we now have
a C implementation of ``OrderedDict`` and that ``OrderedDict`` is the
common use case for ``__prepare__()``, we have such an opportunity by
defaulting to ``OrderedDict``.

The usefulness of ``OrderedDict``-by-default is greatly increased if the
definition order is directly introspectable on classes afterward,
particularly by code that is independent of the original class definition.
One of the original motivating use cases for this PEP is generic class
decorators that make use of the definition order.

Changing the default class definition namespace has been discussed a
number of times, including on the mailing lists and in PEP 422 and
PEP 487 (see the References section below).


Specification
=

* the default class *definition* namespace is now ``OrderdDict``
* the order in which class attributes are defined is preserved in the
  new ``__definition_order__`` attribute on each class
* "dunder" attributes (e.g. ``__init__``, ``__module__``) are ignored
* ``__definition_order__`` is a ``tuple`` (or ``None``)
* ``__definition_order__`` is a read-only attribute
* ``__definition_order__`` is always set:

  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``
  2. classes that do not have a class definition (e.g. builtins) have
 their ``__definition_order__`` set to ``None``
  3. classes for which `__prepare__()`` returned something other than
 ``OrderedDict`` (or a subclass) have their ``__definition_order__``
 set to ``None`` (except where #1 applies)

The following code demonstrates roughly equivalent semantics for the
default behavior::

   class Meta(type):
   def __prepare__(cls, *args, **kwargs):
   return OrderedDict()

   class Spam(metaclass=Meta):
   ham = None
   eggs = 5
   __definition_order__ = tuple(k for k in locals()
if not (k.startswith('__') and
k.endswith('__')))

Note that [pep487_] proposes a similar solution, albeit as part of a
broader proposal.

Why a tuple?


Use of a tuple reflects the fact that we are exposing the order in
which attributes on the class were *defined*.  Since the definition
is already complete by the time ``definition_order__`` is set, the
content and order of the value won't be changing.  Thus we use a type
that communicates that state of immutability.

Why a read-only attribute?
--

As with the use of tuple, making ``__definition_order__`` a read-only
attribute communicates the fact that the information it represents is
complete.  Since it represents the state of a particular one-time event
(execution of the class definition body), allowing the value to be
replaced would reduce confidence that the attribute corresponds to the
original class body.

If a use case for a writable (or mutable) 

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

2016-06-11 Thread Tim Peters
[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 directly return bytes.

`secrets.token_bytes()` does just that, and other token_XXX()
functions return bytes too but with different spellings (e.g., if you
want, with the byte values represented as ASCII hex digits)..

I believe everyone agrees token_bytes() will potentially block in 3.6
(along with all the other `secrets` facilities) on platforms
supporting getrandom().

You're right that `random` doesn't expose such a function, and that
the closest it gets is .getrandbits() (which returns a potentially
giant int).  So far, nobody has proposed adding new functions to
`random`.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Larry Hastings

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 or not it's a suitable source of 
entropy to use for seeding urandom.


   https://en.wikipedia.org/wiki/RdRand#Reception

Wikipedia goes on to describe the very-new RDSEED instruction which 
might be more suitable.



//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Stephen J. Turnbull
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, separate, entropy pools):
 > 
 > open("/dev/urandom", "w").write("hello world")

This fails for unprivileged users on Mac.  I'm not sure what happens
on Linux; it appears to succeed, but the result wasn't what I
expected.

Also, when entropy gets low, it's not clear how additional entropy is
allocated between the /dev/random and /dev/urandom pools.

 > But of course there's the question of where you're going to get a
 > source of noise to write to the file. While it's (probably?) 
 > harmless to write a hard-coded string to it, I don't think its
 > going to give you much entropy.

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!  I would guess you can probably get something with a USB
interface for $20 or so.
http://scruss.com/blog/2013/06/07/well-that-was-unexpected-the-raspberry-pis-hardware-random-number-generator/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Random832
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 and then converted from that to
calculations per second. Is there any other particular basis for
considering it "right"?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Guido van Rossum
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 (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Larry Hastings



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 this an argument--merely some observations.


First, simply as a practical matter: the secrets module is currently 
pure Python.  ISTM that the os module is where we put miscellaneous bits 
of os functionality; getrandom() definitely falls into that category.  
Rather than adding a new _secrets module or whatever it seemed easiest 
just to add it there.


Second, I'd put this under the "consenting adults" rule.  Clearly 
cryptography is a contentious subject with sharply differing opinions.  
There are many, many cryptography libraries available on PyPi; perhaps 
those libraries would like to use getrandom(), or /dev/urandom, or even 
getentropy(), in a way different than how secrets does it.  My thinking 
is, the os module should provide platform support, the secrets module 
should be our codified best-practices, and we encourage everyone to use 
secrets.  I'd go so far as to add that recommendation to the doc *and* 
the docstrings of os.urandom(), random.SystemRandom, and os.getrandom() 
(and os.getentropy()) if we add it.  But by providing the OS 
functionality in a neutral way we allow external cryptographers to write 
what *they* view as best-practices code without wading into 
implementation detalis of secrets, or using ctypes, or whatnot.



But like I said I don't have a strong opinion.  As long as we're not 
adding mysterious flags to os.urandom() I'll probably sit the rest of 
this one out.



//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] PEP 468

2016-06-11 Thread Franklin? Lee
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 purposes, including kwargs and class definition. If
CPython implements efficient compact dicts, it would be easier to propose
order-preserving (or initially-order-preserving) dicts in some places in
the standard.

[1] Whether delitem preserves order depends on whether you want to allow
gaps in your compact entry table. PyPy implemented compact dicts and
chose(?) to make dicts ordered.

On Saturday, June 11, 2016, Eric Snow  wrote:

> On Fri, Jun 10, 2016 at 11:54 AM, Franklin? Lee
> > wrote:
> > Eric, have you any work in progress on compact dicts?
>
> Nope.  I presume you are talking the proposal Raymond made a while back.
>
> -eric
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Donald Stufft

> 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:
>> 
>> Yeah, but we've already established that there's a lot more upset, rhetoric 
>> and worry than warranted by the situation.
> 
> Have we? There are real, documented security failures in the wild because of 
> /dev/urandom’s behavior. This isn’t just a theoretical problem, it actually 
> has had consequences in real life, and those same consequences could just 
> have easily happened to Python (in one of the cases that most recently comes 
> to mind it was a C program, but that’s not really relevant because the same 
> problem would have happened if they had written in Python using os.urandom in 
> 3.4 but not in 3.5.0 or 3.5.1.
> 
> Actually it's not clear to me at all that it could have happened to Python. 
> (Wasn't it an embedded system?)

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 a shell script that 
called ssh-keygen.

>> Actually the proposal for that was the secrets module. And the secrets 
>> module would be the only user of os.urandom(blocking=True).
> 
> I’m fine if this lives in the secrets module— Steven asked for it to be an os 
> function so that secrets.py could continue to be pure python.
> 
> The main thing that I want to avoid is that people start cargo-culting 
> whatever the secrets module uses rather than just using the secrets module. 
> Having it redundantly available as os.getrandom() is just begging for people 
> to show off how much they know about writing secure code. 


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 os.urandom and hope that it’s been seeded and add a 
SecurityWarning or something like it to mention that it’s falling back to 
os.urandom and it may be getting predictable random from /dev/urandom.
* Hard fail because it can’t guarantee secure cryptographic random.

Of the three, I would probably suggest the second one, it doesn’t let the 
problem happen silently, but it still “works” (where it’s basically just hoping 
it’s being called late enough that /dev/urandom has been seeded), and people 
can convert it to the third case using the warnings module to turn the warning 
into an exception.


>>  
>> * If you want to ensure you get cryptographically secure bytes, 
>> os.getrandom, falling back to os.urandom on non Linux platforms and erroring 
>> on Linux.
>> 
>> "Erroring" doesn't sound like it satisfies the "ensure" part of the 
>> requirement. And I don't see the advantage of os.getrandom() over the 
>> secrets module. (Either way you have to fall back on os.urandom() to 
>> suppport Python 3.5 and before.)
> 
> Erroring does satisfy the ensure part, because if it’s not possible to get 
> cryptographically secure bytes then the only option is to error if you want 
> to be ensured of cryptographically secure bytes. 
> 
> It’s a bit like if you did open(“somefile.txt”), it’s reasonable to say that 
> we should ensure that open(“somefile.txt”) actually opens ./somefile.txt, and 
> doesn’t randomly open a different file if ./somefile.txt doesn’t exist— if it 
> can’t open ./somefile.txt it should error. If I *need* cryptographically 
> secure random bytes, and I’m on a platform that doesn’t provide those, then 
> erroring is often times the correct behavior. This is such an important thing 
> that OS X will flat out kernel panic and refuse to boot if it can’t ensure 
> that it can give people cryptographically secure random bytes.
> 
> But what is a Python script going to do with that error? IIUC this kind of 
> error would only happen very early during boot time, and rarely, so the most 
> likely outcome is a hard-to-debug mystery failure.

Depends on why they’re calling it, which is sort of the underlying problem I 
suspect with why there isn’t agreement about what the right default behavior 
is. The correct answer for some application might be to hard fail and wait for 
the operator to fix the environment that it’s running in. It depends on how 
important the thing that is getting this random is.

One example: If I was writing a communication platform for people who are 
fighting oppressive regimes or to securely discuss sexual orientation in more 
dangerous parts of the world, I would want to make this program hard fail if it 
couldn’t ensure that it was using an interface that ensured cryptographic 
random, because the alternative is 

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

2016-06-11 Thread Tim Peters
[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 might be better than
> anything else. Then the secrets module is just what we recommend new users
> on Python 3.6.

There's an issue currently open about this:

http://bugs.python.org/issue27288

The docs for SystemRandom are very brief, so people may have actually
noticed ;-) the first sentence:

Class that uses the os.urandom() function for generating random numbers ...

IOW, "uses os.urandom()" has been one of its only advertised qualities.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Guido van Rossum
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
> that's unnecessarily complicated and believed to be secure without anybody
> ever verifying.
>
>
>
> Well, new enough Linux has getrandom(0), OpenBSD has getentropy(), Solaris
> has getrandom(), Windows has CryptGenRandom which all make it possible (or
> it’s the only way to invoke it) to get cryptographically secure random
> bytes or block and no in-between. So it’d likely be possible to have
> os.getrandom() with blocking semantics and no FD on all of the most popular
> platforms we support.
>
> If we relax the no FD then FreeBSD and OS X also have /dev/random (or
> /dev/urandom it’s the same thing) which will ensure that you give
> cryptographically secure random bytes.
>

OK, so we should implement the best we can do for the secrets module, and
leave os.urandom() alone. I think the requirement that the secrets module
remain pure Python has to be dropped. I'm not sure what it should do if
even blocking can't give it sufficiently strong random bytes, but I care
much less -- it's a new API and it doesn't resemble any OS function, so as
long as it is documented it should be fine.

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 might be better than
anything else. Then the secrets module is just what we recommend new users
on Python 3.6.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Guido van Rossum
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 are real, documented security failures in the wild because
> of /dev/urandom’s behavior. This isn’t just a theoretical problem, it
> actually has had consequences in real life, and those same consequences
> could just have easily happened to Python (in one of the cases that most
> recently comes to mind it was a C program, but that’s not really relevant
> because the same problem would have happened if they had written in Python
> using os.urandom in 3.4 but not in 3.5.0 or 3.5.1.
>

Actually it's not clear to me at all that it could have happened to Python.
(Wasn't it an embedded system?)

> Actually the proposal for that was the secrets module. And the secrets
> module would be the only user of os.urandom(blocking=True).
>
>
> I’m fine if this lives in the secrets module— Steven asked for it to be an
> os function so that secrets.py could continue to be pure python.
>

The main thing that I want to avoid is that people start cargo-culting
whatever the secrets module uses rather than just using the secrets module.
Having it redundantly available as os.getrandom() is just begging for
people to show off how much they know about writing secure code.

>
>
>> * If you want to ensure you get cryptographically secure bytes,
>> os.getrandom, falling back to os.urandom on non Linux platforms and
>> erroring on Linux.
>>
>
> "Erroring" doesn't sound like it satisfies the "ensure" part of the
> requirement. And I don't see the advantage of os.getrandom() over the
> secrets module. (Either way you have to fall back on os.urandom() to
> suppport Python 3.5 and before.)
>
>
> Erroring does satisfy the ensure part, because if it’s not possible to get
> cryptographically secure bytes then the only option is to error if you want
> to be ensured of cryptographically secure bytes.
>

> It’s a bit like if you did open(“somefile.txt”), it’s reasonable to say
> that we should ensure that open(“somefile.txt”) actually opens
> ./somefile.txt, and doesn’t randomly open a different file if
> ./somefile.txt doesn’t exist— if it can’t open ./somefile.txt it should
> error. If I *need* cryptographically secure random bytes, and I’m on a
> platform that doesn’t provide those, then erroring is often times the
> correct behavior. This is such an important thing that OS X will flat out
> kernel panic and refuse to boot if it can’t ensure that it can give people
> cryptographically secure random bytes.
>

But what is a Python script going to do with that error? IIUC this kind of
error would only happen very early during boot time, and rarely, so the
most likely outcome is a hard-to-debug mystery failure.


> It’s a fairly simple decision tree, I go “hey, give me cryptographically
> secure random bytes, and only cryptographically secure random bytes”. If it
> cannot give them to me because the APIs of the system cannot guarantee they
> are cryptographically secure then there are only two options, either A) it
> is explicit about it’s inability to do this and raises an error or B) it
> does something completely different than what I asked it to do and pretends
> that it’s what I wanted.
>

I really don't believe that there is only one kind of cryptographically
secure random bytes. There are many different applications (use cases) of
randomness and they need different behaviors. (If it was simple we wouldn't
still be arguing. :-)

>
>
>> * If you want to *ensure* that there’s no blocking, then os.urandom on
>> Linux (or os.urandom wrapped with timeout code anywhere else, as that’s the
>> only way to ensure not blocking cross platform).
>>
>
> That's fine with me.
>
>
>> * If you just don’t care, YOLO it up with either os.urandom or
>> os.getrandom or random.random.
>>
>
> Now you're just taking the mickey.
>
>
> No I’m not— random.Random is such a use case where it wants to seed with
> as secure of bytes as it can get it’s hands on, but it doesn’t care if it
> falls back to insecure bytes if it’s not possible to get secure bytes. This
> code even falls back to using time as a seed if all else fails.
>

Fair enough. The hash randomization is the other case I suppose (since not
running any Python code at all isn't an option, and neither is waiting
indefinitely before the user's code gets control).

It does show the point that there are different use cases with different
needs. But I think the stdlib should limit the choices.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Donald Stufft

> 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 anybody ever 
> verifying.



Well, new enough Linux has getrandom(0), OpenBSD has getentropy(), Solaris has 
getrandom(), Windows has CryptGenRandom which all make it possible (or it’s the 
only way to invoke it) to get cryptographically secure random bytes or block 
and no in-between. So it’d likely be possible to have os.getrandom() with 
blocking semantics and no FD on all of the most popular platforms we support.

If we relax the no FD then FreeBSD and OS X also have /dev/random (or 
/dev/urandom it’s the same thing) which will ensure that you give 
cryptographically secure random bytes.

—
Donald Stufft



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Guido van Rossum
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 cryptographically secure random because Python
> called getrandom() or if it got back cryptographically secure random
> because it called /dev/urandom and that gave it secure random because it’s
> on a platform that defines that as always returning secure or because it’s
> on Linux and the urandom pool is initialized or if it got back some random
> bytes that are not cryptographically secure because it fell back to reading
> /dev/urandom on Linux prior to the pool being initialized.
>
>
> Let me jump in tangentially to say: I think os.urandom(block=True) is
> simply a bad API.  On FreeBSD and OpenBSD, /dev/urandom may block, and you
> don't have a choice.  On OS X, /dev/urandom will never block, and you don't
> have a choice.  In Victor's initial patch where he proposed it, the flag
> was accepted on all platforms but only affected its behavior on Linux and
> possibly Solaris.  I think it's bad API design to have a flag that seems
> like it would be meaningful on multiple platforms, but in practice is
> useful only in very limited circumstances.  If this were old code, or
> behavior we inherited from the platform and we were making the best of a
> bad situation, that'd be one thing.  But this is a proposed new API and I
> definitely think we can do better.
>
> As I understand the proposed semantics for os.urandom(exception=True), I
> feel it falls into the same trap though not to the same degree.
>
> Of course, both flags break backwards-compatibility if they default to
> True, and I strongly disagree with .
>
> It's far better in my opinion to keep the os module as a thin shell over
> platform functionality.  That makes Python's behavior more predictable on a
> platform-by-platform basis.  So I think the best approach here is to add
> os.getrandom() as a thin shell over the local getrandom() (if any).
>

OK, the flags are unpopular, so let's forget about them.

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 anybody
ever verifying.

I'd like to consider what people freak out about.

- You could freak out about blocking

- You could freak out about getting slightly less random bits

- You could freak out about supporting Python 3.5 and earlier

- You could freak out about supporting all platforms

You could also freak out about combinations of the above, but that gets
complicated and you should probably consider that you're over-constraining
matters. If you freak out about all at once (or both the first and the
second bullet) you should consider a career change.

If you don't freak out about any of these (meaning you're happy with Python
3.6+) you should use the secrets module.

If you freak out about support for older Python versions, try the secrets
module first and fall back to os.urandom() -- there really isn't any other
choice.

If you freak out about getting slightly less random bits you should
probably do a complete security assessment of your entire stack and fix the
OS and Python version, and use the best you can get for that combination.
You may not want to rely on the standard library at all.

If you freak out about blocking you're probably on a specific platform, and
if that platform is Linux, you're in luck: use os.urandom() and avoid
Python 3.5.0 and 3.5.1. On other platforms you're out of luck.

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

So what should the secrets module use? Let's make that part an extension
module.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Donald Stufft

> 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 semantics (well, it will try to use 
getrandom(GRD_NONBLOCK) but falls back to /dev/urandom if that would have 
blocked).

—
Donald Stufft



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Donald Stufft

> 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:
>> 
>> 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 -- 
>> and the latter category should be checking platform and versions anyway 
>> since they need the whole stack to be secure (if I understand Ted Ts'o's 
>> email right).
>> 
>> My assumption is also that the flags should be hints (perhaps only relevant 
>> on Linux) -- platforms that can't perform the action desired (because their 
>> system's API doesn't support it) would just do their default action, 
>> assuming the system API does the best it can.
> 
> 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 cryptographically secure random because it called /dev/urandom 
> and that gave it secure random because it’s on a platform that defines that 
> as always returning secure or because it’s on Linux and the urandom pool is 
> initialized or if it got back some random bytes that are not 
> cryptographically secure because it fell back to reading /dev/urandom on 
> Linux prior to the pool being initialized.
> 
> The “silently does the wrong thing, even though I explicitly asked for it do 
> something different” is something that I would consider to be a footgun and 
> footgun’s in security sensitive code make me really worried.
> 
> Yeah, but we've already established that there's a lot more upset, rhetoric 
> and worry than warranted by the situation.


Have we? There are real, documented security failures in the wild because of 
/dev/urandom’s behavior. This isn’t just a theoretical problem, it actually has 
had consequences in real life, and those same consequences could just have 
easily happened to Python (in one of the cases that most recently comes to mind 
it was a C program, but that’s not really relevant because the same problem 
would have happened if they had written in Python using os.urandom in 3.4 but 
not in 3.5.0 or 3.5.1.

>  
> Outside of the security side of things, if someone goes “Ok I need some 
> random bytes and I need to make sure it doesn’t block”, then doing 
> ``os.random(block=False, exception=False)`` isn’t going to make sure that it 
> doesn’t block except on Linux.
> 
> To people who "just want some random bytes" we should recommend the random 
> module.
>  
> In other words, it’s basically impossible to ensure you get the behavior you 
> want with these flags which I feel like will make everyone unhappy (both the 
> people who want to ensure non-blocking, and the people who want to ensure 
> cryptographically secure). These flags are an attractive nuisance that look 
> like they do the right thing, but silently don’t.
> 
> OK, it looks like the flags just won't make you happy, and I'm happy to give 
> up on them. By default the status quo will win, and that means neither these 
> flags nor os.getrandom(). (But of course you can roll your own using ctypes. 
> :-)
>  
> Meanwhile if we have os.urandom that reads from /dev/urandom and 
> os.getrandom() which reads from blocking random, then we make it both easier 
> to ensure you get the behavior you want, either by using the function that 
> best suits your needs:
> 
> * If you just want the best the OS has to offer, os.getrandom falling back to 
> os.urandom.
> 
> Actually the proposal for that was the secrets module. And the secrets module 
> would be the only user of os.urandom(blocking=True).

I’m fine if this lives in the secrets module— Steven asked for it to be an os 
function so that secrets.py could continue to be pure python.

>  
> * If you want to ensure you get cryptographically secure bytes, os.getrandom, 
> falling back to os.urandom on non Linux platforms and erroring on Linux.
> 
> "Erroring" doesn't sound like it satisfies the "ensure" part of the 
> requirement. And I don't see the advantage of os.getrandom() over the secrets 
> module. (Either way you have to fall back on os.urandom() to suppport Python 
> 3.5 and before.)

Erroring does satisfy the ensure part, because if it’s not possible to get 
cryptographically secure bytes then the only option is to error if you want to 
be ensured of cryptographically secure bytes.

It’s a bit like if you did open(“somefile.txt”), it’s reasonable to say that we 
should ensure that open(“somefile.txt”) actually opens ./somefile.txt, and 
doesn’t randomly open a different 

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

2016-06-11 Thread Brett Cannon
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 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?

On Sat, Jun 11, 2016, 12:41 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:
>>
>> 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 --
>> and the latter category should be checking platform and versions anyway
>> since they need the whole stack to be secure (if I understand Ted Ts'o's
>> email right).
>>
>> My assumption is also that the flags should be hints (perhaps only
>> relevant on Linux) -- platforms that can't perform the action desired
>> (because their system's API doesn't support it) would just do their default
>> action, assuming the system API does the best it can.
>>
>>
>> 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 cryptographically secure random
>> because it called /dev/urandom and that gave it secure random because it’s
>> on a platform that defines that as always returning secure or because it’s
>> on Linux and the urandom pool is initialized or if it got back some random
>> bytes that are not cryptographically secure because it fell back to reading
>> /dev/urandom on Linux prior to the pool being initialized.
>>
>> The “silently does the wrong thing, even though I explicitly asked for it
>> do something different” is something that I would consider to be a footgun
>> and footgun’s in security sensitive code make me really worried.
>>
>
> Yeah, but we've already established that there's a lot more upset,
> rhetoric and worry than warranted by the situation.
>
>
>> Outside of the security side of things, if someone goes “Ok I need some
>> random bytes and I need to make sure it doesn’t block”, then doing
>> ``os.random(block=False, exception=False)`` isn’t going to make sure that
>> it doesn’t block except on Linux.
>>
>
> To people who "just want some random bytes" we should recommend the random
> module.
>
>
>> In other words, it’s basically impossible to ensure you get the behavior
>> you want with these flags which I feel like will make everyone unhappy
>> (both the people who want to ensure non-blocking, and the people who want
>> to ensure cryptographically secure). These flags are an attractive nuisance
>> that look like they do the right thing, but silently don’t.
>>
>
> OK, it looks like the flags just won't make you happy, and I'm happy to
> give up on them. By default the status quo will win, and that means neither
> these flags nor os.getrandom(). (But of course you can roll your own using
> ctypes. :-)
>
>
>> Meanwhile if we have os.urandom that reads from /dev/urandom and
>> os.getrandom() which reads from blocking random, then we make it both
>> easier to ensure you get the behavior you want, either by using the
>> function that best suits your needs:
>>
>> * If you just want the best the OS has to offer, os.getrandom falling
>> back to os.urandom.
>>
>
> Actually the proposal for that was the secrets module. And the secrets
> module would be the only user of os.urandom(blocking=True).
>
>
>> * If you want to ensure you get cryptographically secure bytes,
>> os.getrandom, falling back to os.urandom on non Linux platforms and
>> erroring on Linux.
>>
>
> "Erroring" doesn't sound like it satisfies the "ensure" part of the
> requirement. And I don't see the advantage of os.getrandom() over the
> secrets module. (Either way you have to fall back on os.urandom() to
> suppport Python 3.5 and before.)
>
>
>> * If you want to *ensure* that there’s no blocking, then os.urandom on
>> Linux (or os.urandom wrapped with timeout code anywhere else, as that’s the
>> only way to ensure not blocking cross platform).
>>
>
> That's fine with me.
>
>
>> * If you just don’t care, YOLO it up with either os.urandom or
>> os.getrandom or random.random.
>>
>
> Now you're just taking the mickey.
>
>
>>
>> I think the problem with making os.urandom() go back to always reading
>> /dev/urandom is that we've come to rely on it on all platforms, so we've
>> passed that station.
>>
>>
>> Sorry, to be more specific I meant the 3.4 behavior, which was
>> 

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

2016-06-11 Thread Larry Hastings


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 cryptographically 
secure random because it called /dev/urandom and that gave it secure 
random because it’s on a platform that defines that as always 
returning secure or because it’s on Linux and the urandom pool is 
initialized or if it got back some random bytes that are not 
cryptographically secure because it fell back to reading /dev/urandom 
on Linux prior to the pool being initialized.


Let me jump in tangentially to say: I think os.urandom(block=True) is 
simply a bad API.  On FreeBSD and OpenBSD, /dev/urandom may block, and 
you don't have a choice.  On OS X, /dev/urandom will never block, and 
you don't have a choice.  In Victor's initial patch where he proposed 
it, the flag was accepted on all platforms but only affected its 
behavior on Linux and possibly Solaris.  I think it's bad API design to 
have a flag that seems like it would be meaningful on multiple 
platforms, but in practice is useful only in very limited 
circumstances.  If this were old code, or behavior we inherited from the 
platform and we were making the best of a bad situation, that'd be one 
thing.  But this is a proposed new API and I definitely think we can do 
better.


As I understand the proposed semantics for os.urandom(exception=True), I 
feel it falls into the same trap though not to the same degree.


Of course, both flags break backwards-compatibility if they default to 
True, and I strongly disagree with .


It's far better in my opinion to keep the os module as a thin shell over 
platform functionality.  That makes Python's behavior more predictable 
on a platform-by-platform basis.  So I think the best approach here is 
to add os.getrandom() as a thin shell over the local getrandom() (if any).



//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Guido van Rossum
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 getrandom()?
>
> My assumption was that nobody would actually use these flags except the
> secrets module and people writing code that generates long-lived secrets --
> and the latter category should be checking platform and versions anyway
> since they need the whole stack to be secure (if I understand Ted Ts'o's
> email right).
>
> My assumption is also that the flags should be hints (perhaps only
> relevant on Linux) -- platforms that can't perform the action desired
> (because their system's API doesn't support it) would just do their default
> action, assuming the system API does the best it can.
>
>
> 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 cryptographically secure random
> because it called /dev/urandom and that gave it secure random because it’s
> on a platform that defines that as always returning secure or because it’s
> on Linux and the urandom pool is initialized or if it got back some random
> bytes that are not cryptographically secure because it fell back to reading
> /dev/urandom on Linux prior to the pool being initialized.
>
> The “silently does the wrong thing, even though I explicitly asked for it
> do something different” is something that I would consider to be a footgun
> and footgun’s in security sensitive code make me really worried.
>

Yeah, but we've already established that there's a lot more upset, rhetoric
and worry than warranted by the situation.


> Outside of the security side of things, if someone goes “Ok I need some
> random bytes and I need to make sure it doesn’t block”, then doing
> ``os.random(block=False, exception=False)`` isn’t going to make sure that
> it doesn’t block except on Linux.
>

To people who "just want some random bytes" we should recommend the random
module.


> In other words, it’s basically impossible to ensure you get the behavior
> you want with these flags which I feel like will make everyone unhappy
> (both the people who want to ensure non-blocking, and the people who want
> to ensure cryptographically secure). These flags are an attractive nuisance
> that look like they do the right thing, but silently don’t.
>

OK, it looks like the flags just won't make you happy, and I'm happy to
give up on them. By default the status quo will win, and that means neither
these flags nor os.getrandom(). (But of course you can roll your own using
ctypes. :-)


> Meanwhile if we have os.urandom that reads from /dev/urandom and
> os.getrandom() which reads from blocking random, then we make it both
> easier to ensure you get the behavior you want, either by using the
> function that best suits your needs:
>
> * If you just want the best the OS has to offer, os.getrandom falling back
> to os.urandom.
>

Actually the proposal for that was the secrets module. And the secrets
module would be the only user of os.urandom(blocking=True).


> * If you want to ensure you get cryptographically secure bytes,
> os.getrandom, falling back to os.urandom on non Linux platforms and
> erroring on Linux.
>

"Erroring" doesn't sound like it satisfies the "ensure" part of the
requirement. And I don't see the advantage of os.getrandom() over the
secrets module. (Either way you have to fall back on os.urandom() to
suppport Python 3.5 and before.)


> * If you want to *ensure* that there’s no blocking, then os.urandom on
> Linux (or os.urandom wrapped with timeout code anywhere else, as that’s the
> only way to ensure not blocking cross platform).
>

That's fine with me.


> * If you just don’t care, YOLO it up with either os.urandom or
> os.getrandom or random.random.
>

Now you're just taking the mickey.


>
> I think the problem with making os.urandom() go back to always reading
> /dev/urandom is that we've come to rely on it on all platforms, so we've
> passed that station.
>
>
> Sorry, to be more specific I meant the 3.4 behavior, which was
> open(“/dev/urandom”).read() on *nix and CryptGenRandom on Windows.
>

I am all for keeping it that way. The secrets module doesn't have to use
any of these, it can use an undocumented extension module for all I care.
Or it can use os.urandom() and trust Ted Ts'o.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Brett Cannon
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()?
>
> My assumption was that nobody would actually use these flags except the
> secrets module and people writing code that generates long-lived secrets --
> and the latter category should be checking platform and versions anyway
> since they need the whole stack to be secure (if I understand Ted Ts'o's
> email right).
>
> My assumption is also that the flags should be hints (perhaps only
> relevant on Linux) -- platforms that can't perform the action desired
> (because their system's API doesn't support it) would just do their default
> action, assuming the system API does the best it can.
>
>
> 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 cryptographically secure random
> because it called /dev/urandom and that gave it secure random because it’s
> on a platform that defines that as always returning secure or because it’s
> on Linux and the urandom pool is initialized or if it got back some random
> bytes that are not cryptographically secure because it fell back to reading
> /dev/urandom on Linux prior to the pool being initialized.
>
> The “silently does the wrong thing, even though I explicitly asked for it
> do something different” is something that I would consider to be a footgun
> and footgun’s in security sensitive code make me really worried.
>
> Outside of the security side of things, if someone goes “Ok I need some
> random bytes and I need to make sure it doesn’t block”, then doing
> ``os.random(block=False, exception=False)`` isn’t going to make sure that
> it doesn’t block except on Linux.
>
> In other words, it’s basically impossible to ensure you get the behavior
> you want with these flags which I feel like will make everyone unhappy
> (both the people who want to ensure non-blocking, and the people who want
> to ensure cryptographically secure). These flags are an attractive nuisance
> that look like they do the right thing, but silently don’t.
>
> Meanwhile if we have os.urandom that reads from /dev/urandom and
> os.getrandom() which reads from blocking random, then we make it both
> easier to ensure you get the behavior you want, either by using the
> function that best suits your needs:
>
> * If you just want the best the OS has to offer, os.getrandom falling back
> to os.urandom.
> * If you want to ensure you get cryptographically secure bytes,
> os.getrandom, falling back to os.urandom on non Linux platforms and
> erroring on Linux.
> * If you want to *ensure* that there’s no blocking, then os.urandom on
> Linux (or os.urandom wrapped with timeout code anywhere else, as that’s the
> only way to ensure not blocking cross platform).
> * If you just don’t care, YOLO it up with either os.urandom or
> os.getrandom or random.random.
>

I'm +1 w/ what Donald is suggesting here and below w/ proper documentation
in both the secrets and random modules to explain when to use what (i.e.
secrets for crypto-no-matter-what randomness, random for quick-and-dirty
randomness). This also includes any appropriate decoupling of the secrets
module from the random module so there's no reliance on the random module
in the docs of the secrets module beyond "this class has the same
interface", and letting the secrets module be the way people generally get
crypto randomness.

-Brett


>
>
> I think the problem with making os.urandom() go back to always reading
> /dev/urandom is that we've come to rely on it on all platforms, so we've
> passed that station.
>
>
> Sorry, to be more specific I meant the 3.4 behavior, which was
> open(“/dev/urandom”).read() on *nix and CryptGenRandom on Windows.
>
>
> —
>
> Donald Stufft
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Donald Stufft

> 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 except the 
> secrets module and people writing code that generates long-lived secrets -- 
> and the latter category should be checking platform and versions anyway since 
> they need the whole stack to be secure (if I understand Ted Ts'o's email 
> right).
> 
> My assumption is also that the flags should be hints (perhaps only relevant 
> on Linux) -- platforms that can't perform the action desired (because their 
> system's API doesn't support it) would just do their default action, assuming 
> the system API does the best it can.

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 cryptographically secure random because it called /dev/urandom and that 
gave it secure random because it’s on a platform that defines that as always 
returning secure or because it’s on Linux and the urandom pool is initialized 
or if it got back some random bytes that are not cryptographically secure 
because it fell back to reading /dev/urandom on Linux prior to the pool being 
initialized.

The “silently does the wrong thing, even though I explicitly asked for it do 
something different” is something that I would consider to be a footgun and 
footgun’s in security sensitive code make me really worried.

Outside of the security side of things, if someone goes “Ok I need some random 
bytes and I need to make sure it doesn’t block”, then doing 
``os.random(block=False, exception=False)`` isn’t going to make sure that it 
doesn’t block except on Linux.

In other words, it’s basically impossible to ensure you get the behavior you 
want with these flags which I feel like will make everyone unhappy (both the 
people who want to ensure non-blocking, and the people who want to ensure 
cryptographically secure). These flags are an attractive nuisance that look 
like they do the right thing, but silently don’t.

Meanwhile if we have os.urandom that reads from /dev/urandom and os.getrandom() 
which reads from blocking random, then we make it both easier to ensure you get 
the behavior you want, either by using the function that best suits your needs:

* If you just want the best the OS has to offer, os.getrandom falling back to 
os.urandom.
* If you want to ensure you get cryptographically secure bytes, os.getrandom, 
falling back to os.urandom on non Linux platforms and erroring on Linux.
* If you want to *ensure* that there’s no blocking, then os.urandom on Linux 
(or os.urandom wrapped with timeout code anywhere else, as that’s the only way 
to ensure not blocking cross platform).
* If you just don’t care, YOLO it up with either os.urandom or os.getrandom or 
random.random.

> 
> I think the problem with making os.urandom() go back to always reading 
> /dev/urandom is that we've come to rely on it on all platforms, so we've 
> passed that station.
> 

Sorry, to be more specific I meant the 3.4 behavior, which was 
open(“/dev/urandom”).read() on *nix and CryptGenRandom on Windows.


—
Donald Stufft



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Guido van Rossum
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
>> - 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 API' should be a parameter, not a new function. With just
> two choices, 'wait' = True/False  could work.  If 'raise an exception' were
> added, then
> 'action (when good bits are not immediately available' =
> 'return (best possible)' or
> 'wait (until have good bits)' or
> 'raise (CryptBitsNotAvailable)'
>
> In either case, there would then be the question of whether the default
> should match 3.5.0/1 or 3.4 and before.
> '''
>
> Deciding on this then might have saved some hurt feelings, to the point
> where two contributors feel like disappearing, and a release manager must
> feel the same.  In any case, Guido already picked 3.4 behavior as the
> default.  Can we agree and move on?
>
> --
> Terry Jan Reedy
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Chi Hsuan Yen
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,
>
> It was delayed because of a security issue. See Georg's email at
> https://mail.python.org/pipermail/python-dev/2016-February/143400.html
>
> --Berker
>

Thanks for that. I'm just curious what's happening on the 3.2 branch.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Guido van Rossum
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 --
and the latter category should be checking platform and versions anyway
since they need the whole stack to be secure (if I understand Ted Ts'o's
email right).

My assumption is also that the flags should be hints (perhaps only relevant
on Linux) -- platforms that can't perform the action desired (because their
system's API doesn't support it) would just do their default action,
assuming the system API does the best it can.

I think the problem with making os.urandom() go back to always reading
/dev/urandom is that we've come to rely on it on all platforms, so we've
passed that station.

On Sat, Jun 11, 2016 at 10:15 AM, Donald Stufft  wrote:

>
> 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 to add
> os.getrandom(). I feel like these flags are going to confuse people,
> particularly when you take into account that all 3 of them are only going
> to really matter on Linux (and particularly on newer Linux) and for things
> like “blocking” it’s going to get confused with the blocking that
> /dev/random does on Linux.
>
> Right now there are two ways to access the system CSPRNG on *nix, there is
> /dev/urandom pretty much always, and then there is getrandom() (or
> arc4random, etc, depending on the specific OS you’re on).
>
> Perhaps the right answer is to go back to making os.urandom always
> open(“/dev/urandom”).read() instead of trying to save a FD by using
> getrandom() and just add os.getrandom() which will interface with
> getrandom()/arc4random()/etc and always in blocking mode. Why always in
> blocking mode? Because it’s the only way to get consistent behavior across
> different platforms, all non Linux OSs either block or they otherwise
> ensure that it is initialized prior to it even being possible to access the
> CSPRNG.
>
> Using this, code can be smarter about what to do in edge cases than we can
> reasonably be in os.urandom, for example see
> https://bpaste.net/show/41d89e520913.
>
> The reasons I think this is preferable to adding parameters to os.urandom
> are:
>
> * If we add parameters to os.urandom, you can’t feature detect their
> existence easily, you have to use version checks.
> * With flags, unless we add even more flags we can’t dictate what should
> happen if we’re on a system where the person’s desired preference can’t be
> satisfied. We either have to just silently do something that may be wrong,
> or add more flags. By adding two functions people can pick which of the
> following they want with some programming (see example):
>
> * Just try to get the strongest random, but fall back to maybe not
> random if it’s early enough in boot process.
> * Fail on old Linux rather than possibly get insecure random.
> * Actually write cross platform code to prevent blocking (since only
> Linux allows you to not block)
> * Fail hard rather than block if we can’t get secure random bytes
> without blocking.
> * Soft fail and get “probably good enough” random from os.urandom
> on Linux.
> * Hard fail on non Linux if we would block since there’s no
> non-blocking and “probably good enough” interface.
> * Soft fail and get “probably good enough” random from os.urandom
> on Linux, and use time/pid/memory offsets on non Linux.
> * Just use the best source of random available to use on the system,
> and block rather than fail.
>
> I don’t see any way to get the same wide set of options by just adding
> flags to os.urandom unless we add flags that work for every possible
> combination of what people may or may not want to.
>
> —
> Donald Stufft
>
>
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Terry Reedy

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 API' should be a parameter, not a new function. With 
just two choices, 'wait' = True/False  could work.  If 'raise an 
exception' were added, then

'action (when good bits are not immediately available' =
'return (best possible)' or
'wait (until have good bits)' or
'raise (CryptBitsNotAvailable)'

In either case, there would then be the question of whether the default 
should match 3.5.0/1 or 3.4 and before.

'''

Deciding on this then might have saved some hurt feelings, to the point 
where two contributors feel like disappearing, and a release manager 
must feel the same.  In any case, Guido already picked 3.4 behavior as 
the default.  Can we agree and move on?


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Donald Stufft

> 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 to add 
os.getrandom(). I feel like these flags are going to confuse people, 
particularly when you take into account that all 3 of them are only going to 
really matter on Linux (and particularly on newer Linux) and for things like 
“blocking” it’s going to get confused with the blocking that /dev/random does 
on Linux.

Right now there are two ways to access the system CSPRNG on *nix, there is 
/dev/urandom pretty much always, and then there is getrandom() (or arc4random, 
etc, depending on the specific OS you’re on). 

Perhaps the right answer is to go back to making os.urandom always 
open(“/dev/urandom”).read() instead of trying to save a FD by using getrandom() 
and just add os.getrandom() which will interface with 
getrandom()/arc4random()/etc and always in blocking mode. Why always in 
blocking mode? Because it’s the only way to get consistent behavior across 
different platforms, all non Linux OSs either block or they otherwise ensure 
that it is initialized prior to it even being possible to access the CSPRNG.

Using this, code can be smarter about what to do in edge cases than we can 
reasonably be in os.urandom, for example see 
https://bpaste.net/show/41d89e520913 .

The reasons I think this is preferable to adding parameters to os.urandom are:

* If we add parameters to os.urandom, you can’t feature detect their existence 
easily, you have to use version checks.
* With flags, unless we add even more flags we can’t dictate what should happen 
if we’re on a system where the person’s desired preference can’t be satisfied. 
We either have to just silently do something that may be wrong, or add more 
flags. By adding two functions people can pick which of the following they want 
with some programming (see example):

* Just try to get the strongest random, but fall back to maybe not random 
if it’s early enough in boot process.
* Fail on old Linux rather than possibly get insecure random.
* Actually write cross platform code to prevent blocking (since only Linux 
allows you to not block)
* Fail hard rather than block if we can’t get secure random bytes 
without blocking.
* Soft fail and get “probably good enough” random from os.urandom on 
Linux.
* Hard fail on non Linux if we would block since there’s no 
non-blocking and “probably good enough” interface.
* Soft fail and get “probably good enough” random from os.urandom on 
Linux, and use time/pid/memory offsets on non Linux.
* Just use the best source of random available to use on the system, and 
block rather than fail.

I don’t see any way to get the same wide set of options by just adding flags to 
os.urandom unless we add flags that work for every possible combination of what 
people may or may not want to.

—
Donald Stufft



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Berker Peksağ
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
https://mail.python.org/pipermail/python-dev/2016-February/143400.html

--Berker
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Brett Cannon
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 new commits since 2016/01/15 on CPython's 3.2
> branch. I'd like to know CPython's attitude against Python 3.2. Is it still
> maintained? Or is it dead?
>

It's up to Georg to decide to do one final source-only release. But to the
rest of us it's reached its end-of-life. Basically checking out the source
code will more-or-less be the same as whatever Georg relesases (sans
tweaking some version numbers).

-Brett


>
> [1] https://mail.python.org/pipermail/python-dev/2016-February/143300.html
> [2]
> https://github.com/pypa/pip/commit/b11cb019a47ff0cf3d8a37a0c89d8ae4cf25282f
> [3]
> https://github.com/pypa/virtualenv/commit/8132fa3a826ff1ba0c0c065563b9733c2e5a5b6c
> [4]
> https://github.com/pypa/setuptools/commit/ae6c73f07680da77345f5ccfac4facde30ad4d7e
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Guido van Rossum
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, 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.
> >
> > That will be hard, because you have to consider an active, clever
> > adversary.
>
> We know that there are exploitable bugs from Linux systems due to
> urandom, e.g. the Raspberry Pi bug referenced elsewhere in this thread.
>
> https://www.raspberrypi.org/forums/viewtopic.php?f=66=126892
>
>
> > On the other hand, convincing yourself that in practice os.urandom would
> > never block unless the setup is super exotic or there is active
> > maliciousness seems much easier.
>
> Not that super exotic. In my day job, I've seen processes hang for five
> or ten minutes during boot up, waiting for the OS to collect enough
> entropy, although this was not recently and it wasn't involving Python.
> But VMs or embedded devices may take a long time to generate entropy. If
> the device doesn't have a hardware source of randomness, and isn't
> connected to an external source of noise like networking or a user who
> habitually fiddles with the mouse, it might take a very long time indeed
> to gather entropy...
>
> If I have understood the concensus, I think we're on the right track:
>
> (1) os.urandom should do whatever the OS says it should do, which on
> Linux is fall back on pseudo-random bytes when the entropy pool hasn't
> be initialised yet. It won't block and won't raise.
>
> (2) os.getrandom will be added to 3.6, and it will block, or possibly
> raise, whichever the caller specifies.
>
> (3) The secrets module in 3.6 will stop relying on os.urandom, and use
> os.getrandom. It may provide a switch to choose between blocking and
> non-blocking (raise an exception) behaviour. It WON'T fall back to
> predictable non-crypto bytes (unless the OS itself is completely
> broken).
>
> (4) random will continue to seed itself from os.urandom, because it
> doesn't care if urandom provides degraded randomness. It just needs to
> be better than using the time as seed.
>
> (5) What about random.SysRandom? I think it should use os.getrandom.
>
> (6) A bunch of stuff will happen to make the hash randomisation not
> break when systemd runs Python scripts early in the boot process, but I
> haven't been paying attention to that part :-)
>
> Is this a good summary of where we are at?
>
>
>
> --
> Steve
> ___
> Python-Dev mailing list
> Python-Dev@python.org 
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>


-- 
--Guido (mobile)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Christian Heimes
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 necessary strength and mental energy to persuade the
issue any further. Donald Stufft just forwarded a quote that resonates
with my current state of mind (replace 'lists' with 'current topic'):

"I feel I no longer possess either the necessary strength or perhaps
the necessary faith to continue rolling the stone of Sisyphus against
the forces of reaction which are triumphing everywhere. I am therefore
retiring from the lists, and ask if my dear contemporaries only one
thing — oblivion."

Christian
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] Current Python 3.2 status?

2016-06-11 Thread Chi Hsuan Yen
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 attitude against Python 3.2. Is it still
maintained? Or is it dead?

[1] https://mail.python.org/pipermail/python-dev/2016-February/143300.html
[2]
https://github.com/pypa/pip/commit/b11cb019a47ff0cf3d8a37a0c89d8ae4cf25282f
[3]
https://github.com/pypa/virtualenv/commit/8132fa3a826ff1ba0c0c065563b9733c2e5a5b6c
[4]
https://github.com/pypa/setuptools/commit/ae6c73f07680da77345f5ccfac4facde30ad4d7e
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Cory Benfield

> 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 /dev/random but 
> it behaves identically to /dev/urandom.)  OS X's man page reassuringly claims 
> blocking is never necessary; the blogosphere disagrees.
> If I were writing the function for the secrets module, I'd write it like you 
> have above: call os.getrandom() if it's present, and os.urandom() if it 
> isn't.  I believe that achieves current-best-practice everywhere: it does the 
> right thing on Linux, it does the right thing on Solaris, it does the right 
> thing on all the other OSes where reading from /dev/urandom can block, and it 
> uses the only facility available to us on OS X.

Sorry Larry, but as far as I know this is misleading (it’s not *wrong*, but it 
suggests that OS X’s /dev/urandom is the same as Linux’s, which is emphatically 
not true).

I’ve found the discussion around OS X’s random devices to be weirdly abstract, 
given that the source code for it is public, so I went and took a look. My 
initial reading of it (and, to be clear, this is a high-level read of a 
codebase I don’t know well, so please take this with the grain of salt that is 
intended) is that the operating system literally will not boot without at least 
128 bits of entropy to read from the EFI boot loader. In the absence of 128 
bits of entropy the kernel will panic, rather than continue to boot.

Generally speaking that entropy will come from RDRAND, given the restrictions 
on where OS X can be run (Intel CPUs for real OS X, virtualised on top of OS X, 
and so on top of Intel CPUs, for VMs), which imposes a baseline on the quality 
of the entropy you can get. Assuming that OS X is being run in a manner that is 
acceptable from the perspective of its license agreement (and we can all agree 
that no-one would violate the terms of OS X’s license agreement, right?), I 
think it’s reasonable to assume that OS X, either virtualised or not, is 
getting 128 bits of somewhat sensible entropy from the boot loader/CPU before 
it boots.

That means we can say this about OS X’s /dev/urandom: the reason it never 
blocks is because the situation of “not enough entropy to generate good random 
numbers” is synonymous with “not enough entropy to boot the OS”. So maybe we 
can stop casting aspersions on OS X’s RNG now.

Cory


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Victor Stinner
> 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
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Christian Heimes
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 behavior in which os.urandom() never blocks on Linux.
>> Moreover, I understand that the case where the insecure bits might be
>> returned are limited to Python scripts that run on system initialization on
>> Linux.
>>
>> If I *were* someone who needed to write a Linux system initialization script
>> using Python 3.5.2, what would the code look like.  I think for this use
>> case, requiring something with a little bit of "code smell" is fine, but I
>> kinda hope it exists at all.
> 
> Good question.  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 blocking on
>> getrandom() in order to initialize hash randomization.  On this fresh
>> virtual machine the entropy pool started out uninitialized.  And since the
>> only thing running on the machine was CPython, and since CPython was blocked
>> on initialization, the entropy pool was initializing very, very slowly.

I repeat for like the fifth time:

os.urandom() and Python startup are totally unrelated. They just happen
to use the same internal function to set the hash randomization state.
The startup problem can be solved without f... up the security
properties of os.urandom().


The correct questions to ask are:

1) Does hash randomization for bytes, text and XML always require
cryptographically strong random values from a potentially blocking CPRNG?

2) Does the initial state of the Mersenne-Twister of the default
random.Random instance really need cryptographically strong values?

3) Should os.urandom() always use the best CSPRNG source available and
make sure it never returns weak, predictable values (when possible)?

The answers are:

1) No
2) No
3) HELL YES!

If you think that the answer to 3 is "No" and that a CSPRNG is permitted
to return predictable values, then you are *by definition* ineligible to
vote on security issues.

Christian

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Giampaolo Rodola'
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:
>
> https://haypo.github.io/journey-to-stable-benchmark-system.html
> https://haypo.github.io/journey-to-stable-benchmark-deadcode.html
> https://haypo.github.io/journey-to-stable-benchmark-average.html
>
> The second result is a new perf module which includes all "tricks"
> discovered in my research: compute average and standard deviation,
> spawn multiple worker child processes, automatically calibrate the
> number of outter-loop iterations, automatically pin worker processes
> to isolated CPUs, and more.
>
> The perf module allows to store benchmark results as JSON to analyze
> them in depth later. It helps to configure correctly a benchmark and
> check manually if it is reliable or not.
>
> The perf documentation also explains how to get stable and reliable
> benchmarks (ex: how to tune Linux to isolate CPUs).
>
> perf has 3 builtin CLI commands:
>
> * python -m perf: show and compare JSON results
> * python -m perf.timeit: new better and more reliable implementation of
> timeit
> * python -m metadata: display collected metadata
>
> Python 3 is recommended to get time.perf_counter(), use the new
> accurate statistics module, automatic CPU pinning (I will implement it
> on Python 2 later), etc. But Python 2.7 is also supported, fallbacks
> are implemented when needed.
>
> Example with the patched telco benchmark (benchmark for the decimal
> module) on a Linux with two isolated CPUs.
>
> First run the benchmark:
> ---
> $ python3 telco.py --json-file=telco.json
> .
> Average: 26.7 ms +- 0.2 ms
> ---
>
>
> Then show the JSON content to see all details:
> ---
> $ python3 -m perf -v show telco.json
> Metadata:
> - aslr: enabled
> - cpu_affinity: 2, 3
> - cpu_count: 4
> - cpu_model_name: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
> - hostname: smithers
> - loops: 10
> - platform: Linux-4.4.9-300.fc23.x86_64-x86_64-with-fedora-23-Twenty_Three
> - python_executable: /usr/bin/python3
> - python_implementation: cpython
> - python_version: 3.4.3
>
> Run 1/25: warmup (1): 26.9 ms; samples (3): 26.8 ms, 26.8 ms, 26.7 ms
> Run 2/25: warmup (1): 26.8 ms; samples (3): 26.7 ms, 26.7 ms, 26.7 ms
> Run 3/25: warmup (1): 26.9 ms; samples (3): 26.8 ms, 26.9 ms, 26.8 ms
> (...)
> Run 25/25: warmup (1): 26.8 ms; samples (3): 26.7 ms, 26.7 ms, 26.7 ms
>
> Average: 26.7 ms +- 0.2 ms (25 runs x 3 samples; 1 warmup)
> ---
>
> Note: benchmarks can be analyzed with Python 2.
>
> I'm posting my email to python-dev because providing timeit results is
> commonly requested in review of optimization patches.
>
> The next step is to patch the CPython benchmark suite to use the perf
> module. I already forked the repository and started to patch some
> benchmarks.
>
> If you are interested by Python performance in general, please join us
> on the speed mailing list!
> https://mail.python.org/mailman/listinfo/speed
>
> Victor
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com
>

This is very interesting and also somewhat related to psutil. I wonder...
would increasing process priority help isolating benchmarks even more? By
this I mean "os.nice(-20)".
Extra: perhaps even IO priority:
https://pythonhosted.org/psutil/#psutil.Process.ionice ?


-- 
Giampaolo - http://grodola.blogspot.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Sebastian Krause
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 to start doing things other
>> than just CPython?)
>
> 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, separate, entropy pools):

There are projects like http://www.issihosts.com/haveged/ that use
some tiny timing fluctuations in CPUs to feed the entropy pool and
which are available in most Linux distributions. But as you said,
that is something completely outside of Python's scope.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Steven D'Aprano
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 blocking on
> > getrandom() in order to initialize hash randomization.  On this fresh
> > virtual machine the entropy pool started out uninitialized.  And since the
> > only thing running on the machine was CPython, and since CPython was blocked
> > on initialization, the entropy pool was initializing very, very slowly.
> 
> 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 to start doing things other
> than just CPython?)

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, separate, entropy pools):

open("/dev/urandom", "w").write("hello world")

But of course there's the question of where you're going to get a source 
of noise to write to the file. While it's (probably?) harmless to write 
a hard-coded string to it, I don't think its going to give you much 
entropy.



-- 
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Larry Hastings


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 Linux and Solaris have getrandom() right now.  IIUC Solaris
   duplicated Linux's API, but I don't know that for certain, and I
   don't know in particular what GRND_RANDOM does on Solaris.  (Of
   course, you don't need GRND_RANDOM for secrets.token_bytes().)
 * 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 /dev/random but it behaves identically to /dev/urandom.) 
   OS X's man page reassuringly claims blocking is never necessary; the

   blogosphere disagrees.

If I were writing the function for the secrets module, I'd write it like 
you have above: call os.getrandom() if it's present, and os.urandom() if 
it isn't.  I believe that achieves current-best-practice everywhere: it 
does the right thing on Linux, it does the right thing on Solaris, it 
does the right thing on all the other OSes where reading from 
/dev/urandom can block, and it uses the only facility available to us on 
OS X.



//arry/

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Steven D'Aprano
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 should use the "best available randomness 
> >(even if it blocks)"
> 
> I'm not particular about how the new API is spelled.  However, I do 
> think os.getrandom() should be exposed as a thin wrapper over 
> getrandom() in 3.6.   That would permit Python programmers to take 
> maximal advantage of the features offered by their platform.  It would 
> also permit the secrets module to continue to be written in pure Python.

A big +1 for that.

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?


-- 
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-06-11 Thread Steven D'Aprano
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.
> 
> That will be hard, because you have to consider an active, clever
> adversary.

We know that there are exploitable bugs from Linux systems due to 
urandom, e.g. the Raspberry Pi bug referenced elsewhere in this thread.

https://www.raspberrypi.org/forums/viewtopic.php?f=66=126892


> On the other hand, convincing yourself that in practice os.urandom would
> never block unless the setup is super exotic or there is active
> maliciousness seems much easier.

Not that super exotic. In my day job, I've seen processes hang for five 
or ten minutes during boot up, waiting for the OS to collect enough 
entropy, although this was not recently and it wasn't involving Python. 
But VMs or embedded devices may take a long time to generate entropy. If 
the device doesn't have a hardware source of randomness, and isn't 
connected to an external source of noise like networking or a user who 
habitually fiddles with the mouse, it might take a very long time indeed 
to gather entropy...

If I have understood the concensus, I think we're on the right track:

(1) os.urandom should do whatever the OS says it should do, which on 
Linux is fall back on pseudo-random bytes when the entropy pool hasn't 
be initialised yet. It won't block and won't raise.

(2) os.getrandom will be added to 3.6, and it will block, or possibly 
raise, whichever the caller specifies.

(3) The secrets module in 3.6 will stop relying on os.urandom, and use 
os.getrandom. It may provide a switch to choose between blocking and 
non-blocking (raise an exception) behaviour. It WON'T fall back to 
predictable non-crypto bytes (unless the OS itself is completely 
broken).

(4) random will continue to seed itself from os.urandom, because it 
doesn't care if urandom provides degraded randomness. It just needs to 
be better than using the time as seed.

(5) What about random.SysRandom? I think it should use os.getrandom.

(6) A bunch of stuff will happen to make the hash randomisation not 
break when systemd runs Python scripts early in the boot process, but I 
haven't been paying attention to that part :-)

Is this a good summary of where we are at?



-- 
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com