Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60945
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4FE33EDF.2000409@lerdorf.com>
References: <CAF+90c-T9hPbuS3bUxnHw-+B+Y2VLu55wQJ8UrtzrcC7TiKyVw@mail.gmail.com>
	<20120621141241.GA25789@analysisandsolutions.com>
	<CAF+90c8=5C_C9wa0q-Tf0OB2vKBow2PH8Nqu5n2SUm=xU1gKgQ@mail.gmail.com>
	<4FE33EDF.2000409@lerdorf.com>
Date: Sat, 23 Jun 2012 06:50:01 -0400
Message-ID: <CAL+t6cGZX5Db7L+0FAc7aCRXueE2O7A-_=NrmoTCteEWWkv-2w@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Nikita Popov <nikita.ppv@googlemail.com>, 
	Daniel Convissor <danielc@analysisandsolutions.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] json_encode() behavior for incorrectly encoded strings
From: theanomaly.is@gmail.com (Sherif Ramadan)

>
> The problem with a warning here is that there is usually no way to
> prevent it short of using @ or preceding all calls to htmlspecialchars()
> with an iconv() call. A bad guy can simply send invalid UTF-8 bytes to a
> web app and look for that warning to get a really good idea about the
> server software being used. And yes, I know people should have
> display_errors off in production, but this case is slightly different
> because it is so universal. Other user-triggerable warnings are very
> code-dependent and there is no universal trigger string you can send to
> all PHP apps. Almost all PHP apps call htmlspecialchars() on user input
> at some point.
>
> The call here was whether to throw a warning at all and the idea was
> that it was ok to do so as long as it didn't leak to the world for
> improperly configured servers that had display_errors on. I would be
> fine with removing the warning altogether since sanitizing the string is
> an inherent characteristic of the function now and throwing warnings
> about the normal operation of a function doesn't make much sense.
>
> -Rasmus


So in other words this patch I submitted should be fine?

https://github.com/php/php-src/pull/111

This particular patch doesn't raise any controversy since it doesn't
touch any of that other stuff and simply puts the defined behavior
back in place as it should have been.