On Tue, 7 May 2019 at 20:05, Stanislav Malyshev wrote:
> So before just swinging the ax and dropping it I think we should really
> research what people are actually using open_basedir for. And then try
> to formulate a proper description of what it can be used for without
> claiming any security
Am Di., 7. Mai 2019 um 12:11 Uhr schrieb Nikita Popov :
>
> Hi internals,
>
> The open_basedir ini setting has two significant problems:
>
> 1. It is a major performance hit, because it disables the realpath cache.
>
> 2. Many people think it is a security feature and use it as such. However,
> ope
Hi!
> Le 7 mai 2019 à 12:11, Nikita Popov a écrit :
>
> Hi internals,
>
> The open_basedir ini setting has two significant problems:
>
> 1. It is a major performance hit, because it disables the realpath cache.
>
> 2. Many people think it is a security feature and use it as such. However,
> o
On Tue, May 7, 2019 at 5:14 PM Mark Randall wrote:
> On 07/05/2019 15:22, Gert wrote:
> > My idea, extremely summarized, would be to take the functions that
> > return false/null when they 'error', and instead make them actually
> > throw an error.
>
> It comes up on various discussion forums eve
Hi!
> If scenario (a) gives even a slight security advantage over scenario (b),
> we should think very carefully before removing the feature.
There's definitely _some_ security advantage, defense is always in
layers, and while open_basedir can not be made secure, it certainly can
avert _some_ att
Hi!
> b) update the security policy (https://wiki.php.net/security) to state that
> open_basedir bypasses are not security issues. I believe this has been part
> of Debian's security policy for some time already.
I think we've been treating them this way effectively for a while now.
The big ques
Hi!
> My idea, extremely summarized, would be to take the functions that
> return false/null when they 'error', and instead make them actually
> throw an error.
First of all, they definitely should not throw Error, because Errors are
for very specific types of things that mean the engine does not
> Le 7 mai 2019 à 16:22, Gert a écrit :
>
> Hello internals,
>
> I wanted to propose an RFC, but i'd like to check first if this idea
> has been considered before already.
>
> My idea, extremely summarized, would be to take the functions that
> return false/null when they 'error', and instead m
On 07/05/2019 15:22, Gert wrote:
My idea, extremely summarized, would be to take the functions that
return false/null when they 'error', and instead make them actually
throw an error.
It comes up on various discussion forums every other month. There's a
few downsides to it, but mainly that any
On Tue, May 7, 2019 at 4:22 PM Gert wrote:
> Hello internals,
>
> I wanted to propose an RFC, but i'd like to check first if this idea
> has been considered before already.
>
> My idea, extremely summarized, would be to take the functions that
> return false/null when they 'error', and instead ma
On Tue, May 7, 2019 at 10:22 AM Gert wrote:
> Hello internals,
>
> I wanted to propose an RFC, but i'd like to check first if this idea
> has been considered before already.
>
> My idea, extremely summarized, would be to take the functions that
> return false/null when they 'error', and instead m
Hello internals,
I wanted to propose an RFC, but i'd like to check first if this idea
has been considered before already.
My idea, extremely summarized, would be to take the functions that
return false/null when they 'error', and instead make them actually
throw an error.
Currently, functions li
On 07.05.2019 at 16:09, Nikita Popov wrote:
> On Fri, May 3, 2019 at 11:44 AM Christoph M. Becker
> wrote:
>
>> On 03.05.2019 at 01:18, Björn Larsson wrote:
>>
>>> Did this lead to a bug report?
>>
>> Hmm, apparently not.
>
> This was reported as https://bugs.php.net/bug.php?id=77907 and will be
On Fri, May 3, 2019 at 11:44 AM Christoph M. Becker
wrote:
> On 03.05.2019 at 01:18, Björn Larsson wrote:
>
> > Den 2019-04-11 kl. 15:41, skrev Christoph M. Becker:
> >
> >> On 02.04.2019 at 11:42, Nicolai Scheer wrote:
> >>
> >>> I'm currently in the process of migrating an old application from
Hi Marco,
> The alternative is to expand the reflection API with an array cast operation
> in there, and then migrate existing userland usages to that to retain BC.
That's an interesting proposal - adding new reflection abilities. Hm..
> In addition to that, as someone that used to write a lot
Hey Steven,
On Tue, 7 May 2019, 14:25 Steven Wade, wrote:
> > I’m not against the proposal. I’m mainly asking if there are other ways
> in the language today to accomplish similar things. I would prefer to see
> interfaces used over more magic methods (something like ArraySerializable).
>
> A T
> On May 7, 2019, at 8:52 AM, Stephen Reay wrote:
>
>
>> On 7 May 2019, at 19:47, Steven Wade wrote:
>>
>>> Maybe I’m missing the point (I’ve never used it) of VarDumper, but isn’t
>>> this type of thing exactly why the `__debugInfo` magic method exists?
>>
>>
>> I can't speak for the ex
> On 7 May 2019, at 19:47, Steven Wade wrote:
>
>> Maybe I’m missing the point (I’ve never used it) of VarDumper, but isn’t
>> this type of thing exactly why the `__debugInfo` magic method exists?
>
>
> I can't speak for the exact reason a library like VarDumper is using casting
> versus __
> Maybe I’m missing the point (I’ve never used it) of VarDumper, but isn’t this
> type of thing exactly why the `__debugInfo` magic method exists?
I can't speak for the exact reason a library like VarDumper is using casting
versus __debugInfo, but in trying to find a substitute this morning, I
> On 7 May 2019, at 19:22, Nikita Popov wrote:
>
> On Tue, May 7, 2019 at 2:20 PM Steven Wade wrote:
>
>>> I want to weight in with what Marco expressed. I have the very same
>> concerns and they are major ones for many use cases. Mine is VarDumper.
>>>
>>> Please don't do this the way it is
> We can add a separate function to provide this functionality. We should do
> that anyway because it's both clearer and because (array) already requires
> some special handling for ArrayObject that could be avoided.
Are you talking about adding a separate function to replace my proposed
__toA
> I’m not against the proposal. I’m mainly asking if there are other ways in
> the language today to accomplish similar things. I would prefer to see
> interfaces used over more magic methods (something like ArraySerializable).
A Twitter user pointed out that 7.4 is adding two new magic methods
On Tue, May 7, 2019 at 2:20 PM Steven Wade wrote:
> > I want to weight in with what Marco expressed. I have the very same
> concerns and they are major ones for many use cases. Mine is VarDumper.
> >
> > Please don't do this the way it is described.
>
>
> Is there a way that you'd suggest? First
> I want to weight in with what Marco expressed. I have the very same concerns
> and they are major ones for many use cases. Mine is VarDumper.
>
> Please don't do this the way it is described.
Is there a way that you'd suggest? First of all, TIL some cool things about
"(array) $foo" and how V
On Tue, 7 May 2019 at 11:38, Zeev Suraski wrote:
> - especially here, where folks who rely on it for (even some level of)
> security would have a lot of work on their hands to come up with a
> different solution for isolation.
>
This point is worth dwelling on I think: if someone is using this
On Fri, May 3, 2019 at 1:21 AM G. P. B. wrote:
> Evening internals,
>
> I am not going to go into the details of every email which got sent in the
> past two days as I am busy with Exam revision.
>
I was also kind of busy, but more importantly I wanted to wait a bit before
I reply - as my previo
Hello,
as an end-user, I'd say that it should go the way of the dinosaurs as
request globals and alike went - these days there are a lot of ways to do
it better and way more securely.
Makes it easier on everyone and removes abuse of it for security purposes.
Deprecate 7.4, dump it in 8.0.
Implem
On Tue, May 7, 2019 at 1:25 PM Gert wrote:
> Hello,
>
> If the plan is to remove it in 8.0, then i'd say its beneficial to already
> deprecate it in 7.4. This will give users an earlier warning that these
> upgrades need to happen.
We should definitely deprecate it before removing it, if we dec
On Tue, May 7, 2019 at 1:11 PM Nikita Popov wrote:
> Hi internals,
>
> The open_basedir ini setting has two significant problems:
>
> 1. It is a major performance hit, because it disables the realpath cache.
>
That's true, but only if it's in use. That's kind of fair...
> 2. Many people think
Hello,
If the plan is to remove it in 8.0, then i'd say its beneficial to already
deprecate it in 7.4. This will give users an earlier warning that these
upgrades need to happen.
Cheers
On Tue, 7 May 2019 at 12:18, Joe Watkins wrote:
> Morning Nikita,
>
> It would be wise to do a) and b) regar
Morning Nikita,
It would be wise to do a) and b) regardless of whether it's going to be
removed.
I think +1 on removing it in 8 ... I'm not sure if it should be deprecated
in 7.4 first, or how that would work ?
Cheers
Joe
On Tue, 7 May 2019 at 12:11, Nikita Popov wrote:
> Hi internals,
>
> Th
Hi internals,
The open_basedir ini setting has two significant problems:
1. It is a major performance hit, because it disables the realpath cache.
2. Many people think it is a security feature and use it as such. However,
open_basedir is in reality a "best effort" mechanism, with known
workaroun
On Tue, Apr 23, 2019 at 10:43 AM Nikita Popov wrote:
> Hi internals,
>
> I've opened voting on the RFC to deprecate & remove left associative
> ternary without explicit parentheses. The vote ends 2019-05-07:
>
> https://wiki.php.net/rfc/ternary_associativity
>
> The RFC stays as originally propos
On Tue, Apr 23, 2019 at 10:39 AM Nikita Popov wrote:
> Hi internals,
>
> I've opened the vote on the LSP error RFC. Voting is open until 2019-05-07.
>
> https://wiki.php.net/rfc/lsp_errors
>
> Regards,
> Nikita
>
This RFC has been accepted with 39 votes in favor and 3 against.
Nikita
Hello Martins,
The core leaves building and packaging of PHP to distros and other
community efforts and focuses their efforts on PHP itself. It's a constant
tug of war here on what to maintain or not by the core because whatever is
taken on means it needs to happen for years and decades going forw
VCS Account Approved: sjon approved by salathe \o/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
helping out in de bugtracker with proper assignments and duplicates
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
37 matches
Mail list logo
