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, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Jani Taskinen <[EMAIL PROTECTED]> writes: > > > Please troll, do you go away if I close my eyes? > > 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 not > trolling. This discussion seems to have strong backing on both sides of the > issue. > > There has been an argument made during this discussion that the include() > construct does exactly as it is documented to do, and therefore the security > concerns are not warranted. I have a bit of a problem with that argument: > > 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 is > unreasonable. PHP is sufficiently like C (a "good thing", I believe) that > experienced C developers can write code in PHP, and reference the > documentation when something doesn't work. > > 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 years. > Although I validate all user input in PHP so I've never been bitten by this > problem, I was surprised when this topic started, that include() could access > remote files. Yes, I probably knew it 5 years ago, but include() has a basic > meaning in all other languages I've used, and I would have expected it to work > the same way in PHP. > > Someone suggested that if include() were insecure, then maybe system() is as > well. I think I have to disagree with the comparison. Anyone using system() > 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 careful. > 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. > > Derrell > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
