[issue34731] pathlib path.match misshandles multiple `**`

New submission from Ronny Pfannschmidt : when porting parts of pytest to pathlib we noted that `path.match` does not quite match normal fnmatch for usages of `**` i believe this is related to always splitting the patter completely and not handling `**` in that case Bruno wrote

[issue13285] signal module ignores external signal changes

Nathaniel Smith added the comment: Here's another case where this bug bites us: https://github.com/python-trio/trio/issues/673 At startup, Trio checks if SIGINT is currently being handled by Python's default SIGINT handler, and if so it substitutes its own SIGINT handler (which works just

[issue34589] Py_Initialize() and Py_Main() should not enable C locale coercion

Change by Ned Deily : -- versions: +Python 3.7 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34730] aclose() doesn't stop raise StopAsyncIteration / GeneratorExit to __anext__()

New submission from Devin Fee : I expected an async-generator's aclose() method to cancel it's __anext__(). Instead, the task isn't cancelled, and (it seems) manually cleanup is necessary. @pytest.mark.asyncio async def test_aclose_cancels(): done = False event = asyncio.Event()

[issue23224] bz2/lzma: Compressor/Decompressor objects are only initialized in __init__

Alexey Izbyshev added the comment: bz2 in 2.7 is also affected. Victor, do we want to fix the crash at all in stable branches? If yes, IMHO taking the slight risk of __init__ -> __new__ change is preferable to taking the trouble to implement the alternative backwards-compatible fix (init

[issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn

Gregory P. Smith added the comment: Give all of this, the lesson I'd take away is perhaps that we should just provide the constant in the os module when available at build time (a configure check) and let people who find a need to use it on their system check for its presence and use it in

[issue34729] bz2/lzma: Compressor/decompressor crash if __init__ is not called

Berker Peksag added the comment: We can definitely make the title of that issue more descriptive. Feel free to change it -- IIRC, you don't need additional permissions to change the title of an issue. Thanks! -- ___ Python tracker

[issue34729] bz2/lzma: Compressor/decompressor crash if __init__ is not called

Alexey Izbyshev added the comment: Reclosing (browser cache problem). -- resolution: -> duplicate stage: needs patch -> resolved status: open -> closed ___ Python tracker

[issue34729] bz2/lzma: Compressor/decompressor crash if __init__ is not called

Alexey Izbyshev added the comment: I somehow failed to notice #23224 when I searched the tracker. You're right, it's the same, and, moreover, PR 7822 fixes problem with both compressors and decompressors (though it includes tests only for the latter for some reason). I think that this

[issue34729] bz2/lzma: Compressor/decompressor crash if __init__ is not called

Berker Peksag added the comment: I think we usually went with option 1 when we fixed similar issues in the past. See also issue 23224 for the same problem in *Decompressor classes of lzma and bz2 modules. It looks like the attached PR to that issue went with option 2: PR 7822. Perhaps we

[issue9148] os.execve puts process to background on windows

Thomas Sibley added the comment: Thanks for taking the time to explain. I was just discovering the same myself experimentally. The MS docs I linked to seem a little misleading. orz In that case, do you think a doc patch for os.exec* adding a more nuanced take on Windows support would be

[issue34729] bz2/lzma: Compressor/decompressor crash if __init__ is not called

New submission from Alexey Izbyshev : The compressor/decompressor classes from bz2 and lzma modules rely on __init__() for initialization, but it is not guaranteed to be called. Method calls on an uninitialized object crash: >>> from bz2 import BZ2Compressor as C >>> c = C.__new__(C) >>>

[issue9148] os.execve puts process to background on windows

Eryk Sun added the comment: nt.execv[e] wraps calling the C runtime _wexecv[e] function. The other os.exec* functions are in turn based on these calls. As to spawn, for Windows _P_OVERLAY just means to exit the current process. The source code is published, so you can see how simple the

[issue9148] os.execve puts process to background on windows

Thomas Sibley added the comment: It seems like it would be very nice to provide compat if its possible with a minimum of effort. At the very least, a doc patch to os.exec*() seems warranted. I expected to find notes on platform compat in the doc and was pleasantly surprised to see the

[issue9148] os.execve puts process to background on windows

Thomas Sibley added the comment: What about using _execv*() and friends, as documented at ? They appear to use the process overlay feature of _spawnv*() et al., as described at

[issue33649] asyncio docs overhaul

miss-islington added the comment: New changeset 73c0006e71683b7d5b28192f18a2b9796e4195ef by Miss Islington (bot) in branch '3.7': bpo-33649: Add a high-level section about Futures; few quick fixes (GH-9403) https://github.com/python/cpython/commit/73c0006e71683b7d5b28192f18a2b9796e4195ef

[issue33649] asyncio docs overhaul

Change by miss-islington : -- pull_requests: +8831 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33649] asyncio docs overhaul

Yury Selivanov added the comment: New changeset 471503954a91d86cf04228c38134108c67a263b0 by Yury Selivanov in branch 'master': bpo-33649: Add a high-level section about Futures; few quick fixes (GH-9403) https://github.com/python/cpython/commit/471503954a91d86cf04228c38134108c67a263b0

[issue34728] deprecate *loop* argument for asyncio.sleep

Yury Selivanov added the comment: Same for asyncio.wait and asyncio.wait_for. -- ___ Python tracker ___ ___ Python-bugs-list

[issue34728] deprecate *loop* argument for asyncio.sleep

New submission from Yury Selivanov : asyncio.sleep is a coroutine; passing a *loop* argument to it makes no sense anymore. We should raise a DeprecationWarning in Python 3.8 and 3.9 and remove it in 4.0. -- components: asyncio keywords: easy messages: 325684 nosy: asvetlov,

[issue34727] Windows/2.7.15 IOError [Errno 0] when user interacts with cmd console

Eryk Sun added the comment: With Windows 10 release 1803, I can't reproduce either this problem or the problems from issue 32245. I'm marking this issue closed as a duplicate. Open a new issue if you still experience the problem after updating to Windows 10 release 1803 or 1809. --

[issue9148] os.execve puts process to background on windows

Eryk Sun added the comment: Python doesn't go out of its way to fake a cross-platform POSIX environment in Windows, complete with emulated fork and exec. I don't recommend using nt.execv[e] or the os.exec* functions in Windows. Their behavior is almost always undesired. I'd be in favor of

[issue34727] Windows/2.7.15 IOError [Errno 0] when user interacts with cmd console

cowlinator added the comment: I think you are probably right. I'm using Windows 10 Version 1709 (OS Build 16299.611) -- ___ Python tracker ___

[issue34727] Windows/2.7.15 IOError [Errno 0] when user interacts with cmd console

Eryk Sun added the comment: This may be the same problem as issue 32245, which was a third-party bug that Microsoft fixed in the last Spring update of Windows 10. Which version of Windows are you using? -- nosy: +eryksun ___ Python tracker

[issue34341] Appending to ZIP archive blows up existing Central Directory entries

Change by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.6 ___ Python tracker ___

[issue34472] zipfile: does not include optional descriptor signature

Change by Serhiy Storchaka : -- pull_requests: +8830 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34341] Appending to ZIP archive blows up existing Central Directory entries

Serhiy Storchaka added the comment: New changeset 29034baf58156e2462b0680e9092c0a3cccb0798 by Serhiy Storchaka in branch '2.7': [2.7] bpo-34341: Fix appending to ZIP archives with the ZIP64 extension. (GH-8683). (GH-9400)

[issue32245] OSError: raw write() returned invalid length on latest Win 10 Consoles

Change by Eryk Sun : -- resolution: -> third party stage: test needed -> resolved status: open -> closed ___ Python tracker ___

[issue34726] Add support of checked hash-based pycs in zipimport

Change by Serhiy Storchaka : -- stage: patch review -> needs patch ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue34726] Add support of checked hash-based pycs in zipimport

Change by Serhiy Storchaka : -- pull_requests: -8829 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34726] Add support of checked hash-based pycs in zipimport

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +8829 stage: -> patch review ___ Python tracker ___ ___

[issue25711] Rewrite zipimport from scratch

Change by Serhiy Storchaka : -- pull_requests: +8828 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn

STINNER Victor added the comment: Oh wow, I didn't expect that exposing a constant would be a source of such deep debate! (I'm not saying that the debate is useless or negative, it's useful and constructive, just I'm surprised how system programming can be hard sometimes!) --

[issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn

Ronald Oussoren added the comment: I did some more research: * seems to indicate that glibc switched to a different implementation of posix_spawn that uses clone(2) instead of fork()/vfork() to avoid some problems with vfork(). The

[issue25711] Rewrite zipimport from scratch

Change by Serhiy Storchaka : -- pull_requests: +8827 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34727] Windows/2.7.15 IOError [Errno 0] when user interacts with cmd console

New submission from cowlinator : I can consistently reproduce a bug in 2.7.15 on Windows which causes an unexpected IOError. Steps to reproduce: Enter the following code in a plain-vanilla windows command line console: >>> import sys >>> while True: ... sys.stdout.write('.') Then,

[issue34726] Add support of checked hash-based pycs in zipimport

New submission from Serhiy Storchaka : Currently zipimport refuses to handle checked hash-based pycs (PEP 552). -- components: Library (Lib) messages: 325675 nosy: brett.cannon, eric.snow, ncoghlan, serhiy.storchaka, twouters priority: normal severity: normal status: open title: Add

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

Mario added the comment: On 18/09/2018 19:24, Steve Dower wrote: > > Steve Dower added the comment: > > That executable doesn't appear to be in a virtual environment - you should be > running C:\TEMP\venv\abcd\Scripts\python.exe > > Does that resolve your problem? > Nope, I am *not*

[issue9148] os.execve puts process to background on windows

Change by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9148] os.execve puts process to background on windows

Change by Thomas Sibley : -- nosy: +trs ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn

Ronald Oussoren added the comment: I get the impression that go uses vfork on Linux, not posix_spawn, because go doesn't use libc (based on reading the referenced issue, not on deep knowledge of go and its implementation). I do wonder why glibc's implementation of posix_spawn doesn't use

[issue25711] Rewrite zipimport from scratch

Serhiy Storchaka added the comment: New changeset 79d1c2e6c9d1bc1cf41ec3041801ca1a2b9a995b by Serhiy Storchaka in branch 'master': bpo-25711: Rewrite zipimport in pure Python. (GH-6809) https://github.com/python/cpython/commit/79d1c2e6c9d1bc1cf41ec3041801ca1a2b9a995b --

[issue34582] VSTS builds should use jobs, pools, and test results

Steve Dower added the comment: New changeset c9276495fc497898544a38b244b38ff61797f32d by Steve Dower (Miss Islington (bot)) in branch '3.6': bpo-34582: Adds JUnit XML output for regression tests (GH-9210) https://github.com/python/cpython/commit/c9276495fc497898544a38b244b38ff61797f32d

[issue34582] VSTS builds should use jobs, pools, and test results

Steve Dower added the comment: New changeset 1a89cb5c479d8e4f467d7f96e1781c7275cefa88 by Steve Dower (Miss Islington (bot)) in branch '3.7': bpo-34582: Adds JUnit XML output for regression tests (GH-9210) https://github.com/python/cpython/commit/1a89cb5c479d8e4f467d7f96e1781c7275cefa88

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

Steve Dower added the comment: (Also, the behavior of Py_GetProgramFullPath is intentional, but we do have another bug somewhere to be able to override it for embedding purposes. sys.executable should be None when it does not contain a suitable path for running the normal Python interpreter

[issue33649] asyncio docs overhaul

Change by Yury Selivanov : -- pull_requests: +8826 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

Steve Dower added the comment: That executable doesn't appear to be in a virtual environment - you should be running C:\TEMP\venv\abcd\Scripts\python.exe Does that resolve your problem? -- ___ Python tracker

[issue34582] VSTS builds should use jobs, pools, and test results

Change by miss-islington : -- pull_requests: +8825 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34582] VSTS builds should use jobs, pools, and test results

Change by miss-islington : -- pull_requests: +8824 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34472] zipfile: does not include optional descriptor signature

Serhiy Storchaka added the comment: Thank you for your contribution Silas. Since popular ZIP file implementation like Info-ZIP and Java write this signature unconditionally, I think most unzipping software support it if they support reading ZIP files in streaming mode at all, at it is safe

[issue34341] Appending to ZIP archive blows up existing Central Directory entries

Change by Serhiy Storchaka : -- pull_requests: +8823 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34725] Py_GetProgramFullPath() odd behaviour in Windows

New submission from Mario : According to the doc Py_GetProgramFullPath() should return the full path of the program name as set by Py_SetProgramName(). https://docs.python.org/3/c-api/init.html#c.Py_GetProgramFullPath This works well in Linux, but in Windows it is always the name of the

[issue34472] zipfile: does not include optional descriptor signature

Change by miss-islington : -- pull_requests: +8822 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34472] zipfile: does not include optional descriptor signature

Change by miss-islington : -- pull_requests: +8821 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34724] argparse subparser help indent too short

TakingItCasual added the comment: More detailed explanation on the SO post I found the HelpFormatter class from: https://stackoverflow.com/q/3215/2868017 -- ___ Python tracker

[issue34472] zipfile: does not include optional descriptor signature

Serhiy Storchaka added the comment: New changeset 4ba3b50bfe6d50cd82d208023ea23e203ab50589 by Serhiy Storchaka (Silas Sewell) in branch 'master': bpo-34472: Add data descriptor signature to zipfile (GH-8871) https://github.com/python/cpython/commit/4ba3b50bfe6d50cd82d208023ea23e203ab50589

[issue34724] argparse subparser help indent too short

New submission from Jeremiah Rosen : The help is indented too early for subparsers with long argument names. I'm currently using the ProperIndentParser class from the following gist to create my top level parser, which fixes the issue:

[issue34582] VSTS builds should use jobs, pools, and test results

Steve Dower added the comment: New changeset d0f49d2f5085ca68e3dc8725f1fb1c9674bfb5ed by Steve Dower in branch 'master': bpo-34582: Adds JUnit XML output for regression tests (GH-9210) https://github.com/python/cpython/commit/d0f49d2f5085ca68e3dc8725f1fb1c9674bfb5ed --

[issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn

Pablo Galindo Salgado added the comment: Some interesting read: Go is using vfork/posix_spawn when possible: https://github.com/golang/go/issues/5838 And it seems that have interesting results: https://about.gitlab.com/2018/01/23/how-a-fix-in-go-19-sped-up-our-gitaly-service-by-30x/

[issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn

Pablo Galindo Salgado added the comment: You still need to allow the flag as being safe or unsafe depends on the user code as glibc cannot know about the details of what is going to be executed. That is the reason they have the flag, so the user can disambiguate if is safe or not. If we

[issue34719] Deprecate set to frozenset conversion in set.__contains__

Raymond Hettinger added the comment: The feature was first implemented in Lib/sets.py (arising from PEP 218) in pure python. It was found to be useful and carried forward to the C implementation for the built-in type. The feature is documented but not highlighted in the Library Reference,

[issue34722] Non-deterministic bytecode generation

Change by Eric Snow : -- nosy: +benjamin.peterson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34722] Non-deterministic bytecode generation

Serhiy Storchaka added the comment: Not all types are orderable. >>> sorted({'', None}) Traceback (most recent call last): File "", line 1, in TypeError: '<' not supported between instances of 'NoneType' and 'str' -- nosy: +serhiy.storchaka ___

[issue34719] Deprecate set to frozenset conversion in set.__contains__

Change by Raymond Hettinger : -- versions: -Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker ___ ___

[issue34719] Deprecate set to frozenset conversion in set.__contains__

Change by Raymond Hettinger : -- assignee: -> rhettinger nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing

[issue34722] Non-deterministic bytecode generation

Raymond Hettinger added the comment: Have a look at line 512 in Python/marshal.c which calls PyObject_GetIter(). We would need to add PySequence_List() and PyList_Sort(). This will slow down marshaling but would make the bytecode deterministic. -- nosy: +rhettinger

[issue25825] AIX shared library extension modules installation broken

Michael Felt added the comment: On 18/09/2018 16:46, Michael Felt wrote: > Michael Felt added the comment: Ignore this. If only I could remove stuff! Good day all. -- ___ Python tracker

[issue32557] allow shutil.disk_usage to take a file path on Windows also

Joe Pamer added the comment: Got it - thanks! That sounds good to me, so I'll take a look at how other functions are working around MAX_PATH and update the diff to also avoid the copy when possible. -- ___ Python tracker

[issue25825] AIX shared library extension modules installation broken

Michael Felt added the comment: On 10/08/2016 17:22, David Edelsohn wrote: > David Edelsohn added the comment: Hi, Just thought I would mention that I have a branch with all the test PR fixes I have made in the last two months. a) would appreciate your testig them with gcc - to be sure all is

[issue31635] test_strptime failure on OpenBSD

Paul Ganssle added the comment: Bug reported to BSD here: https://marc.info/?l=openbsd-bugs=153728102618747=2 -- ___ Python tracker ___

[issue34597] Python needs to check existence of functions at runtime for targeting older macOS platforms

Zorg added the comment: I understand that. I was mainly responding to a question that was asked with information I felt was important to provide. -- ___ Python tracker ___

[issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn

Serhiy Storchaka added the comment: If glibc already uses vfork() if it is safe, I suppose that using vfork() in other cases is unsafe, and we shouldn't support this nonstandard option. -- ___ Python tracker

[issue34597] Python needs to check existence of functions at runtime for targeting older macOS platforms

Ronald Oussoren added the comment: @Zorg: you don't need to sell the usefulness of this functionality. Its just that the python developers are volunteers and hence have limited time to work on python. -- ___ Python tracker

[issue34723] lower() on Turkish letter "İ" returns a 2-chars-long string

STINNER Victor added the comment: > Should it not simply return “i”? Python implements the Unicode standard. >>> "U+%04x" % ord("İ") 'U+0130' >>> ["U+%04x" % ord(ch) for ch in "İ".lower()] ['U+0069', 'U+0307'] >>> unicodedata.name("İ") 'LATIN CAPITAL LETTER I WITH DOT ABOVE' >>>

[issue17239] XML vulnerabilities in Python

Christian Heimes added the comment: > * only Windows and macOS will get the fix Modules/expat can be used on all platforms. A downstream patch is only a problem for platforms that compile Python with "./configure --with-system-expat". The security fixes for entity expansion blowup and

[issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn

Ronald Oussoren added the comment: vfork() is more dangerous than fork() because the parent and child processes share memory (not copy-on-write, but really the same memory). Whether or not this affects posix_spawn depends on its implementation (to give a very vague statement). Glibc

[issue34723] lower() on Turkish letter "İ" returns a 2-chars-long string

New submission from Dogan : Hey there, I believe I've come across a bug. It occurs when you try to lower() the Turkish uppercase letter "İ". Gonna explain it with example code since it's easier: >>> len("Ş") 1 >>> len("Ş".lower()) 1 >>> len("Ğ") 1 >>> len("Ğ".lower()) 1 >>> len("Ö") 1 >>>

[issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn

STINNER Victor added the comment: Serhiy Storchaka: "If this is an optimization, what is the downside of always using vfork()?" I don't know the vfork() function, but you can find articles like: "vfork considered dangerous" (old article of 2012) https://ewontfix.com/7/ But it's unclear to

[issue34722] Non-deterministic bytecode generation

New submission from Peter Ebden : We've found that the following code produces non-deterministic bytecode, even post PEP-552: def test(x): if x in {'ONE', 'TWO', 'THREE'}: pass It's not too hard to test it: $ python3.7 -m compileall --invalidation-mode=unchecked-hash test.py

[issue34659] Inconsistency between functools.reduce & itertools.accumulate

Kristján Valur Jónsson added the comment: I think I'll pass Raymond, its been so long since I've contributed, in the mean time there is github and argument clinic and whatnot so I'm out of training. I´m lurking around these parts and maybe shall return one day :) --

[issue17239] XML vulnerabilities in Python

STINNER Victor added the comment: > Who normally updates the vendored libexpat? I made the 3 latest libexpat updates, and each of them was painful :-) My notes on vendored libraries: https://pythondev.readthedocs.io/cpython.html#vendored-external-libraries I wrote a tool to get the version

[issue34542] [TLS] Update test certs to future proof settings

Change by Christian Heimes : -- pull_requests: +8820 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34542] [TLS] Update test certs to future proof settings

Change by Christian Heimes : -- pull_requests: +8819 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34721] json module loads function

Ammar Askar added the comment: This is intentional, the parsed in JSON doesn't necessarily have to have an object at the root. This is also what allows you to do: >>> json.loads("[]") [] This behavior is also consistent with browsers, try this in your browser's dev console: >

[issue31635] test_strptime failure on OpenBSD

Paul Ganssle added the comment: I do think this is an active bug in OpenBSD's ISO calculations, here: https://github.com/openbsd/src/blob/b66614995ab119f75167daaa7755b34001836821/lib/libc/time/wcsftime.c#L326 I re-created this algorithm in Python and at the beginning of the year it gives

[issue34721] json module loads function

New submission from zack : the json.loads function think a string variable is a json type, but the variable is "123" -- components: Library (Lib) files: json_test.py messages: 325639 nosy: jaihong priority: normal severity: normal status: open title: json module loads function type:

[issue34623] _elementtree.c doesn't call XML_SetHashSalt()

miss-islington added the comment: New changeset f7666e828cc3d5873136473ea36ba2013d624fa1 by Miss Islington (bot) in branch '3.6': bpo-34623: Use XML_SetHashSalt in _elementtree (GH-9146) https://github.com/python/cpython/commit/f7666e828cc3d5873136473ea36ba2013d624fa1 --

[issue34623] _elementtree.c doesn't call XML_SetHashSalt()

miss-islington added the comment: New changeset 18b20bad75b4ff0486940fba4ec680e96e70f3a2 by Miss Islington (bot) (Christian Heimes) in branch '2.7': [2.7] bpo-34623: Use XML_SetHashSalt in _elementtree (GH-9146) (GH-9394)

[issue34623] _elementtree.c doesn't call XML_SetHashSalt()

miss-islington added the comment: New changeset 470a435f3b42c9be5fdb7f7b04f3df5663ba7305 by Miss Islington (bot) in branch '3.7': bpo-34623: Use XML_SetHashSalt in _elementtree (GH-9146) https://github.com/python/cpython/commit/470a435f3b42c9be5fdb7f7b04f3df5663ba7305 --

[issue21109] tarfile: Traversal attack vulnerability

Tal Einat added the comment: I am not a lawyer, but to the best of my understanding, using such tarballs would be fine. Since Jakub's repo only provides code to generate archive files but doesn't include actual archive files, and the generation code is licensed via the MIT license, we are

[issue34623] _elementtree.c doesn't call XML_SetHashSalt()

Change by Christian Heimes : -- pull_requests: +8818 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34623] _elementtree.c doesn't call XML_SetHashSalt()

Christian Heimes added the comment: Since it's a security fix, the change should land in 3.4 and 3.5, too. -- versions: +Python 2.7, Python 3.4, Python 3.5 ___ Python tracker

[issue34623] _elementtree.c doesn't call XML_SetHashSalt()

Change by miss-islington : -- pull_requests: +8817 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34623] _elementtree.c doesn't call XML_SetHashSalt()

Change by miss-islington : -- pull_requests: +8816 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34623] _elementtree.c doesn't call XML_SetHashSalt()

miss-islington added the comment: New changeset cb5778f00ce48631c7140f33ba242496aaf7102b by Miss Islington (bot) (Christian Heimes) in branch 'master': bpo-34623: Use XML_SetHashSalt in _elementtree (GH-9146) https://github.com/python/cpython/commit/cb5778f00ce48631c7140f33ba242496aaf7102b

[issue34702] urlopen doesn't handle query strings with "file" scheme

Change by Karthikeyan Singaravelan : -- nosy: +xtreak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34719] Deprecate set to frozenset conversion in set.__contains__

Change by Karthikeyan Singaravelan : -- nosy: +xtreak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34720] Fix test_importlib.test_bad_traverse for AIX

Change by Michael Felt : -- keywords: +patch pull_requests: +8815 stage: -> patch review ___ Python tracker ___ ___

[issue34720] Fix test_importlib.test_bad_traverse for AIX

Change by Michael Felt : -- title: Fix test_importlib for AIX -> Fix test_importlib.test_bad_traverse for AIX ___ Python tracker ___

[issue34720] Fix test_importlib for AIX

New submission from Michael Felt : Issue32374 added a new subtest (test_bad_traverse) in test_importlib. The test succeeds when a script calling a bad_traverse exits with a non-zero status (e.g., crashes because of segmentation violation) This patch "fixes" Modules/_testmultiphase.c so that

  1   2   >