[issue27254] heap overflow in Tkinter module

[Emin Ghuliev]

Emin Ghuliev added the comment:

the appropriate size should be chosen I)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27262] IDLE: move Aqua context menu code to maxosx

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I think you can just use bindtags().

button = Button(...)
bindtags = button.bindtags()
button.bindtags(bindtags[:1] + ['MyButton'] + bindtags[1:])
root.bind_class('MyButton', ...)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[Larry Hastings]

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.

--

If you read #25003, it's clear that /dev/urandom is a well-known UNIX facility 
with well-known, predictable behavior.  One behavior that I'll draw particular 
attention to now: it will never block.  If the system is low on entropy, 
/dev/urandom will produce lower-quality random bits.

Again I repeat myself: this is the *expected* behavior.  It is so completely 
the expected behavior, that today's special celebrity guest on the issue, Mr. 
Theodore Ts'o himself, added /dev/random specifically so it would be permitted 
to block when the system was low on entropy.  He *did not change* the behavior 
of /dev/urandom.  He added a *new device*.

A well-informed engineer would see "os.urandom()" and predict (correctly) that 
Python has provided a thin layer over /dev/urandom.  Thus os.urandom() should 
provide the same well-known, predictable behavior as /dev/urandom.

It's fine to enhance os.urandom().  For example, it's fine to provide 
higher-quality bits where available.  It's fine to provide the function on 
Windows which doesn't have a /dev/urandom object.

What is *not* fine is to degrade its behavior.  /dev/urandom is known to never, 
ever block.  This is a *feature*.  os.urandom(), therefore, must also never, 
ever block.

Yes, this means that on these cloud instances with no entropy (yet), 
os.urandom() may return these low-quality random bits.  Just like /dev/urandom 
does.

If I understand the APIs correctly, I'm fine with os.urandom() calling 
getrandom(,,GRND_RANDOM|GRND_NONBLOCK).  If that fails with EAGAIN it should 
fall back to reading from /dev/urandom, or getrandom(,,GRND_NONBLOCK) if that 
makes sense.  (IDK if that's Linux-specific; if it is I suppose /dev/urandom is 
the more cross-platform way to go.)

--

If this is seen as the end of the world by the crypto guys in the thread, let 
me say that I'm willing to consider adding a new function in 3.5.2.  I would 
propose it be spelled "os.getrandom(n, block=True)".  Crypto code could use 
this function if available, and fall back to os.urandom() where it was not.  
This means you're covered: in 3.5.0 and 3.5.1 you use os.urandom(), and in 
3.5.2+ you use os.getrandom(), and in both circumstances you'll block if 
there's insufficient entropy.

--

p.s. Colm Buckley: you notice how dstufft's patch got a "review" link, and none 
of the patches you posted got one?  That's because his is based on the current 
3.5 repo and yours aren't.  This "review" link is very useful in reading your 
patches.  Please in the future try to base your patches against 3.5 trunk.  
It's easy:
% hg clone https://hg.python.org/cpython/ 
% cd cpython
% hg up -r 3.5
(do your work here)
% hg diff > patchfile
(upload patchfile)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27265] Hash of different, specific Decimals created from str is the same

[Radosław Szalski]

New submission from Radosław Szalski:

Python 2.7.11 (default, May  9 2016, 19:53:39)
[GCC 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import Decimal
>>> hash(Decimal('0.05')) == hash(Decimal('0.005'))
True
>>> hash(Decimal(0.05)) == hash(Decimal(0.005))
False

Interactive example: https://repl.it/CZUJ/6

Those values are numerically different and IMO should not have equal hashes. I 
am aware of the quirk with hash(-1) == hash(-2) which is at play here.
This only applies to Decimals created from strings as they are hashed 
differently than float-based ones.


What happens? The following equation is True:
>>> hash(Decimal('0.005')) == hash(Decimal('0.05'))

What I expected to happen? The following equation to be False:
>>> hash(Decimal('0.005')) == hash(Decimal('0.05'))


Platform: MacBook Pro Retina, 13", early 2015, OSX 10.11.5
Tested on Python Versions: 2.7.3, 2.7.10, 2.7.11 (installed via pyenv), all 
exhibit the same behavior


Relevant (not duplicate) issues I've found: 

http://bugs.python.org/issue10356 - decimal.py: hash of -1
http://bugs.python.org/issue8188 - Unified hash for numeric types.



---


Transcript of the interactive example: https://repl.it/CZUJ/6:

from decimal import Decimal

# These two different decimals have equal hashes
print(hash(Decimal('0.005')) == hash(Decimal('0.05')))

# Internally, Decimal's hash is computed like this (sign, exp + len(int), int)
print(hash((0, -2+len('5'), '5')) == hash((0, -3+len('5'), '5')))

# Removing constants, this becomes
print(hash(-2+len('5')) == hash(-3+len('5')))

# Which can be further simplified to:
print(hash(-1) == hash(-2))

# They both return -2, because at the CPython level, -1 is reserved for errors

# Whereas:
print(hash(Decimal(0.005)) == hash(Decimal(0.05)))

# And this is because Decimals created from floats are hashed as floats

--
components: Library (Lib)
messages: 267802
nosy: Radosław Szalski, mark.dickinson
priority: normal
severity: normal
status: open
title: Hash of different, specific Decimals created from str is the same
type: behavior
versions: Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[Cory Benfield]

Cory Benfield added the comment:

> If you read #25003, it's clear that /dev/urandom is a well-known UNIX 
> facility with well-known, predictable behavior.  One behavior that I'll draw 
> particular attention to now: it will never block.  If the system is low on 
> entropy, /dev/urandom will produce lower-quality random bits.

That's not accurate.

/dev/urandom is a well-known UNIX facility, yes, but it does not have 
consistent behaviour across Unices. The behaviour you've described here Larry 
is a well-known *Linux* behaviour.

However, on other Unices the behaviour is different. Here, for example, is the 
relevant man page from Mac OS X ("man 4 random"):

 /dev/urandom is a compatibility nod to Linux. On Linux, /dev/urandom will
 produce lower quality output if the entropy pool drains, while
 /dev/random will prefer to block and wait for additional entropy to be
 collected.  With Yarrow, this choice and distinction is not necessary,
 and the two devices behave identically. You may use either.

Note the specific wording here: "the two devices behave identically". That is 
to say, on OS X both /dev/random and /dev/urandom are identical devices, and 
that includes the fact that both will in principle block if used without 
sufficient entropy.

OS X's implementation is a direct descendent of FreeBSD's, so the same caveats 
apply there, and in fact all the BSDs have this exact same behaviour.

So, again, I repeat my objection from above: if the concern is that starting 
Python must never block, then Python must *never* read from /dev/urandom on 
startup. Otherwise, Python *can* block on BSDs (OS X included in principle, 
though in practice I doubt Apple will use Python that early in boot).

At this point I literally no longer care whether os.urandom() is just a wrapper 
around /dev/urandom: we can look back on this in 10 years and see how we feel 
about the choices made by core dev at that time. But if we're arguing that this 
issue is about "Python must never block at startup", then we really have to 
acknowledge that /dev/urandom *can block* on some Unices, and so is entirely 
unacceptable for reading at startup.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[Larry Hastings]

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 superior if sometimes it blocks.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[Cory Benfield]

Cory Benfield added the comment:

I have never seen it block in person, but I also wouldn't expect to. OS X's 
blocking guarantees are the same as FreeBSD's: that is, both /dev/random and 
/dev/urandom block until sufficient entropy has been gathered at startup and 
then never block again.

This means that, on OS X, in practice, /dev/urandom does never block, because 
you basically can't run user code early enough to encounter this problem.

FreeBSD again has the exact same behaviour: /dev/urandom is a symlink to 
/dev/random, and both will block at startup until sufficient entropy is 
gathered and never again. This is the bigger risk for Python, because if Linux 
people want to use Python in their init system it's not unreasonable for 
FreeBSD folks to want to do it too.

This is why I'm concerned about this "solution": while there's no question that 
adding getrandom() made the situation worse on Linux, it has drawn our 
attention to the fact that Python is relying on Linux-only semantics of 
/dev/urandom on all Unices. That's probably not a good plan.

(The above is all facts. Everything in these parentheticals is opinion. Please 
disregard as appropriate.

I agree with the OS X devs in that I believe their implementation *is* better 
than Linux's: sorry Ted! There is no reason to be concerned about using a good 
kernel CSPRNG once sufficient entropy has been gathered *once*. The CSPRNG 
essentially "stretches" the entropy out into a long sequence of numbers, much 
like a cipher like AES "stretches" the entropy in the key across the entire 
cipherstream. Talking about "running out" of entropy in one of these devices is 
weird to me: as a blog post linked earlier mentions, it's like talking about 
"running out of key" in an encryption algorithm.

It seems to me, then, that Linux's /dev/random is wrong in most situations 
(because it sometimes blocks), and /dev/urandom is wrong in some situations 
(because it'll run before it has enough entropy to properly seed the CSPRNG and 
it won't tell you that that is what has happened). On OS X, the best of both 
worlds occurs: you get no random numbers until sufficient entropy has been 
gathered to seed the CSPRNG, and then you get good random numbers from that 
point on.

Please note: I am not a trained cryptographer. However, trained cryptographers 
have agreed with this set of sentiments, so I think I'm on pretty good ground 
here.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[Larry Hastings]

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 "StackExchange" discussion:
  
http://security.stackexchange.com/questions/42952/how-can-i-measure-and-increase-entropy-on-mac-os-x
suggests that the Yarrow-based /dev/random and /dev/urandom on OS X will *both* 
degrade to PRNG if insufficient entropy is present.  Thus they are are *both* 
like /dev/urandom, and *neither* will ever block.

The salient quote is this, from the random(4) manpage on OS X:
"If the SecurityServer system daemon fails for any reason, output quality will 
suffer over time without any explicit indication from the random device itself."

That sure sounds like bad quality PRNG random bits to me.  So that's three.

Again: ISTM that the universal expectation is that /dev/urandom will never 
block.  Therefore os.urandom() should also never block.  That it blocks in 
3.5.0 and 3.5.1 is a performance regression and should be fixed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[Christian Heimes]

Christian Heimes added the comment:

Cory, thanks for summing it up for us. I totally agree with you. In my opinion 
it is troublesome to have different behavior on platforms. We can implement a 
workaround for Linux, but not for BSD. Or would O_NONBLOCK cause read() to fail 
with EWOULDBLOCK on /dev/urandom device?

It might be secure enough to use srandom() / random() instead of /dev/urandom 
in some platforms. It still won't do any good on platforms like Raspberry Pie 
since the SoC has no RTC. Without a RTC the clock is not set yet. It happens 
much later in the boot phase when network is available.

I don't see a cross-platform solution that is able to handle this super-special 
case without opening a potential security issue for the majority of users.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[STINNER Victor]

STINNER Victor added the comment:

To see how long it takes to initialize urandom pool, you can grep your kernel 
logs. On my physical PC with real hardware, interruptions etc. it's quite fast: 
5 seconds.

-- Logs begin at mar. 2016-01-26 07:54:37 CET, ...
...
juin 06 18:34:47 smithers kernel: random: systemd urandom read with 2 bits of 
entropy available
...
juin 06 18:34:52 smithers kernel: random: nonblocking pool is initialized

I get that the "kernel: random: systemd urandom read with 2 bits of entropy 
available" message comes from the kernel when systemd reads from /dev/urandom 
whereas the pool is not initialized yet.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[Christian Heimes]

Christian Heimes added the comment:

Larry,  /dev/urandom blocks on BSD when it hasn't been seeded yet. But it looks 
like we can use sysctl to fetch the seed state from kern.random.sys.seeded.

https://www.freebsd.org/cgi/man.cgi?query=random&sektion=4

 The software generator will start in an unseeded state, and will block
 reads until it is (re)seeded.  This may cause trouble at system boot when
 keys and the like are generated from /dev/random so steps should be taken
 to ensure a reseed as soon as possible.  The sysctl(8) controlling the
 seeded status (see below) may be used if security is not an issue or for
 convenience during setup or development.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[Colm Buckley]

Colm Buckley added the comment:

[[ Larry - thanks for the Mercurial pointers. I was starting from the Debian 
sources because I initially assumed this was a Debian problem. Will switch to 
hg in future. ]]

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[Larry Hastings]

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 wrapper around their local /dev/urandom.  If their /dev/urandom doesn't 
block, then os.urandom() shouldn't block.  If their /dev/urandom blocks, then 
it's acceptable that their os.urandom() would block.

What I'm trying to avoid here is the surprising situation where someone is 
using Python on a system where /dev/urandom will never block, and os.urandom() 
blocks.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[Cory Benfield]

Cory Benfield added the comment:

> What I'm trying to avoid here is the surprising situation where someone is 
> using Python on a system where /dev/urandom will never block, and 
> os.urandom() blocks.

At this point I literally do not understand what issue we're trying to solve 
then.

If the problem is that os.urandom() must behave exactly like /dev/urandom, then 
sure, that got regressed.

However, I've been talking based on your two previous pronouncements:

> First, my previous statements stand: Python startup must not block.  "import 
> random" must not block.

and

> I am officially making a pronouncement as Release Manager: Python 3.5 *must
> not* take 90 seconds to start up under *any* circumstances.  I view this as
> a performance regression, and it is and will remain a release blocker for
> 3.5.2.
> 
> Python *must not* require special command-line flags to avoid a 90 second
> startup time.  Python *must not* require a special environment-variable to
> avoid a 90 second startup time.  This is no longer open to debate, and I
> will only be overruled by Guido.

Now, if that's the case, then this patch does not fix that problem. It fixes 
that problem *on Linux*, but not on BSDs.

Perhaps you meant to say that those pronouncements only apply to Linux. That's 
fine, it's your prerogative. But as written, they don't: they're unconditional. 
And if they are unconditional, then again I feel like we have to say that 
/dev/urandom should get *out* of the call path on interpreter startup, because 
it absolutely can block. And based on Colm's original problem around gathering 
entropy, which is almost certainly not a Linux-specific concern, I see no 
reason to believe that this is a hypothetical concern on the BSDs.

So, let me ask a very direct question: does the position about 90s startup 
apply only to Linux?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27266] Add block keyword-only optional parameter to os.urandom()

[STINNER Victor]

New submission from STINNER Victor:

Follow-up of the issue #26839: I propose to add a "block" keyword-only optional 
parameter to os.urandom(). I chose to make the parameter a keyword-only to 
avoid suprises and backward incompatible change and because I want to make this 
change in Python 3.5.2.

The attached patch:

* add block parameter to os.urandom()
* modify random.Random constructor to call os.urandom() with block=False
* modify _PyOS_URandom() to add a block parameter
* modify dev_urandom_noraise() to not block

The block parameter currently only changes the behaviour on Linux when the 
getrandom() syscall is used and the urandom entropy pool is not initialized.

With the change, os.urandom() blocks by default, but Python startup and "import 
random" doesn't block even if the urandom entropy pool is not initialized yet.

--
files: urandom_block.patch
keywords: patch
messages: 267814
nosy: haypo
priority: normal
severity: normal
status: open
title: Add block keyword-only optional parameter to os.urandom()
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file43304/urandom_block.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[STINNER Victor]

STINNER Victor 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, as asked by our security experts
* Python startup (hash secret) and "import random" don't block anymore

Happy?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[Larry Hastings]

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 yes I'm talking specifically about the regression on 
Linux in the 3.5 series.

But honestly it's too late for me to say for sure one way or another.  I need 
to go to bed.

p.s if we have to slip RC1 by a day or two in order to get this settled, that's 
okay, but hopefully I can keep final on schedule.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[Cory Benfield]

Cory Benfield 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 yes I'm talking specifically about the regression
> on Linux in the 3.5 series.

Ok, so with that clarification I personally would prefer Victor's patch from 
#27266, but can also understand wanting to leave the codebase as-is. Either way 
would be consistent with your goals, Larry. Victor's patch is more secure, but 
does cause os.urandom to diverge from the semantics of /dev/urandom in extreme 
conditions (specifically, early boot) on Linux.

That's your tradeoff to make, Larry. =) I think both sides have been 
well-argued here. Thanks for clarifying.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[Larry Hastings]

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, as asked by our security experts
> * Python startup (hash secret) and "import random" don't block anymore
> 
> Happy?

Probably not.

What is the default value of the "block" parameter?

If called with block=False on FreeBSD, where /dev/urandom may block sometimes, 
what does the function do?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[STINNER Victor]

STINNER Victor added the comment:

no-urandom-by-default.diff uses a very weak source of entropy for random.Random 
:-( I'm fighting against weak sources of entropy since many years...

This change introduces the bug similar to OpenSSL RAND_bytes() bug (two 
processes with the same pid can produce the same random sequence): two Python 
processes started "at the same time" (with a resolution of 1/256 sec ~= 3.9 ms) 
produces the same random sequence.

With my script:
---
import subprocess, sys
args = [sys.executable, '-S', '-c', 'import random; print([random.randint(0, 
999) for _ in range(4)])']
numbers = set()
procs = [subprocess.Popen(args, stdout=subprocess.PIPE) for _ in range(10)]
for proc in procs:
stdout = proc.communicate()[0]
numbers.add(stdout.rstrip())
for line in numbers:
print(line.decode())
print("duplicates", len(procs) - len(numbers))
---

Output:
---
[68, 812, 821, 421]
[732, 506, 562, 439]
[70, 711, 476, 230]
[411, 474, 729, 837]
[530, 161, 699, 521]
[818, 897, 582, 38]
[42, 132, 359, 275]
[630, 863, 370, 288]
[497, 716, 61, 93]
duplicates 1
---

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27267] memory leak in _ssl.c, function load_cert_chain

[Ralph Haist]

New submission from Ralph Haist:

Test program:

$ cat sslTest.py
import ssl
ctx = ssl.SSLContext(ssl.PROTOCOL_SSLv23)
ctx.load_cert_chain("mycert.pem")
$

valgrind reports a memory leak if this test program is executed by python2.7 as 
follows:

==7266== 24 bytes in 1 blocks are definitely lost in loss record 564 of 2,578
==7266== at 0x4C2815D: malloc (vg_replace_malloc.c:299)
==7266== by 0x4BCDAA: convertsimple (getargs.c:1160)
==7266== by 0x4BCDAA: convertitem (getargs.c:514)
==7266== by 0x4BD841: vgetargskeywords (getargs.c:1618)
==7266== by 0x4BE47B: _PyArg_ParseTupleAndKeywords_SizeT (getargs.c:1464)
==7266== by 0x6DCFADC: load_cert_chain (_ssl.c:2536)
==7266== by 0x4AA75D: call_function (ceval.c:4350)
==7266== by 0x4AA75D: PyEval_EvalFrameEx (ceval.c:2987)
==7266== by 0x4AE209: PyEval_EvalCodeEx (ceval.c:3582)
==7266== by 0x4AE641: PyEval_EvalCode (ceval.c:669)
==7266== by 0x4CC9AD: run_mod (pythonrun.c:1370)
==7266== by 0x4CDAC1: PyRun_FileExFlags (pythonrun.c:1356)
==7266== by 0x4CE4C9: PyRun_SimpleFileExFlags (pythonrun.c:948)
==7266== by 0x4155FF: Py_Main (main.c:654)

After applying this patch to _ssl.c, the memory leak disappears:

$ diff -rc _ssl.c.org _ssl.c
*** _ssl.c.org 2016-05-18 14:18:39.093418625 +0200
--- _ssl.c 2016-05-18 14:41:50.215460826 +0200
***
*** 2611,2616 
--- 2611,2617 
SSL_CTX_set_default_passwd_cb(self->ctx, orig_passwd_cb);
SSL_CTX_set_default_passwd_cb_userdata(self->ctx, orig_passwd_userdata);
PyMem_Free(pw_info.password);
+ PyMem_Free(certfile_bytes);
Py_RETURN_NONE;

error:

--
components: Extension Modules
messages: 267820
nosy: rhaist
priority: normal
severity: normal
status: open
title: memory leak in _ssl.c, function load_cert_chain
type: resource usage
versions: Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27266] Add block keyword-only optional parameter to os.urandom()

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +larry

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27266] Add block keyword-only optional parameter to os.urandom()

[STINNER Victor]

STINNER Victor added the comment:

Larry Hastings (msg267818, on the issue #26839):
> What is the default value of the "block" parameter?

False

> If called with block=False on FreeBSD, where /dev/urandom may block 
> sometimes, what does the function do?

The function blocks.

In which case FreeBSD urandom can block?

Is there a way to read from /dev/urandom without blocking? If not, 
_PyOS_URandom() may use arc4random() on FreeBSD if block is false. I suggest to 
enhance _PyOS_URandom() after the Python 3.5.2 release.

My patch is a quick fix for Python 3.5.2, it can be enhanced later.

I chose to only modify the behaviour on Linux since issues #26839 and #25420 
were only reported on Linux.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[STINNER Victor]

STINNER Victor added the comment:

Larry Hastings:

> > Hi. I created the issue #27266 "Add block keyword-only optional parameter 
> > to os.urandom()" (...)
> > Happy?

> Probably not. (...)

I replied on the issue #27266. Sorry I'm unable to follow this issue, there are 
too many messages now :-(

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24136] document PEP 448: unpacking generalization

[Martin Panter]

Martin Panter added the comment:

Thanks for helping with this Jelle.

The documentation of unpacking sequences vs iterables was adjusted in 3.6 as 
part of Issue 23275. I guess part of revision 8a0754fed986 should be extracted 
to 3.5 as well.

Looking at the function call syntax, positional and starred should be optional. 
I don’t think your syntax would allow print(file=stderr).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27266] Add block keyword-only optional parameter to os.urandom()

[STINNER Victor]

STINNER Victor added the comment:

This issue is the opposite of the issue #27250 "Add os.urandom_block()".

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[Christian Heimes]

Christian Heimes added the comment:

On 2016-06-08 11:39, STINNER Victor wrote:
> 
> STINNER Victor added the comment:
> 
> no-urandom-by-default.diff uses a very weak source of entropy for 
> random.Random :-( I'm fighting against weak sources of entropy since many 
> years...

It is totally fine to init the MT of random.random() from a weak entropy
source. Just keep in mind that a Mersenne Twister is not a CPRNG. There
is simply no reason why you want to init a MT from a CPRNG.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24136] document PEP 448: unpacking generalization

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy:  -pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25738] http.server doesn't handle RESET CONTENT status correctly

[Roundup Robot]

Roundup Robot added the comment:

New changeset 1dc495007b8f by Martin Panter in branch '3.5':
Issue #25738: Don’t send message body for 205 Reset Content
https://hg.python.org/cpython/rev/1dc495007b8f

New changeset b1041ddb1391 by Martin Panter in branch '2.7':
Issue #25738: Don’t send message body for 205 Reset Content
https://hg.python.org/cpython/rev/b1041ddb1391

New changeset de5e1eb4a88d by Martin Panter in branch 'default':
Issue #25738: Merge HTTP server from 3.5
https://hg.python.org/cpython/rev/de5e1eb4a88d

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21313] Py_GetVersion() is broken when using mqueue and a long patch name

[Roundup Robot]

Roundup Robot added the comment:

New changeset b86e259271b3 by Martin Panter in branch '2.7':
Issue #21313: Tolerate truncated buildinfo in sys.version
https://hg.python.org/cpython/rev/b86e259271b3

New changeset 4deec876db0d by Martin Panter in branch '3.5':
Issue #21313: Tolerate truncated buildinfo in sys.version
https://hg.python.org/cpython/rev/4deec876db0d

New changeset aec5a3fc4890 by Martin Panter in branch 'default':
Issue #21313: Merge version parsing from 3.5
https://hg.python.org/cpython/rev/aec5a3fc4890

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27267] memory leak in _ssl.c, function load_cert_chain

[SilentGhost]

Changes by SilentGhost :


--
nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27266] Add block keyword-only optional parameter to os.urandom()

[STINNER Victor]

STINNER Victor added the comment:

> Is there a way to read from /dev/urandom without blocking? If not, 
> _PyOS_URandom() may use arc4random() on FreeBSD if block is false. I suggest 
> to enhance _PyOS_URandom() after the Python 3.5.2 release.

See the issue #22542 "Use arc4random under OpenBSD for os.urandom() if 
/dev/urandom is not present".

It looks like arc4random() is now initialized with getentropy(KEYSZ+IVSZ) (32+8 
= 40 bytes) on OpenBSD:
http://bxr.su/OpenBSD/lib/libc/crypt/arc4random.c

getentropy() is non-blocking. By the way, os.urandom() is now implemented with 
getentropy() on OpenBSD.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27266] Add block keyword-only optional parameter to os.urandom()

[Donald Stufft]

Donald Stufft added the comment:

I'm pretty sure that getentropy on OpenBSD will block until the pool is 
initialized.

--
nosy: +dstufft

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22942] Language Reference - optional comma

[Martin Panter]

Martin Panter added the comment:

Bug 1 is still present in 3.5. In 3.6 it is no longer relevant because the 
documentation was changed for Issue 9232 (allowing trailing commas in function 
definitions).

Bug 2 is present in 2.7, but is not relevant to 3.5+. Trailing commas are now 
allowed in function calls, probably thanks to PEP 448, unpacking 
generalizations.

Bug 3 has been fixed in Issue 27042.

--
stage:  -> needs patch
versions: +Python 2.7, Python 3.5 -Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[Donald Stufft]

Donald Stufft added the comment:

Larry,

I would greatly prefer it if we would allow os.urandom to block on Linux, at 
least by default. This will make os.urandom behavior similarly on most modern 
platforms. The cases where this is going to matter are extreme edge cases, for 
most users they'll just silently be a bit more secure-- important for a number 
of use cases of Python (think for instance, if someone has a SSH server written 
in Twisted that generates it's own host keys, a perfectly reasonable use of 
os.urandom). We've been telling people that os.urandom is the right source for 
generating randomness for cryptographic use for ages, and I think it is 
important to use the tools provided to us by the platform to best satisfy that 
use case by default-- in this case, getrandom() in blocking mode is the best 
tool provided by the Linux platform.

People writing Python code cannot expect that os.urandom will not block, 
because on most platforms it *will* block on intialization. However, the cases 
where it will block are a fairly small window, so by allowing it to block we're 
giving a better guarantee for very little downside-- essentially that something 
early on in the boot process shouldn't call os.urandom(), which is the right 
behavior on Linux (and any other OS) anyways.

The problem is that the Python interpreter itself (essentially) calls 
os.urandom() as part of it's start up sequence which makes it unsuitable for 
use in very early stage boot programs. In the abstract, it's not possible to 
fix this on every single platform without removing all use of os.urandom from 
Python start up (which I think would be a bad idea). I think Colm's 
nonblocking_urandom_noraise.patch is a reasonable trade off (perhaps not the 
one I would personally make, but I think it's reasonable). If we wish to ensure 
that Python interpreter start up never blocks on Linux without needing to 
supply any command line flags or environment variables, then I would strongly 
urge us to adopt his patch, but allow os.urandom to still block.

In other words, please let's not let systemd's design weaken the security 
guarantees of os.urandom (generate cryptographically secure random bytes using 
the best tools provided by the platform). Let's make a targeted fix.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20842] pkgutil docs should reference glossary terms not PEP 302

[Berker Peksag]

Changes by Berker Peksag :


--
keywords: +easy
versions: +Python 3.6 -Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12962] TitledHelpFormatter and IndentedHelpFormatter are not documented

[Berker Peksag]

Berker Peksag added the comment:

optparse has been deprecated for years and I don't see any reason to document 
them now. Closing as rejected.

--
assignee:  -> docs@python
components: +Documentation -Library (Lib)
nosy: +berker.peksag, docs@python
resolution:  -> rejected
stage:  -> resolved
status: open -> closed
type:  -> enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26437] asyncio create_server() not always accepts the 'port' parameter as str

[Berker Peksag]

Berker Peksag added the comment:

After changeset 3ec208c01418 this is no longer an issue:

>>> from asyncio import *
>>> loop = get_event_loop()
>>> coro = loop.create_server(Protocol(), '', '12345')
>>> loop.run_until_complete(coro)
>> coro = loop.create_server(Protocol(), '127.0.0.1', '12345')
>>> loop.run_until_complete(coro)
Traceback (most recent call last):
  File "/home/berker/projects/cpython/default/Lib/asyncio/base_events.py", line 
981, in create_server
sock.bind(sa)
OSError: [Errno 98] Address already in use

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 1, in 
  File "/home/berker/projects/cpython/default/Lib/asyncio/base_events.py", line 
404, in run_until_complete
return future.result()
  File "/home/berker/projects/cpython/default/Lib/asyncio/futures.py", line 
274, in result
raise self._exception
  File "/home/berker/projects/cpython/default/Lib/asyncio/tasks.py", line 240, 
in _step
result = coro.send(None)
  File "/home/berker/projects/cpython/default/Lib/asyncio/base_events.py", line 
985, in create_server
% (sa, err.strerror.lower()))
OSError: [Errno 98] error while attempting to bind on address ('127.0.0.1', 
12345): address already in use

The traceback looks a bit noisy though. Perhaps it needs ``... from None`` or 
something like that.

--
nosy: +berker.peksag
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27264] python 3.4 vs. 3.5 strftime same locale different output on Windows

[Eryk Sun]

Eryk Sun added the comment:

The universal CRT that's used by 3.5+ implements locales using Windows locale 
names [1], which were introduced in Vista. Examples for Spanish include 'es', 
'es-ES', and 'es-ES_tradnl' . The latter is the traditional sort for Spain, 
which has the 3-letter abbreviations for the days of the week. The default for 
Spain is the modern sort, which uses 2-letter abbreviations. 

The old LCID system [2] defaults to the traditional sort (0x40A), to which the 
old CRT maps unqualified "spanish". The modern sort (0xC0A) is available as 
"spanish-modern" [3]. The universal CRT still honors "spanish-modern" [4], but 
just "spanish" by itself is mapped instead to neutral "es", which uses the 
modern sort.

If you need to use the traditional form in both versions, then in 3.4 it's just 
"spanish", but 3.5+ requires a locale name with the sort suffix. I actually 
couldn't find a table on MSDN that listed the "tradnl" sort name to append to 
"es-ES", so I wrote a quick script to find it, assuming at least "tra" would be 
in the name:

import re
import ctypes

kernel32 = ctypes.WinDLL('kernel32')

LOCALE_ENUMPROCEX = ctypes.WINFUNCTYPE(
ctypes.c_int,
ctypes.c_wchar_p,
ctypes.c_uint,
ctypes.c_void_p)

def find_locale(pattern):
result = []
@LOCALE_ENUMPROCEX
def cb(locale, flags, param):
if re.match(pattern, locale, re.I):
result.append(locale)
return True
kernel32.EnumSystemLocalesEx(cb, 0, None, None)
result.sort()
return result

>>> find_locale('es-.*TRA.*')
['es-ES_tradnl']

>>> import locale, time
>>> locale.setlocale(locale.LC_TIME, 'es-ES_tradnl')
'es-ES_tradnl'
>>> time.strftime('%a')
'mié'

Note that abbreviations in Spanish generally end with a period. It's present 
for every country except Spain, such as Mexico:

>>> locale.setlocale(locale.LC_TIME, 'spanish_mexico')
'Spanish_Mexico.1252'
>>> time.strftime('%a')
'mié.'

or using the locale name (3.5+):

>>> locale.setlocale(locale.LC_TIME, 'es-MX')
'es-MX'
>>> time.strftime('%a')
'mié.'

Note that Python still doesn't support parsing locale names:

>>> locale.getlocale(locale.LC_TIME)
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Program Files\Python35\lib\locale.py", line 578, in getlocale
return _parse_localename(localename)
  File "C:\Program Files\Python35\lib\locale.py", line 487, in 
_parse_localename
raise ValueError('unknown locale: %s' % localename)
ValueError: unknown locale: es-MX

Since locale names don't include the encoding, parsing them for getlocale() 
will require an additional call to get the locale's ANSI codepage, in case 
anyone wants to update the locale module to support this:

>>> LOCALE_IDEFAULTANSICODEPAGE = 0x1004
>>> buf = (ctypes.c_wchar * 10)()
>>> kernel32.GetLocaleInfoEx('es-MX', LOCALE_IDEFAULTANSICODEPAGE, buf, 10)
5
>>> buf.value
'1252'

If no one has additional concerns here, I'll close this issue as 3rd party in a 
day or so. Inconsistencies in the locale that "spanish" maps to in different 
versions of the CRT are completely Microsoft's problem.

[1]: https://msdn.microsoft.com/en-us/library/dd373814
[2]: https://msdn.microsoft.com/en-us/library/dd318693
[3]: https://msdn.microsoft.com/en-us/library/39cwe7zf%28v=vs.100%29.aspx
[4]: https://msdn.microsoft.com/en-us/library/39cwe7zf.aspx

--
nosy: +eryksun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

Even though it may sound like a minor problem that os.urandom()
blocks on startup, I think the problem is getting more and more
something to consider given how systems are used nowadays.

Today, we no longer have the case where you keep a system up
and running for multiple years as we had in the past. VM,
containers and other virtualizations are spun up and down at
a high rate, so the boot cycle becomes more and more important.

FreeBSD, for example, is also concerned about the blocking issue
they have in their implementation:

https://wiki.freebsd.org/201308DevSummit/Security/DevRandom

and they are trying to resolve this by making sure to add as
much entropy they can find very early on in the process.

Now, most applications you run early on in the boot process
are not going to be applications that need crypto random
numbers and this is where I think the problem originates.

We've been telling everybody to use os.urandom() for seeding,
and so everyone uses it, including many many applications that
don't even require crypto random seeding.

The random module is the perfect example.

Essentially, we'd need to educate people that there's a difference
in requesting crypto random data and pseudo random data.

While we can fix the the cases in the stdlib and
the interpreter that don't need crypto random data to use
other means of seeding (e.g. reading straight from /dev/urandom
on Linux or gathering other data to mix into a seed), existing
applications out there will continue to use os.urandom() for
things that don't need crypto random numbers - after all, we told
them to use it.

Some of these will eventually be hit by the blocking problem,
even for applications such as Monte Carlo simulations that
don't need crypto random and should thus not have to wait for
some entropy pool to get initialized.

Now, applications that do need crypto random data should be
able to request this from Python via the stdlib and os.urandom()
may sound like a good basis, but since this is designed as
interface to /dev/urandom, it doesn't block on Linux, so
not such a good choice.

Using /dev/random probably doesn't work either, because this can
block unexpected even after initialization.

IMO, the best way forward and to educate application writers
about the problems is to introduce a two new APIs in 3.6:

os.cyptorandom() for getting OS crypto random data
os.pseudorandom() for getting OS pseudo random data

Crypto applications will then clearly know that
os.cryptorandom() is the right choice for them and
everyone else can use os.pseudorandom().

The APIs would on Linux and other platforms then use getrandom()
with appropriate default settings, i.e. blocking or raising
for os.cryptorandom() and non-blocking, non-raising for
os.pseudorandom().

As for the solving the current issue, we will have to
give people some way to get at non-blocking pseudo random data,
if they need it early in the boot process. With the
proposed change, this is still possible via reading
/dev/urandom directly on Linux, so not everything is
lost.

BTW: Wikipedia has a good overview of how the different
implementations of /dev/random work across platforms:

https://en.wikipedia.org/wiki//dev/random

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[Christian Heimes]

Changes by Christian Heimes :


--
nosy:  -christian.heimes

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[Christian Heimes]

Christian Heimes added the comment:

I'm unsubscribing from this ticket for the second time. This form of discussion 
is becoming toxic for me because I strongly beliefe that it is not the correct 
way to handle a security-related problem.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21593] Clarify re.search documentation first match

[Roundup Robot]

Roundup Robot added the comment:

New changeset 48bb48e7499d by Berker Peksag in branch '3.5':
Issue #21593: Clarify that re.search() returns the first match
https://hg.python.org/cpython/rev/48bb48e7499d

New changeset 243b95782059 by Berker Peksag in branch 'default':
Issue #21593: Merge from 3.5
https://hg.python.org/cpython/rev/243b95782059

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21593] Clarify re.search documentation first match

[Berker Peksag]

Berker Peksag added the comment:

> This should also be applied to regex.search's docstring.

Done.

--
nosy: +berker.peksag
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27265] Hash of different, specific Decimals created from str is the same

[Mark Dickinson]

Mark Dickinson added the comment:

There's nothing wrong with two different Decimal objects having the same hash 
(indeed, it's inevitable, given that there are fewer than 2**64 hash values 
available, and many more possible Decimal objects). It only becomes a problem 
if you have a largish naturally-occurring dataset whose values all end up 
falling into the same hash bucket, resulting in linear-time dict operations 
instead of constant time.

I don't think that's the case here: each example of this form only has two 
different values with the same hash.

@Radosław Szalski: is this causing problems in a real application? If not, I 
think it should be closed as "won't fix".

Note that Python 3 is not subject to this issue: it uses a different hashing 
technique (as described in the issue 8188 that you already linked to).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26985] Information about CodeType in inspect documentation is outdated

[Berker Peksag]

Berker Peksag added the comment:

I prefer to not duplicate the list in Lib/inspect.py. We did similar docstring 
cleanups in several modules (venv for example) recently.

--
nosy: +berker.peksag
stage:  -> patch review
type:  -> behavior
versions: +Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21313] Py_GetVersion() is broken when using mqueue and a long patch name

[Martin Panter]

Martin Panter added the comment:

Closing now that platform._sys_version() can tolerate the truncated version 
info.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25738] http.server doesn't handle RESET CONTENT status correctly

[Martin Panter]

Changes by Martin Panter :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27265] Hash of different, specific Decimals created from str is the same

[Mark Dickinson]

Changes by Mark Dickinson :


--
resolution:  -> wont fix
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27242] Make the docs for NotImplemented & NotImplementedError unambigous

[Emanuel Barry]

Emanuel Barry added the comment:

Martin: yes, I plan to install Sphinx soon enough, so that I can build the docs.

As for the notes part, I indented it exactly like it was indented for other 
existing notes boxes in the same file. I'll change that if needed though.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24617] os.makedirs()'s [mode] not correct

[Tommy Beadle]

Changes by Tommy Beadle :


Added file: 
http://bugs.python.org/file43305/0001-Issue-24617-Add-comment-for-os.makedirs-about-certai.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27257] get_addresses results in traceback with a valid? header

[Stephen J. Turnbull]

Stephen J. Turnbull added the comment:

In Python 3.5, both entering the problematic header by hand with a trivial body 
and using email.message_from_string to parse it, and calling 
email.message_from_file on lkml-exception.mail, produce an 
email.message.Message with no defects and no traceback.

Without access to mail_filter.py, it's not clear what the defect might be.

--
nosy: +sjt
stage:  -> test needed
type:  -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8491] Need readline command and keybinding information

[Evelyn Mitchell]

Evelyn Mitchell added the comment:

Revised patch following Martin Panter's review comments.

--
nosy: +Evelyn Mitchell
Added file: http://bugs.python.org/file43306/patch8491a

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27261] io.BytesIO.truncate does not work as advertised

[Justus Winter]

Justus Winter added the comment:

FWIW, I consider the documented behavior a feature.  My use case is to allocate 
a BytesIO object with a given size, obtain a view to its buffer, and write to 
it from a c library.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24617] os.makedirs()'s [mode] not correct

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

See also issue19930.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23275] Can assign [] = (), but not () = []

[Roundup Robot]

Roundup Robot added the comment:

New changeset 39a72018dd76 by Martin Panter in branch '3.5':
Issue #23275: Backport target list assignment documentation fixes
https://hg.python.org/cpython/rev/39a72018dd76

New changeset 8700f4d09b28 by Martin Panter in branch '2.7':
Issue #23275: Backport empty square bracket assignment documentation fix
https://hg.python.org/cpython/rev/8700f4d09b28

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[STINNER Victor]

STINNER Victor added the comment:

Donald: "Cory wasn't speaking about (non)blocking in general, but the case 
where (apparently) it's desired to not block even if that means you don't get 
cryptographically secure random in the CPython interpreter start up. (...)"

Oh sorry, I misunderstood his message.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[STINNER Victor]

STINNER Victor added the comment:

Cory Benfield (msg267637): "if the purpose of this patch was to prevent long 
startup delays, *it failed*. On all the systems above os.urandom may continue 
to block system startup."

I don't pretend fixing the issue on all operating systems. As stated in the 
issue title, this issue is specific to Linux. I understand that the bug still 
exists on other platforms and is likely to require a specific fix for each 
platform.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24617] os.makedirs()'s [mode] not correct

[Tommy Beadle]

Tommy Beadle added the comment:

I think that the documentation should be updated to reflect issue19930's change 
when that is actually committed, not as a part of this change.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27242] Make the docs for NotImplemented & NotImplementedError unambigous

[Martin Panter]

Martin Panter added the comment:

I think the box about NotImplementedError needs indenting too. See the box for 
 for a better 
example.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[Theodore Tso]

Theodore Tso added the comment:

One of the reasons why trying to deal with randomness is hard is because a lot 
of it is about trust.  Did Intel backdoor RDRAND to help out the NSA?   You 
might have one answer if you work for the NSA, and perhaps if you are willing 
to assume the worst about the NSA balancing its equities between its signals 
intelligence mission and providing a secure infrastructure for its customers 
and keeping the US computing industry strong.   Etc., etc.

It is true that OS developers are trying to make their random number generators 
be initialized more quickly at boot time.  Part of this is because of the 
dynamic which we can all see at work on the discussion of this bug.  Some 
people care about very much about not blocking; some people want Python to be 
useful during the boot sequences; some people care very much about security 
above all else; some people don't trust application programmers.  (And if you 
fit in that camp; congratulations, now you know how I often feel when I worry 
about user space programmers doing potentially crazy things and I have no way 
of even knowing about them until the security researchers publish a web site 
such as http://www.factorable.net)

>From the OS's perspective, one of the problems is that it's very hard to know 
>when you have actually achieved a securely initialized random number 
>generator.  Sure, we can say we've done this once we have accumulated at least 
>128 bits of entropy, but that begs the question of when you've collected a bit 
>of entropy.  There's no way to know for sure.  On current systems, we assume 
>that each interrupt gathers 1/64th of a bit of entropy on average.  This is an 
>incredibly conservative number, and on real hardware, assuming the normal 
>bootup activity, we achieve that within about 5 seconds (plus/minus 2 seconds) 
>after boot.   On Intel, on real hardware, I'm comfortable cutting this to 1 
>bit of entropy per interrupt, which will speed up things considerably.  In an 
>ARM SOC, or if you are on a VM and you don't trust the hypervisor so you don't 
>use virtio-rng, is one bit of entropy per interrupt going to be good enough?  
>It's hard to say.

On the other hand, if we use too conservative a number, there is a risk that 
userspace programmers (such as some have advocated on the discussionon this 
bug) to simply always use GRND_NONBLOCK, or fall back to /dev/urandom, and then 
if there's a security exposure, they'll cast the blame on the OS developers.  
The reality is that we really need to work together, because the real problem 
are the clueless people writing python scripts at boot time to create long-term 
RSA private keys for IOT devices[1].  :-)

So when people assert that developers at FreeBSD are at work trying to speedup 
/dev/random initialization, folks need to understand that there's no magic 
here.  What's really happening is that we're all trying to figure out which 
defaults work the best.  In some ways the FreeBSD folks have it easier, because 
they support a much fewer range of platforms.  It's a lot easier to get things 
right on x86, where we have instructions like RDTSC and RDRAND to help us out.  
It's a lot harder to be sure you have things right for ARM SOC's.   There are 
other techniques such as trying to carry entropy over from previous boot 
sessions, but (a) this requires support from the boot loaders, and on an OS 
with a large number of architectures, that means adding support to a large 
number of different ways of booting the kernel --- and it doesn't solve the 
"consumer device generating keys after a cold start when the device is freshly 
removed from the packaging".

As far as adding knobs, such as "blocking vs non-blocking", etc., keep in mind 
that as you add knobs, you increase the knowledge of the system that you force 
onto the next layer of the stack.  So this goes to the question of whether you 
trust application programmers will be able to get things right.

So Ted, why does Linux expose /dev/random vs /dev/urandom?  Historical reasons; 
some people don't believe that relying on cryptogaphic random number generators 
is sufficient, they *want* to use entropy which has minimal reliance on the 
belief that NSA ***probably*** didn't leave a back door into SHA-1, for 
example.  It is for that reason that /dev/random exists.  These days, the 
number of people who believe that to be true are very small, but I didn't want 
to make changes in existing interfaces.  For similar reasons I didn't want to 
suddenly make /dev/urandom block.   The fact that getrandom(2) blocks only 
until the cryptographic RNG has been initialized, and that it depends on a 
cryptogaphic RNG, is the consensus that *most* people have come to, and it 
reflects my recommendations that unless you ***really*** know what you are 
doing, the right thing to do is to call getrandom(2) with the flags field set 
to zero, and to be happy.   Of course, many people are sure they know what they 
n

[issue27257] get_addresses results in traceback with a valid? header

[Stephen J. Turnbull]

Stephen J. Turnbull added the comment:

OK, I can reproduce now.

$ python3.5
Python 3.5.0 (v3.5.0:374f501f4567, Sep 17 2015, 17:04:56) 
[GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import email
>>> with open(b'lkml-exception.mail', mode = 'r') as f:
...  msg = email.message_from_file(f, policy=email.policy.SMTP)
... 
>>> msg.get_all('to')
Traceback (most recent call last):

and (except for a slight skew in line-numbering) the rest is the same as the 
tail of the OP.

The crucial part is the policy=email.policy.SMTP argument, and evidently what's 
happening is that the parser assumes that the local-part of the addr-spec is 
non-empty.  RFC5322 does permit a quoted-string to be empty, so this is a bug 
in the email module's parser.  (I don't have a patch,sorry.)

Aside: although strictly speaking it's hold-your-nose-and-avert-your-eyes legal 
according to RFC 5322, RFC 5321 (SMTP) does say:

   While the above definition for Local-part is relatively permissive,
   for maximum interoperability, a host that expects to receive mail
   SHOULD avoid defining mailboxes where the Local-part requires (or
   uses) the Quoted-string form[...].

I don't see a good reason for the usage in the test case, so I'd call this 
nonconformant to RFC 5321.  I think the right way to handle it is to register a 
defect but let the parse succeed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[Theodore Tso]

Theodore Tso added the comment:

Oh --- and about people wondering whether os.random is being used for 
cryptographic purposes or not "most of the time" or not --- again, welcome to 
my world.  I get complaints all the time from people who try to do "dd 
if=/dev/urandom of=/dev/hdX bs=4k" and then complain this is too slow.

Creating an os.cryptorandom and os.pseudorandom might be a useful way to go 
here.  I've often considered whether I should create a /dev/frandom for the 
crazies who want to use dd as a way to wipe a disk, but to date I've haven't 
thought it was worth the effort, and I didn't want to encourage them.  Besides, 
isn't obviously the right answer is to create a quickie python script?  :-)

Splitting os.random does beg the question of what os.random should do, however. 
 If you go down that path, I'd suggest defaulting to the secure-but-slow choice.

I'd also suggest assuming it's OK to put the onus on the people who are trying 
to run python scripts during early boot to have to either add some command 
flags to the python interpreter, or to otherwise make adjustments, as being 
completely fair.  But again, that's my bias, and if people don't want to deal 
with trying to ask the systemd folks to make a change in their code, I'd 
_completely_ understand.

My design preference is that outside of boot scripts, having os.random block in 
the same of security is completely fair, since in that case you won't deadlock 
the system.  People of good will may disagree, of course, and I'm not on the 
Python development team, so take that with whatever grain of salt you wish.   
At the end of the day, this is all about tradeoffs, and you know your 
customer/developer base better than I do.\

Cheers!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[Colm Buckley]

Colm Buckley added the comment:

Victor -

Yes, it is possible for it to block forever - see the test I proposed for Ted 
upthread. The triggering case (systemd-crontab-generator) delays for 90 
seconds, but is *killed* by systemd after that time; it doesn't itself time out.

Colm

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[STINNER Victor]

STINNER Victor added the comment:

>> The current behavior is that Python *will not start at all* if getrandom() 
>> blocks (because the hash secret initialization fails).
> It starts jsut fine, it just can possible takes awhile.

In my experience, connecting to a VM using SSH with low entropy can take longer 
than 1 minute. As an user, I considered that the host was down. Longer than 1 
minute is simply too long.

It's unclear to me if getrandom() can succeed (return random bytes) on embedded 
devices without hardware RNG. Can it take longer than 1 minute?

Is it possible that getrandom() simply blocks forever?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27268] Incorrect error message on float('')

[Adam Bartoš]

New submission from Adam Bartoš:

>>> float('foo')
ValueError: could not convert string to float: 'foo'
>>> float('')
ValueError: could not convert string to float: 

should be
ValueError: could not convert string to float: ''

The message comes from Objects/floatobject.c:183 but I don't understand how the 
empty string gets discarded.

--
components: Interpreter Core
messages: 267858
nosy: Drekin
priority: normal
severity: normal
status: open
title: Incorrect error message on float('')
type: behavior
versions: Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27187] Relax __all__ location requirement in PEP 8

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

Thanks Ian.  I'm going to apply that, but rephrase it a bit.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27254] heap overflow in Tkinter module

[Emin Ghuliev]

Emin Ghuliev added the comment:

psuedocode

<+16>:  movsxd rdx,DWORD PTR [rbx+0x8]
<+20>:  leaeax,[rdx+rbp*1]

newSize = length ($rdx) + dsPtr->length ($rbp)
gdb > print /x $rbp
$5 = 0xf
gdb > print /x $rdx
$6 = 0x10

newsize = 0xf+0x10 = 0x1f

  cmpeax,DWORD PTR [rbx+0xc]   ← $pc
  jl 0x76194e38 

newSize ($eax) >= dsPtr->spaceAvl

gdb > print /x $eax
$7 = 0x1f

gdb > x/x $rbx+0xc
0x7fffd0cc: 0x001e

condition: 0x1f >= 0x001e = True

if (newSize >= dsPtr->spaceAvl) {
  leaesi,[rax+rax*1] ; magic compiler 
optimization :) (newSize(0x1f)*2)
/*  */
dsPtr->spaceAvl = newSize * 2;
gdb > print /x $rax
$4 = 0x1f
$esi = 0x1f+0x1f (newSize(0x1f)*2) = 0x3e
/*  */

=> <+34>:   learax,[rbx+0x10]
   <+38>:   movDWORD PTR [rbx+0xc],esi
   <+41>:   cmprdi,rax ; $rax = dsPtr->staticSpace and 
$rdi = dsPtr->string
   <+44>:   je 0x76194e50 

condition : dsPtr->string == dsPtr->staticSpace = False then 
jump to '  call   0x760c2040 '

if (dsPtr->string == dsPtr->staticSpace) {
char *newString = ckalloc(dsPtr->spaceAvl);
memcpy(newString, dsPtr->string, (size_t) 
dsPtr->length);
dsPtr->string = newString;
} 
else {
  call   0x760c2040 

$rsi = 0x3e
$rdi = 0x7333e020
dsPtr->string = ckrealloc(dsPtr->string = 
0x7333e020, dsPtr->spaceAvl = 0x3e);
}
}


disassemble: 
   leardi,[rax+rdx*1] ; 
dsPtr->string + dsPtr->length
   movrsi,r12 ; bytes
   movsxd rdx,ebp ; length
   call   0x760a25c0 
 memcpy(dsPtr->string + dsPtr->length, bytes, length);

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27269] ipaddress: Wrong behavior with ::ffff:1.2.3.4 style IPs

[ThiefMaster]

New submission from ThiefMaster:

I'd expect the IPv4 address to be considered part of that network (or actually 
parsed as an IPv4Address and not IPv6Address) even if it's written in IPv6 
notation. It's an IPv4 after all.

Python 3.5.1 (default, Jun  7 2016, 09:20:44)
[GCC 4.9.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ipaddress
>>> ipaddress.ip_address(':::127.0.0.1')
IPv6Address(':::7f00:1')
>>> ipaddress.ip_address(':::127.0.0.1') in 
>>> ipaddress.ip_network('127.0.0.0/8')
False
>>> ipaddress.ip_address('127.0.0.1') in ipaddress.ip_network('127.0.0.0/8')
True

--
components: Library (Lib)
messages: 267861
nosy: ThiefMaster
priority: normal
severity: normal
status: open
title: ipaddress: Wrong behavior with :::1.2.3.4 style IPs
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27265] Hash of different, specific Decimals created from str is the same

[Mark Dickinson]

Changes by Mark Dickinson :


--
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27265] Hash of different, specific Decimals created from str is the same

[Mark Dickinson]

Mark Dickinson added the comment:

For what it's worth, here are timings on my machine showing the overhead of the 
extra equality check when a hash collision occurs.

Python 2.7.11 (default, Mar  1 2016, 18:08:21) 
Type "copyright", "credits" or "license" for more information.

IPython 4.2.0 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help  -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: from decimal import Decimal

In [2]: set1 = set([Decimal(str(n/1000.0)) for n in range(1, 10)] + 
[Decimal(str(n/100.0)) for n in range(1, 10)])

In [3]: set2 = set([Decimal(str(n/1000.0)) for n in range(2, 20)])

In [4]: print len(set1), len(set2)  # Both sets have the same length
18 18

In [5]: print len(set(map(hash, set1))), len(set(map(hash, set2)))  # But set1 
has hash collisions
9 18

In [6]: %timeit Decimal('0.005') in set1  # checking elt in the set, first 
match is the right one
The slowest run took 5.98 times longer than the fastest. This could mean that 
an intermediate result is being cached.
10 loops, best of 3: 17.4 µs per loop

In [7]: %timeit Decimal('0.05') in set1  # checking elt in the set, collision 
resolution needed
The slowest run took 5.72 times longer than the fastest. This could mean that 
an intermediate result is being cached.
10 loops, best of 3: 19.6 µs per loop

In [8]: %timeit Decimal('0.005') in set2  # should be similar to the first set1 
result
The slowest run took 5.99 times longer than the fastest. This could mean that 
an intermediate result is being cached.
10 loops, best of 3: 17.3 µs per loop

--
status: pending -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27269] ipaddress: Wrong behavior with ::ffff:1.2.3.4 style IPs

[SilentGhost]

Changes by SilentGhost :


--
nosy: +pmoody
versions:  -Python 3.3, Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7063] Memory errors in array.array

[Berker Peksag]

Changes by Berker Peksag :


--
nosy: +berker.peksag
stage: needs patch -> patch review
versions: +Python 3.6 -Python 3.3, Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[Colm Buckley]

Colm Buckley added the comment:

Just to re-state; I think we have three problems:

1) _Py_HashSecret initialization blocking. Affects all Python invocations; 
already a substantial issue on Debian testing track (90s startup delay).

* there seems to be general agreement that this does not need a 'strong' secret 
in a script called at/near startup.
* On Linux, getrandom(GRND_NONBLOCK) *or* /dev/urandom are sufficient for this 
initialization.
* On other OS, we don't have a non-blocking kernel PRNG; this is probably not 
an issue for Solaris or OS X, and only a possible issue for OpenBSD.
* Is it acceptable to fall back to an in-process seed generation for the cases 
where initialization via /dev/urandom fails (NB : there have been no reports of 
this type of failure in the wild).

* existing tip with or without nonblocking_urandom_noraise.patch addresses this 
for Linux. Solution for other OS remains to be written.
* Possibly can be considered non-blocking for other OS, as there has been no 
recent regression in behavior.

2) Blocking on 'import random' and/or os.urandom. I don't see a clear consensus 
on the Right Thing for this case. Existing tip (without 
nonblocking_urandom_noraise.patch) addresses it for Linux, but solution is not 
universally accepted. Unclear whether this is a 3.5.2 blocker.

3) Design of future APIs for >= 3.6. The most frequent suggestion is something 
like os.pseudorandom() (guaranteed nonblocking) and os.cryptorandom() 
(guaranteed entropy); I guess this needs to go to the dev list for full 
discussion - is it safely out of scope for this bug?

My suggestion (for what it's worth): accept Victor's changeset plus 
nonblocking_urandom_noraise for 3.5.2 (I'll submit a proper patch shortly), 
recommend userspace workarounds for the blocking urandom issue, propose new 
APIs for 3.6 on the dev list.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27268] Incorrect error message on float('')

[Eryk Sun]

Eryk Sun added the comment:

> The message comes from Objects/floatobject.c:183

No, in this case the error is set in PyOS_string_to_double in 
Python/pystrtod.c, because `fail_pos == s`, and it doesn't get replaced in 
PyFloat_FromString because `end == last`. The format string in 
PyOS_string_to_double should probably be "'%.200s'".

--
nosy: +eryksun
versions: +Python 2.7, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27243] __aiter__ should return async iterator instead of awaitable

[Yury Selivanov]

Yury Selivanov added the comment:

Nick,

Please see the updated patch.  Do you think it's ready to be merged?  I want 
buildbots to have some time with it before RC.

--
Added file: http://bugs.python.org/file43307/fix_aiter3.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27050] Demote run() below the high level APIs in subprocess docs

[Akira Li]

Akira Li added the comment:

> setting "universal_newlines=True" switches to UTF-8 encoded text pipes

It uses locale.getpreferredencoding(False) encoding -- something like 
cp1252,cp1251,etc on Windows, and UTF-8 on *nix with proper locale settings.

It is ASCII (C/POSIX locale default) if the locale is not set in cron, ssh, 
init.d scripts, etc.

If you need a different character encoding, you could use (instead of 
universal_newlines=True):

  pipe = io.TextIOWrapper(process.stdout, encoding=character_encoding)

A better spelling for universal_newlines=True would be text_mode=True.

A summary table (like in itertools' module) would be nice.

check_output() name is unfortunate but it does the right thing and it is not 
hard to use for a beginner --
once somebody discovers it e.g., via "Running shell command from Python and 
capturing the output" Stack Overflow question
http://stackoverflow.com/questions/4760215/running-shell-command-from-python-and-capturing-the-output

Compare:

  output = check_output([sys.executable, '-c', 'print("abc")'])

and

  output = run([sys.executable, '-c', 'print("abc)'], stdout=PIPE).stdout

The latter command doesn't raise exception if the child process fails.
A beginner has to know about check=True to do the right thing:

  output = run([sys.executable, '-c', 'print("abc")'], stdout=PIPE, 
check=True).stdout

It is easier to refer to check_output() if someone asks "How do I get command's 
output in Python?"


I wish call() did what check_call() does and the current call() behavior would 
be achieved by
the opposite parameter e.g. no_raise_on_status=False being the default:

   rc = call(command, no_raise_on_status=True)

If we can't change the interface then check_call() is the answer to "Calling an 
external command in Python" question
http://stackoverflow.com/questions/89228/calling-an-external-command-in-python

  - check_call(command) -- run command, raise if it fails
  - output = check_output(command) -- get command's output, raise if it fails.
  To pass *data* to the command via its standard input, pass input=data.
  To get/pass text (Unicode) instead of bytes, pass universal_newlines=True
  - check_call("a -- *.jpg | b 2>&1 >output | c", shell=True) -- run a shell 
command as is
  It is a pity that a list argument such as ["ls", "-l"] is allowed with 
shell=True

These cover the most common operations with a subprocess.

Henceforth, run() is more convenient if we don't need to interact with the 
child process while it is running.

For example, if  we introduce the word PIPE (a magic object in the kernel that 
connects processes) then
to capture both standard and error streams of the command:

  cp = run(command, stdout=PIPE, stderr=PIPE)
  output, errors = cp.stdout, cp.stderr

run() allows to get the output and to get the exit status easily: cp.returncode.
Explicit cp.stdout_text, cp.stdout_bytes regardless the text mode would be nice.

To interact with a child process while it is running, Popen() have to be used 
directly.
There could be buffering and other issues (tty vs. pipe), see "Q: Why not just 
use a pipe (popen())?"
http://pexpect.readthedocs.io/en/latest/FAQ.html#whynotpipe

Working with both stdout/stderr or a non-blocking read require threads or 
asyncio, fcntl, etc.

A couple of words should be said about killing a command started with 
shell=True.
(to kill a process tree: set start_new_session=True parameter and call 
os.killpg()).
timeout option doesn't work in this case (it uses Popen.kill()).
check_output() unlike check_call() may wait for grandchildren if they inherit 
the pipe.
Mention Job object on Windows e.g.,
http://stackoverflow.com/questions/23434842/python-how-to-kill-child-processes-when-parent-dies

--
nosy: +akira

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27127] Never have GET_ITER not followed by FOR_ITER

[Demur Rumed]

Changes by Demur Rumed :


--
resolution:  -> rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27266] Add block keyword-only optional parameter to os.urandom()

[STINNER Victor]

STINNER Victor added the comment:

Ah, there is maybe a solution for BSD?

msg267810: "it looks like we can use sysctl to fetch the seed state from 
kern.random.sys.seeded"

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27266] Always use getrandom() in os.random() and add block=False parameter to os.urandom()

[STINNER Victor]

STINNER Victor added the comment:

I changed the title to make my intent more explicit: the goal is to make 
os.urandom() more secure on Linux by always using getrandom(). But always using 
getrandom() in os.urandom() requires a non-blocking os.urandom() to start 
Python: see #25420 (import random) and #26839 (hash secret) for practical 
issues.

I removed Python 3.5 from versions since Larry explicitly asked to not add a 
new parameter to os.urandom() in Python 3.5: msg267721.

--
title: Add block keyword-only optional parameter to os.urandom() -> Always use 
getrandom() in os.random() and add block=False parameter to os.urandom()
type:  -> enhancement
versions:  -Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

[STINNER Victor]

Changes by STINNER Victor :


--
title: Always use getrandom() in os.random() and add block=False parameter to 
os.urandom() -> Always use getrandom() in os.random() on Linux and add 
block=False parameter to os.urandom()

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27136] sock_connect fails for bluetooth (and probably others)

[Roundup Robot]

Roundup Robot added the comment:

New changeset 3f49e89be8a9 by Yury Selivanov in branch '3.5':
Issue #27136: Fix DNS static resolution; don't use it in getaddrinfo
https://hg.python.org/cpython/rev/3f49e89be8a9

New changeset e46b23b6a068 by Yury Selivanov in branch 'default':
Merge 3.5 (issue #27136, asyncio)
https://hg.python.org/cpython/rev/e46b23b6a068

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27136] sock_connect fails for bluetooth (and probably others)

[Yury Selivanov]

Yury Selivanov added the comment:

Will be fixed in CPython 3.5.2.

--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27136] sock_connect fails for bluetooth (and probably others)

[Roundup Robot]

Roundup Robot added the comment:

New changeset 149fbdbe4729 by Yury Selivanov in branch '3.5':
Issue #27136: Update asyncio docs
https://hg.python.org/cpython/rev/149fbdbe4729

New changeset 44767f603535 by Yury Selivanov in branch 'default':
Merge 3.5 (asyncio, issue #27136)
https://hg.python.org/cpython/rev/44767f603535

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26446] Mention in the devguide that core dev stuff falls under the PSF CoC

[Brett Cannon]

Brett Cannon added the comment:

Thanks for the patch, Evelyn! The latest one LGTM and I will commit it when I 
have time.

I do still plan to add a subsection at the bottom of the index page mentioning 
the CoC so it's in a very visible location.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26839] Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()

[STINNER Victor]

STINNER Victor added the comment:

I spent almost my whole day to read this issue, some related issues, and some 
more related links. WOW! Amazing discussing. Sorry that Christian decided to 
quit the discussion (twice) :-(

Here is my summary: http://haypo-notes.readthedocs.io/pep_random.html

tl; dr "The issue is to find a solution to not block Python startup on such 
case, and keep getrandom() enhancement for os.urandom()."

--

Status of Python 3.5.2: 
http://haypo-notes.readthedocs.io/pep_random.html#status-of-python-3-5-2

My summary: "With the changeset 9de508dc4837: Python doesn’t block at startup 
anymore (issues #25420 and #26839 are fixed) and os.urandom() is as secure as 
Python 2.7, Python 3.4 and any application reading /dev/urandom."

=> STOP! don't touch anything, it's now fine ;-) (but maybe follow my link for 
more information)

--

To *enhance* os.urandom(), always use getrandom() syscall on Linux, I opened 
the issue #27266. I changed the title to "Always use getrandom() in os.random() 
on Linux and add block=False parameter to os.urandom()" to make my intent more 
explicit.

As some of you have already noticed, it's not easy to implement this issue! 
There are technical issues to implement os.urandom(block=False).

In fact, this issue tries to fix two different but close issues:

(a) Always use getrandom() for os.urandom() on Linux
(b) Implement os.urandom(block=False) on *all* platforms

The requirement for (a) is to not reopen the bug #25420 (block on "import 
random"). dstufft proposed no-urandom-by-default.diff (attached to this issue), 
but IMHO it makes the random module worse than before. I proposed (b) as the 
correct fix. It's a work-in-progress, please come on the issue #27266 to help 
me!

--

Please contact me if we want to fix/enhance my doc 
http://haypo-notes.readthedocs.io/pep_random.html

Right now, I'm not interested to convert this summary to a real PEP. It looks 
like you agree on solutions. We should now invest our time on solutions rather 
than listing again all issues ;-)

I know that it's really hard, but I suggest to abandon this issue (since, 
again, it's closed!), and focus on more specific issues and work on fixing 
issues. No? What do you think?

--

IMHO The problem in this discussion is that it started with a very well defined 
issue (Python blocks at startup on Debian Testing in a script started by 
systemd when running in a VM) to a wide discussion about all RNG, all kinds of 
issues related to RNG and a little bit to security in general.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27242] Make the docs for NotImplemented & NotImplementedError unambiguous

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
title: Make the docs for NotImplemented & NotImplementedError unambigous -> 
Make the docs for NotImplemented & NotImplementedError unambiguous

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24567] random.choice IndexError due to double-rounding

[Raymond Hettinger]

Raymond Hettinger added the comment:

Will get to it shortly.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27260] Missing equality check for super objects

[Raymond Hettinger]

Raymond Hettinger added the comment:

I don't think this should be done.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27268] Incorrect error message on float('')

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +mark.dickinson, serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27262] IDLE: move Aqua context menu code to maxosx

[Terry J. Reedy]

Terry J. Reedy added the comment:

[The light dawns, as the pieces connect together] The pseudoclass 'MyButton' 
would then consist of all widgets with 'MyButton' inserted into its bindtags 
list.  Similarly for 'Editor'. I presume that a) tk has the equivalent of a 
master bind dict mapping bindtags to dicts mapping event sequences strings to 
event handlers, and b) .bind_class(cname, evseq, func) does the equivalent of 
"tagdict.get(cname, {})[evseq] = func".

I also notice that the introspective versions of .bind... call will let us 
discover the pre-defined bindings on difference systems and check our 
alterations.  Anyway, thanks.  I will experiment when ready to refactor 
bindings.  In the meanwhile, I will apply the patch and close this.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27262] IDLE: move Aqua context menu code to maxosx

[Roundup Robot]

Roundup Robot added the comment:

New changeset 09ec7f7322b5 by Terry Jan Reedy in branch 'default':
Issue #27262: move Aqua unbinding code, which enable context menus, to maxosx.
https://hg.python.org/cpython/rev/09ec7f7322b5

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

[Larry Hastings]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

[Theodore Tso]

Theodore Tso added the comment:

Larry, at least on FreeBSD, it sounds like the implementation could just the 
kern.random.sys.seeded sysctl, and return .  (Note: what is the 
proposed behaviour if the PRNG is not seeded?  Return Null?)

As far as OpenBSD is concerned, it's true that it's getentropy(2) never blocks. 
 But that's because OpenBSD assumes that the bootloader can read a seeded 
entropy file from the previous boot session, and that the CD-ROM installer will 
be able to gather enough entropy to save a entropy file from the beginning of 
the installation.So if you don't have worry about booting your OS on an ARC 
Internet of Things device, you can afford to make certain simplifying 
assumptions.

Could Linux on x86 do something similar (read the entropy file in the 
bootloader)?  Sure, the design isn't difficult.  If someone can fund the 
headcount to do the work, I'd be happy to help supervise the GSOC intern or 
work with some engineer at some other company who is interested in getting a 
change like this upstream.  But there will still be cases where getrandom(2) 
could block, simply because I can't control all of the hardware platforms where 
Linux might be ported to.   The real problem is that since on real hardware 
platforms it's only a problem in very early boot, it's hard to make a business 
case to invest in solving this problem.

--
nosy: +Theodore Tso

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27129] Wordcode, part 2

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Here is a patch that just refactors the code. It renames OPCODE and OPCODE to 
_Py_OPCODE and _Py_OPCODE and moves them to code.h for reusing in other files. 
Introduces _Py_CODEUNIT as an alias to unsigned short (if it is 16-bit, 
otherwise a compile error is raised). Makes compiler and peepholer to operate 
with _Py_CODEUNIT units instead of bytes. Replaces or scale magic numbers with 
sizeof(_Py_CODEUNIT). Adds fill_nops() for filling specified region with NOPs. 
Decreases memory consumption for peepholer (doesn't allocate memory for unused 
odd addresses).

--
Added file: http://bugs.python.org/file43308/wordcode-refactor.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27270] 'parentheses-equality' warnings when building with clang and ccache

[Xavier de Gaye]

New submission from Xavier de Gaye:

Building Python with clang and ccache produces about 200 'parentheses-equality' 
warnings with the message:
warning: equality comparison with extraneous parentheses 
[-Wparentheses-equality]

It seems that clang does not recognize that these extraneous parentheses are 
valid [1] after a macro expansion because the preprocessing is done as a 
separate stage by ccache.

[1] For example:
With the macros:
#define Py_TYPE(ob)   (((PyObject*)(ob))->ob_type)
#define PyLong_CheckExact(op) (Py_TYPE(op) == &PyLong_Type)
The statement:
if (PyLong_CheckExact(v))
is expanded to:
if (PyObject*)(v))->ob_type) == &PyLong_Type))
and produces the warning with ccache.

--
components: Devguide
files: clang_ccache.patch
keywords: patch
messages: 267881
nosy: eric.araujo, ezio.melotti, ncoghlan, willingc, xdegaye
priority: normal
severity: normal
stage: patch review
status: open
title: 'parentheses-equality' warnings when building with clang and ccache
type: enhancement
Added file: http://bugs.python.org/file43309/clang_ccache.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

[STINNER Victor]

STINNER Victor added the comment:

Larry Hastings added the comment:
>
> First, DO NOT merge this change into 3.5.2 without my explicit permission.
>

I explicitly removed Python 3.5 from this issue to follow your request. See
my previous comment :-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27266] Always use getrandom() in os.random() on Linux and add block=False parameter to os.urandom()

[Larry Hastings]

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 not suffice.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7063] Memory errors in array.array

[Mark Lawrence]

Changes by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27271] asyncio lost udp packets

[valdemar pavesi]

New submission from valdemar pavesi:

hello,

I am using asyncio to handle 165 udp-packet per second

everything received by (datagram_received) will be put into a queue.

+++
124605 UDP packets send from client.

and received by server network:

dumpcap  ( filter "port 5  and len > 100" ) 
Packets: 124605

correct number send and received.  124605

++

received by application:

def datagram_received(self, data, addr):

[2016-06-08 14:59:49] total udp = 124255,queue size =0
[2016-06-08 14:59:49] Got 124255 json report from server.

only 124255 received by application.

124605 - 124255 = 350 udp , received by network card , but application never 
got it.

+++


code:
#
class UDPProtocolServerTraffica:

def __init__(self):
self.transport = None
# heart beat timer
self.HEARTBEAT_TIMEOUT = 10.0
self.REPORTSHOWTOTAL_TIMEOUT=60.0
self.MSG_UDP_HEARTBEAT = 
b'\x01\x00\x00\x00\x11\x00\x00\x00\x01\x00\x00\x00\x00\x05\x00\x00\x00'
self.UDPCount = 0

def connection_made(self, transport):
self.transport = transport
# traffica startup message
self.transport.sendto(self.MSG_UDP_HEARTBEAT, (fns_remote_host, 
fns_remote_port))
# start 10 seconds timeout timer
self.h_timeout = 
asyncio.get_event_loop().call_later(self.HEARTBEAT_TIMEOUT, 
self.timeout_heartbeat)
# show total report
self.h_timeout = 
asyncio.get_event_loop().call_later(self.REPORTSHOWTOTAL_TIMEOUT, 
self.timeout_report_showtotal)

 
def datagram_received(self, data, addr):
#fns_mmdu_ipaddr = addr [0]
#fns_mmdu_port = addr [1]
Report_Id = (int.from_bytes(data[0:2], byteorder='big'))
if Report_Id != 327:
self.UDPCount += 1
# send message to queue
asyncio_queue.put_nowait(data)
  
def pause_reading(self):
print('pause_reading')

def resume_reading(self):
print('resume_reading')

def error_received(self, exc):
print('Error received:', exc)

def connection_lost(self, exc):
print('stop', exc)

def timeout_heartbeat(self):
self.transport.sendto(self.MSG_UDP_HEARTBEAT, (fns_remote_host, 
fns_remote_port))
self.h_timeout = 
asyncio.get_event_loop().call_later(self.HEARTBEAT_TIMEOUT, 
self.timeout_heartbeat)
#print('queue size ',asyncio_queue.qsize())
 
def timeout_report_showtotal(self):
self.h_timeout = 
asyncio.get_event_loop().call_later(self.REPORTSHOWTOTAL_TIMEOUT, 
self.timeout_report_showtotal)
self.displayReportTotalCount()
elasticsearch_get_all_reports()

def displayReportTotalCount(self):
logging.info('Total udp from fns: ' + str(self.UDPCount) + ' , queue 
size: ' + str(asyncio_queue.qsize()) )



regards!
Valdemar

--
components: asyncio
messages: 267884
nosy: gvanrossum, haypo, valdemar.pavesi, yselivanov
priority: normal
severity: normal
status: open
title: asyncio lost udp packets
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com