Hi Lester and all,
On Fri, Feb 6, 2015 at 5:30 PM, Lester Caine wrote:
> On 06/02/15 05:01, Yasuo Ohgaki wrote:
> >> But it is the key point. It is not PHP role to do it. PHP is not
> >> > alone. It is a server configuration job. But I have said that already
> >> > many times, we got our points
On 06/02/15 05:01, Yasuo Ohgaki wrote:
>> But it is the key point. It is not PHP role to do it. PHP is not
>> > alone. It is a server configuration job. But I have said that already
>> > many times, we got our points :)
> I understand your point.
>
> We need both OS and PHP feature for perfection
Hi Pierre,
On Fri, Feb 6, 2015 at 1:52 PM, Pierre Joye wrote:
> But it is the key point. It is not PHP role to do it. PHP is not
> alone. It is a server configuration job. But I have said that already
> many times, we got our points :)
>
I understand your point.
We need both OS and PHP feature
On Fri, Feb 6, 2015 at 11:35 AM, Yasuo Ohgaki wrote:
> Hi Pierre,
>
> On Fri, Feb 6, 2015 at 1:16 PM, Pierre Joye wrote:
>>
>> > With SElinux, we can restrict access. However, PHP should be able to
>> > read/write
>> > uploaded files. PHP just read and execute them with include.
>>
>> Again, I am
Hi all,
On Fri, Feb 6, 2015 at 1:35 PM, Yasuo Ohgaki wrote:
> > I have similar idea for PHP to have data only dirs.
>>
>> We have that already, not for php, but for web servers. This is their
>> job to deal with that.
>
>
> Yes, indeed.
> engine=off
> per dirs. This is what I suggest people. It
Hi Pierre,
On Fri, Feb 6, 2015 at 1:16 PM, Pierre Joye wrote:
> > With SElinux, we can restrict access. However, PHP should be able to
> > read/write
> > uploaded files. PHP just read and execute them with include.
>
> Again, I am talking about executing files. You can exclude a file,
> path, fo
On Fri, Feb 6, 2015 at 11:08 AM, Yasuo Ohgaki wrote:
>
> On Fri, Feb 6, 2015 at 12:40 PM, Pierre Joye wrote:
>>
>> > Even if uploaded files are stored under non web root dir, attackers can
>> > use
>> > path
>> > traversal or even full path with bad code. As long as PHP can access,
>> > attacker
Hi Pierre,
On Fri, Feb 6, 2015 at 12:40 PM, Pierre Joye wrote:
> > Even if uploaded files are stored under non web root dir, attackers can
> use
> > path
> > traversal or even full path with bad code. As long as PHP can access,
> > attacker
> > can access to files for inclusion attacks. Compress
On Fri, Feb 6, 2015 at 10:33 AM, Yasuo Ohgaki wrote:
> Hi Pierre,
>
> On Fri, Feb 6, 2015 at 11:13 AM, Pierre Joye wrote:
>>
>> > I am :) Almost all of my clients are ISMS or similar certified.
>>
>> Marketing ;)
>>
>> >> However, back to this exact feature. I am not convinced it is the
>> >> ri
Hi Pierre,
On Fri, Feb 6, 2015 at 11:13 AM, Pierre Joye wrote:
> > I am :) Almost all of my clients are ISMS or similar certified.
>
> Marketing ;)
>
> >> However, back to this exact feature. I am not convinced it is the
> >> right way, there are many cases required more than just checking vali
On Feb 6, 2015 9:08 AM, "Yasuo Ohgaki" wrote:
>
> Hi Pierre,
>
> On Fri, Feb 6, 2015 at 10:39 AM, Pierre Joye wrote:
>>
>> I do not put high value in this ISO ;-)
>
>
> I am :) Almost all of my clients are ISMS or similar certified.
Marketing ;)
>> However, back to this exact feature. I am not
Hi Pierre,
On Fri, Feb 6, 2015 at 10:39 AM, Pierre Joye wrote:
> I do not put high value in this ISO ;-)
>
I am :) Almost all of my clients are ISMS or similar certified.
However, back to this exact feature. I am not convinced it is the
> right way, there are many cases required more than jus
On Fri, Feb 6, 2015 at 8:25 AM, Yasuo Ohgaki wrote:
> Hi Pierre,
>
> On Thu, Feb 5, 2015 at 8:49 PM, Pierre Joye wrote:
>>
>> PHP is just as safe than the other languages. PHP applicatons maybe
>> less, maybe more. I tend to see the amount of attacks as a proof of
>> success of a tool instead of
Hi Pierre,
On Thu, Feb 5, 2015 at 8:49 PM, Pierre Joye wrote:
> PHP is just as safe than the other languages. PHP applicatons maybe
> less, maybe more. I tend to see the amount of attacks as a proof of
> success of a tool instead of a proof of the tool being unsafe (not
> worth attacking 0.01% o
On Thu, Feb 5, 2015 at 5:47 PM, Yasuo Ohgaki wrote:
> Hi Pierre and all,
>
> On Thu, Feb 5, 2015 at 7:24 PM, Pierre Joye wrote:
>>
>> >
>> >
>> > I'm proposing *SCRIPT* only inclusion. This can be done by
>> >
>> > - allowing "> > - not allowing "?>" anywhere (We may allow at the end possibly)
Hi Leigh,
On Thu, Feb 5, 2015 at 7:51 PM, Leigh wrote:
> On 5 February 2015 at 10:24, Pierre Joye wrote:
> > I do understand what you try to achieve, from all point of view.
> > However I strongly disagree with this as a security improvement. I see
> > this more as yet another attempt to replac
Hi Pierre,
On Thu, Feb 5, 2015 at 7:24 PM, Pierre Joye wrote:
> I do understand what you try to achieve, from all point of view.
> However I strongly disagree with this as a security improvement. I see
> this more as yet another attempt to replace what should be done at the
> OS level.
>
I shou
On 5 February 2015 at 10:24, Pierre Joye wrote:
> I do understand what you try to achieve, from all point of view.
> However I strongly disagree with this as a security improvement. I see
> this more as yet another attempt to replace what should be done at the
> OS level.
>
I'm inclined to agree,
Hi Pierre and all,
On Thu, Feb 5, 2015 at 7:24 PM, Pierre Joye wrote:
> >
> >
> > I'm proposing *SCRIPT* only inclusion. This can be done by
> >
> > - allowing " > - not allowing "?>" anywhere (We may allow at the end possibly)
> >
> > Those who do not understand my point.
> > Please search by
On Thu, Feb 5, 2015 at 5:20 PM, Yasuo Ohgaki wrote:
> Hi Leigh,
>
> On Thu, Feb 5, 2015 at 5:31 PM, Leigh wrote:
>
>> On 5 February 2015 at 05:37, Adam Harvey wrote:
>> > I'm not totally clear on what this RFC is proposing, honestly. Is the
>> > new script statement meant to only include files t
Hi Leigh,
On Thu, Feb 5, 2015 at 5:31 PM, Leigh wrote:
> On 5 February 2015 at 05:37, Adam Harvey wrote:
> > I'm not totally clear on what this RFC is proposing, honestly. Is the
> > new script statement meant to only include files that are entirely
> > wrapped in tags? Are files included that
> De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
> How about alternative way that turn 'require' into non embedded mode by INI
> switch?
A big NO for me, as I am using 'include/require' in a lot of programs to
include template files containing mixed text/php content
On 5 February 2015 at 05:37, Adam Harvey wrote:
> I'm not totally clear on what this RFC is proposing, honestly. Is the
> new script statement meant to only include files that are entirely
> wrapped in tags? Are files included that way assumed to
> be PHP and don't require tags? Something else?
On 5 February 2015 at 13:06, Yasuo Ohgaki wrote:
>> Since script()/script_once() is almost copy of require()/require_once(),
> it could be
>> INI option.
>>
>> require_embed = On/Off
>
> Almost all users use 'require' only for script today, I guess.
> I should have included this option in RFC. I'l
Hi Reeze,
On Thu, Feb 5, 2015 at 1:38 PM, reeze wrote:
> The name seems ambiguous , how about "require_script/once" to match
> "do_sth" pattern?
I thought so at first, too.
How about alternative way that turn 'require' into non embedded mode by INI
switch?
> Since script()/script_once() is al
The name seems ambiguous , how about "require_script/once" to match
"do_sth" pattern?
On 5 February 2015 at 10:03, Yasuo Ohgaki wrote:
> Hi all,
>
> On Thu, Feb 5, 2015 at 10:53 AM, Yasuo Ohgaki wrote:
>
> > I would like to discuss my "must have it in PHP 7" item.
> >
> > PHP RFC: script() and
Hi all,
On Thu, Feb 5, 2015 at 10:53 AM, Yasuo Ohgaki wrote:
> I would like to discuss my "must have it in PHP 7" item.
>
> PHP RFC: script() and script_once()
> https://wiki.php.net/rfc/script_and_script_once
>
Since script()/script_once() is almost copy of require()/require_once(), it
could b
27 matches
Mail list logo
