[php-maint] Bug#668067: Bug#668067: Bug#668067: Bug#668067: [php5-common] Nonsensical part about configuration known to be inherently insecure in README.Debian.security

Thomas Goirand thomas at goirand.fr
Wed Apr 11 03:13:07 UTC 2012

On 04/11/2012 10:02 AM, Filipus Klutiero wrote:
> Right... unless you have evidence to the contrary, we can assume the
> review missed this, or that the text making sense was out of the
> review's scope.

How about: we can assume that you are neat-picking or being wrong, since
everyone is happy with the current text, and that you're the only one
that wants to change it?

And by the way, the text makes sense to me and others. You're the one
who "don't understand it", please don't generalize.

> I can't say there's nothing of value there as I don't
> understand all of it

You've repeatedly said that you "don't understand it" (your own words,
see below). Frankly, I do agree with this statement.

> but each package shouldn't have a
> README.Debian.security. Only particular situations should require that.
> Looking at the specific situations covered:
>>  * Security issues which are caused by careless programming, such as:
>>    - extracting a tar file without first checking the contents;
>>    - using unserialize() on untrusted data;
>>    - relying on a specific value of short_open_tag.
> We will clearly not provide support just because one of our packages was
> involved in a security flaw due to misusage, nothing specific to PHP here.

Yes there is. unserialize() is a specific function of PHP which is known
to be unsafe with untrusted data, and this is specific to PHP.
short_open_tag is PHP specific as well.

Also, miss-using the language and accusing the language itself is
historically a PHP specific thing. Don't ask me why, I don't know why
people think PHP should be the magical language that solves all of your
programming mistakes (I don't even agree it should be the case), but it
is a fact that many people write like this about PHP.

>>  * Vulnerabilities involving any kind of open_basedir violation, as
>>    this feature is not considered a security model either by us or by
>>    PHP upstream.
> If open_basedir is not for security, that (and, hopefully, what it *is*
> for) should be mentioned in open_basedir's documentation, not in a README.

open_basedir may be miss-used by an administrator. Talking about it in
the package documentation is a very good idea, since few years ago, the
situation wasn't the same at all.

>>  * Any "works as expected" vulnerabilities, such as "user can cause
>>    PHP to crash by writing a malicious PHP script", unless such
>>    vulnerabilities involve some kind of higher-level DoS or privilege
>>    escalation that would not otherwise be available.
> Doesn't PHP 5.3 solve this?

No. What makes you think it was?


More information about the pkg-php-maint mailing list