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