On Fri, May 10, 2019, 2:06 PM Peter Kokot wrote:
>
> The images for such C software are one of the more useless ones. Snaps
> or custom Linux repositories are the way to go here. Because of the
> installation time. Building several extensions from source is really
> time consuming...
Maybe this
On Fri, May 10, 2019 at 2:52 PM Riikka Kalliomäki <
riikka.kalliom...@riimu.net> wrote:
> > The new code has what looks like, to me, a refactor bug. I'd expect that,
> when one adds the JSON_THROW_ON_ERROR flag, one must also remove the
> subsequent json_last_error() handling, as it's no longer re
On Thu, May 9, 2019, 1:59 AM Sara Golemon wrote:
good catch, I did not know all these side effects but the kmg :)
- It won't respect KMG suffixes, but they never really wanted that logic
>anyway.
The only place where I thought it would e used was for handling php.ini
and the likes. I s
On Fri, 10 May 2019 22:55:51 +0200 / Niklas Keller
said :
> That's exactly the reason why I'm for removing it. There will always
> be ways to circumvent open_basedir and setups like this are insecure.
> It gives a false sense of security. It's not better than nothing,
> because most hosting provi
Instead of introducing a declare option or special open tag, how about
another "include" construct, that only allows side-effect free (apart
from class loading) operations?
e.g. "require_noexec 'foobar.php'"
Regards, Niklas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
> I'm against deprecating it or removing it.
>
> As said earlier, it has some security value, especially with mass
> hosting. If I'm hosting thousands of websites for thousands of users,
> using chroot is not doable, and open_basedir is a good alternative (at
> least it's better than nothing).
>
>
> The new code has what looks like, to me, a refactor bug. I'd expect that,
when one adds the JSON_THROW_ON_ERROR flag, one must also remove the
subsequent json_last_error() handling, as it's no longer relevant to that
call and instead relevant to the most recent prior call.
This does create a kin
On Thu, May 9, 2019 at 12:06 PM Dan Ackroyd wrote:
> Apparently there is an implementation detail in JSON_THROW_ON_ERROR
> that differs in the RFC text, from the discussion on list
> http://news.php.net/php.internals/100569:
>
> > I decided to reset it to no error because there's no
> > previous
On Fri, May 10, 2019 at 3:40 PM Dustin Wheeler wrote:
> On Fri, May 10, 2019 at 9:15 AM Lynn wrote:
> >
> > 2. Certain features, can be restricted to php-header files only, meaning
> it
> > does not affect
> >"normal" PHP files. This might open up a whole new range of syntax
> > possibilitie
On Fri, May 10, 2019 at 9:15 AM Lynn wrote:
>
> 2. Certain features, can be restricted to php-header files only, meaning it
> does not affect
>"normal" PHP files. This might open up a whole new range of syntax
> possibilities that
>are currently blocked, such as `@trigger_error()` vs `@Ann
Hi Nikita,
By limiting a header file to declaring code only, a couple of issues could
be tackled:
1. No side effects when loading files. You can assume the global state
remains the same, no
code is executed by this file, and no output can be sent.
2. Certain features, can be restricted to php-
On Fri, May 10, 2019 at 2:30 PM Lynn wrote:
> Hello everyone!
>
> This is my first mail to the internals, my apologies if I made a mistake
> somewhere.
>
> I would like to propose a new type of php "file" called "phph", short for
> "php-header".
> This file could receive an optional open-tag: ` `
Hello everyone!
This is my first mail to the internals, my apologies if I made a mistake
somewhere.
I would like to propose a new type of php "file" called "phph", short for
"php-header".
This file could receive an optional open-tag: `
Hello,
On Tue, 7 May 2019 at 07:01, Martins Sipenko wrote:
>
> Hi,
>
> Has PHP community thought about providing official PHP Docker images?
>
> I'm aware there are php images available on Docker hub, but as their docs
> state those are not to be confused with any official php image provided by
>
14 matches
Mail list logo