New submission from Larry Hastings :
With the Capsule API patch accepted, I'd like to officially deprecate
CObject. This patch causes Python to emit a single runtime warning the
first time a CObject is constructed in a particular Python instance. If
those aren't the right seman
Larry Hastings added the comment:
I don't know what would be proper, but I'm happy to change it if you
think that's best.
--
___
Python tracker
<http://bugs.py
Larry Hastings added the comment:
I tested your patch and it looks good to me. I didn't get the
deprecation warning on ntpath.splitunc unless I disabled all warnings.
--
___
Python tracker
<http://bugs.python.org/i
Larry Hastings added the comment:
It's 12:45am, and I've already learned my New Thing for the day. I
didn't know about PendingDeprecationWarning. That's just exactly what
CObject should throw.
Attached is a new patch. The two CObject constructors now throw a
PendingDepr
Larry Hastings added the comment:
I noticed this a while ago. And FWIW it's not just 3.x; I see this same
behavior in 2.6.
I've whipped up a test case, attached, which runs in both Python 2 and Python
3. The test runs "sys.interpreter -V" four times: it tries all the
c
Larry Hastings added the comment:
I realize we're down to the wire, but would it be too late to fix this in 2.7?
It is a genuine bug, and it won't break any correct code.
--
___
Python tracker
<http://bugs.python.
Changes by Larry Hastings :
--
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/issue7839>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
Sorry for spamming updates, but here's two more things to consider.
1) What does it do on Windows? For all I know all four combinations work fine
there and we should preserve the existing functionality.
2) All four combinations work fine if you c
Larry Hastings added the comment:
Zsolt: an excellent idea! That shouldn't change the semantics of the function,
and therefore is strictly a bug fix. Which means we could potentially backport
it, yes?
Obviously we only need to change it between string / list if we're going to
Larry Hastings added the comment:
Why did you assign this to me? I don't know why my name is on this bug in the
first place.
Is it possible you were thinking of another Larry?
--
___
Python tracker
<http://bugs.python.org/i
Larry Hastings added the comment:
I assert that Argument Clinic's / PyArg_ParseTuple's handling of bool is
correct.
* Python has a well-established concept of "truth":
https://docs.python.org/3/library/stdtypes.html#truth-value-testing
The C equivalent is, ind
Larry Hastings added the comment:
You propose an automatic conversion of "None" into "-1"? That's awful. Please
don't commit that patch to CPython.
--
___
Python tracker
<
Larry Hastings added the comment:
It looks like you did it with a converter for 28754. That's okay. But not in
the default implementation.
--
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
FWIW, pypy uses defaults of lo=0, hi=None.
https://bitbucket.org/pypy/pypy/src/25da7bc9719457aee57547993833d5168ba6aded/lib-python/2.7/bisect.py?at=default&fileviewer=file-view-default
--
___
Python tracker
&
Larry Hastings added the comment:
Okay, but do it with a converter function, not by changing the default behavior
for Py_ssize_t. The vast majority of uses of Py_ssize_t should not accept None.
--
___
Python tracker
<http://bugs.python.
Larry Hastings added the comment:
We don't *have* to use a converter function, no. But consider: someone
somewhere will have to convert a PyObject * into a Py_ssize_t, also accepting
None. Doing it in a converter function means we can easily share the code with
bisect_right, which s
Larry Hastings added the comment:
Sorry, Argument Clinic doesn't support automatic tuple unpacking for arguments.
It was almost never used, I don't think it was ever a good idea, and it would
have made an already-too-complicated program even more comp
Larry Hastings added the comment:
I don't want this change committed to CPython, you can do what you need with a
converter so do that.
--
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
Since this is the first time anybody has needed it, I suggest the latter.
--
___
Python tracker
<http://bugs.python.org/issue28
Larry Hastings added the comment:
This is currently blocking the release of 3.5.3 rc1.
--
___
Python tracker
<http://bugs.python.org/issue29057>
___
___
Python-bug
Larry Hastings added the comment:
If this is fixed, can we close this issue? This release blocker is one of two
issues blocking 3.5.3 rc1.
--
___
Python tracker
<http://bugs.python.org/issue29
Changes by Larry Hastings :
--
nosy: +larry
___
Python tracker
<http://bugs.python.org/issue29006>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
Can this be marked closed now?
--
___
Python tracker
<http://bugs.python.org/issue29057>
___
___
Python-bugs-list mailin
Larry Hastings added the comment:
I'm making an executive decision to not hold up the 3.5.3rc1 release for
OpenBSD. Hopefully the OpenBSD folks can make sure it works for them before
3.5.3 final ships in two weeks.
--
___
Python tracker
Larry Hastings added the comment:
This code hasn't changed in years. So while I believe it's a security bug and
should be fixed, I don't know if I agree it's a bad enough security bug to stop
Python 3.5.3rc1, which is literally in the middle of the release process.
Larry Hastings added the comment:
Mr. Nasby, as long as you're in a test-reproducing mood, would you mind
downloading the source to 3.5.3rc1 and confirming that it builds correctly for
you? I'd appreciate it! (Not that I don't trust Ned et al, but independent
confirmati
Larry Hastings added the comment:
I cut 3.4.6rc1 and 3.5.3rc1 a couple of days ago. Do you think the CVEs are
bad enough to warrant cherry-picking this? A quick google suggests they were
all low severity:
http://www.openwall.com/lists/oss-security/2016/12/05/21
I'm inclined to not c
Larry Hastings added the comment:
I don't understand the fix. Does this really prevent the injection?
I would fix it this way:
if tixlib is not None and os.path.exists(tixlib):
--
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
FYI I'm keeping an eye on this for possible cherry-picking into 3.5.3 final,
depending on the resolution. Reverting 030e100f048a work for me, assuming
that's a reasonable solution.
--
___
Python trac
Larry Hastings added the comment:
Well, clearly I'm not qualified to review the patch. Could someone please
review it? I want to cherry-pick the fix for this issue for 3.5.3 final, which
I tag in about four days.
--
___
Python tracker
Larry Hastings added the comment:
Ping. Hoping to resolve this in time for 3.5.3, which I tag in about four days.
--
___
Python tracker
<http://bugs.python.org/issue29
Larry Hastings added the comment:
Hoping to tag in less than 48 hours...!
--
___
Python tracker
<http://bugs.python.org/issue29006>
___
___
Python-bugs-list mailin
Larry Hastings added the comment:
Could one of you recent tagees (Terry, Zach) review the patch? Hoping to tag
3.5.3 final in less than 48 hours, and I want to cherry-pick the fix for
this...!
--
___
Python tracker
<http://bugs.python.
Larry Hastings added the comment:
I'll make you a deal. If you check this in in the next 3 hours, I'll
cherry-pick it for 3.5.3. Otherwise I don't want to hold up the release. To
be honest I'm not sure why it's marked as "release b
Larry Hastings added the comment:
If it "has a small attack surface" and affects "a very small number of
applications", I don't think it's a release blocker. Demoting to "high"
priority, which will permit me to release 3.5.3.
Larry Hastings added the comment:
Releasing 3.5.3 even though technically this is an open release blocker. IIUC
the fix is checked in, and fixed the issue for OS X. We don't know whether or
not it is also fixed on OpenBSD, because we don't know anybody running OpenBSD,
and nobody
Changes by Larry Hastings :
--
nosy: -larry
___
Python tracker
<http://bugs.python.org/issue28339>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
I don't think we should update it in 3.5. That sounds destabilizing.
--
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
Sorry about that! It's almost like manually updating Misc/NEWS is a bad design
:(
--
___
Python tracker
<http://bugs.python.org/is
Larry Hastings added the comment:
Speaking as the 3.5 RM, I suppose I have to have an opinion. I don't think
"Python now uses a better source of randomness to seed the random module at
startup" is a major feature. It's a nice-to-have, not a must-have. And people
Larry Hastings added the comment:
> I'm uploading a third version of the patch (against clean 3.5.1 source
Not against the 3.5 branch from hg.python.org/cpython ? If not, why not?
--
___
Python tracker
<http://bugs.python.org
Larry Hastings added the comment:
As RM my default position is naturally "don't change behavior in point
releases". I'm willing to be overruled by the BDFL, less so by anybody else.
--
___
Python tracker
<http://bug
Larry Hastings added the comment:
Okay.
I'm hoping to not delay 3.5.2 RC1, and the schedule calls for me to tag the
release Saturday afternoon. Can you guys get this solid and checked in before
then?
--
___
Python tracker
<http://bugs.py
Larry Hastings added the comment:
I agree with the previous comment author. Can you post a sample program that
crashes Python? Please specify what platform you're running on.
On 32-bit platforms, you'd be unable to construct even the first "r" *
((2**32)-1) string. T
Larry Hastings added the comment:
Was this critical bug fix released on May 17th as promised?
I will not hold up 3.5.2 for this. 3.5.2 has waited long enough.
--
___
Python tracker
<http://bugs.python.org/issue26
Larry Hastings added the comment:
> PSRT VETO!
This is an amusing concept, but membership in the PSRT does not empower you
with a "veto".
On the other hand, being Release Manager does give me some say here.
> You wouldn't add a workaround for broken CPU instructions
Larry Hastings added the comment:
Thank you for summarizing the debate. It made it a lot easier to
> * blocking initialization of the hash secret. This occurs regardless of
> script contents; at present Python simply can't be used at all in low-entropy
> situations. I feel that
Larry Hastings added the comment:
Everybody: let's drop discussing "hashlib" unless someone says it actually is a
problem. I think it was always, as we say in English, a "red herring".
> The secret for SipHash is composed of two 64bit integers. The entire
>
Larry Hastings added the comment:
That reminds me. I want to be clear: I think it's preferable that os.urandom()
blocks when insufficient entropy is available. If Victor's patch changed that,
it should be backed out.
(Since non-blocking urandom is useful, perhaps in 3.6 os.urando
Larry Hastings added the comment:
> This is only a DoS vector if you can hit the server so early in the boot
> process that it doesn't have enough entropy.
Python hash randomization only happens once. So it's not a matter of how early
we try the attack, it's a matter
Larry Hastings added the comment:
I fear I may be changing my mind a little bit. However, I skipped
breakfast--and now it's looking like a late lunch--so I simply have to step
away for a while. Expect me to post in about two hours when I get some
calories down and finally make up my
Larry Hastings added the comment:
I've revised my thinking on the subject.
First, my previous statements stand: Python startup must not block. "import
random" must not block.
Now I'm thinking that "os.urandom()" must not block, too. Here's my reasoning.
Larry Hastings added the comment:
Are you certain that /dev/urandom will block on Mac OS X if sufficient entropy
is not available? The dismissive tone ("this choice and distinction is not
necessary") suggests that *their* implementation is superior, and it could
hardly be seen as s
Larry Hastings added the comment:
So, in short, you don't know.
#25003 is about Solaris, and the reporter clearly had the expectation that
/dev/urandom would never block. The documentation on Linux is clear:
/dev/urandom will never block. That's two.
This "StackExcha
Larry Hastings added the comment:
I don't know if anyone literally still uses BSD. But on FreeBSD, /dev/urandom
can block.
So let me revise my statement slightly. Developers on platform X know how
*their* /dev/urandom behaves. They should rightly expect that os.urandom() is
a thin wr
Larry Hastings added the comment:
You're right, it's remotely possible that on platforms where /dev/urandom could
block, Python startup could therefore also block. And I'm not proposing we fix
that, as so far nobody has reported it as a problem.
This suggests to me that
Larry Hastings added the comment:
> Hi. I created the issue #27266 "Add block keyword-only optional parameter
> to os.urandom()" which is compromise between all proposed solutions and
> should fix *all* urandom issues ;-)
>
> * os.urandom() remains secure by default,
Larry Hastings added the comment:
First, DO NOT merge this change into 3.5.2 without my explicit permission.
Second, unless you can guarantee you support blocking / non-blocking behavior
on all platforms, this is a bad move.
--
___
Python tracker
Larry Hastings added the comment:
> getentropy() is non-blocking. By the way, os.urandom() is now implemented
> with getentropy() on OpenBSD.
I quote issue #25003:
> You can not substitute getentropy() for getrandom(), if you need randomness
> then entropy does
Larry Hastings added the comment:
I am increasingly convinced that I'm right.
--
First, consider that the functions in the os module, as a rule, are a thin
shell over the equivalent function provided by the operating system. If Python
exposes a function called os.XYZ(), and it calls t
Larry Hastings added the comment:
This is why I'm unwilling to accept this change in 3.5.2. This sort of "we
think it's right" behavior is only appropriate in a point release like 3.6.
I think odds are better than even that I'm going to get an os.getrandom(n,
block
Larry Hastings added the comment:
os.getrandom() would be a thin shell around what the local OS provides, and has
the advantage of behaving in a predictable manner. If you provide block=, its
implementation and semantics will vary wildly between platforms.
* On Linux, block=False should be
Larry Hastings added the comment:
> There are a number of functions in os.py that add additional logic ontop of
> the system calls, like:
All the functions you name don't have POSIX equivalents, except popen and
scandir.
popen provides a lot of functionality around popen (which
Larry Hastings added the comment:
Let me make one more thing clear. I'm willing for os.urandom() to try to use
getrandom(GRND_NOBLOCK) (or whatever the flag is called). This will not block
unless the entropy pool is low--which almost never happens. So 99.% of the
time, os.ur
Larry Hastings added the comment:
Wait a minute. If I read the code correctly, currently os.urandom() is
implemented strictly using getrandom() *on all platforms*. And if block=false,
it... returns an empty buffer? Am I reading that right?
And what does it do on platforms that don't h
Larry Hastings added the comment:
> I don't think most people calling os.urandom have any idea how /dev/urandom
> behaves on their machine nor do I think most people have any idea how
> /dev/urandom behaves on other people's machines.
Here I invoke the "consenting
Larry Hastings added the comment:
> Regardless of the behavior of os.urandom (and 'import random'), is it agreed
> that the current state of _PyRandom_Init is acceptable for 3.5.2?
I'll get back to you with a specific yes or no. What I want is that it the
behavior
Larry Hastings added the comment:
> I'd also *STRONGLY* request that we avoid adding any new APIs in relation to
> this that mean "Use os.urandom" is no longer the preferred option to obtain
> cryptographically strong random numbers in Python.
According to the document
Larry Hastings added the comment:
> As a process comment: I agree with what Victor wrote in
> http://haypo-notes.readthedocs.io/pep_random.html#status-of-python-3-5-2,
> when he suggests that we leave 3.5.2 as is for now [...]
I agree in principle. Certainly we all agre
Larry Hastings added the comment:
> Larry, I'm sorry but I think you're just flat wrong here and I don't know
> what else to say about it.
Yeah, I think maybe asking Guido to make a ruling would be the right thing
here. Again, I cite #25003: he implicitly rule
Larry Hastings added the comment:
Victor: just to confirm, would "os.getrandom(n, block=True)" be okay with you?
Do you strongly prefer adding the "block" parameter to os.urandom(), or do you
not care much?
--
___
P
Larry Hastings added the comment:
AFAICT, the history is, Linux added /dev/urandom, then all the other UNIXes
followed suit. I've read a lot of man pages for /dev/urandom (or equivalent)
on a lot of different platforms and most of them say "this was added to Linux,
so we add
Larry Hastings added the comment:
> I wonder what we should do on Linux if /dev/urandom is unavailable and
> getrandom() would block.
I don't think that happens.
getrandom() actually supports two flags. The flag GRND_RANDOM tells it "behave
like /dev/random".
Larry Hastings added the comment:
I +1 on new functions that are designated the best-practice places to get your
pseudo-random numbers.
(IDK if the best place for both is in random; maybe the crypto one should be in
secrets?)
To be precise: on most OSes what you're calling "cry
Larry Hastings added the comment:
Fair enough. But Theodore Ts'o said on the tracker: if you call getrandom()
and don't pass in GRND_RANDOM, it's equivalent to /dev/urandom. So, if
getrandom is available, getrandom(flags=0) will always work
Larry Hastings added the comment:
> Can we please try to be clear about what kind of blocking we mean?
> getrandom(flags=0) absolutely *can* block: that's what the original issue was
> all about. To ensure it *never* blocks you need to call
> getrandom(GRND_NONBLOCK): th
Larry Hastings added the comment:
> Oh, I found how to start a task before the user login, and os.urandom() still
> works: it produces 16 bytes immediatly (in 0.0 second).
Just to confirm: that's a fresh Windows VM, never been booted before ever? If
it had ever been booted befor
Larry Hastings added the comment:
> In my tests, reading from /dev/urandom never blocks even before urandom is
> initialized.
That's correct, and is the big difference between getrandom(0) and reading from
/dev/urandom. If "the entropy pool has not been initialized" (
Larry Hastings added the comment:
> * FreeBSD will likely switch to the new Fortuna successor of Yarrow in an
> upcoming release:
A little more information about that.
FreeBSD did a major refactoring of their /dev/urandom (etc) support, which
landed in October 2014:
Larry Hastings added the comment:
I just posted to python-dev and asked Guido to make a BDFL ruling. I only
represented my side, both because I worried I'd do a bad job of representing
*cough* literally everybody else *cough*, and because it already took me so
long to write the email.
Larry Hastings added the comment:
Colm Buckley: I've read the code, *and* stepped through it, and AFAICT it is no
longer even possible for Python on Linux to call getrandom() in a blocking way.
Thanks for doing this! I'm marking the issue as closed.
--
stage: pa
Larry Hastings added the comment:
Christian: I don't see any checkins on this issue, and I tag 3.4.4 rc1 and
3.5.2 rc1 in about twelve hours. As I mentioned to you in person at the PyCon
2016 sprints, I'm not holding up either of these releases for the expat update.
If this is
Larry Hastings added the comment:
I don't think this is necessary, as the documentation for os.urandom() is
already pretty good. Here's the relevant bit:
This function returns random bytes from an OS-specific randomness
source. The returned data should be unpredictable
Larry Hastings added the comment:
Oh, and, for 3.6 I would definitely support adding a mention of "Instead of
using this function directly, we recommend you use the token_bytes() function
in the secrets module", blah blah best practices etc.
That goes for os.getrandom() too, if we
Larry Hastings added the comment:
As with #27292, I'm going to nosy Georg Brandl about this so he can guide us in
how to approach it. My hunch is, it'd be best if we avoided specifics, and
talked instead in generalities.
Perhaps all that's really necessary is to consistently
Larry Hastings added the comment:
Oops, sorry, forgot to actually nosy Georg. D'oh!
--
nosy: +georg.brandl
___
Python tracker
<http://bugs.python.org/is
New submission from Larry Hastings:
Linux contains two separate sources for random numbers: /dev/urandom and
/dev/random. On a reasonably-current Linux box, the urandom(4) man page states:
As a general rule, /dev/urandom should be used for
everything except long-lived GPG/SSL/SSH keys
Larry Hastings added the comment:
I would suggest weakening the one-line summary. Currently the first line reads:
Return a string of n random bytes suitable for cryptographic use.
I'd support adding some "weasel words" to this, e.g.:
Return a string of n random bytes
Larry Hastings added the comment:
So, you assert getrandom(0) and getrandom(GRND_RANDOM) return random bits of
identically high quality?
I'm curious about this political pressure you cite. It seems bizarre to me
that the Linux developers would bow to such a thing, given how they behav
Larry Hastings added the comment:
I understand. It's just that the manpage for urandom (and in fact the comments
in the source code for /dev/random and /dev/urandom) both recommend using
/dev/random for these long-lived cryptographic keys. Under normal
circumstances I'd simply a
Larry Hastings added the comment:
I'm not the right person to decide this.
As RM, all I can do is decide whether or not to hold up a release based on the
bug. The answer: no. Since this isn't fixed yet in the 3.5 branch, 3.5.2 will
go out without it being fixed. S
Larry Hastings added the comment:
This is not a release blocker.
--
priority: release blocker -> normal
___
Python tracker
<http://bugs.python.org/issu
Larry Hastings added the comment:
I got this when testing 3.5.2rc1 on my Ubuntu 16.04 machine. CAs Xiang Zhang
showed, this is Ubuntu doing something crazy. I ignored the failure and
shipped 3.5.2rc1, however I would be interested in suppressing the test for
3.5.2 final. That way it has a
Larry Hastings added the comment:
This still affects 3.4 and 3.5. It'd be lovely if it could be fixed in all the
still-alive versions. (Yes, this is technically a "bug fix", but I'd still
like it fixed in 3.4.)
--
versions: +Py
Larry Hastings added the comment:
That does seem like it'd make the test failure go away. But the fix seems a
little Ubuntu-specific. Is it reasonable to do that when testing on every
platform?
--
___
Python tracker
<http://bugs.py
Changes by Larry Hastings :
--
nosy: -larry
___
Python tracker
<http://bugs.python.org/issue27314>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
Someone asked on reddit. The Misc/NEWS entry for this reads:
Issue #25843: When compiling code, don’t merge constants if they are equal but
have a different types. For example, f1, f2 = lambda: 1, lambda: 1.0 is now
correctly compiled to two different
Larry Hastings added the comment:
Yes, which doesn't help 3.5.2 final as I don't pull revisions by default after
rc1. :p
--
___
Python tracker
<http://bugs.python.o
Larry Hastings added the comment:
Yes, I'll accept this for 3.5.2 final.
Steve: do I need to do anything besides cherry-pick these revisions?
--
___
Python tracker
<http://bugs.python.org/is
New submission from Larry Hastings:
I can't tell if CPython ever really officially supported Windows CE or not.
There are some checkins around 2.5 that suggest there was at least partial
support. However posixmodule was supposed to be renamed "ce" on Windows CE,
and that wa
1801 - 1900 of 2415 matches
Mail list logo
