
Just to let you know and to initiate some cross-platform testing: While working on the warning patch for modsupport.c, I've added two new APIs which hopefully make it easier for Python to switch to buffer overflow safe [v]snprintf() APIs for error reporting et al. The two new APIs are PyOS_snprintf() and PyOS_vsnprintf() and work just like the standard ones in many C libs. On platforms which have snprintf(), the native APIs are used, on all other an emulation with snprintf() tries to do its best. Please try them out on your platform. If all goes well, I think we should replace all sprintf() (without the n in the name) with these new safer APIs. Thanks, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/

It would be easier to test out the fallback implementation if there was a config option to enable it even on platforms that do have the native version. Or maybe (following the getopt example) we might consider always using our own code -- so it gets the maximum testing. --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
How about always enabling our version in the alpha cycle and then reverting back to the native one in the betas ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/

[MAL]
How about always enabling our version in the alpha cycle and then reverting back to the native one in the betas ?
If we have to ship our own code for it anyway, why ever revert to the native one? Historically, all that gives us is boundless opportunities to catalog and #ifdef our way around gratuitous discrepancies among platform C libraries. since-we-switched-to-our-own-getopt-everywhere-we-no-longer-get- getopt-bug-reports-anywhere-ly y'rs - tim

Tim Peters wrote:
Well, the emulation is not as robust and fast as the native implementation is, plus it cannot recover from a buffer overrun; such an overrun is likely to cause a core dump due to sprintf() writing into the heap -- still better than allowing a cracker to hack your system by exploiting a stack overrun, but not as good as a true snprintf() implementation will do. If we do get complaints about snprintf() failures on systems which do have a native API, then we can still switch to the emulation for all platforms. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/

It would be easier to test out the fallback implementation if there was a config option to enable it even on platforms that do have the native version. Or maybe (following the getopt example) we might consider always using our own code -- so it gets the maximum testing. --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
How about always enabling our version in the alpha cycle and then reverting back to the native one in the betas ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/

[MAL]
How about always enabling our version in the alpha cycle and then reverting back to the native one in the betas ?
If we have to ship our own code for it anyway, why ever revert to the native one? Historically, all that gives us is boundless opportunities to catalog and #ifdef our way around gratuitous discrepancies among platform C libraries. since-we-switched-to-our-own-getopt-everywhere-we-no-longer-get- getopt-bug-reports-anywhere-ly y'rs - tim

Tim Peters wrote:
Well, the emulation is not as robust and fast as the native implementation is, plus it cannot recover from a buffer overrun; such an overrun is likely to cause a core dump due to sprintf() writing into the heap -- still better than allowing a cracker to hack your system by exploiting a stack overrun, but not as good as a true snprintf() implementation will do. If we do get complaints about snprintf() failures on systems which do have a native API, then we can still switch to the emulation for all platforms. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
participants (3)
-
Guido van Rossum
-
M.-A. Lemburg
-
Tim Peters