Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:17009
Return-Path: <flying.mushroom@gmail.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 93731 invoked by uid 1010); 29 Jun 2005 19:27:29 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 93716 invoked from network); 29 Jun 2005 19:27:29 -0000
Received: from unknown (HELO gmail.com) (127.0.0.1)
  by localhost with SMTP; 29 Jun 2005 19:27:29 -0000
X-Host-Fingerprint: 64.233.162.197 zproxy.gmail.com Linux 2.4/2.6
Received: from ([64.233.162.197:28286] helo=zproxy.gmail.com)
	by pb1.pair.com (ecelerity 1.2 r(5656M)) with SMTP
	id D4/5D-42553-126F2C24 for <internals@lists.php.net>; Wed, 29 Jun 2005 15:27:29 -0400
Received: by zproxy.gmail.com with SMTP id 8so524029nzo
	for <internals@lists.php.net>; Wed, 29 Jun 2005 12:27:25 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=beta; d=gmail.com;
	h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=C2Ml0u0eyrUNzsEOIIH05bYXUx1Z1aSHmscYvetUFLaaYKZiH4GrUMEioEsXThRXmQW2lamV5NWZvfwUuuverlUVgvXnuKJhheyPSbNuJrVeXR/XDHKOlirbJsucrhi34uPxWzVEW2GSXMwDVo7GeYbF2DnVmQPQUtFt915kahc=
Received: by 10.36.13.8 with SMTP id 8mr430770nzm;
	Wed, 29 Jun 2005 12:27:25 -0700 (PDT)
Received: by 10.36.57.3 with HTTP; Wed, 29 Jun 2005 12:27:25 -0700 (PDT)
Message-ID: <a440ea0805062912273b431c4b@mail.gmail.com>
Date: Wed, 29 Jun 2005 20:27:25 +0100
Reply-To: Nelson Menezes <flying.mushroom@gmail.com>
To: Russell Nelson <nelson@crynwr.com>
Cc: internals@lists.php.net
In-Reply-To: <17090.15074.92337.224192@desk.crynwr.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <42BDDC82.6020208@ohgaki.net> <42C0CF76.6090203@lerdorf.com>
	<42C0F4DA.4000605@php.net> <17089.18702.450236.614561@desk.crynwr.com>
	<1119998580.13690.109.camel@localhost>
	<17089.63833.772427.529013@desk.crynwr.com>
	<42C1FF2A.4000006@fission.org.uk>
	<17090.9316.148303.68882@desk.crynwr.com>
	<30bd802405062822091191c8fc@mail.gmail.com>
	<17090.15074.92337.224192@desk.crynwr.com>
Subject: Re: [PHP-DEV] allow_url_fopen should be INI_ALL
From: flying.mushroom@gmail.com (Nelson Menezes)

On 6/29/05, Russell Nelson <nelson@crynwr.com> wrote:

> If 'strchr' caused your CPU's fan to stop turning, should 1) a
> work-around be documented, or 2) the code fixed?  If a bug in libjpeg
> allows a url_fopened image to contain invalid data that elevates
> privilege, should that be 1) a work-around be documented, or 2) the
> code fixed?  If the design of 'include' allows remote users to execute
> hostile code, should that be 1) a work-around be documented, or 2) the
> code fixed?

This is a stupid comparison. In the first two cases, the *bugs* would
be allowing something to happen that was not even remotely related
with the intention of the function/library. include() is simply doing
its job, which by the way is well documented. It's not
unexpeced/undesigned/buggy behaviour that it will include what it's
told to. The potential for inclusion of malicious code is, if
anything, a common oversight, not a design flaw.

What I can suggest is one of two things... (not particularly
whole-heartedly, though):

1. Create an INI_ALL variable that means something like "allow fopen
wrappers in include/require" and default it to whatever is thought
appropriate -- if it *is* a very common oversight, maybe false.

2. Add a "Basic considerations for your web page/application" top
level that addresses the basic most common security issues. The rest
of the docs could then be peppered with "security warnings" (<blink>s)
where found *really* necessary.

Of those, I'd probably prefer suggestion 2.
=20
>  > Are you suggesting that virtually _any_ function should be
>  > protected against stupidity ?
>=20
> If people do stupid things with a computer, is it their fault or the
> computer's fault?  Personally, I always think it's the computer's
> fault.  So, yes, if people end up doing stupid things, it is because
> the computer is wrong.

Well, if you are a total end-user, I'd agree with you. But developers
do need to take up some responsability to not being stupid (how much
is always debatable, but you can' use such a blanket argument).

--=20
Nelson Menezes
flying.mushroom@gmail.com