Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:17002
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
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=ZXcNXRWCZSXKdR2L0xiOe3INbDvTOVL43c1QHCZf80qurg7UdetxcbKuB+Q59ECmF4dPKG009vt96zs2hPXXJ42/nHYYD6n+it5Jpy7EzEl3ib2D9CREh27tAQFihjfy3tQb9U+wCvxPfBuNp6PUgIAAXkAA/8OxuQZllmrjZuU=
Message-ID: <4e89b426050629071519bdcc36@mail.gmail.com>
Date: Wed, 29 Jun 2005 10:15:10 -0400
Reply-To: Wez Furlong <kingwez@gmail.com>
To: Derrell.Lipman@unwireduniverse.com
Cc: Jani Taskinen <sniper@iki.fi>, Russell Nelson <nelson@crynwr.com>, 
	internals@lists.php.net
In-Reply-To: <3br12t95.fsf@random.internal>
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>
	<17088.52397.92440.326561@desk.crynwr.com>
	<42C0CF76.6090203@lerdorf.com> <42C0F4DA.4000605@php.net>
	<17089.18702.450236.614561@desk.crynwr.com>
	<42C225F7.1060201@lerdorf.com>
	<17090.14242.815242.149673@desk.crynwr.com>
	<Pine.LNX.4.61.0506290919310.17486@arfg.argcubovn.sv>
	<3br12t95.fsf@random.internal>
Subject: Re: [PHP-DEV] allow_url_fopen should be INI_ALL
From: kingwez@gmail.com (Wez Furlong)

I think the point is that we're not going to change include() any time
soon, and that this thread is not a productive use of everyones time.

--Wez.

On 6/29/05, Derrell.Lipman@unwireduniverse.com
<Derrell.Lipman@unwireduniverse.com> wrote:
> Jani Taskinen <sniper@iki.fi> writes:
>=20
> >     Please troll, do you go away if I close my eyes?
>=20
> That's not fair.  Russell is providing strong arguments and rebuttals for
> every point.  You may not agree with his points, but what he's doing is n=
ot
> trolling.  This discussion seems to have strong backing on both sides of =
the
> issue.
>=20
> There has been an argument made during this discussion that the include()
> construct does exactly as it is documented to do, and therefore the secur=
ity
> concerns are not warranted.  I have a bit of a problem with that argument=
:
>=20
> The PHP documentation is really good -- some of the best of all the
> open-source projects I've seen -- but there is so much documentation (and=
 so
> many capabilities of the language) that expecting people to read it all i=
s
> unreasonable.  PHP is sufficiently like C (a "good thing", I believe) tha=
t
> experienced C developers can write code in PHP, and reference the
> documentation when something doesn't work.
>=20
> I've been developing PHP code for about 5 years, and have been a software
> engineer working with many languages (but primarily C) for the past 25 ye=
ars.
> Although I validate all user input in PHP so I've never been bitten by th=
is
> problem, I was surprised when this topic started, that include() could ac=
cess
> remote files.  Yes, I probably knew it 5 years ago, but include() has a b=
asic
> meaning in all other languages I've used, and I would have expected it to=
 work
> the same way in PHP.
>=20
> Someone suggested that if include() were insecure, then maybe system() is=
 as
> well.  I think I have to disagree with the comparison.  Anyone using syst=
em()
> in any language expects the potential for nasty effects if the parameter =
is
> nasty, so it would be clear that the developer needs to be extremely care=
ful.
> If include() could include only local files as is done in other languages=
 (and
> as many -- most? -- developers would expect), then it would be much less
> dangerous.
>=20
> Derrell
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20
>