hi, If there is no objection I like to apply this patch to 5.3 tomorrow morning (Europe) so we have it in for 5.3.4RC1. Please raise your concerns until then. At the very least we can always revert it after RC1.
Cheers, On Mon, Nov 15, 2010 at 11:42 AM, Rasmus Lerdorf <ras...@lerdorf.com> wrote: > Ok, I went through all the 5.3 code. This should fix the null poisoning > problems in 5.3 without breaking binary compatibility: > > http://progphp.com/nullpatch.txt > > There are quite a few places where we can't solve it centrally, so > perhaps we need to take the same approach in trunk. > > This should take care of every issue mentioned here: > > http://www.madirish.net/?article=436 > > along with a number of bug reports. > > I think the only outstanding issue with the patch is whether to show an > error message when we hit a null in a filesystem path string. With the > Zend part of the patch, right now the error is slightly misleading for > code like this: > > $file = "foo.php\0"; > include $file . ".png"; > > This will output: > > PHP Warning: include(): Failed opening 'foo.php' for inclusion > (include_path='.:') in foo on line 3 > > Without this patch, this code will of course simply include the foo.php > file and ignore the .png extension. > > -Rasmus > > On 11/14/10 9:35 PM, Andi Gutmans wrote: >> Hi Rasmus, >> >> Hope I understood the problem correctly. If not, this answer won't make >> sense :) >> I do not see a major problem in passing path_len but wonder how much it'd >> actually solve as we end up calling OS APIs that do not accept path_len, no? >> I assume we don't want to start searching all these strings for invalid >> chars before we pass them to the OS. >> >> Andi >> >>> -----Original Message----- >>> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] >>> Sent: Sunday, November 14, 2010 11:54 AM >>> To: internals >>> Subject: [PHP-DEV] Adding path_len to all stream functions in trunk >>> >>> I think we need to pass along the string length to all the stream functions >>> to >>> maintain binary string safety through this code. This would fix annoying >>> problems like http://bugs.php.net/39863 and a bunch of similar issues. >>> Obviously not something we can do in 5.3 without breaking binary >>> compatibility >>> though. Although we might be able to do something if we assume only chars >>> valid in the current charset is valid in file paths. >>> >>> Anybody have any other thoughts on this one? >>> >>> -Rasmus >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: >>> http://www.php.net/unsub.php >> > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
