Yes, it most certainly was. :( Sorry about that!
From: on behalf of Guido van Rossum
Reply-To:
Date: Thursday, June 16, 2016 at 8:25 PM
To: Kevin Ollivier
Cc: Python Dev
Subject: Re: [Python-Dev] Discussion overload
More likely your post was too long... :-(
On Thu, Jun 16, 2016 at 7:0
More likely your post was too long... :-(
On Thu, Jun 16, 2016 at 7:00 PM, Kevin Ollivier <
kevin-li...@theolliviers.com> wrote:
> Hi Guido,
>
> From: on behalf of Guido van Rossum <
> gu...@python.org>
> Reply-To:
> Date: Thursday, June 16, 2016 at 5:27 PM
> To: Kevin Ollivier
> Cc: Python De
Hi Guido,
From: on behalf of Guido van Rossum
Reply-To:
Date: Thursday, June 16, 2016 at 5:27 PM
To: Kevin Ollivier
Cc: Python Dev
Subject: Re: [Python-Dev] Discussion overload
Hi Kevin,
I often feel the same way. Are you using GMail? It combines related messages in
threads and lets
Hi Kevin,
I often feel the same way. Are you using GMail? It combines related
messages in threads and lets you mute threads. I often use this feature so
I can manage my inbox. (I presume other mailers have the same features, but
I don't know if all of them do.) There are also many people who read
Yes 'secrets' is one-liners. However, it might grow a few more lines around
the blocking in getrandom() on Linux. But still, not more than a few.
But the reason it should be on PyPI is so that programs can have a uniform
API across various Python versions. There's no real reason that someone
stick
On Fri, Jun 17, 2016 at 2:36 AM, Nick Coghlan wrote:
> On 16 June 2016 at 14:17, Martin Teichmann wrote:
> An implementation like PyPy, with an inherently ordered standard dict
> implementation, can just rely on that rather than being obliged to
> switch to their full collections.OrderedDict typ
On Thu, Jun 16, 2016 at 3:36 PM, Nick Coghlan wrote:
> I don't think that's a side note, I think it's an important point (and
> relates to one of Nikita's questions as well): we have the option of
> carving out certain aspects of PEP 520 as CPython implementation
> details.
>
> In particular, the
On 16 June 2016 at 14:17, Martin Teichmann wrote:
> As a side note, you propose to use OrderedDict as the class definition
> namespace, and this is exactly how I implemented it. Nonetheless, I
> would like to keep this fact as an implementation detail, such that
> other implementations of Python (
Hi Eric, hi List,
> I'd be glad to give feedback on this, probably later today or
> tomorrow. In particular, I'd like to help resolve the intersection
> with PEP 520. :)
Thanks in advance! Let me already elaborate on the differences, so
that others can follow:
You chose the name "__definition_o
On Thu, Jun 16, 2016 at 12:56 PM, Martin Teichmann
wrote:
> I am looking forward to a lot of comments on this!
I'd be glad to give feedback on this, probably later today or
tomorrow. In particular, I'd like to help resolve the intersection
with PEP 520. :)
-eric
On 16 June 2016 at 13:09, Barry Warsaw wrote:
> On Jun 16, 2016, at 01:01 PM, David Mertz wrote:
>
>>It seems to me that backporting 'secrets' and putting it on Warehouse would
>>be a lot more productive than complaining about 3.5.2 reverting to (almost)
>>the behavior of 2.3-3.4.
>
> Very wise su
On Jun 16, 2016, at 01:01 PM, David Mertz wrote:
>It seems to me that backporting 'secrets' and putting it on Warehouse would
>be a lot more productive than complaining about 3.5.2 reverting to (almost)
>the behavior of 2.3-3.4.
Very wise suggestion indeed. We have all kinds of stdlib modules ba
On 16 June 2016 at 18:03, Nick Coghlan wrote:
> On 16 June 2016 at 09:39, Paul Moore wrote:
>> I'm willing to accept the view of the security experts that there's a
>> problem here. But without a clear explanation of the problem, how can
>> a non-specialist like myself have an opinion? (And I hop
Hi all,
Recent joiner here, I signed up after PyCon made me want to get more involved
and have been lurking. I woke up this morning again to about 30 new messages in
my inbox, almost all of which revolve around the os.urandom blocking
discussion. There are just about hourly new posts showing up
Hi list,
using metaclasses in Python is a very flexible method of customizing
class creation, yet this customization comes at a cost: once you want
to combine two classes with different metaclasses, you run into
problems.
This is why I proposed PEP 487 (see
https://github.com/tecki/peps/blob/pep4
On Thu, Jun 16, 2016 at 10:26:22AM -0700, Nick Coghlan wrote:
> meta-guidance. However, there are multiple levels of improvement being
> pursued here, since developer ignorance of security concerns and
> problematic defaults at the language level is a chronic problem rather
> than an acute one (and
On Jun 16 2016, Nick Coghlan wrote:
> On 16 June 2016 at 09:39, Paul Moore wrote:
>> I'm willing to accept the view of the security experts that there's a
>> problem here. But without a clear explanation of the problem, how can
>> a non-specialist like myself have an opinion? (And I hope the secu
On Thu, Jun 16, 2016 at 5:11 AM, Nikita Nemkin wrote:
> I'll reformulate my argument:
>
> Ordered class namespaces are a minority use case that's already covered
> by existing language features (custom metaclasses) and doesn't warrant
> the extension of the language (i.e. making OrderedDict a buil
On 16 June 2016 at 10:40, Nathaniel Smith wrote:
> On Jun 16, 2016 10:01 AM, "David Mertz" wrote:
>> Python 3.6 is introducing a NEW MODULE, with new APIs. The 'secrets'
>> module is the very first time that Python has ever really explicitly
>> addressed cryptography in the standard library.
>
>
Thanks for raising these good points, Nikita. I'll make sure the PEP
reflects this discussion. (inline responses below...)
-eric
On Tue, Jun 14, 2016 at 3:41 AM, Nikita Nemkin wrote:
> Is there any rationale for rejecting alternatives like:
>
> 1. Adding standard metaclass with ordered namespa
On Jun 16, 2016 10:01 AM, "David Mertz" wrote:
> Python 3.6 is introducing a NEW MODULE, with new APIs. The 'secrets'
module is the very first time that Python has ever really explicitly
addressed cryptography in the standard library.
This is completely, objectively untrue. If you look up os.ura
On 16 June 2016 at 10:01, David Mertz wrote:
> It seems to me that backporting 'secrets' and putting it on Warehouse would
> be a lot more productive than complaining about 3.5.2 reverting to (almost)
> the behavior of 2.3-3.4.
"Let Flask/Django/passlib/cryptography/whatever handle the problem
ra
On 16 June 2016 at 09:39, Paul Moore wrote:
> I'm willing to accept the view of the security experts that there's a
> problem here. But without a clear explanation of the problem, how can
> a non-specialist like myself have an opinion? (And I hope the security
> POV isn't "you don't need an opinio
On Thu, Jun 16, 2016 at 11:58 AM, Nathaniel Smith wrote:
> [...] no one else be able to predict what session cookie I sent [...] In
> python 2.3-3.5, the most correct way to write this code is to use
> os.urandom. The question in this thread is whether we should break that in
> 3.6, so that consc
On Thu, Jun 16, 2016, at 07:34, Donald Stufft wrote:
> python-dev tends to favor not breaking “working” code over securing
> existing APIs, even if “working” is silently doing the wrong thing
> in a security context. This is particularly frustrating when it
> comes to security because
On 16 June 2016 at 16:58, Nathaniel Smith wrote:
> The word "cryptographic" here is a bit of a red herring. The guarantee that
> a CSPRNG makes is that the output should be *unguessable by third parties*.
> There are plenty of times when this is what you need even when you aren't
> using actual cr
On Jun 16, 2016 1:23 AM, "Stefan Krah" wrote:
>
> Nathaniel Smith pobox.com> writes:
> > In practice, your proposal means that ~all existing code that uses
> > os.urandom becomes incorrect and should be switched to either secrets
> > or random. This is *far* more churn for end-users than Nick's
>
On 16 June 2016 at 05:50, Paul Moore wrote:
> On 16 June 2016 at 12:34, Donald Stufft wrote:
>> [1] I don’t think using os.urandom is incorrect to use for security sensitive
>> applications and I think it’s a losing battle for Python to try and fight
>> the rest of the world that urandom
On Thu, Jun 16, 2016 at 1:04 PM, Donald Stufft wrote:
> In my opinion, this is a usability issue as well. You have a ton of third
> party documentation and effort around “just use urandom” for Cryptographic
> random which is generally the right (and best!) answer except for this one
> little nigg
On Thu, Jun 16, 2016, at 10:04, Barry Warsaw wrote:
> On Jun 16, 2016, at 09:51 AM, Random832 wrote:
>
> >On Thu, Jun 16, 2016, at 04:03, Barry Warsaw wrote:
> >> *If* we can guarantee that os.urandom() will never block or raise an
> >> exception when only poor entropy is available, then it may
I also think it’s a great module for providing defaults that we can’t
provide in os.urandom, like the number of bytes that are considered
“secure” [1].
What I don’t think is that the secrets module means that all of a sudden
os.urandom is no longer an API that is primarily used in a security
se
On Jun 16, 2016, at 09:51 AM, Random832 wrote:
>On Thu, Jun 16, 2016, at 04:03, Barry Warsaw wrote:
>> *If* we can guarantee that os.urandom() will never block or raise an
>> exception when only poor entropy is available, then it may be indeed
>> indistinguishably backward compatible for most if n
On Thu, Jun 16, 2016, at 04:03, Barry Warsaw wrote:
> *If* we can guarantee that os.urandom() will never block or raise an
> exception when only poor entropy is available, then it may be indeed
> indistinguishably backward compatible for most if not all cases.
Why can't we exclude cases when only
> On Jun 16, 2016, at 8:50 AM, Paul Moore wrote:
>
> On 16 June 2016 at 12:34, Donald Stufft wrote:
>> [1] I don’t think using os.urandom is incorrect to use for security sensitive
>>applications and I think it’s a losing battle for Python to try and fight
>>the rest of the world that u
Cory Benfield lukasa.co.uk> writes:
> python-dev cannot wash its hands of the security decision here. As I’ve
said many times, I’m pleased to
> see the decision makers have not done that: while I don’t agree with their
decision, I totally respect
> that it was theirs to make, and they made it with
On 16 June 2016 at 12:34, Donald Stufft wrote:
> [1] I don’t think using os.urandom is incorrect to use for security sensitive
> applications and I think it’s a losing battle for Python to try and fight
> the rest of the world that urandom is not the right answer here.
>
> [2] python-dev t
On Thu, Jun 16, 2016 at 03:24:33PM +0300, Barry Warsaw wrote:
> Except that I disagree. I think os.urandom's original intent, as documented
> in Python 3.4, is to provide a thin layer over /dev/urandom, with all that
> implies, and with the documented quality caveats. I know as a Linux developer
On Jun 16, 2016, at 07:34 AM, Donald Stufft wrote:
>Well, I don’t think that for os.urandom someone using it for security is
>running “counter to it’s original intent”, given that in general urandom’s
>purpose is for cryptographic random. Someone *may* be using it for something
>other than that, b
> On 16 Jun 2016, at 09:19, Stefan Krah wrote:
>
> This should only concern code that a) was specifically written for
> 3.5.0/3.5.1 and b) implements a serious cryptographic application
> in Python.
>
> I think b) is not a good idea anyway due to timing and side channel
> attacks and the lack o
> On Jun 16, 2016, at 7:07 AM, Barry Warsaw wrote:
>
> On Jun 16, 2016, at 06:04 AM, Donald Stufft wrote:
>
>> Regardless of what we document it as, people are going to use os.urandom for
>> cryptographic purposes because for everyone who doesn’t keep up on exactly
>> what modules are being add
I'll reformulate my argument:
Ordered class namespaces are a minority use case that's already covered
by existing language features (custom metaclasses) and doesn't warrant
the extension of the language (i.e. making OrderedDict a builtin type).
This is about Python-the-Language, not CPython-the-ru
On Wed, 15 Jun 2016 11:51:05 +1200, Greg Ewing
wrote:
> R. David Murray wrote:
> > The fundamental purpose of the base64 encoding is to take a series
> > of arbitrary bytes and reversibly turn them into another series of
> > bytes in which the eighth bit is not significant.
>
> No, it's not. If
On Jun 16, 2016, at 06:04 AM, Donald Stufft wrote:
>Regardless of what we document it as, people are going to use os.urandom for
>cryptographic purposes because for everyone who doesn’t keep up on exactly
>what modules are being added to Python who has any idea about cryptography at
>all is going
> On Jun 16, 2016, at 4:46 AM, Barry Warsaw wrote:
>
> We can educate them through documentation, but I don't think it's appropriate
> to retrofit existing APIs to different behavior based on those faulty
> assumptions, because that has other negative effects, such as breaking the
> promises we
Nick Coghlan writes:
> - even if there is a test suite, sufficiently pervasive [str/bytes]
> type ambiguity may make it difficult to use for fault isolation
Difficult yes, but I would argue that that difficuly is inherent[1].
Ie, if it's pervasive, the fault should be isolated to the whole
modu
On Jun 16, 2016, at 01:40 AM, Larry Hastings wrote:
>As Robert Collins points out, this does change the behavior ever-so-slightly
>from 3.4;
Ah yes, I misunderstood Robert's point.
>if urandom is initialized, and the kernel has the getrandom system call,
>getrandom() will give us the bytes we as
On Jun 16, 2016, at 12:36 AM, Nathaniel Smith wrote:
>Basically this is a question of whether we should make an (unlikely) error
>totally invisible to the user, and "errors should never pass silently" is
>right there in the Zen of Python :-).
I'd phrase it differently though. To me, it comes dow
On 06/16/2016 01:03 AM, Barry Warsaw wrote:
*If* we can guarantee that os.urandom() will never block or raise an exception
when only poor entropy is available, then it may be indeed indistinguishably
backward compatible for most if not all cases.
I stepped through the code that shipped in 3.5.
On Jun 16, 2016, at 12:53 AM, Nathaniel Smith wrote:
>> We have introduced churn. Predicting a future SO question such as "Can
>> os.urandom() block on Linux?" the answer is "No in Python 3.4 and earlier,
>> yes possibly in Python 3.5.0 and 3.5.1, no in Python 3.5.2 and the rest of
>> the 3.5.x s
On Jun 16, 2016, at 07:26 PM, Robert Collins wrote:
>Which is a contract change. Someone testing in E.g. a chroot could have a
>different device on /dev/urandom, and now they will need to intercept
>syscalls for the same effect. Personally I think this is fine, but assuming
>i see Barry's point co
Nathaniel Smith pobox.com> writes:
> In practice, your proposal means that ~all existing code that uses
> os.urandom becomes incorrect and should be switched to either secrets
> or random. This is *far* more churn for end-users than Nick's
> proposal.
This should only concern code that a) was spe
On Jun 15, 2016, at 11:52 PM, Larry Hastings wrote:
>Well, 3.5.2 hasn't happened yet. So if you see it as still being broken,
>please speak up now.
In discussion with other Ubuntu developers, several salient points were raised.
The documentation for os.urandom() in 3.5.2rc1 doesn't make sense:
On Wed, Jun 15, 2016 at 11:45 PM, Barry Warsaw wrote:
> On Jun 15, 2016, at 01:01 PM, Nick Coghlan wrote:
>
>>No, this is a bad idea. Asking novice developers to make security
>>decisions they're not yet qualified to make when it's genuinely
>>possible for us to do the right thing by default is th
Nathaniel Smith pobox.com> writes:
> On Wed, Jun 15, 2016 at 10:25 PM, Theodore Ts'o mit.edu> wrote:
> > In practice, those Python ivocation which are exposed to hostile input
> > are those that are started while the network are up.
>
> Not sure what you mean about the vast majority of Python in
On Wed, Jun 15, 2016 at 10:25 PM, Theodore Ts'o wrote:
> On Wed, Jun 15, 2016 at 04:12:57PM -0700, Nathaniel Smith wrote:
>> - It's not exactly true that the Python interpreter doesn't need
>> cryptographic randomness to initialize SipHash -- it's more that
>> *some* Python invocations need ungues
On 16 Jun 2016 6:55 PM, "Larry Hastings" wrote:
>
>
> Why do you call it only "semi-fixed"? As far as I understand it, the
semantics of os.urandom() in 3.5.2rc1 are indistinguishable from reading
from /dev/urandom directly, except it may not need to use a file handle.
Which is a contract change
56 matches
Mail list logo
