Hi, 2012/4/10 Kris Craig <kris.cr...@gmail.com>: > > > 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 believe there is misunderstanding. allow_url_include and templat_mode is very similar to me, yet there is not an agreement. > > 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. =) These RFC is similar, but it's different. That why I separated the RFC. Why shouldn't thread. I'll post new one. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
