Am 17.06.19 um 21:27 schrieb Björn Larsson:
Den 2019-06-17 kl. 19:10, skrev Erik Lundin:
Background:
The latest version of PHP seems to handle fatal errors as exceptions
which results in stack traces being logged. Stack traces can
potentially contain sensitive information and should not be
Joe’s solution seems to fix the problem. I havent tested it yet though. I would
have been forced to patch this reguardless before bringing php 7+ into
production. His fix would be enough to protect the data provided proper config
files are enforced.
Thanks Joe! Hopefully this will be merged
> On Jun 17, 2019, at 12:50, Mark Randall wrote:
>
> On 17/06/2019 15:40, Ben Ramsey wrote:
>>> Where "use (...)" would auto-capture all of the used variables in a similar
>>> manner to short closures, that would certainly save a bit of time.
>
>> Would this mean that all variables in the
Den 2019-06-17 kl. 19:10, skrev Erik Lundin:
Background:
The latest version of PHP seems to handle fatal errors as exceptions
which results in stack traces being logged. Stack traces can
potentially contain sensitive information and should not be logged in
a production environment.
Test
Evening all,
I've prepared an alternative: https://github.com/php/php-src/pull/4282
Hiding the arguments seems sensible enough, not as a hardcoded default
(default behaviour should be retained), but as a documented recommended
default for production.
I think, this needs to go through the RFC
Encrypting logs could potentially impact performance alot. My opinion is that
core dumps and full stack traces should be disabled by default and activated
only when needed to minimize the risk of data leaks. However, logging is
needed. You need to get information about what went wrong.
Maybe
On 17/06/2019 15:40, Ben Ramsey wrote:
Where "use (...)" would auto-capture all of the used variables in a similar
manner to short closures, that would certainly save a bit of time.
Would this mean that all variables in the “parent" are now available in the
“child?” This seems like it could
On 17/06/2019 18:10, Erik Lundin wrote:
Background:
The latest version of PHP seems to handle fatal errors as exceptions
which results in stack traces being logged. Stack traces can potentially
contain sensitive information and should not be logged in a production
environment.
Having access
Background:
The latest version of PHP seems to handle fatal errors as exceptions which
results in stack traces being logged. Stack traces can potentially contain
sensitive information and should not be logged in a production
environment.
Test code:
Jun 17 15:58:01 server php[29650]: PHP
On Sat, 15 Jun 2019 at 23:22, Kalle Sommer Nielsen wrote:
> The proposed syntax was also that of the proposed syntax when closures
> arrived in 5.3 (and back then it was using the then keyword
> 'lexical'), anyway. I believe the current syntax was chosen due to
> scopes, as values are bound
> On Jun 16, 2019, at 07:04, Mark Randall wrote:
>
> On 15/06/2019 22:53, Wes wrote:
>> Hello PHP, I just published
>> https://wiki.php.net/rfc/alternative-closure-use-syntax
>> I would love your opinion on this
>
> I'm not overly fond of it myself because I think it could make it slightly
>
Hello,
I experimented with preload on a small Symfony app. I have two segfaults on
my patch to make it work, reported here:
https://bugs.php.net/bug.php?id=78175
I also opened https://bugs.php.net/bug.php?id=78169 but were asked to raise
the point on the list:
When opcache.preload is used,
On Thu, Jun 6, 2019 at 2:41 PM Nikita Popov wrote:
> Hi internals,
>
> I plan to disable the checking of arginfo argument types for internal
> functions in https://github.com/php/php-src/pull/4232 (PHP 8 only). This
> is necessary to avoid duplicate type checks in both arginfo and zpp. Once
>
On Fri, May 24, 2019 at 6:53 PM Peter Kokot wrote:
> Hello,
>
> On Sat, 11 May 2019 at 20:56, Peter Kokot wrote:
> >
> > Not trying to rush anyone to something they have no energy working on
> > anymore here but what's the plan here then? And what plan is there
> > with these short tags on the
On Sun, Jun 16, 2019 at 3:02 AM M. W. Moe wrote:
> Hello,
>
> if you are upset; it's not the place here; your argument is efficiently
> based on problems of indentation and handling commas
> properly.
>
> Moreover, but not least, you have no idea what a lambda is; if we admit it
> what you
>
> ""M. W. Moe"" wrote
> > If you do not accept any rational criticism; you should think of doing
> > something else; I do not know; gardening maybe? who knows.
> >
> > P.S For my use of the "closure" you made a fool yourself beyond what you
> > can grasp; but anyhow, my dear, it's refreshing,
""M. W. Moe"" wrote in message
news:CAHN63oOGX1E8n2_N7-m=vhytf7kxccpvlw3lokrotnzuzz-...@mail.gmail.com...
> If you do not accept any rational criticism; you should think of doing
> something else; I do not know; gardening maybe? who knows.
>
> P.S For my use of the "closure" you made a fool
17 matches
Mail list logo
