[ python-Bugs-1295179 ] termios.c in qnx4.25
Bugs item #1295179, was opened at 2005-09-19 09:28 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295179&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Platform-specific >Status: Open Resolution: None Priority: 5 Submitted By: kbob_ru (kbob_ru) Assigned to: Nobody/Anonymous (nobody) Summary: termios.c in qnx4.25 Initial Comment: I compile python version 2.3.5 in QNX4.25. But I found that #include don't work because in qnx4 we need to include first in which #include already present. Second, Module/termios.c needs flag IXANY, that not defined in qnx4 headers. Include right header and write #ifdef IXANY \ #endif around helps to compile Module/termios.c. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-06 07:01 Message: Logged In: YES user_id=849994 Okay, reopening. -- Comment By: kbob_ru (kbob_ru) Date: 2006-08-05 15:56 Message: Logged In: YES user_id=1347065 Now I have patch for Python-2.5b3 -- Comment By: SourceForge Robot (sf-robot) Date: 2006-07-18 02:21 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Georg Brandl (gbrandl) Date: 2006-07-03 13:40 Message: Logged In: YES user_id=849994 Can you test this with Python 2.5b1? -- Comment By: kbob_ru (kbob_ru) Date: 2006-06-03 05:03 Message: Logged In: YES user_id=1347065 I used next patch for Python versions 2.3.5 and 2.4.3. It helps work properly termios module in QNX4.25 and termios test pass. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295179&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1535182 ] typo in test_bz2.py
Bugs item #1535182, was opened at 2006-08-05 22:22 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1535182&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Not a Bug >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Lawrence Oluyede (rhymes) Assigned to: Nobody/Anonymous (nobody) Summary: typo in test_bz2.py Initial Comment: I've found a test passing but someone missed an 'x' at the end of the test. It's "xlines" not "lines" again because you're testing the xreadlines() method. I've attached the svn diff. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-06 07:08 Message: Logged In: YES user_id=849994 Thanks, fixed in rev. 51126, 51127. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1535182&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1522046 ] RPM build fails for Py2.5b2
Bugs item #1522046, was opened at 2006-07-13 21:55
Message generated for change (Comment added) made by scoder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522046&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Behnel (scoder)
Assigned to: Nobody/Anonymous (nobody)
Summary: RPM build fails for Py2.5b2
Initial Comment:
Using Misc/RPM/python-2.5.spec, Python 2.5b2 fails to
compile into an RPM on my machine (SuSE 10.1, AMD64,
gcc 4.1). Unlike with b1, I get loads of errors saying:
"ld: cannot find -lpython2.5"
The funny thing is that it continues to build and only
fails at the end when collecting the files for the RPM.
I use
configure --enable-shared --enable-unicode=ucs4 \
--enable-ipv6 --with-pymalloc --prefix=/usr \
--libdir=/usr/lib64
The shared library is correctly built before these
errors come up. The error appear on the "sharedmods"
target. I also tried setting LD_LIBRARY_PATH by hand,
although the build script sets it before starting to
build the modules - no help.
What *does* help is adding "-L." to the LDFLAGS in
Makefile.pre.in:
sed -e '/DIR=.*lib$/ s|/lib$|/%{libdirname}| ; \
/LDFLAGS/ s|LDFLAGS=|LDFLAGS= -L. |'\
./Makefile.pre.in.old >Makefile.pre.in
The "DIR=" is for an x86_64 bug that installs Python to
the wrong directory (/usr/lib instead of /usr/lib64).
I tried building Py2.5 by hand (configure/make) and
that also works nicely.
I attached a patch that fixes the problems I encountered.
--
>Comment By: Stefan Behnel (scoder)
Date: 2006-08-06 09:10
Message:
Logged In: YES
user_id=313935
The linking is fixed in 2.5b3. However, the /usr/lib64
problem remains. Python is installed to lib64 on my AMD64
machine, but the import mechanism keeps looking in /usr/lib.
--
Comment By: Eric Wald (breadman)
Date: 2006-08-04 22:22
Message:
Logged In: YES
user_id=324500
Seems to be fixed in 2.5b3.
--
Comment By: Eric Wald (breadman)
Date: 2006-08-03 22:12
Message:
Logged In: YES
user_id=324500
There is a deeper issue here: Dynamic extensions fail to
link until after libpython2.5.so.1.0 is installed. The
'-L.' flag is the better approach to fixing this bug, but
perhaps it should use the full path name, like the
LD_LIBRARY_PATH environment variable used when running
setup.py. Unfortunately, this bug is hidden from people
compiling on top of an earlier 2.5 installation, where the
link step will find and use the old library; for others, it
is resolved in installation, where make will happily link
the extensions if they failed to link earlier, right after
installing the library.
However, it means that the dynamic libraries are unavailable
between the build and install steps. One major result is
that the test suite refuses to run at that time. It also
means that 'make install' can cause the linker to be called,
which is generally discouraged.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522046&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1535081 ] can't staticaly build modules md5 and sha
Bugs item #1535081, was opened at 2006-08-05 16:01 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1535081&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: kbob_ru (kbob_ru) Assigned to: Nobody/Anonymous (nobody) Summary: can't staticaly build modules md5 and sha Initial Comment: When build Python-2.5b3 I find that function initsha(void) in shamodule.c in Python-2.4.3 renamed to init_sha(void) in Python-2.5b3 but in Setup I just find old rule for static building sha module. This looks like sha shamodule.c Same thing with md5 module too. init_md5(void) in Python-2.5b3 but initmd5(void) in Python-2.4.3. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-06 07:26 Message: Logged In: YES user_id=849994 Fixed in rev. 51128. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1535081&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1535165 ] python segfaults when reading from closed stdin
Bugs item #1535165, was opened at 2006-08-05 20:47 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1535165&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Patrick Mezard (trickos) Assigned to: Nobody/Anonymous (nobody) Summary: python segfaults when reading from closed stdin Initial Comment: Python 2.5b3 (r25b3:51041, Aug 3 2006, 09:35:06) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.stdin.close() >>> raw_input() """ segfaults on Windows XP. Same thing happen with Python 2.4.2 (Build 248). -- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-06 08:24 Message: Logged In: YES user_id=849994 Thanks for the report, fixed raw_input() and input() in rev. 51129, 51130 (2.4). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1535165&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1535502 ] Python 2.5 windows builds should link hashlib with OpenSSL
Bugs item #1535502, was opened at 2006-08-06 12:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1535502&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Gregory P. Smith (greg) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.5 windows builds should link hashlib with OpenSSL Initial Comment: The Windows builds of Python 2.5 need to be updated to build and link the hashlib modules with OpenSSL 0.9.8. The OpenSSL implementations of the hash algorithms are *much* faster (often 2-3x) than the fallback C implementations that python includes for use when OpenSSL isn't available. I just tested the python 2.5b3 installer on windows. its using the fallback versions rather than OpenSSL: here's a simple way to check from a running python: Without OpenSSL: >>> import hashlib >>> hashlib.sha1 With OpenSSL: >>> import hashlib >>> hashlib.sha1 (please use openssl 0.9.8; older versions don't include sha256 and sha512 implementations) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1535502&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1526834 ] unbalanced parentheses from command line crash pdb
Bugs item #1526834, was opened at 2006-07-21 21:03 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526834&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: A.M. Kuchling (akuchling) Summary: unbalanced parentheses from command line crash pdb Initial Comment: bagira:~/python-svn/patches> cat simple print 123 bagira:~/python-svn/patches> ../python/trunk/python -m pdb simple (Pdb) b f( #crashes your program Traceback (most recent call last): ... File "/home/ilya/python-svn/python/trunk/Lib/sre.py", line 233, in _compile raise error, v # invalid expression error: unbalanced parenthesis Uncaught exception. Entering post mortem debugging (Pdb) b f( # doing it post-mortem fully crashes pdb Traceback (most recent call last): .. raise error, v # invalid expression sre_constants.error: unbalanced parenthesis bagira:~/python-svn/patches> -- >Comment By: Ilya Sandler (isandler) Date: 2006-08-06 12:41 Message: Logged In: YES user_id=971153 I don't think supporting "b f()" is needed... And as a catch-all argument, gdb does not support "b f()" either -- Comment By: A.M. Kuchling (akuchling) Date: 2006-07-27 05:38 Message: Logged In: YES user_id=11375 Easily fixed by adding a re.escape() call, but this means that 'b f()', if you've been doing that, will no longer work to set a breakpoint. The documentation doesn't claim that 'b f()' should work, but people may be used to typing this. I've asked the 2.5 release manager about this issue. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526834&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1436206 ] CGIHTTPServer doesn't handle path names with embeded space
Bugs item #1436206, was opened at 2006-02-21 22:56 Message generated for change (Comment added) made by htgoebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436206&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Richard Coupland (rick-eci) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer doesn't handle path names with embeded space Initial Comment: On Windows, if the path name of a CGI script to be run contains one or more space characters, the path name is split into multiple parameters causing an error. I have not tried not tried this on other platforms. -- Comment By: Hartmut Goebel (htgoebel) Date: 2006-08-06 21:45 Message: Logged In: YES user_id=376953 I just submitted a patch for this. see patch #1535504. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436206&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1464056 ] curses library in python 2.4.3 broken
Bugs item #1464056, was opened at 2006-04-04 04:47 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: Accepted Priority: 9 Submitted By: nomind (vnainar) Assigned to: A.M. Kuchling (akuchling) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-08-06 18:12 Message: Logged In: YES user_id=11375 Committed to the trunk in rev. 51134. -- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 08:53 Message: Logged In: YES user_id=11375 Sure. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-03 02:03 Message: Logged In: YES user_id=33168 Andrew, could you apply this after the freeze is over? -- Comment By: Paul Smedley (psmedley) Date: 2006-05-21 10:38 Message: Logged In: YES user_id=1359962 I have a similar problem on OS/2. When running any script that uses curses I get: [U:\dev\Python-2.4.3\PC\os2emx]python test_curses.py Traceback (most recent call last): File "test_curses.py", line 242, in ? curses.wrapper(main) File "U:/DEV/PYTHON-2.4.3/Lib/curses/wrapper.py", line 49, in wrapper curses.nocbreak() _curses.error: nocbreak() returned ERR If I remove the reference to nocbreak() from wrapper.py, I get the same error but in endwin(), removing endwin() from wrapper.py, I get an error in cbreak(), removing cbreak() then some scripts work. For example, from the demo folder, all work exceptlife.py & xmas.py, which both return an error "_curses.error: nocbreak() returned ERR" on various line numbers. Seems certain curses functions are working correctly, others aren't. The patch in this bug does NOT make any difference here. -- Comment By: Jan Palus (atler_) Date: 2006-04-17 14:50 Message: Logged In: YES user_id=1497957 /me confirms -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-15 11:30 Message: Logged In: YES user_id=21627 Good spotting! Can everybody please confirm that the attached patch fixes the problem? -- Comment By: Jan Palus (atler_) Date: 2006-04-15 10:48 Message: Logged In: YES user_id=1497957 Half day of debugging and it seems that I found an answer... just by accident ;). When curses module is linked against ncursesw it seems that it also should be linked against panelw not plain panel. After changing this in setup.py, ncurses.py demo finally runs fine. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-15 03:05 Message: Logged In: YES user_id=21627 I couldn't reproduce the problem on a Linux console (although my console had a different size); so it remains unreproducable for me. -- Comment By: nomind (vnainar) Date: 2006-04-13 07:00 Message: Logged In: YES user_id=1493752 Well , it is the linux console (in VGA mode ). The local is en_US.The size of the console is 100X37. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-11 01:32 Message: Logged In: YES user_id=21627 Ah, ok. vnainar, atler_: What terminal had you been using to make it crash? What is your locale? Any other conditions that might be relevant (e.g. dimension of the terminal)? -- Comment By: nomind (vnainar) Date: 2006-04-11 01:13 Message: Logged In: YES user_id=1493752 Removing 'ncursesw' (there are two references to it in 'setup.py') seems to solve the problem. I noticed one more oddity. Even before the above recompilation , it ran fine on an Xterm ! -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-10 18:28 Message: Logged In: YES user_id=21627 That's hard to tell. Somebody would have to debug ncurses to find out why it crashes. Notice that it crashes only on some installations, so it is likely rather a problem
[ python-Bugs-1464056 ] curses library in python 2.4.3 broken
Bugs item #1464056, was opened at 2006-04-04 04:47 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed Resolution: Accepted Priority: 9 Submitted By: nomind (vnainar) Assigned to: A.M. Kuchling (akuchling) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-08-06 20:39 Message: Logged In: YES user_id=11375 Committed to 2.4 branch in rev.51136. -- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-06 18:12 Message: Logged In: YES user_id=11375 Committed to the trunk in rev. 51134. -- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 08:53 Message: Logged In: YES user_id=11375 Sure. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-03 02:03 Message: Logged In: YES user_id=33168 Andrew, could you apply this after the freeze is over? -- Comment By: Paul Smedley (psmedley) Date: 2006-05-21 10:38 Message: Logged In: YES user_id=1359962 I have a similar problem on OS/2. When running any script that uses curses I get: [U:\dev\Python-2.4.3\PC\os2emx]python test_curses.py Traceback (most recent call last): File "test_curses.py", line 242, in ? curses.wrapper(main) File "U:/DEV/PYTHON-2.4.3/Lib/curses/wrapper.py", line 49, in wrapper curses.nocbreak() _curses.error: nocbreak() returned ERR If I remove the reference to nocbreak() from wrapper.py, I get the same error but in endwin(), removing endwin() from wrapper.py, I get an error in cbreak(), removing cbreak() then some scripts work. For example, from the demo folder, all work exceptlife.py & xmas.py, which both return an error "_curses.error: nocbreak() returned ERR" on various line numbers. Seems certain curses functions are working correctly, others aren't. The patch in this bug does NOT make any difference here. -- Comment By: Jan Palus (atler_) Date: 2006-04-17 14:50 Message: Logged In: YES user_id=1497957 /me confirms -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-15 11:30 Message: Logged In: YES user_id=21627 Good spotting! Can everybody please confirm that the attached patch fixes the problem? -- Comment By: Jan Palus (atler_) Date: 2006-04-15 10:48 Message: Logged In: YES user_id=1497957 Half day of debugging and it seems that I found an answer... just by accident ;). When curses module is linked against ncursesw it seems that it also should be linked against panelw not plain panel. After changing this in setup.py, ncurses.py demo finally runs fine. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-15 03:05 Message: Logged In: YES user_id=21627 I couldn't reproduce the problem on a Linux console (although my console had a different size); so it remains unreproducable for me. -- Comment By: nomind (vnainar) Date: 2006-04-13 07:00 Message: Logged In: YES user_id=1493752 Well , it is the linux console (in VGA mode ). The local is en_US.The size of the console is 100X37. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-11 01:32 Message: Logged In: YES user_id=21627 Ah, ok. vnainar, atler_: What terminal had you been using to make it crash? What is your locale? Any other conditions that might be relevant (e.g. dimension of the terminal)? -- Comment By: nomind (vnainar) Date: 2006-04-11 01:13 Message: Logged In: YES user_id=1493752 Removing 'ncursesw' (there are two references to it in 'setup.py') seems to solve the problem. I noticed one more oddity. Even before the above recompilation , it ran fine on an Xterm ! -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-10
[ python-Bugs-1112549 ] cgi.FieldStorage memory usage can spike in line-oriented ops
Bugs item #1112549, was opened at 2005-01-30 05:40
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 8
Submitted By: Chris McDonough (chrism)
Assigned to: Nobody/Anonymous (nobody)
Summary: cgi.FieldStorage memory usage can spike in line-oriented ops
Initial Comment:
Various parts of cgi.FieldStorage call its
"read_lines_to_outerboundary", "read_lines" and
"skip_lines" methods.These methods use the
"readline" method of the file object that represents an
input stream. The input stream is typically data
supplied by an untrusted source (such as a user
uploading a file from a web browser). The input data
is not required by the RFC 822/1521/1522/1867
specifications to contain any newline characters. For
example, it is within the bounds of the specification
to supply a a multipart/form-data input stream with a
"file-data" part that consists of a 2GB string composed
entirely of "x" characters (which happens to be
something I did that led me to noticing this bug).
The simplest fix is to make use of the "size" argument
of the readline method of the file object where it is
used within all parts of FieldStorage that make use of
it. A patch against the Python 2.3.4 cgi.py module
that does this is attached.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-08-06 22:50
Message:
Logged In: YES
user_id=33168
Doesn't this require a change to test/output/test_cgi or
something like that? Does this test pass when run under
regrtest.py ?
The verify(x == y) should be vereq(x, y).
type(a) != type(0), should be not isinstance(a, int).
The last chunk of the patch in cgi.py should be:
last_line_lfend = line.endswith('\n')
rather than the 4 lines of if/else.
I don't know if this patch really addresses the problem or
creates other problems. However, if someone more
knowledgable is confident about this patch, I'm fine with
this going in. At this point, it might be better to wait
for 2.5.1 though.
--
Comment By: Chris McDonough (chrism)
Date: 2006-07-27 14:42
Message:
Logged In: YES
user_id=32974
The files I've just uploaded are revisions to the cgi and test_cgi modules for
the
current state of the SVN trunk. If someone could apply these, it would be
appreciated, or give me access and I'll be happy to.
FTR, this is a bug which exposes systems which use the cgi.FieldStorage class
(most Python web frameworks do) to a denial of service potential.
--
Comment By: Chris McDonough (chrism)
Date: 2005-04-02 20:00
Message:
Logged In: YES
user_id=32974
FYI, I'd be happy to do the merging here if you wanted to
give me checkin access.
--
Comment By: Chris McDonough (chrism)
Date: 2005-04-02 19:42
Message:
Logged In: YES
user_id=32974
An updated test_cgi.py is attached. I test both the
readline behavior and add a test for basic multipart parsing.
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2005-03-31 20:48
Message:
Logged In: YES
user_id=6380
Can I tweak you into uploading a unit test?
--
Comment By: Chris McDonough (chrism)
Date: 2005-03-31 18:56
Message:
Logged In: YES
user_id=32974
Re: parse_multipart.. yes, it looks like there's no use
fixing that as it just turns around and puts the line into a
list.. it is vulnerable but just by virtue of its non-use of
a tempfile, it appears doomed anyway for large requests. I
don't know of anything that uses it.
Good catch wrt boundary recognition bug, I'm uploading
another patch.
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2005-03-31 14:13
Message:
Logged In: YES
user_id=6380
Methinks that the fix isn't quite right: it would
incorrectly recognize as a boundary a very long line
starting with "--" followed by the appropriate random string
at offset 2**16. This could probably be taken care of by
adding a flag that is true initially and after that keeps
track of whether the previous line ended in \n.
Also, there's a call to fp.readline() in parse_multipart()
that you didn't patch -- it wouldn't help because that code
is saving the lines in a list anyway, but isn't that code
vulnerable as well? Or is it not used?
--
You can re
