On Mon, Apr 9, 2012 at 10:35 PM, Luke Scott <l...@cywh.com> wrote: > On Apr 9, 2012, at 10:03 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > > > I strongly discourage settingallow_url_include=on, too. > > Good. > > > Enabling it only when it is needed is okay. > > No it's not. There is no reason to do so other than backwards > compatibility for very old code. > > > I think you are concerned about security, > > Absolutely. > > > so you could agree to have > > option for disabling embedded mode by option, couldn't you? > > Sure it can be an option. But it can't be the default, at least right > away. It's unreasonable. I would prefer an environmental variable to > choose the mode though. I'm not opposed to a php.ini option, but some > people are > > (If by embedded mode you mean template mode, and non-embedded mode as > "pure code mode"). > > I still fail to see what this has to do with allow_url_include. > > > Letting programmers decide what to do > > Not in all cases. > > > Programming languages should give freedom to write suicide code > > more or less. > > No, it shouldn't. > > All that you've said comes down to this: > > Don't write bad code. Configure your web server properly. > > The RFC isn't meant to address these issues, and quite frankly it > isn't a core PHP issue. It's no different than any language with an > eval() statement. > > Keep in mind an RFC isn't gospel. And it's still being drafted. We > need to give Tom a chance to finish it. > > Luke > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > I feel obliged to point out that both sides of this argument have been represented eloquently and fully IMHO. It now seems to have reached the point where all substantive arguments have been said and thus are now merely being repeated. The last few messages back-and-forth could, at least one some level, be summarized simply as, "Yes it is!" and "No it isn't!"
There's clearly a fundamental disagreement exposed here as to the role a programming language should play pertaining to the prevention of vulnerable code and whether the burden lies with the language or the programmer to assume responsibility for this. My guess would be that it falls somewhere in the middle, though I really haven't given it much thought to be honest. I'd like to suggest that a new thread be created for this debate, since it does seem to be sufficiently divergent from the original topic posted by Tom. I would also be interested to hear why you believe it should or should not be the role of the language to prevent exploitable code and to what degree. Both sides have stated quite authoritatively that it is one or the other, but what I'd like to see are some more in-depth arguments to back-up those assertions. From a strictly academic standpoint, I think this argument poses an interesting opportunity to explore this philosophical divide in detail. But regardless, let's at least move it to a separate topic so Tom can argue the case for his RFC without too much distraction. =) --Kris
