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

[Thijs Kinkhorst]

On Sun, April 8, 2012 21:23, Filipus Klutiero wrote:
> Hi Thijs,
>
> On 2012-04-08 13:16, Thijs Kinkhorst wrote:
>> On Sun, April 8, 2012 18:31, Filipus Klutiero wrote:
>>> Package: php5-common
>>> Version: 5.4.1~rc1-1
>>> Severity: normal
>>>
>>> README.Debian.security starts:
>>>
>>>> The Debian stable security team does not provide security support for
>>>> certain configurations known to be inherently insecure. This includes
>>>> the interpreter itself, extensions, and user scripts written in the
>>>> PHP
>>>> language.
>>> This is at least most unclear. How would the PHP interpreter be a
>>> configuration known to be inherently insecure?
>> If I add "features in", does it get clear to you what's meant?
>>
>> | The Debian stable security team does not provide security support for
>> | certain configurations known to be inherently insecure. This includes
>> | features in the interpreter itself, extensions, and user scripts
>> written
>> | in the PHP language. Most specifically, but not exclusively, the
>> | security team will not provide support for the following.
>
> I'm not sure. This raises the question "Are features configurations?"

Making use of a feature is most certainly a configuration.

> Looking at the list of specific cases/examples:
>
>>  * 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.
>
> Only the last example makes me think of configuration.
>
>>
>>  * Vulnerabilities involving any kind of open_basedir violation, as
>>    this feature is not considered a security model either by us or by
>>    PHP upstream.
>
> That does make me think of configuration.
>
>>
>>  * 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.
>
> That doesn't make me think of configuration.

You've noticed that there are at least two examples that refer to
configuration. That seems like enough examples to me. I take it that
you're ok with the proposed change then?


Thijs