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.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
