On 2012-04-10 23:13, Thomas Goirand wrote:
On 04/11/2012 10:02 AM, Filipus Klutiero wrote:
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.
How about: we can assume that you are neat-picking or being wrong, since
everyone is happy with the current text, and that you're the only one
that wants to change it?
And by the way, the text makes sense to me and others. You're the one
who "don't understand it", please don't generalize.
"neat-picking"... heh, neat.
If I was wrong, someone should have been able to answer my question.
I can't say there's nothing of value there as I don't
understand all of it
You've repeatedly said that you "don't understand it" (your own words,
see below). Frankly, I do agree with this statement.
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.
Yes there is. unserialize() is a specific function of PHP which is known
to be unsafe with untrusted data, and this is specific to PHP.
short_open_tag is PHP specific as well.
Yes, and rm is a specific command of coreutils which is known to be
"unsafe" with useful data, and this is specific to coreutils. Yet, there
is no /usr/share/doc/coreutils/README.Debian.security, and nobody asking
for one.
Also, miss-using the language and accusing the language itself is
historically a PHP specific thing. Don't ask me why, I don't know why
people think PHP should be the magical language that solves all of your
programming mistakes (I don't even agree it should be the case), but it
is a fact that many people write like this about PHP.
Just like people accuse other programming languages and other software.
More importantly, even if you were right, it wouldn't be php5's
documentation's role to defend PHP. The documentation is not a
propaganda tool, it's there to inform users about what they need to
know, not to advocate the software.
* 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.
open_basedir may be miss-used by an administrator. Talking about it in
the package documentation is a very good idea, since few years ago, the
situation wasn't the same at all.
What do you mean? open_basedir was considered as a security feature a
few years ago, but it no longer is?
* 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?
No.
In that case, please point to an example.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
