[php-maint] PHP security policy review

Nico Golde nico at ngolde.de
Wed Jun 30 17:10:38 UTC 2010


Hi,
* Raphael Geissert <geissert at debian.org> [2010-06-30 11:17]:
> While reviewing the security policy for PHP I noticed a few gaps which I think 
> are important to address.
> 
> At the moment I'd like to propose the following changes, so please comment and 
> feel free to propose others:
> 
> > --- a/debian/README.Debian.security
> > +++ b/debian/README.Debian.security
> > @@ -1,10 +1,13 @@
> > 
> >  the Debian stable security team does not provide security support
> > -for certain configurations known to be inherently insecure.  Most
> > -specifically, the security team will not provide support for flaws in:
> > +for certain configurations known to be inherently insecure.  This
> > +includes the interpreter itself, extensions, and code written in the
> > +PHP language. Most specifically, the security team will not provide
> > +support for flaws in:
> 
> To clarify that the policy applies to the interpreter and apps, which is how 
> it has been treated so far.

Looks fine to me.

> >  - problems which are not flaws in the design of php but can be problematic
> > -  when used by sloppy developers (for example, not checking the contents
> > -  of a tar file before extracting it).
> > +  when used by sloppy developers (for example: not checking the contents
> > +  of a tar file before extracting it, using unserialize() on
> > +  untrusted data, or relying on a specific value of short_open_tag).
> 
> To include unserialize() and ini settings such as short_open_tag. 

Using unserialize() on user input is imho not necessary sloppy, I'd put that 
into its own sentence. While the unserialize() implementation is known to be 
problematic security wise it's use is not discouraged, there is no security 
hint on the php site itself and it's widely in use.

Cheers
Nico
P.S. excuse me if I misunderstood you, after all I'm no PHP expert
-- 
Nico Golde - http://www.ngolde.de - nion at jabber.ccc.de - GPG: 0xA0A0AAAA
For security reasons, all text in this mail is double-rot13 encrypted.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-maint/attachments/20100630/77a0f1c9/attachment.pgp>


More information about the pkg-php-maint mailing list