Re: error_log binary unsafe

On 10/27/2013 09:24 AM, Yasuo Ohgaki wrote:

Hi Joe, On Sun, Oct 27, 2013 at 4:40 PM, Joe Watkins <krakjoe@php.net> wrote:

On 10/27/2013 07:33 AM, Yasuo Ohgaki wrote:

On Sun, Oct 27, 2013 at 3:14 PM, Joe Watkins <pthreads@pthreads.org> wrote: The patch implements binsafe log for cli and cgi, do we need to implement

any more ??

It's better to check & fix all SAPIs :) Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net Indeed ...

But the original question I asked was for approval on the approach ... I guess I got that ?? I don't mind implementing other SAPI's at all, I was just wondering if the approach is satisfactory ...

I think approach is ok. We should leave receiver how the special characters are treated. Even if receiver has problem with null chars, the result is merely a 'truncated message' for most cases. However, I should mention that some database systems (e.g. Oracle) just ignore null char and it enables SQL injection detection bypass. (i.e. application firewall bypass) Some databases would not accept null char as valid text and refuse to store data. I would say this is not our issue, but it's a kind of BC issue. There may be many developers against your patch. I would suggest to create RFC before start working on other SAPIs. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net I don't see that it needs an RFC for the SAPI to have a means of logging binary safe data.

The implementations of FPM and Apache2 are things that might require RFC, but I don't see that the basic CLI and CGI SAPI's do. So it might be best to merge as it is, with cli and cgi implemented for reference, and then if someone wants to do the Apache2 and FPM implementations they can, along with an RFC for them. Cheers Joe