Mailman 3 May 2004 - Python-checkins

pydotorg-redesign-request@python.org: your academic qualification expired
by Tonia Connolly May 28, 2004

May 28, 2004

1 0

python/nondist/peps pep-0330.txt, NONE, 1.1 pep-0000.txt, 1.272, 1.273
by goodger＠users.sourceforge.net May 28, 2004

May 28, 2004

Update of /cvsroot/python/python/nondist/peps In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4467 Modified Files: pep-0000.txt Added Files: pep-0330.txt Log Message: added PEP 330, Python Bytecode Verification, by Michel Pelletier --- NEW FILE: pep-0330.txt --- PEP: 330 Title: Python Bytecode Verification Version: $Revision: 1.1 $ Last-Modified: $Date: 2004/05/28 01:45:34 $ Author: Michel Pelletier <michel(a)users.sourceforge.net> Status: Draft Type: Standards Track Content-Type: text/plain Created: 17-Jun-2004 Python-Version: 2.6? Post-History: Abstract If Python Virtual Machine (PVM) bytecode is not "well-formed" it is possible to crash or exploit the PVM by causing various errors such as under/overflowing the value stack or reading/writing into arbitrary areas of the PVM program space. Most of these kinds of errors can be eliminated by verifying that PVM bytecode does not violate a set of simple constraints before execution. This PEP proposes a set of constraints on the format and structure of Python Virtual Machine (PVM) bytecode and provides an implementation in Python of this verification process. Motivation The Python Virtual Machine executes Python programs that have been compiled from the Python language into a bytecode representation. The PVM assumes that any bytecode being executed is "well-formed" with regard to a number implicit constraints. Some of these constraints are checked at run-time, but most of them are not due to the overhead they would create. When running in debug mode the PVM does do several run-time checks to ensure that any particular bytecode cannot violate these constraints that, to a degree, prevent bytecode from crashing or exploiting the interpreter. These checks add a measurable overhead to the interpreter, and are typically turned off in common use. Bytecode that is not well-formed and executed by a PVM not running in debug mode may create a variety of fatal and non-fatal errors. Typically, ill-formed code will cause the PVM to seg-fault and cause the OS to immediately and abruptly terminate the interpreter. Conceivably, ill-formed bytecode could exploit the interpreter and allow Python bytecode to execute arbitrary C-level machine instructions or to modify private, internal data structures in the interpreter. If used cleverly this could subvert any form of security policy an application may want to apply to it's objects. Practically, it would be difficult for a malicious user to "inject" invalid bytecode into a PVM for the purposes of exploitation, but not impossible. Buffer overflow and memory overwrite attacks are commonly understood, particularly when the exploit payload is transmitted unencrypted over a network or when a file or network security permission weakness is used as a foothold for further attacks. Ideally, no bytecode should ever be allowed to read or write underlying C-level data structures to subvert the operation of the PVM, whether the bytecode was maliciously crafted or not. A simple pre-execution verification step could ensure that bytecode cannot over/underflow the value stack or access other sensitive areas of PVM program space at run-time. This PEP proposes several validation steps that should be taken on Python bytecode before it is executed by the PVM so that it compiles with static and structure constraints on its instructions and their operands. These steps are simple and catch a large class of invalid bytecode that can cause crashes. There is also some possibility that some run-time checks can be eliminated up front by a verification pass. There is, of course, no way to verify that bytecode is "completely safe", for every definition of complete and safe. Even with bytecode verification, Python programs can and most likely in the future will seg-fault for a variety of reasons and continue to cause many different classes of run-time errors, fatal or not. The verification step proposed here simply plugs an easy hole that can cause a large class of fatal and subtle errors at the bytecode level. Currently, the Java Virtual Machine (JVM) verifies Java bytecode in a way very similar to what is proposed here. The JVM Specification version 2 [1], Sections 4.8 and 4.9 were therefore used as a basis for some of the constraints explained below. Any Python bytecode verification implementation at a minimum must enforce these constraints, but may not be limited to them. Static Constraints on Bytecode Instructions 1. The bytecode string must not be empty. (len(co_code) > 0). 2. The bytecode string cannot exceed a maximum size (len(co_code) < sizeof(unsigned char) - 1). 3. The first instruction in the bytecode string begins at index 0. 4. Only valid byte-codes with the correct number of operands can be in the bytecode string. Static Constraints on Bytecode Instruction Operands 1. The target of a jump instruction must be within the code boundaries and must fall on an instruction, never between an instruction and its operands. 2. The operand of a LOAD_* instruction must be an valid index into its corresponding data structure. 3. The operand of a STORE_* instruction must be an valid index into its corresponding data structure. Structural Constraints between Bytecode Instructions 1. Each instruction must only be executed with the appropriate number of arguments in the value stack, regardless of the execution path that leads to its invocation. 2. If an instruction can be executed along several different execution paths, the value stack must have the same depth prior to the execution of the instruction, regardless of the path taken. 3. At no point during execution can the value stack grow to a depth greater than that implied by co_stacksize. 4. Execution never falls off the bottom of co_code. Implementation This PEP is the working document for an Python bytecode verification implementation written in Python. This implementation is not used implicitly by the PVM before executing any bytecode, but is to be used explicitly by users concerned about possibly invalid bytecode with the following snippet: import verify verify.verify(object) The `verify` module provides a `verify` function which accepts the same kind of arguments as `dis.dis`: classes, methods, functions, or code objects. It verifies that the object's bytecode is well-formed according to the specifications of this PEP. If the code is well-formed the call to `verify` returns silently without error. If an error is encountered, it throws a 'VerificationError' whose argument indicates the cause of the failure. It is up to the programmer whether or not to handle the error in some way or execute the invalid code regardless. Phillip Eby has proposed a pseudo-code algorithm for bytecode stack depth verification used by the reference implementation. Verification Issues This PEP describes only a small number of verifications. While discussion and analysis will lead to many more, it is highly possible that future verification may need to be done or custom, project-specific verifications. For this reason, it might be desirable to add a verification registration interface to the test implementation to register future verifiers. The need for this is minimal since custom verifiers can subclass and extend the current implementation for added behavior. Required Changes Armin Rigo noted that several byte-codes will need modification in order for their stack effect to be statically analyzed. These are END_FINALLY, POP_BLOCK, and MAKE_CLOSURE. Armin and Guido have already agreed on how to correct the instructions. Currently the Python implementation punts on these instructions. This PEP does not propose to add the verification step to the interpreter, but only to provide the Python implementation in the standard library for optional use. Whether or not this verification procedure is translated into C, included with the PVM or enforced in any way is left for future discussion. References [1] The Java Virtual Machine Specification 2nd Edition http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 End: Index: pep-0000.txt =================================================================== RCS file: /cvsroot/python/python/nondist/peps/pep-0000.txt,v retrieving revision 1.272 retrieving revision 1.273 diff -C2 -d -r1.272 -r1.273 *** pep-0000.txt 19 May 2004 21:18:54 -0000 1.272 --- pep-0000.txt 28 May 2004 01:45:32 -0000 1.273 *************** *** 123,126 **** --- 123,127 ---- S 325 Resource-Release Support for Generators Pedroni S 327 Decimal Data Type Batista + S 330 Python Bytecode Verification Pelletier S 754 IEEE 754 Floating Point Special Values Warnes *************** *** 352,355 **** --- 353,357 ---- SA 328 Imports: Multi-Line and Absolute/Relative Aahz SR 329 Treating Builtins as Constants in the Standard Library Hettinger + S 330 Python Bytecode Verification Pelletier SR 666 Reject Foolish Indentation Creighton S 754 IEEE 754 Floating Point Special Values Warnes

1 0

python/dist/src/Lib weakref.py,1.21,1.22
by doerwalter＠users.sourceforge.net May 27, 2004

May 27, 2004

Update of /cvsroot/python/python/dist/src/Lib In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21761/Lib Modified Files: weakref.py Log Message: The default argument in dict.setdefault() defaults to None. Add this default to weakref.WeakValueDictionary.setdefault() and weakref.WeakKeyDictionary.setdefault() too. Index: weakref.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/weakref.py,v retrieving revision 1.21 retrieving revision 1.22 diff -C2 -d -r1.21 -r1.22 *** weakref.py 4 Mar 2004 08:25:44 -0000 1.21 --- weakref.py 27 May 2004 18:16:25 -0000 1.22 *************** *** 114,118 **** return o ! def setdefault(self, key, default): try: wr = self.data[key] --- 114,118 ---- return o ! def setdefault(self, key, default=None): try: wr = self.data[key] *************** *** 242,246 **** return self.data.pop(ref(key), *args) ! def setdefault(self, key, default): return self.data.setdefault(ref(key, self._remove),default) --- 242,246 ---- return self.data.pop(ref(key), *args) ! def setdefault(self, key, default=None): return self.data.setdefault(ref(key, self._remove),default)

1 0

python/dist/src/Lib UserDict.py,1.27,1.28
by doerwalter＠users.sourceforge.net May 27, 2004

May 27, 2004

Update of /cvsroot/python/python/dist/src/Lib In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21578/Lib Modified Files: UserDict.py Log Message: The default argument in dict.setdefault() defaults to None. Add this default to UserDict.DictMixin.setdefault() too. Index: UserDict.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/UserDict.py,v retrieving revision 1.27 retrieving revision 1.28 diff -C2 -d -r1.27 -r1.28 *** UserDict.py 4 Mar 2004 08:25:44 -0000 1.27 --- UserDict.py 27 May 2004 09:41:04 -0000 1.28 *************** *** 114,118 **** for key in self.keys(): del self[key] ! def setdefault(self, key, default): try: return self[key] --- 114,118 ---- for key in self.keys(): del self[key] ! def setdefault(self, key, default=None): try: return self[key]

1 0

python/dist/src/Lib/idlelib NEWS.txt, 1.23.4.6, 1.23.4.7
by anthonybaxter＠users.sourceforge.net May 27, 2004

May 27, 2004

Update of /cvsroot/python/python/dist/src/Lib/idlelib In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv16984/Lib/idlelib Modified Files: Tag: release23-maint NEWS.txt Log Message: formatting nit Index: NEWS.txt =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/idlelib/NEWS.txt,v retrieving revision 1.23.4.6 retrieving revision 1.23.4.7 diff -C2 -d -r1.23.4.6 -r1.23.4.7 *** NEWS.txt 12 May 2004 19:50:04 -0000 1.23.4.6 --- NEWS.txt 27 May 2004 05:59:16 -0000 1.23.4.7 *************** *** 1,4 **** What's New in IDLE 1.0.3? ! =================================== *Release date: 13-May-2004* --- 1,4 ---- What's New in IDLE 1.0.3? ! ========================= *Release date: 13-May-2004* *************** *** 9,13 **** What's New in IDLE 1.0.2? ! =================================== *Release date: 05-Dec-2003* --- 9,13 ---- What's New in IDLE 1.0.2? ! ========================= *Release date: 05-Dec-2003* *************** *** 23,27 **** What's New in IDLE 1.0.1? ! =================================== *Release date: 23-Sep-2003* --- 23,27 ---- What's New in IDLE 1.0.1? ! ========================= *Release date: 23-Sep-2003* *************** *** 34,38 **** What's New in IDLE 1.0? ! =================================== *Release date: 29-Jul-2003* --- 34,38 ---- What's New in IDLE 1.0? ! ======================= *Release date: 29-Jul-2003* *************** *** 43,47 **** What's New in IDLE 1.0 release candidate 2? ! =================================== *Release date: 24-Jul-2003* --- 43,47 ---- What's New in IDLE 1.0 release candidate 2? ! =========================================== *Release date: 24-Jul-2003* *************** *** 51,55 **** What's New in IDLE 1.0 release candidate 1? ! =================================== *Release date: 18-Jul-2003* --- 51,55 ---- What's New in IDLE 1.0 release candidate 1? ! =========================================== *Release date: 18-Jul-2003* *************** *** 72,76 **** What's New in IDLE 1.0b2? ! =================================== *Release date: 29-Jun-2003* --- 72,76 ---- What's New in IDLE 1.0b2? ! ========================= *Release date: 29-Jun-2003* *************** *** 113,117 **** What's New in IDLEfork 0.9b1? ! =================================== *Release date: 02-Jun-2003* --- 113,117 ---- What's New in IDLEfork 0.9b1? ! ============================= *Release date: 02-Jun-2003*

1 0

python/dist/src/Misc/RPM python-2.3.spec, 1.2.12.11, 1.2.12.12
by anthonybaxter＠users.sourceforge.net May 27, 2004

May 27, 2004

Update of /cvsroot/python/python/dist/src/Misc/RPM In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv16644/Misc/RPM Modified Files: Tag: release23-maint python-2.3.spec Log Message: reset release Index: python-2.3.spec =================================================================== RCS file: /cvsroot/python/python/dist/src/Misc/RPM/python-2.3.spec,v retrieving revision 1.2.12.11 retrieving revision 1.2.12.12 diff -C2 -d -r1.2.12.11 -r1.2.12.12 *** python-2.3.spec 25 May 2004 18:43:41 -0000 1.2.12.11 --- python-2.3.spec 27 May 2004 05:56:12 -0000 1.2.12.12 *************** *** 33,37 **** %define version 2.3.4 %define libvers 2.3 ! %define release 3pydotorg %define __prefix /usr --- 33,37 ---- %define version 2.3.4 %define libvers 2.3 ! %define release 1pydotorg %define __prefix /usr

1 0

python/nondist/peps pep-0101.txt, 1.48, 1.49 pep-0102.txt, 1.21, 1.22
by anthonybaxter＠users.sourceforge.net May 27, 2004

May 27, 2004

Update of /cvsroot/python/python/nondist/peps In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv16561 Modified Files: pep-0101.txt pep-0102.txt Log Message: more rpm goodness Index: pep-0101.txt =================================================================== RCS file: /cvsroot/python/python/nondist/peps/pep-0101.txt,v retrieving revision 1.48 retrieving revision 1.49 diff -C2 -d -r1.48 -r1.49 *** pep-0101.txt 5 Dec 2003 00:45:13 -0000 1.48 --- pep-0101.txt 27 May 2004 05:55:55 -0000 1.49 *************** *** 160,163 **** --- 160,166 ---- %define libvers 2.3 + You also probably want to reset the %define release line + to '1pydotorg' if it's not already that. + If the new release uses a major/minor version which is different than is in the name of the current Index: pep-0102.txt =================================================================== RCS file: /cvsroot/python/python/nondist/peps/pep-0102.txt,v retrieving revision 1.21 retrieving revision 1.22 diff -C2 -d -r1.21 -r1.22 *** pep-0102.txt 13 May 2004 07:20:16 -0000 1.21 --- pep-0102.txt 27 May 2004 05:55:55 -0000 1.22 *************** *** 73,76 **** --- 73,79 ---- %define version 2.3.1 + You also probably want to reset the %define release line + to '1pydotorg' if it's not already that. + ___ If you're changing the version number for Python (e.g. from Python 2.1.1 to Python 2.1.2), you also need to update the

1 0

Pre-qualify, and apply for home [loans] and [mortgages]
by Jaime Mcneill May 26, 2004

May 26, 2004

Good Day, You have been Pre-Selected to join our exculsive "Extreme_Low_Rate" mortgage program. The only catch is that this Extreme Rate won't last so you must ACT NOW as there are limited spots available. Please visit the following link to complete your application which has been pre-approved. http://thehomeloanguy.com/?partid=wh6 Thank You Patty Merritt Senior Mortgage Consultant to opt out of this special program click here...it may take up to 48 hours to complete thank you http://thehomeloanguy.com/st.html

1 0

python/dist/src/Objects floatobject.c, 2.129, 2.130
by mwh＠users.sourceforge.net May 26, 2004

May 26, 2004

Update of /cvsroot/python/python/dist/src/Objects In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv12065 Modified Files: floatobject.c Log Message: Remove float_compare as per [ 899109 ] 1==float('nan') which can now finally be closed, I think. Index: floatobject.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Objects/floatobject.c,v retrieving revision 2.129 retrieving revision 2.130 diff -C2 -d -r2.129 -r2.130 *** floatobject.c 26 Feb 2004 13:16:03 -0000 2.129 --- floatobject.c 26 May 2004 17:36:12 -0000 2.130 *************** *** 353,364 **** } - static int - float_compare(PyFloatObject *v, PyFloatObject *w) - { - double i = v->ob_fval; - double j = w->ob_fval; - return (i < j) ? -1 : (i > j) ? 1 : 0; - } - static PyObject* float_richcompare(PyObject *v, PyObject *w, int op) --- 353,356 ---- *************** *** 853,857 **** 0, /* tp_getattr */ 0, /* tp_setattr */ ! (cmpfunc)float_compare, /* tp_compare */ (reprfunc)float_repr, /* tp_repr */ &float_as_number, /* tp_as_number */ --- 845,849 ---- 0, /* tp_getattr */ 0, /* tp_setattr */ ! 0, /* tp_compare */ (reprfunc)float_repr, /* tp_repr */ &float_as_number, /* tp_as_number */

1 0

python/dist/src/Modules socketmodule.c, 1.288, 1.289
by mwh＠users.sourceforge.net May 26, 2004

May 26, 2004

Update of /cvsroot/python/python/dist/src/Modules In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv5830 Modified Files: socketmodule.c Log Message: Band-aid type fix for [ 728330 ] Don't define _SGAPI on IRIX The Right Thing would be nice, for now this'll do. At least it isn't going to break anything *other* than IRIX... Index: socketmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v retrieving revision 1.288 retrieving revision 1.289 diff -C2 -d -r1.288 -r1.289 *** socketmodule.c 11 Apr 2004 12:02:25 -0000 1.288 --- socketmodule.c 26 May 2004 17:06:31 -0000 1.289 *************** *** 62,65 **** --- 62,69 ---- */ + #if defined(__sgi) && _COMPILER_VERSION>700 && !_SGIAPI + #define _BSD_TYPES + #endif + #include "Python.h" *************** *** 193,198 **** --- 197,212 ---- /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ + #undef _SGIAPI /* to avoid warning */ #define _SGIAPI 1 + #undef _XOPEN_SOURCE + #include <sys/socket.h> + #include <sys/types.h> + #include <netinet/in.h> + #ifdef _SS_ALIGNSIZE + #define HAVE_GETADDRINFO 1 + #define HAVE_GETNAMEINFO 1 + #endif + #define HAVE_INET_PTON #include <netdb.h> *************** *** 258,262 **** --- 272,281 ---- #endif + #if defined(__sgi) && _COMPILER_VERSION>700 \ + && !defined(_SS_ALIGNSIZE) /* defined in sys/socket.h */ + /* by some newer versions of IRIX */ + /* (e.g. not by 6.5.10 but by 6.5.21) */ #include "addrinfo.h" + #endif #ifndef HAVE_INET_PTON

1 0