Re: allow_url_fopen should be INI_ALL

Just for the records, I guess you all know that I meant 'language construct' where I wrote 'function' instead (in reference to include). On 6/29/05, Nicolas Bérard Nault <nicobn@gmail.com> wrote: > PHP is not, in my opinion, idiot-proof. You're right on that point. > Where our opinions differ is about what should be done about this. > > If a programmer is not capable of controlling an user input, why then > should we trust him with anything ? A lot of other functions taking > user input as arguments could potentially be as damaging as this one. > I think if a programmer can't read a manual page about a so common > function, he deserves what he has. Yes, I'm feeling a bit > pre-conventionnal tonight. > > As for the rm -rf / case, I think it's the best exemple. > Why should > a hacker bother on exploiting an include stupidly called with user > input unfiltered when he can get straight to an unprotected > system($_GET['Whatever']). Are you suggesting that virtually _any_ > function should be protected against stupidity ? What kind of language > PHP would be after that ? > > On 6/29/05, Russell Nelson <nelson@crynwr.com> wrote: > > Gareth Ardron writes: > > > To me, it's obvious that include includes a file - I see no obvious > > > determination that that file is either local or remote in the "include" > > > statement. > > > > Can you name some other languages in which 'include' has such > > incredibly sharp edges? C? Python? Perl? BASH? Sed? Awk? Pascal? > > BASIC? Is there *any* precedent for a language in which 'include' > > will fetch hostile code from a remote server and execute it? If > > you're going to argue that experienced programmers will understand > > that 'include' will fetch code, you should explain how their > > experience helps them. > > > > > Also, I think it's silly to make include into two functions as you > > > suggest given that the ability to include a remote file depends on the > > > fopen wrapper being enabled. If we were to follow this line of logic, we > > > would have two functions for every current one function which can use > > > the fopen wrappers. > > > > That's not my line of logic, so following it takes you off the map. > > > > > I think the documentation quite clearly states that /all/ functions that > > > deal with files may deal with remote files if the fopen wrappers are > > > enabled > > > > Why did both of my users miss that documentation? The facts seem to > > be in opposition to your assertion that "the documentation quite > > clearly states". > > > > > However, as I mention above, every single function that can use > > > fopen wrappers can be exploited in this way. > > > > Not true. You would need to have *another* security flaw (a bug in > > jpg or xml parsing) for hostile jpg or xml content to gain privileges. > > > > > It's unfortunate, but there's a lot of muppets out there who think > > > they can code > > > > Now you're blaming the victim. > > > > -- > > --My blog is at blog.russnelson.com | If you want to find > > Crynwr sells support for free software | PGPok | injustice in economic > > 521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the > > Potsdam, NY 13676-3213 | | hand of a legislator. > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > -- > Nicolas Bérard Nault (nicobn@gmail.com) > "Maybe nature is fundamentally ugly, chaotic and complicated. But if > it's like that, then I want out." -- Steven Weinberg (prix Nobel de > physique, 1979). > -- Nicolas Bérard Nault (nicobn@gmail.com) "Maybe nature is fundamentally ugly, chaotic and complicated. But if it's like that, then I want out." -- Steven Weinberg (prix Nobel de physique, 1979).