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

[Filipus Klutiero]

On 2012-04-08 15:45, Thijs Kinkhorst wrote:
> 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.

Hum, if I use my MUA's reply feature, I don't think of myself as being 
configuring anything. Then again, whether an action constitutes 
"configuring" may be unclear in certain cases. If you can explain what 
features in the PHP interpreter you consider as configurations, that may 
clarify.

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

The problem is not a lack of examples that qualify. The whole list is 
presented as configurations known to be inherently insecure. Please 
either remove those which are not about configuration, present the list 
differently, or clarify your understanding of what "configuration" means.

I'm not sure the proposed change helps. It certainly doesn't fix the 
README, but it may not hurt.