[php-maint] 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 05:10, Thijs Kinkhorst wrote:
> On Mon, April 9, 2012 21:07, Filipus Klutiero wrote:
>> There is a difference between configuring and using a configuration.
>> Using my MUA's reply feature may indeed be conceived as *using* a
>> configuration. However, it's certainly not commonly conceived as
>> *configuring*.
> Could be, but the word 'configuring' is not used in the text so this is
> not relevant here.

I was replying to your reply stating that 'You can use a configuration 
without "being configuring" it', which is correct, but irrelevant in 
this discussion, as the text discussed does not contain 'use a 
configuration'.

>>>> or clarify your understanding of what "configuration" means.
>>> I've done that now.
>>>
>>> We already had this text reviewed by Debian's native English review team
>>> and that resulted in the text as it is now.
>> Hum. Could you point to that review?
> The end result of the review is in the package. The process that led to it
> is not really on topic here.

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.

> You snipped the part where I proposed that the way to continue towards
> resolution is that you provide an alternative that we can talk about.

See my last message to Thomas Goirand.

If none of these suggestions please you, I'd also suggest to simply 
scrap the file. I can't say there's nothing of value there as I don't 
understand all of it, 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.

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

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