Hi!
>> This was a request for feedback
>
> then you should withstand the feedback!
Request for feedback does not mean consent for abuse. You can criticize
without being offensive.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, vis
Again, tell me I'm wrong. I have no problem with that. After all I'd still need
50%+ of people with voting privileges to agree with me which is rather unlikely
if it has major flaws.
I don't claim to know it all, you don't need to get rude for me to listen. As
soon as you do that the discussion
On 9/16/2017 3:50 AM, ilija.tov...@me.com wrote:
That’s fine, I have no problem with feedback. I changed my mind once other
people pointed out the flaws in my thinking. Politely.
Sorry for spending my free time thinking about how to make PHP better. I’m not
claiming to be an expert in any mean
I think there is some idea we can borrow from the discussion of unserialize
security policy. `extract` should not be used on untrusted input, and that's it.
Best regrads,
CHU Zhaowei
On Fri, Sep 15, 2017 at 7:20 PM, wrote:
> Hi!
>
> The `extract` function takes an associative array and
Am 16.09.2017 um 13:48 schrieb Marco Pivetta:
"then don't use it" worked great for `register_globals` and
`magic_quotes`. Not saying it is the same here, but you really ought to
have a bit of a mentality adjustment
so when it is not the same why do you mention it?
there is a difference betw
"then don't use it" worked great for `register_globals` and `magic_quotes`.
Not saying it is the same here, but you really ought to have a bit of a
mentality adjustment.
On 16 Sep 2017 11:36, "li...@rhsoft.net" wrote:
Am 15.09.2017 um 19:20 schrieb ilija.tov...@me.com:
> Hi!
>
> The `extract
That’s fine, I have no problem with feedback. I changed my mind once other
people pointed out the flaws in my thinking. Politely.
Sorry for spending my free time thinking about how to make PHP better. I’m not
claiming to be an expert in any means, hence the RFC.
On 16 Sep 2017, 11:49 +0200, li.
Am 16.09.2017 um 11:44 schrieb ilija.tov...@me.com:
Dude, calm down.
dude when people have no other hobbies than think about removing
functionality for *no gain*
This was a request for feedback
then you should withstand the feedback!
why don't you spend your time for *add* features inst
Dude, calm down.
This was a request for feedback. As other people have pointed out before it may
not be the best idea to remove it since there’s no good way to write the
equivalent code in PHP. No reason to be rude.
On 16 Sep 2017, 11:42 +0200, li...@rhsoft.net , wrote:
>
>
> Am 15.09.2017 um 2
Am 15.09.2017 um 20:27 schrieb Arvids Godjuks:
well, basically, none. Results are from a Q6600 machine and under windows,
so your mileage probably gonna be quite better :)
well, and now implement the EXTR_SKIP in PHP code - that becomes a ugly
piece of code and that only because someone like
Am 15.09.2017 um 19:38 schrieb ilija.tov...@me.com:
I can see your argument. The reasoning behind it is that a function in the
standard library should not encourage unsafe code. Admittedly, since this
function is rarely used
who do you think you are that you can qualify this?
breaking news:
Am 15.09.2017 um 19:20 schrieb ilija.tov...@me.com:
Hi!
The `extract` function takes an associative array and puts it into the local
symbol table.
http://php.net/manual/en/function.extract.php
```
$array = [
‘foo’ => ‘foo’,
‘bar’ => ‘bar’,
];
extract($array);
print $foo; // "foo"
Hi!
On 9/15/17 2:20 PM, ilija.tov...@me.com wrote:
>> no, as there is no special risks
>
> There certainly is. No other function (as far as I’m aware) mutates your
> local symbol table. This means you need to know exactly what symbols are
Sure, because this is the function to mutate your local s
Hi Yasuo
These sound good to me!
There’s still a smaller vulnerability of defining variables beforehand:
```
$data = ['hasAccess' => true];
export($data);
if ($user->isAdmin()) {
$hasAccess = true;
}
if (isset($hasAccess) && $hasAccess === true) {
print 'Bingo';
}
```
but code like th
> no, as there is no special risks
There certainly is. No other function (as far as I’m aware) mutates your local
symbol table. This means you need to know exactly what symbols are defined and
what kind of data you’ll receive when calling `extract`. So basically this is
only safe right at the b
Hi all,
On Sat, Sep 16, 2017 at 2:50 AM, Sara Golemon wrote:
> On Fri, Sep 15, 2017 at 1:35 PM, wrote:
> > The `extract` function takes an associative array and
> > puts it into the local symbol table.
> > http://php.net/manual/en/function.extract.php
> >
> > I seriously doubt the usefulness o
Hi!
> Dangerous meaning that if given untrusted input someone could mess with
> the behaviour of your code. There are risks and benefits to every
Same as many other functions. Given untrusted input, unlink() could
delete files on your hard drive, and file_put_contents() could overwrite
your data
Hi Stas
Dangerous meaning that if given untrusted input someone could mess with the
behaviour of your code. There are risks and benefits to every solution.
Certainly you’d agree that in some cases the risks outweigh the benefits.
As Sara pointed out, this might not be the case here as there’s n
Hi!
> As a second parameter the `extract` function takes some options to
> make this function less dangerous, like `EXTR_SKIP` that
I'd start with specifying what exactly is "dangerous" in this function.
So far I don't see any specific danger. You can shoot yourself in the
foot, so you can with m
> On 16 Sep 2017, at 01:27, Arvids Godjuks wrote:
>
> 2017-09-15 20:52 GMT+03:00 Ryan Pallas :
>
>>> On Fri, Sep 15, 2017 at 11:38 AM, wrote:
>>>
>>> Hi Ryan
>>>
>>> I can see your argument. The reasoning behind it is that a function in
>> the
>>> standard library should not encourage unsafe
Hi Sara
That is indeed a very good point. Haven't thought of that one.
Regards
> On 15. Sep 2017, at 19:50, Sara Golemon wrote:
>
>> On Fri, Sep 15, 2017 at 1:35 PM, wrote:
>> The `extract` function takes an associative array and
>> puts it into the local symbol table.
>> http://php.net/manu
2017-09-15 20:52 GMT+03:00 Ryan Pallas :
> On Fri, Sep 15, 2017 at 11:38 AM, wrote:
>
> > Hi Ryan
> >
> > I can see your argument. The reasoning behind it is that a function in
> the
> > standard library should not encourage unsafe code. Admittedly, since this
> > function is rarely used except f
Hi, (accidentally replied to only OP)...
> On Sep 15, 2017, at 1:35 PM, ilija.tov...@me.com wrote:
>
> Hi Marco
>
> I can see it’s usefulness in this case.
>
> But wouldn’t it be better to implement this by hand in these rare cases (it’s
> 3 lines of code) instead of encouraging the pollution
On Fri, Sep 15, 2017 at 11:50 AM, Sara Golemon wrote:
> On Fri, Sep 15, 2017 at 1:35 PM, wrote:
> > The `extract` function takes an associative array and
> > puts it into the local symbol table.
> > http://php.net/manual/en/function.extract.php
> >
> > I seriously doubt the usefulness of this f
On Fri, Sep 15, 2017 at 11:38 AM, wrote:
> Hi Ryan
>
> I can see your argument. The reasoning behind it is that a function in the
> standard library should not encourage unsafe code. Admittedly, since this
> function is rarely used except for templating systems one could call this a
> non-issue.
On Fri, Sep 15, 2017 at 1:35 PM, wrote:
> The `extract` function takes an associative array and
> puts it into the local symbol table.
> http://php.net/manual/en/function.extract.php
>
> I seriously doubt the usefulness of this function,
> especially looking at the potential risks. The fact
> tha
Hi Ryan
I can see your argument. The reasoning behind it is that a function in the
standard library should not encourage unsafe code. Admittedly, since this
function is rarely used except for templating systems one could call this a
non-issue. I just wanted to bring it up.
Regards
On 15 Sep
Hi,
On 15 Sep 2017 19:37, wrote:
Hi Marco
I can see it’s usefulness in this case.
But wouldn’t it be better to implement this by hand in these rare cases
(it’s 3 lines of code) instead of encouraging the pollution of the symbol
table by unknown input? It’s also clearer since people who don’t k
Hi Marco
I can see it’s usefulness in this case.
But wouldn’t it be better to implement this by hand in these rare cases (it’s 3
lines of code) instead of encouraging the pollution of the symbol table by
unknown input? It’s also clearer since people who don’t know the `extract`
function probab
On Sep 15, 2017 11:22 AM, wrote:
Hi!
The `extract` function takes an associative array and puts it into the
local symbol table.
http://php.net/manual/en/function.extract.php
```
$array = [
‘foo’ => ‘foo’,
‘bar’ => ‘bar’,
];
extract($array);
print $foo; // "foo"
```
As a second parame
Heya,
This is typically used in templating engines.
The one I worked on is
https://github.com/zendframework/zend-view/blob/5523511b6771cb6c060a77f6777426526a8db5ab/src/Renderer/PhpRenderer.php#L491-L492
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On Fri, Sep 15, 2017
31 matches
Mail list logo
