[issue29424] Multiple vulnerabilities in BaseHTTPRequestHandler enable HTTP response splitting attacks
Changes by Benjamin Gilbert <bgilb...@backtick.net>: -- nosy: +bgilbert ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects
Benjamin Gilbert added the comment: Is there any reason an import library generated by a particular MinGW version shouldn't be usable by any other MinGW version? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24385 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects
Benjamin Gilbert added the comment: Zachary: gendef is an auxiliary tool; I'm not sure a basic installation of MinGW-w64 will have it. However, I've checked Cygwin and Fedora (my two points of reference) and a gendef package is available in both. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24385 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects
Changes by Benjamin Gilbert bgilb...@backtick.net: -- nosy: +bgilbert ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24385 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21866] zipfile.ZipFile.close() doesn't respect allowZip64
Benjamin Gilbert added the comment: Here are the cases where close() will generate a ZIP64 archive and an exception will never be raised: 1. There are more than 65535 files in the archive. 2. The start of the central directory is at 2 GB. 3. The central directory size is 2 GB. #1 could be checked from write/writestr. #2 could possibly be checked from write/writestr by looking at the file offset after writing the compressed data. #3 cannot be checked until close, but I'm not sure if it can ever occur without triggering one of the other checks first. -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21866 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21866] zipfile.ZipFile.close() doesn't respect allowZip64
New submission from Benjamin Gilbert: The ZipFile documentation says: If allowZip64 is True (the default) zipfile will create ZIP files that use the ZIP64 extensions when the zipfile is larger than 2 GiB. If it is false zipfile will raise an exception when the ZIP file would require ZIP64 extensions. ZipFile.close() will write ZIP64 central directory records if e.g. a member's local file header starts at an offset 2 GB, or if there are more than 65535 files in the archive. It will do this even if allowZip64 is False, whereas the documentation implies that it should raise an exception in that case. -- components: Library (Lib) messages: 221525 nosy: bgilbert priority: normal severity: normal status: open title: zipfile.ZipFile.close() doesn't respect allowZip64 type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21866 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13215] multiprocessing Manager.connect() aggressively retries refused connections
New submission from Benjamin Gilbert bgilb...@backtick.net: multiprocessing.managers.BaseManager.connect() takes 20 seconds to return on failure, even if the server refuses the connection. This is because the function that creates the connection, multiprocessing.connection.SocketClient(), handles ECONNREFUSED by retrying the connection attempt every 10 ms for 20 seconds. While a 20 second timeout may make sense for *unresponsive* servers, ECONNREFUSED probably indicates that the server is not listening on this port, so hammering it with 1,999 more connection attempts isn't going to help. In this case, SocketClient() should fail immediately, or -- at most -- retry a small number of times with exponential backoff. -- components: Library (Lib) messages: 145857 nosy: bgilbert priority: normal severity: normal status: open title: multiprocessing Manager.connect() aggressively retries refused connections type: behavior versions: Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13215 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12836] cast() creates circular reference in original object
New submission from Benjamin Gilbert bgilb...@backtick.net:
Section 15.17.1.15 of the ctypes documentation illustrates the use of cast()
thusly:
a = (c_byte * 4)()
cast(a, POINTER(c_int))
ctypes.LP_c_long object at ...
Executing the cast() causes a._objects to gain a reference back to a:
a = (c_byte * 4)()
a._objects
cast(a, POINTER(c_int))
__main__.LP_c_int object at 0x7fb879065b90
a._objects
{140430281170384: __main__.c_byte_Array_4 object at 0x7fb879065dd0}
a
__main__.c_byte_Array_4 object at 0x7fb879065dd0
If large temporary arrays are allocated, cast, used, and discarded in a tight
inner loop, a lot of memory can thus be consumed by self-referencing objects
before the garbage collector has a chance to run. Even if this behavior is
correct from the perspective of ctypes, it is surprising.
--
components: ctypes
messages: 142933
nosy: bgilbert
priority: normal
severity: normal
status: open
title: cast() creates circular reference in original object
type: resource usage
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12836
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
