[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

[Filipus Klutiero]

On 2012-04-10 23:13, Thomas Goirand wrote:
> 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.

"neat-picking"... heh, neat.
If I was wrong, someone should have been able to answer my question.

>
>> 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.

Yes, and rm is a specific command of coreutils which is known to be 
"unsafe" with useful data, and this is specific to coreutils. Yet, there 
is no /usr/share/doc/coreutils/README.Debian.security, and nobody asking 
for one.

>
> 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.

Just like people accuse other programming languages and other software.

More importantly, even if you were right, it wouldn't be php5's 
documentation's role to defend PHP. The documentation is not a 
propaganda tool, it's there to inform users about what they need to 
know, not to advocate the software.

>>>   * 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.

What do you mean? open_basedir was considered as a security feature a 
few years ago, but it no longer is?

>
>>>   * 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.

In that case, please point to an example.