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
