[issue27245] IDLE: Fix deletion of custom themes and key bindings

Serhiy Storchaka added the comment: Proposed patch should fix this issue. -- components: +IDLE keywords: +patch nosy: +serhiy.storchaka stage: test needed -> patch review versions: +Python 2.7, Python 3.5 Added file: http://bugs.python.org/file43275/idle_delete_current_theme.patch _

[issue26415] Fragmentation of the heap memory in the Python parser

A. Skrobov added the comment: An arena might help reclaim the memory once the parsing is complete, but it wouldn't reduce the peak memory consumption by the parser, and so it wouldn't prevent a MemoryError when parsing a 35MB source on a PC with 2GB of RAM. --

[issue27221] multiprocessing documentation is outdated regarding method picklability

Changes by Berker Peksag : -- nosy: +berker.peksag stage: -> patch review title: [multiprocessing] Doc is outdated regarding method picklability -> multiprocessing documentation is outdated regarding method picklability type: -> behavior versions: +Python 3.6

[issue27186] add os.fspath()

Changes by Berker Peksag : -- stage: test needed -> resolved ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue27247] telnetlib AttributeError: 'error' object has no attribute 'errno' (handling of select.error)

New submission from Muhammad Toufeeq Ockards: I was using the telnetlib on linux in python 2.7 and ran into error that executed line 320 of https://hg.python.org/cpython/file/2.7/Lib/telnetlib.py -- 319: except select.error as e: 320:if e.errno == errno.EINT

[issue27247] telnetlib AttributeError: 'error' object has no attribute 'errno' (handling of select.error)

Xiang Zhang added the comment: In py2, select.error is a stand alone exception while in py3 it's an alias of OSError. This difference seems not noticed when introduced in 872afada51b0. -- nosy: +gregory.p.smith, xiang.zhang ___ Python tracker

[issue23264] Add pickle support of dict views

Serhiy Storchaka added the comment: Thank you for your attention Guido. -- resolution: -> rejected stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue23401] Add pickle support of Mapping views

Serhiy Storchaka added the comment: Should we forbid pickling MappingView? And what about copying and deepcopying? -- ___ Python tracker ___

[issue27248] Possible refleaks in PyType_Ready in error condition

New submission from Xiang Zhang: As the title, in add_* used in PyType_Ready, the reference counts are not decreased when adding them to dict fails. -- files: refleak_in_pytype_ready.patch keywords: patch messages: 267607 nosy: serhiy.storchaka, xiang.zhang priority: normal severity: no

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

Roundup Robot added the comment: New changeset 9de508dc4837 by Victor Stinner in branch '3.5': os.urandom() doesn't block on Linux anymore https://hg.python.org/cpython/rev/9de508dc4837 -- nosy: +python-dev ___ Python tracker

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

STINNER Victor added the comment: Manual check to ensure that getrandom() syscall is used on Linux: $ strace -o trace ./python -c 'import os; os.urandom(16); os.urandom(16)' && grep getrandom trace getrandom("...", 24, GRND_NONBLOCK) = 24 getrandom("...", 16, GRND_NONBLOCK) = 16 getrandom("...

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

STINNER Victor added the comment: Sorry for the delay. getrandom_nonblocking_v4.patch LGTM, but I made a major change: if getrandom() fails with EAGAIN, it now *always* fall back on reading /dev/urandom. I also documented the change in os.urandom() documentation and in Misc/NEWS. I pushed the

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

STINNER Victor added the comment: I'm the author of the os.urandom() change which introduced the usage of the new getrandom() syscall: see the issue #22181. My motivation was to avoid the internal file descriptor to read /dev/urandom. In some corner cases (issue #18756), creating a file descri

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

STINNER Victor added the comment: Colm Buckley: "I feel that there is no consistent way to signal to higher-level applications that the random data has sub-standard entropy; but that this at least preserves the expected semantics, and doesn't block on startup in the event of an uninitialized e

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

Susumu Koshiba added the comment: Thanks for the suggestions, I've updated the test cases and created a patch for 3.6. -- Added file: http://bugs.python.org/file43277/issue25738_http_reset_content_07.patch ___ Python tracker

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

Colm Buckley added the comment: @haypo - I concur with all of your comments. I didn't have a strong opinion on whether to modify getrandom_works; your proposal looks fine to me (and will give consistent behavior over the lifetime of the process). Thanks all for your help with this issue; much

[issue27235] Heap overflow occurred due to the int overflow (Python-2.7.11/Modules/posixmodule.c)

Larry Hastings added the comment: I agree with the previous comment author. Can you post a sample program that crashes Python? Please specify what platform you're running on. On 32-bit platforms, you'd be unable to construct even the first "r" * ((2**32)-1) string. That string would use 4GB

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

STINNER Victor added the comment: Martin Panter (msg267504): "As I understand it, if there is no entropy initialized, this patch will fall back to reading /dev/urandom, which will return predictable data (opposite of “random” data!)." No, I don't think so. Linux uses a lot of random sources,

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

STINNER Victor added the comment: Martin Panter (msg267511): "Maybe an alternative would be to add a special PYTHONHASHSEED=best-effort (or whatever) value that says if there is no entropy available, use a predictable hash seed. That would force whoever starts the Python process to be aware of

[issue27248] Possible refleaks in PyType_Ready in error condition

Changes by Serhiy Storchaka : -- components: +Interpreter Core stage: -> patch review type: -> behavior ___ Python tracker ___ ___ P

[issue26415] Fragmentation of the heap memory in the Python parser

STINNER Victor added the comment: Benjamin Peterson: "It seems to me a simpler solution would be allocate all nodes for a parse tree in an arena." Exactly, that's the real fix. Just make sure that deallocating this arena does punch holes in the "heap memory". For example, on Linux, it means us

[issue26556] Update expat to 2.2.1

Larry Hastings added the comment: Was this critical bug fix released on May 17th as promised? I will not hold up 3.5.2 for this. 3.5.2 has waited long enough. -- ___ Python tracker ___

[issue26415] Fragmentation of the heap memory in the Python parser

A. Skrobov added the comment: My current patch avoids the memory peak *and* doesn't add any memory fragmentation on top of whatever is already there. In other words, it makes the parser better in this one aspect, and it doesn't make it worse in any aspect. --

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

Stefan Krah added the comment: On Tue, Jun 07, 2016 at 10:01:16AM +, STINNER Victor wrote: > Maybe need something like time.get_clock_info(), sys.float_info and > sys.thread_info for os.urandom(): a string describing the implementation of > os.urandom(). It would allow the developer to deci

[issue26415] Excessive peak memory consumption by the Python parser

A. Skrobov added the comment: (Updating the issue title, to avoid confusion between two orthogonal concerns) -- title: Fragmentation of the heap memory in the Python parser -> Excessive peak memory consumption by the Python parser ___ Python tracker

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

Alex Gaynor added the comment: This doesn't look correct to me. Despite what the Linux maintainers insist, it's a _bug_ that /dev/urandom will return immediately if the system's entropy pool has never been seeded; one of the whole points of the getrandom syscall is that it has the correct beha

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

STINNER Victor added the comment: Alex: "IMO the patch landed this morning should be reverted and it should be left as is." Sorry, but you should elaborate a little bit more, see my rationale: https://bugs.python.org/issue26839#msg267611 There are multiple issues. --

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

STINNER Victor added the comment: Stefan Krah: "I think this is a very good idea. Just a flag for "cryptographically secure" or not." If you consider it is worth it, please open a new issue. I dislike the idea of a boolean. The quality of each system RNG has been discussed long enough to be a

[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 added the comment: On 07.06.2016 13:27, Alex Gaynor wrote: > > This doesn't look correct to me. Despite what the Linux maintainers insist, > it's a _bug_ that /dev/urandom will return immediately if the system's > entropy pool has never been seeded; one of the whole points o

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

Cory Benfield added the comment: This patch explicitly violates several of the documented constraints of the Python standard library. For example, random.SystemRandom uses os.urandom to generate its random numbers. SystemRandom is then used by the secrets module to generate *its* random numbe

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

Donald Stufft added the comment: I agree with Alex here. The documentation of ``os.urandom`` states: Return a string of n random bytes suitable for cryptographic use. However the old behavior prior to using the ``getrandom()`` call and the behavior with this patch makes that documentation a l

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

Donald Stufft added the comment: I also agree with Cory :) If CPython needs a non blocking RNG for start up, then it should add a new function that does that, breaking the promise of ``os.urandom`` cryptographically suitable random is not the way to do that. -- ___

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

Thomas Petazzoni added the comment: The original problem is that Python wants to generate random numbers at *startup*. Are those random numbers really used for crypto-related activities? I doubt it. So isn't the proper solution to have two functions, one delivering random numbers that are usa

[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 added the comment: On 07.06.2016 13:36, Donald Stufft wrote: > No where in the documentation of ``os.urandom`` does it ever promise it will > not block. In fact, on systems like FreeBSD where their /dev/urandom is > better than Linuxes it always blocked on start up because th

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

Donald Stufft added the comment: > That's pretty much in line with what the implementation now does. Literally the first line of the os.urandom documentation is "Return a string of n random bytes suitable for cryptographic use.". There is absolutely a promise that, as long as your OS isn't bro

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

STINNER Victor added the comment: Cory Benfield: "For example, random.SystemRandom uses os.urandom to generate its random numbers. SystemRandom is then used by the secrets module to generate *its* random numbers. This means that os.urandom *is* explicitly used by the Python standard library to ge

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

Donald Stufft added the comment: > Reminder: getrandom() feature is specific to Linux. I understand that all > other operating systems don't warn if the urandom entropy pool is not > initialized yet! As far as I know, all other modern OSs *ALWAYS* block until their entropy pool is intialized.

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

Donald Stufft added the comment: > IMHO you should read http://www.2uo.de/myths-about-urandom/ which explains > that the property of blocking or not blocking doesn't matter for the quality > of the RNG. /dev/urandom is good enough to generate crytographic keys. Can we > please stay focused on

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

STINNER Victor added the comment: Donald Stufft: "As far as I know, all other modern OSs *ALWAYS* block until their entropy pool is intialized. It's Linux that refuses to get with the program." Ah? I didn't know. Anyway, it doesn't change anything to the problem. I don't think that security mat

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

Alex Gaynor added the comment: Repeating what a few other folks have said: the of os.urandom's callers shouldn't have to pay for the hash seed implementation. If Python internally is ok with suboptimal entropy, it should use a different function. Or early-boot Python users should set PYTHONHAS

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

Cory Benfield added the comment: Victor Stinner: I found that comment to be pretty patronising, but I'm assuming that wasn't the intent. However, your characterisation of my comment was not as I intended it: when I said "because it can block", I meant because on almost every system urandom wil

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

Donald Stufft added the comment: > I don't think that security matters enough to block Python at startup. > Python has a long history of being a thin wrapper on top of the OS. > Usually, Python doesn't workaround design issues of OSes, but expose > functions as they are. That's fine, so make a n

[issue27105] cgi.__all__ is incomplete

Jacek Kołodziej added the comment: Thank you, Martin. :) -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: htt

[issue27249] Add os.urandom_info

New submission from STINNER Victor: It seems like in some cases, you do need to know how os.urandom() generates random numbers. On Linux, using getrandom() to read /dev/urandom in blocking mode or reading from /dev/urandom give a different level of security if the urandom entropy pool is not f

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

STINNER Victor added the comment: Since many people seem to disagree, I reopen the issue, even if I still consider it as fixed ;-) I also opened the issue #27249: "Add os.urandom_info". -- resolution: fixed -> ___ Python tracker

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

Donald Stufft added the comment: To be clear, I don't have a problem adding ``os.urandom_info`` but I don't think that it solves the problem, we shouldn't force people to introspect ``os.urandom`` to figure out if CPython decided to make it less secure on this invocation or not. -- _

[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 added the comment: On 07.06.2016 13:51, Donald Stufft wrote: > > Donald Stufft added the comment: > >> That's pretty much in line with what the implementation now does. > > Literally the first line of the os.urandom documentation is "Return a string > of n random bytes suit

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

Donald Stufft added the comment: > Note how the documentation emphasizes on os.urandom() not blocking. That line about not-blocking was added by the patch that Victor committed that we're objecting to. -- ___ Python tracker

[issue27250] Add os.urandom_block()

New submission from STINNER Victor: The change of the issue #26839 creates a long discussion around the behaviour of os.urandom() when the entropy pool is not seeded with enough entropy. On Python 2.7, os.urandom() doesn't block in this case. I expect that bytes are random, but not "random eno

[issue27247] telnetlib AttributeError: 'error' object has no attribute 'errno' (handling of select.error)

Berker Peksag added the comment: Thanks for the report. This is a duplicate of issue 18035. -- nosy: +berker.peksag resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> telnetlib incorrectly assumes that select.error has an errno attribute __

[issue27250] Add os.urandom_block()

Changes by Alex Gaynor : -- nosy: +alex ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org

[issue27249] Add os.urandom_info

Changes by Alex Gaynor : -- nosy: +alex ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org

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

STINNER Victor added the comment: Thomas Petazzoni: "The original problem is that Python wants to generate random numbers at *startup*. Are those random numbers really used for crypto-related activities? I doubt it." Python randomized hash function and random.Random (Mersenne Twister, instanc

[issue27250] Add os.urandom_block()

Donald Stufft added the comment: This should be add ``os.urandom_noblock`` instead. Don't make every other application change just so the Python interpreter can continue to call ``os.urandom``. -- nosy: +dstufft ___ Python tracker

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

STINNER Victor added the comment: (Oh, in fact I wanted to reopen the issue, so Status must be changed, not Resolution, so the issue is visible again in the main list of issues.) -- resolution: -> fixed status: closed -> open ___ Python tracker

[issue27250] Add os.urandom_block()

STINNER Victor added the comment: If os.urandom_block() is added, I don't think that it's worth to add os.urandom_info as I proposed in the issue #27249. -- ___ Python tracker _

[issue27250] Add os.urandom_block()

Cory Benfield added the comment: Let me make the security person argument even though you've dismissed it in your original post: Security should be on by default and opted out of, not the other way around. If the obvious choice is insecure then users who aren't careful enough won't notice, be

[issue27250] Add os.urandom_block()

STINNER Victor added the comment: See also issue #26970 "Replace OpenSSL's CPRNG with system entropy source". -- ___ Python tracker ___ __

[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 added the comment: On 07.06.2016 14:19, Donald Stufft wrote: > >> Note how the documentation emphasizes on os.urandom() not blocking. > > That line about not-blocking was added by the patch that Victor committed > that we're objecting to. Ah, sorry, I was looking at the onl

[issue27250] Add os.urandom_block()

Changes by STINNER Victor : -- nosy: +christian.heimes ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://

[issue27250] Add os.urandom_block()

Marc-Andre Lemburg added the comment: Should this ticket be named "Add os.random()" ? After all, blocking in case of missing entropy is what /dev/random is all about. -- nosy: +lemburg ___ Python tracker __

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

Donald Stufft added the comment: (Basically) nobody should ever use /dev/random (and cryptographers agree!). The thing you want to use is /dev/urandom and the fact that /dev/urandom on Linux doesn't block before the pool is initalized has long been considered by cryptographers to be a fairly l

[issue27250] Add os.urandom_block()

Cory Benfield added the comment: Marc-Andre: No. See the discussion in the related issue #27249 for more. -- ___ Python tracker ___ __

[issue27250] Add os.urandom_block()

Cory Benfield added the comment: Uh, sorry, I meant #26839. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue27249] Add os.urandom_info

Christian Heimes added the comment: +1 How are you planning to handle initialization? Run getentropy() and check if the syscall succeeds? -- nosy: +christian.heimes ___ Python tracker

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

STINNER Victor added the comment: Currently, os.urandom() doesn't block anymore which means secrets should be updated. If we revert os.urandom(), Python must be patched to use a non-blocking urandom to initialized hash secret and random.Random (when the random module is imported). In both cas

[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 added the comment: On 07.06.2016 14:40, Donald Stufft wrote: > > Donald Stufft added the comment: > > (Basically) nobody should ever use /dev/random (and cryptographers agree!). > The thing you want to use is /dev/urandom and the fact that /dev/urandom on > Linux doesn't bl

[issue27250] Add os.urandom_block()

Marc-Andre Lemburg added the comment: On 07.06.2016 14:41, Cory Benfield wrote: > > Uh, sorry, I meant #26839. Ok, then perhaps "Add os.getrandom()" - also see the discussion there :-) -- ___ Python tracker _

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

Donald Stufft added the comment: What I'm trying to tell you is that /dev/random is a bad implementation and practically every cryptographer agrees that everyone should use /dev/urandom and they all also agree that on Linux /dev/urandom has a bad wart of giving bad randomness at the start of t

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

Donald Stufft added the comment: Since there's obviously contention about what the right answer here is, I suggest we should revert the patch (since the old behavior already exists in 3.5 and is shipped to thousands of people already, and status quo wins) and then continue the discussion about

[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 added the comment: On 07.06.2016 15:12, Donald Stufft wrote: > > Since there's obviously contention about what the right answer here is, I > suggest we should revert the patch (since the old behavior already exists in > 3.5 and is shipped to thousands of people already, and

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

Donald Stufft added the comment: The patch causes a regression because I'm relying on the 3.5 behavior of getting secure randomness from ``os.urandom`` via the ``getrandom()`` system call (behavior that was documented in the Whats New in 3.5). The 3.5 behavior also makes ``os.urandom`` behave

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

Colm Buckley added the comment: Here's where things stand, as I currently see it. Under certain circumstances, under Linux at least, calls to getrandom() will block. Specifically, they will block if the system's PRNG has been insufficiently initialized. Depending on the nature of the host, thi

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

Colm Buckley added the comment: Donald: please note - the current behavior is that Python *will not start at all* if getrandom() blocks (because the hash secret initialization fails). If you are relying on the current behavior with a functioning application, then you are invoking it well after

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

Changes by Christian Heimes : -- nosy: +christian.heimes ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:

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

Donald Stufft added the comment: > My personal preference would be for os.urandom(n) to favor non-blocking > operation over cryptographic security, and either add os.random() or add an > optional parameter to os.urandom() to make the opposite trade-off. Insecure by default is very rarely the r

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

Donald Stufft added the comment: > The net effect is that *all* invocations of Python will block at startup if > the system RNG is blocking. The only reason this is being called out as > Linux-specific is that the behavior has been noticed in Linux. The fix is Linux specific, because all other

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

Colm Buckley added the comment: Donald - With the greatest respect, you're talking about introducing multi-minute delays into the startup times of hundreds of millions of systems, regardless of whether they have a proximate requirement for cryptographically-secure RNG sources. I don't think t

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

Alex Gaynor added the comment: Colm -- how is that situation not addressed by fixing the hash seed generation specifically, rather than patching all consumers of os.urandom? -- ___ Python tracker _

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

Donald Stufft added the comment: > With the greatest respect, you're talking about introducing multi-minute > delays into the startup times of hundreds of millions of systems, regardless > of whether they have a proximate requirement for cryptographically-secure RNG > sources. No I'm not. I'm

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

Colm Buckley added the comment: I have no objection to *deliberate* invocations of the system RNG blocking if needed. Presumably this behavior can be codified into the various APIs. My objection is *entirely* to _PyRandom_Init() calling a potentially-blocking RNG source, before script parsing

[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 added the comment: On 07.06.2016 15:21, Donald Stufft wrote: > > The patch causes a regression because I'm relying on the 3.5 behavior of > getting secure randomness from ``os.urandom`` via the ``getrandom()`` system > call (behavior that was documented in the Whats New in 3

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

Donald Stufft added the comment: > I have no objection to *deliberate* invocations of the system RNG blocking if > needed. Presumably this behavior can be codified into the various APIs. > > My objection is *entirely* to _PyRandom_Init() calling a potentially-blocking > RNG source, before scrip

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

Christian Heimes added the comment: I'm with Donald here. Python must not reduce security just for a special case. It doesn't mean that we should not address and fix this special case -- just treat it as special. 1) For your use case, the hash randomization key for the SipHash PRN doesn't nee

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

STINNER Victor added the comment: nonblocking_urandom_noraise.patch doesn't fix the issue #21470. -- ___ Python tracker ___ ___ Python

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

STINNER Victor added the comment: > nonblocking_urandom_noraise.patch doesn't fix the issue #21470. Sorry, it's the issue #25420: "import random" blocks on entropy collection on Linux with low entropy -- ___ Python tracker

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

Donald Stufft added the comment: > I just don't understand why you are apparently not willing to even consider > compromises. I have one thing that I hold immutable here, That os.urandom should use the best interfaces provided by the OS to ensure that it always returns cryptographically rando

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

Stefan Krah added the comment: man urandom: "A read from the /dev/urandom device will not block waiting for more entropy. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algor

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

Colm Buckley added the comment: The attached patch (against tip) is a very quick attempt to implement the desired behavior: * add a "nonblocking" argument to py_getrandom() * dev_urandom_python() sets this to 0, to request blocking operation * dev_urandom_noraise() sets this to 1 to request non

[issue5124] IDLE - pasting text doesn't delete selection

Ned Deily added the comment: Terry, after the discussion I don't have a strong opinion one way or the other. It seems that current X11 users expect the replace behavior, so option 4 seems fine to me. -- ___ Python tracker

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

Colm Buckley added the comment: Victor - I see three options for 3.5.2: * continue with the 3.5.1 behaviour, which blocks all python invocations in low-entropy situations. I think this is highly undesireable. * apply my patches, which fixes the hash secret initialization but not 'import rand

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

Christian Heimes added the comment: PSRT VETO! This ticket is turning into a bike-shedding discussion. In the light of the upcoming release 3.5.2 I'm now putting on my PSRT hat (Python Security Response Team) and proclaim a veto against any and all changes to os.urandom(). The security proper

[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 added the comment: On 07.06.2016 16:18, Donald Stufft wrote: > > Donald Stufft added the comment: > >> I just don't understand why you are apparently not willing to even consider >> compromises. > > I have one thing that I hold immutable here, That os.urandom should use the

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

Colm Buckley added the comment: Christian - I would like to make one further comment: The only reason getrandom() was used instead of /dev/random was to avoid wasting a file descriptor. The previous behavior was in use for many years with no security issues; it was changed for FD conservation

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

Christian Heimes added the comment: On 2016-06-07 16:49, Marc-Andre Lemburg wrote: > This gives people a clear choice and doesn't cause people > to have to reconsider using the random module or wait for > Python hash randomization to initialize itself when using > Python during VM/container/syste

[issue27221] multiprocessing documentation is outdated regarding method picklability

Changes by Ned Deily : -- nosy: +davin ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/

[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 added the comment: On 07.06.2016 16:59, Christian Heimes wrote: > > Christian Heimes added the comment: > > On 2016-06-07 16:49, Marc-Andre Lemburg wrote: >> This gives people a clear choice and doesn't cause people >> to have to reconsider using the random module or wait for

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

Colm Buckley added the comment: Christian - Please note: this is *not* just a VM/cloud issue. This is observed on physical standalone systems. The issue (on Debian) is that the Python script is called very early in the boot process; in particular before most hardware initialization is do

[issue23401] Add pickle support of Mapping views

Guido van Rossum added the comment: No, it should just be up to the implementation. Though you might add a note to the docs explaining that it's probably a misguided idea. On Tue, Jun 7, 2016 at 2:23 AM, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > Should we forbid pickl

[issue9253] argparse: optional subparsers

paul j3 added the comment: My answer to http://stackoverflow.com/questions/23349349/argparse-with-required-subparser is getting a slow but steady stream of + scores; so the `required subparser` issue is still bothering people. This particular question addresses the problem that the error mess

  1   2   3   >