Re: php5 README.Debian.security
Ondřej Surý wrote:
> could you please review our README.Debian.security?
>
> http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=blob;f=debian/README.Debian.security;hb=HEAD
>
> The file change was initiated #658208, but it's now heading to dead lock,
> so I did some more rewritting and it would probably be good if somebody
> else had reviewed this file for the clarity of the text.
Okay, incuding it inline:
> 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 code written in the PHP
> language. Most specifically, but not exclusively, the security team
> will not provide support for:
Ultra-trivial nitpick: inconsistent inter-sentence spacing. Our
"house style" is singlespaced.
More importantly, I assume when it says "code written in the PHP
language" it means non-packaged end-user code - this could clearer.
Maybe s/code/user scripts/ ?
"Most specifically, but not exclusively" is an odd phrase, but it
makes sense and I don't see a better alternative.
> - security issues which are caused by careless programming, such as:
> * not checking the contents of a tar file before extracting it
> * using unserialize() on untrusted data
> * relying on a specific value of short_open_tag
Bulleted lists of bulleted lists are annoying, especially when
introduced by nested colons (though on the other hand you get rhetoric
points for all these three-item lists!); I wish I could see a way of
flattening it into one list.
I would suggest that bullet 1a should be
* extracting a tar file without first checking the contents;
to make the sentences more closely parallel.
D-l-e house style would also reverse the use of asterisks and dashes
here (and add punctuation to the ends of each line).
> - vulnerabilities involving any kind of open_basedir violation, as
> this is considered a security model neither by us nor PHP upstream.
More idiomatically:
this is not considered a security model either by us or by PHP upstream.
(but what exactly is the "this" referring back to here?)
> - 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.
s/php/PHP/g here.
>
> PHP upstream has published a statement regarding their view on security
> and the PHP interpreter:
> http://www.php.net/security-note.php
Some might insist that a singular upstream is an "it", but for me this
use of "singular their" seems entirely natural.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
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. Most specifically, but not exclusively, the security team will
not provide support for the following.
* 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.
* Vulnerabilities involving any kind of open_basedir violation, as this
is not considered a security model either by us or by PHP upstream.
* 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.
PHP upstream has published a statement regarding their view on security
and the PHP interpreter:
http://www.php.net/security-note.php
Reply to: