[issue13948] rm needless use of set function
New submission from Tshepang Lekhonkhobe tshep...@gmail.com: I assume that the set() function was used to get rid of duplicates from self.versions, but there aren't any and the test would pass even if there were. -- assignee: tarek components: Distutils2 files: rm-needless-use-of-set-function.patch keywords: patch messages: 152725 nosy: alexis, eric.araujo, tarek, tshepang priority: normal severity: normal status: open title: rm needless use of set function type: behavior Added file: http://bugs.python.org/file24430/rm-needless-use-of-set-function.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13948 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13949] rm needless use of pass statement
New submission from Tshepang Lekhonkhobe tshep...@gmail.com: I found the use of the pass statement redundant. -- assignee: tarek components: Distutils2 files: rm-needless-use-of-pass-keyword.patch keywords: patch messages: 152726 nosy: alexis, eric.araujo, tarek, tshepang priority: normal severity: normal status: open title: rm needless use of pass statement type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file24431/rm-needless-use-of-pass-keyword.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13950] rm commented-out code
New submission from Tshepang Lekhonkhobe tshep...@gmail.com: It does not appear that the commented-out code adds any value. If anything, it's maybe just a distraction. -- assignee: tarek components: Distutils2 files: rm-commented-out-code.patch keywords: patch messages: 152727 nosy: alexis, eric.araujo, tarek, tshepang priority: normal severity: normal status: open title: rm commented-out code versions: Python 3.3 Added file: http://bugs.python.org/file24432/rm-commented-out-code.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13950 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13889] str(float) and round(float) issues with FPU precision
Stefan Krah stefan-use...@bytereef.org added the comment: I can run the tests on win64, but it I think it would be nice to have a patch with exactly the same logic as the gcc-asm version (Mark already mentioned _MCW_PC | _MCW_RC). Another thing: _WIN32 might be defined on MinGW, but I'm not sure. If that's the case, it would be nice to guard the VS specific passage with _MSC_VER. -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13889 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4709] Mingw-w64 and python on windows x64
Ralf Schmitt python-b...@systemexit.de added the comment: Marting, this issue is about building python extensions with mingw-w64 not about building python itself. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4709 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
STINNER Victor victor.stin...@haypocalc.com added the comment: In a security fix release, we shouldn't change the linkage procedures, so I recommend that the LoadLibrary dance remains. So the overhead in startup time is not an issue? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Marc-Andre Lemburg m...@egenix.com added the comment: STINNER Victor wrote: STINNER Victor victor.stin...@haypocalc.com added the comment: In a security fix release, we shouldn't change the linkage procedures, so I recommend that the LoadLibrary dance remains. So the overhead in startup time is not an issue? It is an issue. Not only in terms of startup time, but also because randomization per default makes Python behave in non-deterministc ways - which is not what you want from a programming language or interpreter (unless you explicitly tell it to behave like that). I think it would be much better to just let the user define a hash seed using environment variables for Python to use and then forget about how this variable value is determined. If it's not set, Python uses 0 as seed, thereby disabling the seeding logic. This approach would have Python behave in a deterministic way per default and still allow users who wish to use a different seed, set this to a different value - even on a case by case basis. If you absolutely want to add a feature to have the seed set randomly, you could make a seed value of -1 trigger the use of a random number source as seed. I also still firmly believe that the collision counting scheme should be made available via an environment variable as well. The user could then set the variable to e.g. 1000 to have it enabled with limit 1000, or leave it undefined to disable the collision counting. With those two tools, users could then choose the method they find most attractive for their purposes. By default, they would be disabled, but applications which are exposed to untrusted user data and use dictionaries for managing such data could check whether the protections are enabled and trigger a startup error if needed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13590] exension module builds fail with python.org OS X installers on OS X 10.7 and 10.6 with Xcode 4.2
Changes by Ned Deily n...@acm.org: -- assignee: ronaldoussoren - ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13590 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Antoine Pitrou pit...@free.fr added the comment: It is an issue. Not only in terms of startup time, but also because randomization per default makes Python behave in non-deterministc ways - which is not what you want from a programming language or interpreter (unless you explicitly tell it to behave like that). That's debatable. For example id() is fairly unpredictable accross runs (except for statically-allocated instances). I think it would be much better to just let the user define a hash seed using environment variables for Python to use and then forget about how this variable value is determined. If it's not set, Python uses 0 as seed, thereby disabling the seeding logic. This approach would have Python behave in a deterministic way per default and still allow users who wish to use a different seed, set this to a different value - even on a case by case basis. If you absolutely want to add a feature to have the seed set randomly, you could make a seed value of -1 trigger the use of a random number source as seed. Having both may indeed be a good idea. I also still firmly believe that the collision counting scheme should be made available via an environment variable as well. The user could then set the variable to e.g. 1000 to have it enabled with limit 1000, or leave it undefined to disable the collision counting. With those two tools, users could then choose the method they find most attractive for their purposes. It's not about being attractive, it's about fixing the security problem. The simple collision counting approach leaves a gaping hole open, as demonstrated by Frank. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13931] os.path.exists inconsistent between 32 bit and 64 bit
zxw eeyore@gmail.com added the comment: I've posted the code to http://code.activestate.com/recipes/578035-disable-file-system-redirector/ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13931 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Marc-Andre Lemburg m...@egenix.com added the comment: Antoine Pitrou wrote: The simple collision counting approach leaves a gaping hole open, as demonstrated by Frank. Could you elaborate on this ? Note that I've updated the collision counting patch to cover both possible attack cases I mentioned in http://bugs.python.org/issue13703#msg150724. If there's another case I'm unaware of, please let me know. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13951] Seg Fault in .so called by ctypes causes the interpreter to Seg Fault
New submission from Graeme Glass graemegl...@gmail.com:
When doing something obviously incorrect (read, wrong/stupid) while calling
libX11.so.6 via ctypes, it causes a Segmentation fault, which in turn cause the
python interpreter to fall over with a Segmentation fault.
My question is, is this the correct behaviour? Should it seg fault or just
throw an exception?
Details below.
graeme@roger:~$ uname -a
Linux roger 3.0.0-15-generic-pae #26-Ubuntu SMP Fri Jan 20 17:07:31 UTC 2012
i686 i686 i386 GNU/Linux
graeme@roger:~$ python
Python 2.7.2+ (default, Oct 4 2011, 20:03:08)
[GCC 4.6.1] on linux2
graeme@roger:~$ python2.6
Python 2.6.7 (r267:88850, Aug 11 2011, 12:16:10)
[GCC 4.6.1] on linux2
## The example code
graeme@roger:~$ cat xtest.py
from ctypes import cdll
dll = cdll.LoadLibrary('libX11.so.6')
d = dll.XOpenDisplay(None)
root = dll.XDefaultRootWindow(d)
dll.XWarpPointer(d,None,root,0,0,0,0,20,39)
dll.XCloseDisplay(d)
dll.XCloseDisplay(d) #2nd call, should not be called, is not needed. Causes seg
fault.
##The results
graeme@roger:~$ pdb2.7 xtest.py
/home/graeme/xtest.py(1)module()
- from ctypes import cdll
(Pdb) c
Segmentation fault
graeme@roger:~$ python2.7 xtest.py
Segmentation fault
graeme@roger:~$ ipython-2.7 xtest.py
Segmentation fault
graeme@roger:~$ ipython-2.6 xtest.py
Segmentation fault
graeme@roger:~$ gdb python2.7
(gdb) set args xtest.py
(gdb) run
Starting program: /usr/bin/python xtest.py
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
__GI___libc_free (mem=0x151) at malloc.c:3709
3709malloc.c: No such file or directory.
in malloc.c
graeme@roger:~$ python2.6 xtest.py
*** glibc detected *** python2.6: double free or corruption (!prev): 0x083533a0
***
=== Backtrace: =
/lib/i386-linux-gnu/libc.so.6(+0x6ebc2)[0xb7402bc2]
/lib/i386-linux-gnu/libc.so.6(+0x6f862)[0xb7403862]
/lib/i386-linux-gnu/libc.so.6(cfree+0x6d)[0xb740694d]
/usr/lib/i386-linux-gnu/libX11.so.6(+0x9232b)[0xb6ff732b]
/usr/lib/i386-linux-gnu/libX11.so.6(_XFreeDisplayStructure+0x16f)[0xb6f8bddf]
/usr/lib/i386-linux-gnu/libX11.so.6(XCloseDisplay+0xd9)[0xb6f78179]
/usr/lib/python2.6/lib-dynload/_ctypes.so(ffi_call_SYSV+0x1a)[0xb70c548a]
/usr/lib/python2.6/lib-dynload/_ctypes.so(ffi_call+0x6f)[0xb70c51bf]
/usr/lib/python2.6/lib-dynload/_ctypes.so(_CallProc+0x2c2)[0xb70bfd12]
/usr/lib/python2.6/lib-dynload/_ctypes.so(+0x61ed)[0xb70b71ed]
python2.6(PyObject_Call+0x4d)[0x80648cd]
python2.6(PyEval_EvalFrameEx+0x3984)[0x80d6514]
python2.6(PyEval_EvalCodeEx+0x882)[0x80d96e2]
python2.6(PyEval_EvalCode+0x57)[0x80d97e7]
python2.6(PyRun_FileExFlags+0xa6)[0x80f8b26]
python2.6(PyRun_SimpleFileExFlags+0xc6)[0x80f98b6]
python2.6(Py_Main+0xa49)[0x805be59]
python2.6(main+0x1b)[0x805affb]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb73ad113]
python2.6[0x805b021]
=== Memory map:
08048000-08255000 r-xp 08:06 4459238/usr/bin/python2.6
08255000-08256000 r--p 0020c000 08:06 4459238/usr/bin/python2.6
08256000-082a5000 rw-p 0020d000 08:06 4459238/usr/bin/python2.6
082a5000-082ae000 rw-p 00:00 0
082d2000-08374000 rw-p 00:00 0 [heap]
b6e0-b6e21000 rw-p 00:00 0
b6e21000-b6f0 ---p 00:00 0
b6f28000-b6f44000 r-xp 08:06 2097174
/lib/i386-linux-gnu/libgcc_s.so.1
b6f44000-b6f45000 r--p 0001b000 08:06 2097174
/lib/i386-linux-gnu/libgcc_s.so.1
b6f45000-b6f46000 rw-p 0001c000 08:06 2097174
/lib/i386-linux-gnu/libgcc_s.so.1
b6f46000-b6f63000 r-xp 08:06 4458588
/usr/lib/i386-linux-gnu/libxcb.so.1.1.0
b6f63000-b6f64000 r--p 0001c000 08:06 4458588
/usr/lib/i386-linux-gnu/libxcb.so.1.1.0
b6f64000-b6f65000 rw-p 0001d000 08:06 4458588
/usr/lib/i386-linux-gnu/libxcb.so.1.1.0
b6f65000-b7096000 r-xp 08:06 4458582
/usr/lib/i386-linux-gnu/libX11.so.6.3.0
b7096000-b7097000 ---p 00131000 08:06 4458582
/usr/lib/i386-linux-gnu/libX11.so.6.3.0
b7097000-b7098000 r--p 00131000 08:06 4458582
/usr/lib/i386-linux-gnu/libX11.so.6.3.0
b7098000-b709a000 rw-p 00132000 08:06 4458582
/usr/lib/i386-linux-gnu/libX11.so.6.3.0
b709a000-b709b000 rw-p 00:00 0
b70b1000-b70c8000 r-xp 08:06 3634
/usr/lib/python2.6/lib-dynload/_ctypes.so
b70c8000-b70cb000 r--p 00017000 08:06 3634
/usr/lib/python2.6/lib-dynload/_ctypes.so
b70cb000-b70ce000 rw-p 0001a000 08:06 3634
/usr/lib/python2.6/lib-dynload/_ctypes.so
b70ce000-b710f000 rw-p 00:00 0
b711-b7111000 r--p 00299000 08:06 4464349/usr/lib/locale/locale-archive
b7111000-b7311000 r--p 08:06 4464349/usr/lib/locale/locale-archive
b7311000-b7394000 rw-p 00:00 0
b7394000-b750a000 r-xp 08:06 2097561
/lib/i386-linux-gnu/libc-2.13.so
b750a000-b750c000 r--p 00176000 08:06 2097561
/lib/i386-linux-gnu/libc-2.13.so
b750c000-b750d000 rw-p 00178000 08:06 2097561
/lib/i386-linux-gnu/libc-2.13.so
[issue13590] extension module builds fail with python.org OS X installers on OS X 10.7 and 10.6 with Xcode 4.2
Changes by Éric Araujo mer...@netwok.org: -- title: exension module builds fail with python.org OS X installers on OS X 10.7 and 10.6 with Xcode 4.2 - extension module builds fail with python.org OS X installers on OS X 10.7 and 10.6 with Xcode 4.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13590 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13950] rm commented-out code
Éric Araujo mer...@netwok.org added the comment: Before Tarek started the distutils2 project, the version code lived standalone and its README file served as doctest. Most of its text was moved to PEP 386 and the tests themselves to test_verlib (and now test_version): https://bitbucket.org/tarek/distutilsversion/changeset/140170ef3896#chg-README.txt So you’re right, the lines that your patch removes are indeed unneeded, but I’d just like to check that all tests were moved into test_version before applying it. -- assignee: tarek - eric.araujo versions: +3rd party ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13950 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13949] rm needless use of pass statement
Éric Araujo mer...@netwok.org added the comment: Sure, I’ll apply this. -- assignee: tarek - eric.araujo versions: +3rd party ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13948] rm needless use of set function
Éric Araujo mer...@netwok.org added the comment: Yes, this test method could be a little clearer. I’ll do this. -- assignee: tarek - eric.araujo versions: +3rd party ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13948 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13951] Seg Fault in .so called by ctypes causes the interpreter to Seg Fault
Ramchandra Apte maniandra...@gmail.com added the comment: It is the correct behaviour for an invalid usage to segfault and is also mentioned in the documentation. Can somebody close this bug as invalid? -- nosy: +ramchandra.apte ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13951 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Jim Jewett jimjjew...@gmail.com added the comment: On Mon, Feb 6, 2012 at 8:12 AM, Marc-Andre Lemburg rep...@bugs.python.org wrote: Marc-Andre Lemburg m...@egenix.com added the comment: Antoine Pitrou wrote: The simple collision counting approach leaves a gaping hole open, as demonstrated by Frank. Could you elaborate on this ? Note that I've updated the collision counting patch to cover both possible attack cases I mentioned in http://bugs.python.org/issue13703#msg150724. If there's another case I'm unaware of, please let me know. The problematic case is, roughly, (1) Find out what N will trigger collision-counting countermeasures. (2) Insert N-1 colliding entries, to make it as slow as possible. (3) Keep looking up (or updating) the N-1th entry, so that the slow-as-possible-without-countermeasures path keeps getting rerun. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13938] 2to3 fails to convert types.StringTypes appropriately
Changes by Éric Araujo mer...@netwok.org: -- assignee: - benjamin.peterson nosy: +benjamin.peterson versions: +Python 2.7 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13938 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040439] Missing documentation on how to link with libpython
Éric Araujo mer...@netwok.org added the comment: Is there still work to do on this issue? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1040439 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13951] please close - Seg Fault in .so called by ctypes causes the interpreter to Seg Fault
Changes by Ramchandra Apte maniandra...@gmail.com: -- title: Seg Fault in .so called by ctypes causes the interpreter to Seg Fault - please close - Seg Fault in .so called by ctypes causes the interpreter to Seg Fault ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13951 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040439] Missing documentation on how to link with libpython
Antoine Pitrou pit...@free.fr added the comment: Is there still work to do on this issue? Not for Unix, no. I don't if it's applicable to Windows. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1040439 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4709] Mingw-w64 and python on windows x64
John Pye j...@curioussymbols.com added the comment: Martin, Ralf is right and my as previously linked is about building a python extension. I should have been more explicit about that. FWIW I found that the configure scripts on MinGW-w64 generally work fine if you add a --build=x86_64-w64-mingw32 argument on the ./configure command line. Then you should only add /mingw/bin to your path (and edit /etc/fstab to map c:/mingw64 to /mingw). Adding those subdirectories to the PATH doesn't seem to be successful; I suspect that those binaries are off the standard path for some reason, eg internal use by GCC only, or something (GCC seems to do some clever tricks with relative paths, so I'm sure it's important that you use the correct starting executable). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4709 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13951] Seg Fault in .so called by ctypes causes the interpreter to Seg Fault
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: [Please do not change issue titles - your recommendation was enough] Indeed, incorrect usage of ctypes can crash the program, and there is nothing Python can do. But I could not find any warning about this in the documentation, except maybe this sentence: There are, however, enough ways to crash Python with ctypes, so you should be careful anyway. Let's turn this into a doc issue, then. -- assignee: - docs@python components: +Documentation nosy: +amaury.forgeotdarc, docs@python title: please close - Seg Fault in .so called by ctypes causes the interpreter to Seg Fault - Seg Fault in .so called by ctypes causes the interpreter to Seg Fault ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13951 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13903] New shared-keys dictionary implementation
Changes by Mark Shannon m...@hotpy.org: -- hgrepos: -109 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13903 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11805] package_data only allows one glob per-package
Éric Araujo mer...@netwok.org added the comment: (I forgot that distutils2’s setup.py has its own fork of the conversion functions, for bootstrapping reasons, so I need to port the fix there.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11805 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5302] Allow package_data specs/globs to match directories
Éric Araujo mer...@netwok.org added the comment: One implementation by George Sakkis is found in this thread: http://bugs.python.org/issue2279#msg82213 There are subtle issues with this feature. For example, a glob pattern could match both package data files and Python submodules, leading to the same .py files being included as modules and data. I’ll see how far I want to specify the behavior in tests and docs. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5302 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Marc-Andre Lemburg m...@egenix.com added the comment: Jim Jewett wrote: Jim Jewett jimjjew...@gmail.com added the comment: On Mon, Feb 6, 2012 at 8:12 AM, Marc-Andre Lemburg rep...@bugs.python.org wrote: Marc-Andre Lemburg m...@egenix.com added the comment: Antoine Pitrou wrote: The simple collision counting approach leaves a gaping hole open, as demonstrated by Frank. Could you elaborate on this ? Note that I've updated the collision counting patch to cover both possible attack cases I mentioned in http://bugs.python.org/issue13703#msg150724. If there's another case I'm unaware of, please let me know. The problematic case is, roughly, (1) Find out what N will trigger collision-counting countermeasures. (2) Insert N-1 colliding entries, to make it as slow as possible. (3) Keep looking up (or updating) the N-1th entry, so that the slow-as-possible-without-countermeasures path keeps getting rerun. Since N is constant, I don't see how such an attack could be used to trigger the O(n^2) worst-case behavior. Even if you can create n sets of entries that each fill up N-1 positions, the overall performance will still be O(n*N*(N-1)/2) = O(n). So in the end, we're talking about a regular brute force DoS attack, which requires different measures than dictionary implementation tricks :-) BTW: If you set the limit N to e.g. 100 (which is reasonable given Victor's and my tests), the time it takes to process one of those sets only takes 0.3 ms on my machine. That's hardly usable as basis for an effective DoS attack. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5411] add xz compression support to shutil
Éric Araujo mer...@netwok.org added the comment: This not-so-bad patch adds lzma compression support to the shutil functions, under the 'xztar' name. Please review. -- Added file: http://bugs.python.org/file24433/shutil-xz.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5411 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5411] add xz compression support to shutil
Éric Araujo mer...@netwok.org added the comment: I should add that a doc update will be part of the next patch. In parallel, I’ve also started updating packaging to add lzma support to the bdist command, but the situation is very disappointing: tarfile knows what format it supports, shutil has its own list, and packaging has a few duplicates too! Ideally, tarfile should have an attribute to expose what compression formats are available, then shutil would reuse that, and packaging would just call shutil. (I’m not even talking about the duplication in the doc.) If you agree with the general idea, I’ll open reports to a) add the attribute to tarfile b) rework the (luckily internal) registries in shutil to stop being hard-coded c) remove packaging’s registries. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5411 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12703] Improve error reporting for packaging.util.resolve_name
Éric Araujo mer...@netwok.org added the comment: In the absence of feedback, I’m going to apply my find_object idea as described in my previous message. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13952] mimetypes doesn't recognize .csv
New submission from Ian Davis iwd32...@yahoo.com: The mimetypes module does not respond with text/csv for files that end in .csv, and I think it should :) For goodness sake, text/tab-delimited-values is in there as .tsv, and that seems much less used (to me). -- components: Library (Lib) messages: 152751 nosy: iwd32900 priority: normal severity: normal status: open title: mimetypes doesn't recognize .csv type: behavior versions: Python 2.6, Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13952 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13952] mimetypes doesn't recognize .csv
R. David Murray rdmur...@bitdance.com added the comment: Yes, but text/tab-delimited-values/.tsv is older. .tsv dates from the days of Gopher, but text/csv was formalized only in October of 2005. Presumably nobody has asked for it before, for some odd reason. Now we get to debate again whether updating mimetypes with a registered type can be considered a bug fix. We've gone both ways in the past, as far as I can tell. This one has the advantage of actually having a formal IANA registration, unlike the last couple. -- nosy: +r.david.murray stage: - needs patch versions: +Python 3.2, Python 3.3 -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13952 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8255] Packaging step-by-step tutorial
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8255 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Jim Jewett jimjjew...@gmail.com added the comment: On Mon, Feb 6, 2012 at 12:07 PM, Marc-Andre Lemburg rep...@bugs.python.org wrote: Marc-Andre Lemburg m...@egenix.com added the comment: Jim Jewett wrote: The problematic case is, roughly, (1) Find out what N will trigger collision-counting countermeasures. (2) Insert N-1 colliding entries, to make it as slow as possible. (3) Keep looking up (or updating) the N-1th entry, so that the slow-as-possible-without-countermeasures path keeps getting rerun. Since N is constant, I don't see how such an attack could be used to trigger the O(n^2) worst-case behavior. Agreed; it tops out with a constant, but if it takes only 16 bytes of input to force another run through a 1000-long collision, that may still be too much leverage. BTW: If you set the limit N to e.g. 100 (which is reasonable given Victor's and my tests), Agreed. Frankly, I think 5 would be more than reasonable so long as there is a fallback. the time it takes to process one of those sets only takes 0.3 ms on my machine. That's hardly usable as basis for an effective DoS attack. So it would take around 3Mb to cause a minute's delay... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Frank Sievertsen pyt...@sievertsen.de added the comment: Agreed; it tops out with a constant, but if it takes only 16 bytes of input to force another run through a 1000-long collision, that may still be too much leverage. You should prepare the dict so that you have the collisions-run with a one-byte string or better with an even empty string, not a 16 bytes string. BTW: If you set the limit N to e.g. 100 (which is reasonable given Victor's and my tests), 100 is probably hard to exploit for a DoS attack. However it makes it much easier to cause unwanted (future?) exceptions in other apps. So it would take around 3Mb to cause a minute's delay... How did you calculate that? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Marc-Andre Lemburg m...@egenix.com added the comment: Jim Jewett wrote: BTW: If you set the limit N to e.g. 100 (which is reasonable given Victor's and my tests), Agreed. Frankly, I think 5 would be more than reasonable so long as there is a fallback. the time it takes to process one of those sets only takes 0.3 ms on my machine. That's hardly usable as basis for an effective DoS attack. So it would take around 3Mb to cause a minute's delay... I'm not sure how you calculated that number. Here's what I get: tale a dictionary with 100 integer collisions: d = dict((x*(2**64 - 1), 1) for x in xrange(1, 100)) The repr(d) has 2713 bytes, which is a good approximation of how much (string) data you have to send in order to trigger the problem case. If you can create distinct integer sequences, you'll get a processing time of about 1 second on my slow dev machine. The resulting dict will likely have a repr() of around 60**2713 = 517MB. So you need to send 517MB to cause my slow dev machine to consume 1 minute of CPU time. Today's servers are at least 10 times as fast as my aging machine. If you then take into account that the integer collision dictionary is a very efficient collision example (size vs. effect), the attack doesn't really sound practical anymore. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13953] test_packaging: unused test?
New submission from Tshepang Lekhonkhobe tshep...@gmail.com: I'm not sure what's happening here (not sure how doctest works), but I suspect that there is no test at all. Perhaps it was forgotten: http://hg.python.org/cpython/file/567767a6df02/Lib/packaging/tests/test_version.py#l68. I say this because it whatever change I make to that long string, I always get a successful test. -- assignee: tarek components: Distutils2 messages: 152756 nosy: alexis, eric.araujo, tarek, tshepang priority: normal severity: normal status: open title: test_packaging: unused test? versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13953 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13952] mimetypes doesn't recognize .csv
Antoine Pitrou pit...@free.fr added the comment:
I would argue the embedded mime-types dictionary should at least mirror current
IANA assignments, which are already present in up-to-date Unix systems:
mimetypes.guess_type(foo.csv)
('text/csv', None)
So not having text/csv is IMHO a bug.
Also it would be nice if there were an easy way to keep the mime-types
dictionary up-to-date wrt. a system's mime-types file.
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13952
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13952] mimetypes doesn't recognize .csv
R. David Murray rdmur...@bitdance.com added the comment: As far as I know having it mirror the IANA registry is the intent (there's a comment in the module that can be read as implying that). So I'd be inclined to treat this one as a bug and fix it in 2.7 and 3.2 as well as 3.3. I'm not sure what you mean by your final comment, since by default the system mime types are read on both Unix and Windows and merged with the built in table. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13952 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Dave Malcolm dmalc...@redhat.com added the comment: On Mon, 2012-02-06 at 10:20 +, Marc-Andre Lemburg wrote: Marc-Andre Lemburg m...@egenix.com added the comment: STINNER Victor wrote: STINNER Victor victor.stin...@haypocalc.com added the comment: In a security fix release, we shouldn't change the linkage procedures, so I recommend that the LoadLibrary dance remains. So the overhead in startup time is not an issue? It is an issue. Not only in terms of startup time, but also msg152362 indicated that there was negligible impact on startup time when randomization is disabled. The impact when it *is* enabled is unclear, but reported there as isn't crippling. because randomization per default makes Python behave in non-deterministc ways - which is not what you want from a programming language or interpreter (unless you explicitly tell it to behave like that). The release managers have pronounced: http://mail.python.org/pipermail/python-dev/2012-January/115892.html Quoting that email: 1. Simple hash randomization is the way to go. We think this has the best chance of actually fixing the problem while being fairly straightforward such that we're comfortable putting it in a stable release. 2. It will be off by default in stable releases and enabled by an envar at runtime. This will prevent code breakage from dictionary order changing as well as people depending on the hash stability. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13952] mimetypes doesn't recognize .csv
Antoine Pitrou pit...@free.fr added the comment: I'm not sure what you mean by your final comment, since by default the system mime types are read on both Unix and Windows and merged with the built in table. I mean to have our built-in table mirror a recent Unix system's mime-types table. There could be a special switch to mimetypes.py, which would output the Python code of a dict mirroring /etc/mime.types (or /etc/mime.types + the current built-in table) when run. Then it would be easy to integrate the changes back into the code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13952 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13952] mimetypes doesn't recognize .csv
R. David Murray rdmur...@bitdance.com added the comment: Ah, analagous to the way keyword.py regenerates its embedded table based on the actual python grammar? Yes, that would be nice. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13952 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Jim Jewett jimjjew...@gmail.com added the comment: On Mon, Feb 6, 2012 at 1:53 PM, Frank Sievertsen rep...@bugs.python.org wrote: BTW: If you set the limit N to e.g. 100 (which is reasonable given Victor's and my tests), So it would take around 3Mb to cause a minute's delay... How did you calculate that? 16 bytes/entry * 3300 entries/second * 60 seconds/minute But if there is indeed a way to cut that 16 bytes/entry, that is worse. Switching dict implementations at 5 collisions is still acceptable, except from a complexity standpoint. -jJ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Marc-Andre Lemburg m...@egenix.com added the comment: Dave Malcolm wrote: So the overhead in startup time is not an issue? It is an issue. Not only in terms of startup time, but also ... because randomization per default makes Python behave in non-deterministc ways - which is not what you want from a programming language or interpreter (unless you explicitly tell it to behave like that). The release managers have pronounced: http://mail.python.org/pipermail/python-dev/2012-January/115892.html Quoting that email: 1. Simple hash randomization is the way to go. We think this has the best chance of actually fixing the problem while being fairly straightforward such that we're comfortable putting it in a stable release. 2. It will be off by default in stable releases and enabled by an envar at runtime. This will prevent code breakage from dictionary order changing as well as people depending on the hash stability. Right, but that doesn't contradict what I wrote about adding env vars to fix a seed and optionally enable using a random seed, or adding collision counting as extra protection for cases that are not addressed by the hash seeding, such as e.g. collisions caused by 3rd types or numbers. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10811] sqlite segfault with generators
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 631e99961c5f by Petri Lehtinen in branch '2.7': Issue #10811: Fix recursive usage of cursors. Instead of crashing, raise a ProgrammingError now. http://hg.python.org/cpython/rev/631e99961c5f New changeset d51ceef4b62f by Petri Lehtinen in branch '3.2': Issue #10811: Fix recursive usage of cursors. Instead of crashing, raise a ProgrammingError now. http://hg.python.org/cpython/rev/d51ceef4b62f -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10811 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10811] sqlite segfault with generators
Petri Lehtinen pe...@digip.org added the comment: It's now fixed in all branches. Thanks for reporting! -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10811 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Marc-Andre Lemburg m...@egenix.com added the comment: Marc-Andre Lemburg wrote: Dave Malcolm wrote: The release managers have pronounced: http://mail.python.org/pipermail/python-dev/2012-January/115892.html Quoting that email: 1. Simple hash randomization is the way to go. We think this has the best chance of actually fixing the problem while being fairly straightforward such that we're comfortable putting it in a stable release. 2. It will be off by default in stable releases and enabled by an envar at runtime. This will prevent code breakage from dictionary order changing as well as people depending on the hash stability. Right, but that doesn't contradict what I wrote about adding env vars to fix a seed and optionally enable using a random seed, or adding collision counting as extra protection for cases that are not addressed by the hash seeding, such as e.g. collisions caused by 3rd types or numbers. ... at least I hope not :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Antoine Pitrou pit...@free.fr added the comment: Right, but that doesn't contradict what I wrote about adding env vars to fix a seed and optionally enable using a random seed, or adding collision counting as extra protection for cases that are not addressed by the hash seeding, such as e.g. collisions caused by 3rd types or numbers. ... at least I hope not :-) I think the env var part is a good idea (except that -1 as a magic value to enable randomization isn't great). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Marc-Andre Lemburg m...@egenix.com added the comment: Antoine Pitrou wrote: Antoine Pitrou pit...@free.fr added the comment: Right, but that doesn't contradict what I wrote about adding env vars to fix a seed and optionally enable using a random seed, or adding collision counting as extra protection for cases that are not addressed by the hash seeding, such as e.g. collisions caused by 3rd types or numbers. ... at least I hope not :-) I think the env var part is a good idea (except that -1 as a magic value to enable randomization isn't great). Agreed. Since it's an env var, using random would be a better choice. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13588] Change name of internal closure functions in importlib
Changes by Brett Cannon br...@python.org: -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13588 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8184] multiprocessing.managers will not fail if listening ocket already in use
Antoine Pitrou pit...@free.fr added the comment: Anyway, in that case, my last patch should be correct (tested on one of the Win7 buildbots). It looks good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8184 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13954] Add regrtest option to record test results to a file
New submission from Brett Cannon br...@python.org: The idea is that if a test succeeded then it is written to a file commented out(including skipped tests w/ the appropriate comment), and if a test failed then it is left uncommented. This way the failing tests can simply be passed to --fromfile for easy repeatability. This becomes especially handy when randomizing test order and there is some dependency on a previously run test as you can begin to uncomment tests until you find the trigger. This can also be used with some other new flag which lists which tests to skip (i.e. the inverse of --fromfile). This is helpful when you don't want to run tests in some branch when you know they are failing in the default branch already and you are not trying to fix them. -- components: Tests messages: 152771 nosy: brett.cannon priority: normal severity: normal stage: needs patch status: open title: Add regrtest option to record test results to a file versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13955] email: RFC 2822 has been obsoleted by RFC 5322
New submission from Samuel Bronson naes...@gmail.com: As you can see by looking at http://tools.ietf.org/html/rfc2822 or http://tools.ietf.org/html/rfc5322, RFC 2822 has been obsoleted by RFC 5322. It would probably be a good idea to update the email package to support it, if in fact anything needs changing, and to mention/link to the new RFC in the documentation. (It would probably *not* be a good idea to stop mentioning RFC 2822, though, since that's rather more well known, and the number is a bit more memorable for those who've heard of RFC 822. I'm actually a bit surprised the new one didn't get numbered 5822...) -- components: Library (Lib) messages: 152772 nosy: SamB priority: normal severity: normal status: open title: email: RFC 2822 has been obsoleted by RFC 5322 versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13955 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13956] add a note regarding building on recent versions of Debian and Ubuntu
New submission from Tshepang Lekhonkhobe tshep...@gmail.com: I was puzzled why the various parts, like readline and ssl, failed to be built into my Python. It was after seeing #11715 that I realized I needed to install dpkg-dev, whose binary, dpkg-architecture, helps detect the locations of those libraries (). -- components: Devguide files: note-on-building-on-recent-debian-releases.patch keywords: patch messages: 152773 nosy: ezio.melotti, tshepang priority: normal severity: normal status: open title: add a note regarding building on recent versions of Debian and Ubuntu type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file24438/note-on-building-on-recent-debian-releases.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13956 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13955] email: RFC 2822 has been obsoleted by RFC 5322
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13955 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13957] parsedate_tz doesn't distinguish -0000 from +0000
New submission from Samuel Bronson naes...@gmail.com:
This is what I'm seeing:
import email.utils
email.utils.parsedate_tz('Fri, 09 Nov 2001 01:08:47 +')
(2001, 11, 9, 1, 8, 47, 0, 1, -1, 0)
email.utils.parsedate_tz('Fri, 09 Nov 2001 01:08:47 -')
(2001, 11, 9, 1, 8, 47, 0, 1, -1, 0)
But RFC 5322 says:
minutes). The form + SHOULD be used to indicate a time zone at
Universal Time. Though - also indicates Universal Time, it is
used to indicate that the time was generated on a system that may be
in a local time zone other than Universal Time and that the date-time
contains no information about the local time zone.
(As does RFC 2822, which RFC 5322 obsoletes.)
And the documentation for email.utils.parsedate_tz is:
Performs the same function as parsedate(), but returns either None or a
10-tuple; the first 9 elements make up a tuple that can be passed directly to
time.mktime(), and the tenth is the offset of the date’s timezone from UTC
(which is the official term for Greenwich Mean Time) [1]. If the input string
has no timezone, the last element of the tuple returned is None. Note that
indexes 6, 7, and 8 of the result tuple are not usable.
So it seems like I should have seen:
email.utils.parsedate_tz('Fri, 09 Nov 2001 01:08:47 -')
(2001, 11, 9, 1, 8, 47, 0, 1, -1, None)
--
components: Library (Lib)
messages: 152774
nosy: SamB
priority: normal
severity: normal
status: open
title: parsedate_tz doesn't distinguish - from +
type: behavior
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13957
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13954] Add regrtest option to record test results to a file
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13958] Comment _PyUnicode_FromId
New submission from Jim Jewett jimjjew...@gmail.com: Add a comment explaining why _PyUnicode_FromId can (and should) assume ASCII-only identifiers. /* PEP3131 guarantees that all python-internal identifiers are ASCII-only. Violating this would break some supported C compilers. */ See http://mail.python.org/pipermail/python-dev/2012-February/116234.html -- components: Unicode messages: 152775 nosy: Jim.Jewett, ezio.melotti priority: normal severity: normal status: open title: Comment _PyUnicode_FromId versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13958 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13955] email: RFC 2822 has been obsoleted by RFC 5322
R. David Murray rdmur...@bitdance.com added the comment: 5322 is still a draft, according to the IETF. That said, we are paying attention to 5322. -- nosy: +r.david.murray resolution: - invalid stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13955 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Gregory P. Smith g...@krypto.org added the comment: The release managers have pronounced: http://mail.python.org/pipermail/python-dev/2012-January/115892.html Quoting that email: 1. Simple hash randomization is the way to go. We think this has the best chance of actually fixing the problem while being fairly straightforward such that we're comfortable putting it in a stable release. 2. It will be off by default in stable releases and enabled by an envar at runtime. This will prevent code breakage from dictionary order changing as well as people depending on the hash stability. Right, but that doesn't contradict what I wrote about adding env vars to fix a seed and optionally enable using a random seed, or adding collision counting as extra protection for cases that are not addressed by the hash seeding, such as e.g. collisions caused by 3rd types or numbers. We won't be back-porting anything more than the hash randomization for 2.6/2.7/3.1/3.2 but we are free to do more in 3.3 if someone can demonstrate it working well and a need for it. For me, things like collision counting and tree based collision buckets when the types are all the same and known comparable make sense but are really sounding like a lot of additional complexity. I'd *like* to see active black-box design attack code produced that goes after something like a wsgi web app written in Python with hash randomization *enabled* to demonstrate the need before we accept additional protections like this for 3.3+. -gps -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13958] Comment _PyUnicode_FromId
Martin v. Löwis mar...@v.loewis.de added the comment: This has nothing to do with PEP 3131. Python could (and does) support non-ASCII identifiers just fine, regardless of C compiler limitations. -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13958 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13807] logging.Handler.handlerError() may raise AttributeError in traceback.print_exception()
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 6b951f27f6a8 by Vinay Sajip in branch '3.2': Null merge for reverted fix for #13807. http://hg.python.org/cpython/rev/6b951f27f6a8 New changeset 140f7de4d2a5 by Vinay Sajip in branch 'default': Null merge for reverted fix for #13807. http://hg.python.org/cpython/rev/140f7de4d2a5 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13807 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13958] Comment _PyUnicode_FromId
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13958 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Marc-Andre Lemburg m...@egenix.com added the comment: Gregory P. Smith wrote: Gregory P. Smith g...@krypto.org added the comment: The release managers have pronounced: http://mail.python.org/pipermail/python-dev/2012-January/115892.html Quoting that email: 1. Simple hash randomization is the way to go. We think this has the best chance of actually fixing the problem while being fairly straightforward such that we're comfortable putting it in a stable release. 2. It will be off by default in stable releases and enabled by an envar at runtime. This will prevent code breakage from dictionary order changing as well as people depending on the hash stability. Right, but that doesn't contradict what I wrote about adding env vars to fix a seed and optionally enable using a random seed, or adding collision counting as extra protection for cases that are not addressed by the hash seeding, such as e.g. collisions caused by 3rd types or numbers. We won't be back-porting anything more than the hash randomization for 2.6/2.7/3.1/3.2 but we are free to do more in 3.3 if someone can demonstrate it working well and a need for it. For me, things like collision counting and tree based collision buckets when the types are all the same and known comparable make sense but are really sounding like a lot of additional complexity. I'd *like* to see active black-box design attack code produced that goes after something like a wsgi web app written in Python with hash randomization *enabled* to demonstrate the need before we accept additional protections like this for 3.3+. I posted several examples for the integer collision attack on this ticket. The current randomization patch does not address this at all, the collision counting patch does, which is why I think both are needed. Note that my comment was more about the desire to *not* recommend using random hash seeds per default, but instead advocate using a random but fixed seed, or at least document that using random seeds that are set during interpreter startup will cause problems with repeatability of application runs. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Alex Gaynor alex.gay...@gmail.com added the comment: On Mon, Feb 6, 2012 at 4:41 PM, Marc-Andre Lemburg rep...@bugs.python.orgwrote: Marc-Andre Lemburg m...@egenix.com added the comment: Gregory P. Smith wrote: Gregory P. Smith g...@krypto.org added the comment: The release managers have pronounced: http://mail.python.org/pipermail/python-dev/2012-January/115892.html Quoting that email: 1. Simple hash randomization is the way to go. We think this has the best chance of actually fixing the problem while being fairly straightforward such that we're comfortable putting it in a stable release. 2. It will be off by default in stable releases and enabled by an envar at runtime. This will prevent code breakage from dictionary order changing as well as people depending on the hash stability. Right, but that doesn't contradict what I wrote about adding env vars to fix a seed and optionally enable using a random seed, or adding collision counting as extra protection for cases that are not addressed by the hash seeding, such as e.g. collisions caused by 3rd types or numbers. We won't be back-porting anything more than the hash randomization for 2.6/2.7/3.1/3.2 but we are free to do more in 3.3 if someone can demonstrate it working well and a need for it. For me, things like collision counting and tree based collision buckets when the types are all the same and known comparable make sense but are really sounding like a lot of additional complexity. I'd *like* to see active black-box design attack code produced that goes after something like a wsgi web app written in Python with hash randomization *enabled* to demonstrate the need before we accept additional protections like this for 3.3+. I posted several examples for the integer collision attack on this ticket. The current randomization patch does not address this at all, the collision counting patch does, which is why I think both are needed. Note that my comment was more about the desire to *not* recommend using random hash seeds per default, but instead advocate using a random but fixed seed, or at least document that using random seeds that are set during interpreter startup will cause problems with repeatability of application runs. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ Can't randomization just be applied to integers as well? Alex -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13957] parsedate_tz doesn't distinguish -0000 from +0000
R. David Murray rdmur...@bitdance.com added the comment: This is fixed already in 3.3. It is a behavior change that could theoretically cause some problems. Currently, you can think of None as meaning there was no timezone info at all, which is subtly different from -, which means this time is UTC, but I don't know what timezone it originated from. These two tend to be conflated in practice (how else are you going to interpret a time with no timezone attached?), and since we are making other additions to email in 3.3 we decided it was a small enough change that it was OK for a dot release. But not for a maintenance release, just in case. (I'm open to argument on that, but these backward compatibility calls are notoriously hard to make.) -- assignee: - r.david.murray nosy: +r.david.murray resolution: - out of date stage: - committed/rejected status: open - closed versions: +Python 3.3 -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13957 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4709] Mingw-w64 and python on windows x64
Ralf Schmitt python-b...@systemexit.de added the comment: There's no need to discuss or even run configure scripts. Martin, please reread the OPs original message. It's easy enough to reason about the issue instead of trying to reproduce it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4709 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Dave Malcolm dmalc...@redhat.com added the comment: Can't randomization just be applied to integers as well? It could, but see http://bugs.python.org/issue13703#msg151847 Would my patches be more or less likely to get reviewed with vs without an extension of randomization to integers? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2377] Replace __import__ w/ importlib.__import__
Brett Cannon br...@python.org added the comment: Thanks to Benjamin, the test_capi assert failure is fixed. At this point the only failures are listed in the FAILING file and are (probably) minor. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2377 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13878] test_sched failures on Windows buildbot
Charles-François Natali neolo...@free.fr added the comment:
Here's another failure due to the same type of race:
==
FAIL: test_queue (test.test_sched.TestCase)
--
Traceback (most recent call last):
File D:\Buildslave\3.x.moore-windows\build\lib\test\test_sched.py, line 74,
in test_queue
self.assertEqual(list(scheduler.queue), [e1, e2, e3, e4, e5])
AssertionError: Lists differ: [Event(time=1328544857.025, pr... !=
[Event(time=1328544857.025, pr...
First differing element 2:
Event(time=1328544857.055, priority=1, action=function
TestCase.test_queue.locals.lambda at 0x04C072D8, argument=[], kwargs={})
Event(time=1328544857.060, priority=1, action=function
TestCase.test_queue.locals.lambda at 0x04C072D8, argument=[], kwargs={})
Diff is 836 characters long. Set self.maxDiff to None to see it.
Here's a patch that:
- increases the timeouts for test_enter
- converts other tests to use enterabs() instead of enter()
It should fix all those failures.
--
components: +Tests
keywords: +needs review, patch
versions: +Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24439/test_sched_race.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13878
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Marc-Andre Lemburg m...@egenix.com added the comment: Alex Gaynor wrote: Can't randomization just be applied to integers as well? A simple seed xor'ed with the hash won't work, since the attacks I posted will continue to work (just colliding on a different hash value). Using a more elaborate hash algorithm would slow down uses of numbers as dictionary keys and also be difficult to implement for non-integer types such as float, longs and complex numbers. The reason is that Python applications expect x == y = hash(x) == hash(y), e.g. hash(3) == hash(3L) == hash(3.0) == hash(3+0j). AFAIK, the randomization patch also doesn't cover tuples, which are rather common as dictionary keys as well, nor any of the other more esoteric Python built-in hashable data types (e.g. frozenset) or hashable data types defined by 3rd party extensions or applications (simply because it can't). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2377] Replace __import__ w/ importlib.__import__
STINNER Victor victor.stin...@haypocalc.com added the comment: Is there a benchmark for import? How slow is importlib? :) -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2377 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Alex Gaynor alex.gay...@gmail.com added the comment: On Mon, Feb 6, 2012 at 5:04 PM, Marc-Andre Lemburg rep...@bugs.python.orgwrote: Marc-Andre Lemburg m...@egenix.com added the comment: Alex Gaynor wrote: Can't randomization just be applied to integers as well? A simple seed xor'ed with the hash won't work, since the attacks I posted will continue to work (just colliding on a different hash value). Using a more elaborate hash algorithm would slow down uses of numbers as dictionary keys and also be difficult to implement for non-integer types such as float, longs and complex numbers. The reason is that Python applications expect x == y = hash(x) == hash(y), e.g. hash(3) == hash(3L) == hash(3.0) == hash(3+0j). AFAIK, the randomization patch also doesn't cover tuples, which are rather common as dictionary keys as well, nor any of the other more esoteric Python built-in hashable data types (e.g. frozenset) or hashable data types defined by 3rd party extensions or applications (simply because it can't). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ There's no need to cover any container types, because if their constituent types are securely hashable then they will be as well. And of course if the constituent types are unsecure then they're directly vulnerable. Alex -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13928] bug in asyncore.dispatcher_with_send
Giampaolo Rodola' g.rod...@gmail.com added the comment: No problem. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13928 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13958] Comment _PyUnicode_FromId
Jim Jewett jimjjew...@gmail.com added the comment: On Mon, Feb 6, 2012 at 4:25 PM, Martin v. Löwis rep...@bugs.python.org wrote: Martin v. Löwis mar...@v.loewis.de added the comment: This has nothing to do with PEP 3131. Python could (and does) support non-ASCII identifiers just fine, regardless of C compiler limitations. I *think* you're saying that the _Py_Identifier( ) is a smaller set than identifiers in general. Would the following be more accurate? /* PEP3131 does allow non-ASCII identifiers in user code, but limits their use within the implementation itself. In particular, a _Py_Identifier may be passed directly to C code; such identifiers are restricted to ASCII to avoid breaking some supported C compilers. */ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13958 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13958] Comment _PyUnicode_FromId
Jim Jewett jimjjew...@gmail.com added the comment: And is there a way to characterize the compilers that would break? Is it a few specific compilers, or compilers that do not implement UTF8, which is not required by the C standard, or ... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13958 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13958] Comment _PyUnicode_FromId
STINNER Victor victor.stin...@haypocalc.com added the comment: Using _Py_static_string(), you can write literal UTF-8 strings using hexadecimal escape sequences. It works on any C compiler. E.g. _Py_static_string(ecute, \xc3\xa9). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13958 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13578] Add subprocess.iter_output() convenience function
Giampaolo Rodola' g.rod...@gmail.com added the comment: This biggest challenge I have noticed so far in exploring this is how to handle timeouts on Windows I haven't actually looked into it but this somewhat recalls: http://bugs.python.org/issue1191964 Since issue1191964 is supposed to provide async subprocess I/O I presume Windows timeouts are also involved somewhere in the provided patch/recipe. -- nosy: +giampaolo.rodola ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13578 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13882] PEP 410: Use decimal.Decimal type for timestamps
STINNER Victor victor.stin...@haypocalc.com added the comment: Hum, time_decimal-10.patch contains a debug message: +print(la) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13882 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13882] PEP 410: Use decimal.Decimal type for timestamps
STINNER Victor victor.stin...@haypocalc.com added the comment: -return posix_do_stat(self, args, O:stat, STAT, U:stat, win32_stat_w); +return posix_do_stat(self, args, kw, O|O:stat, STAT, U:stat, win32_stat_w); The second format string should also be updated to U|O:stat. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13882 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Marc-Andre Lemburg m...@egenix.com added the comment: Alex Gaynor wrote: There's no need to cover any container types, because if their constituent types are securely hashable then they will be as well. And of course if the constituent types are unsecure then they're directly vulnerable. I wouldn't necessarily take that for granted: since container types usually calculate their hash based on the hashes of their elements, it's possible that a clever combination of elements could lead to a neutralization of the the hash seed used by the elements, thereby reenabling the original attack on the unprotected interpreter. Still, because we have far more vulnerable hashable types out there, trying to find such an attack doesn't really make practical sense, so protecting containers is indeed not as urgent :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12659] Add tests for packaging.tests.support
Francisco Martín Brugué franci...@email.de added the comment: I've just updated “test_support.py” and tested against 'default' and 'distutils2' (after changing the imports). Just let me know what has to be changed ... BTW: in distutils2 I get (not because of this change): == FAIL: test_bad_urls (distutils2.tests.test_pypi_simple.SimpleCrawlerTestCase) -- Traceback (most recent call last): File /home/ci/prog/cpython/distutils2/distutils2/tests/pypi_server.py, line 68, in wrapped func(server=server, *args, **kwargs) File /home/ci/prog/cpython/distutils2/distutils2/tests/test_pypi_simple.py, line 93, in test_bad_urls self.assertIn(wanted, str(v)) AssertionError: 'nonnumeric port' not found in 'Download error for http://http://svn.pythonpaste.org/Paste/wphp/trunk: [Errno -2] Name or service not known' -- Cheers, francis -- Added file: http://bugs.python.org/file24440/test_support_v2.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12659 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13889] str(float) and round(float) issues with FPU precision
Samuel Iseli samuel.is...@gmail.com added the comment: Completed the patch by adding the rounding-control bits to the mask (_MCW_RC) and making sure the macros only get defined for MS-VC compiler (#ifdef _MSC_VER). Ran the tests (python_d -m test.autotest) on win32. Seems OK. The tests that were skipped or failed don't seem to be connected to this patch: - test_repr failed on trying to import a very long package and module name - test_popen failed with SyntaxError: unexpected EOF while parsing. Here's the summary: 323 tests OK. 2 tests failed: test_popen test_repr 2 tests altered the execution environment: test_distutils test_site 62 tests skipped: test_aepack test_al test_applesingle test_bsddb test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_commands test_crypt test_curses test_dbm test_dl test_epoll test_fcntl test_fork1 test_gdb test_gdbm test_gl test_grp test_imgfile test_ioctl test_kqueue test_largefile test_linuxaudiodev test_macos test_macostools test_mhlib test_nis test_openpty test_ossaudiodev test_pipes test_poll test_posix test_pty test_pwd test_py3kwarn test_readline test_resource test_scriptpackages test_smtpnet test_socketserver test_sqlite test_ssl test_sunaudiodev test_tcl test_threadsignals test_timeout test_tk test_ttk_guionly test_ttk_textonly test_urllib2net test_urllibnet test_wait3 test_wait4 test_zipfile64 10 skips unexpected on win32: test_bsddb test_bz2 test_gdb test_readline test_sqlite test_ssl test_tcl test_tk test_ttk_guionly test_ttk_textonly [43048 refs] -- Added file: http://bugs.python.org/file24441/120206_set_53bit_precision.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13889 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13953] test_packaging: unused test?
Changes by Francisco Martín Brugué franci...@email.de: -- nosy: +francismb ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13953 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13959] Re-implement parts of imp in pure Python
New submission from Brett Cannon br...@python.org: A bunch of code in Python/import.c exists purely for the imp module, but a large chunk of it does not need to be implemented in C but instead can be implemented in Python code. Once importlib is bootstrapped in then an attempt to scale back the C code should be done by re-implementing parts of imp in pure Python (either in some _imp module or directly in _importlib itself). -- components: Library (Lib) messages: 152800 nosy: brett.cannon priority: normal severity: normal status: open title: Re-implement parts of imp in pure Python versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13959] Re-implement parts of imp in pure Python
Changes by Brett Cannon br...@python.org: -- dependencies: +Replace __import__ w/ importlib.__import__ ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12970] os.walk() consider some symlinks as dirs instead of non-dirs
Changes by Sung-Yu Chen eeso...@gmail.com: -- nosy: +Sung-Yu.Chen ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12970 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13370] test_ctypes fails when building python with clang
Meador Inge mead...@gmail.com added the comment: It turns out that this isn't OS X specific. I can reproduce the exact same issue by building with clang on a 64-bit Fedora 16 box. -- components: -Macintosh title: test_ctypes fails on osx 10.7 - test_ctypes fails when building python with clang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13370 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13742] Add a key parameter (like sorted) to heapq.merge
Raymond Hettinger raymond.hettin...@gmail.com added the comment: I'll look at this in the next couple of weeks. Hang tight :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13742 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13590] extension module builds fail with python.org OS X installers on OS X 10.7 and 10.6 with Xcode 4.2
Ned Deily n...@acm.org added the comment: When building and installing C extension modules, distutils attempts to use the same compiler and some compiler options as Python itself was built with. For the current (3.2.2 and 2.7.2) 64-bit/32-bit python installers, the standard Apple-supplied gcc-4.2 in Xcode 3.2.x on OS X 10.6 was used. As of Xcode 4.2, now standard for OS X 10.7 and optional for OS X 10.6, Apple no longer ships gcc-4.2 in Xcode, in favor of clang and the transitional llvm-gcc. Moving the entire Python build to another compiler is a major undertaking, requiring careful testing, which is underway. A compiler change may well be deemed too risky for a bug-fix release. In any case, we can no longer assume that the same build compiler will be available on most user systems. While it is possible for the user to manually override the distutils defaults by setting the CC and LDSHARED environment variables properly, setting the latter is tedious. For example, to manually override to clang, the following is currently needed: CC=clang LDSHARED='clang -bundle -undefined dynamic_lookup \ -arch i386 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk -g' python setup.py ... Attached is a patch that attempts to do the right thing for OS X. First, if the default build compiler is gcc-4.2 and the compiler has not been explicitly overridden by defining CC, distutils will check for the presence of gcc-4.2 on the default path. If gcc-4.2 is not found and if clang is found, it will automatically substitute clang as the build compiler. Second, if CC is used to override the compiler selection but LDSHARED is not defined, distutils will substitute the CC value into the default LDSHARED value. This allows simple one-line compiler overrides, like: CC=llvm-gcc python setup.py ... To minimize the risk of unintended side effects, these changes would apply to OS X only. I propose applying this patch to 3.2 (for 3.2.3) and 2.7 (for 2.7.3) as well as provisionally to default for 3.3; a second patch will be needed with similar changes to packaging. After the evaluation of compiler alternatives is complete and we decide what to do for 3.3, this approach might change. -- keywords: +patch stage: - patch review Added file: http://bugs.python.org/file24442/issue13590_distutils.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13590 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13370] test_ctypes fails when building python with clang
Ned Deily n...@acm.org added the comment: Thanks for the analysis, Meador. So perhaps as a temporary workaround, we could tweak setup.py to set -O0 for building ctypes with clang? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13370 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
