Re: [PHP-DEV] [PATCH] Add configuration value to enable/disable stack trace logging
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 logged in
a production environment.
Test code:
Jun 17 15:58:01 server php[29650]: PHP Fatal error: Call to
undefined function does_not_exist() in /var/www/html/index.php on line 3
PHP 7.4 (dev):
Jun 17 15:58:01 server php[18159]: PHP Fatal error: Uncaught Error:
Call to undefined function does_not_exist() in
/var/www/html/index.php:3#012Stack trace:#012#0
/var/www/html/index.php(5): handle_password('s3cretp4ssword')#012#1
{main}#012 thrown in /var/www/html/index.php on line 3
Suggested patch:
Add a configuration value to be able to prevent exceptions from
logging stack traces.
log_exception_trace = On/Off
It would be optimal to have this disabled as default as novice
administrators would perhaps not be aware that this information would
be logged. For debugging purposes it would be helpful to be able to
enable this but maybe the default value should be set conservatively
to minimize unnecessary problems?
I've added this configuration value in Zend/zend.c as the exception
message is compiled in Zend/zend_exceptions.c. Adding it to
main/main.c would change the scope from zend_compiler_globals to
php_core_globals and I guess that you wouldn't want to mix them?
Link to pull request: https://github.com/php/php-src/pull/4281
Regards, Erik Lundin
Hi,
In our environment these kind of errors goes to the Apache error log.
We have full control of the complete LAMP stack and it's only our
ISP who can access these. So little risk for leakage of sensitive info.
Now we have a large legacy code base that has been migrated from
PHP 5.2 to PHP 7.3. Even if we have tested a lot we have had great
usage of these kind of stack traces in the production environment.
It helped us fixing the (hopefully) last issues. We also have a kind of
beta site, but we didn't got enough traffic on that one to trigger the
errors we got in production.
My 50c on this subject, well aware of that having "ownership" of the
LAMP stack is one prerequisite to not disclose sensitive info.
r//Björn Larsson
A "me too" from here.
For stacktraces with fully qualified class names, I would rather like to
have the max string length of arguments in the backtrace configurable
instead of the currently hard coded value.
Also, what about cutting a base path from the stack trace? Having
something like "/opt/projects/customer/project/" no longer in the trace
would be more readable for the developer, and, in case somebody has
dispay_errors=on, a bit less of information disclosure.
Just my 2c
Thomas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Add configuration value to enable/disable stack trace logging
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 which would be one less thing to
maintain.
/Erik
> 17 juni 2019 kl. 21:27 skrev 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 logged in a production environment.
>>
>> Test code:
>> > function handle_password($a) {
>> does_not_exist();
>> }
>> handle_password('s3cretp4ssword');
>>
>> PHP 5.4.16:
>> Jun 17 15:58:01 server php[29650]: PHP Fatal error: Call to undefined
>> function does_not_exist() in /var/www/html/index.php on line 3
>>
>> PHP 7.4 (dev):
>> Jun 17 15:58:01 server php[18159]: PHP Fatal error: Uncaught Error: Call to
>> undefined function does_not_exist() in /var/www/html/index.php:3#012Stack
>> trace:#012#0 /var/www/html/index.php(5):
>> handle_password('s3cretp4ssword')#012#1 {main}#012 thrown in
>> /var/www/html/index.php on line 3
>>
>> Suggested patch:
>> Add a configuration value to be able to prevent exceptions from logging
>> stack traces.
>>
>> log_exception_trace = On/Off
>>
>> It would be optimal to have this disabled as default as novice
>> administrators would perhaps not be aware that this information would be
>> logged. For debugging purposes it would be helpful to be able to enable this
>> but maybe the default value should be set conservatively to minimize
>> unnecessary problems?
>>
>> I've added this configuration value in Zend/zend.c as the exception message
>> is compiled in Zend/zend_exceptions.c. Adding it to main/main.c would change
>> the scope from zend_compiler_globals to php_core_globals and I guess that
>> you wouldn't want to mix them?
>>
>> Link to pull request: https://github.com/php/php-src/pull/4281
>>
>> Regards, Erik Lundin
>>
> Hi,
>
> In our environment these kind of errors goes to the Apache error log.
> We have full control of the complete LAMP stack and it's only our
> ISP who can access these. So little risk for leakage of sensitive info.
>
> Now we have a large legacy code base that has been migrated from
> PHP 5.2 to PHP 7.3. Even if we have tested a lot we have had great
> usage of these kind of stack traces in the production environment.
> It helped us fixing the (hopefully) last issues. We also have a kind of
> beta site, but we didn't got enough traffic on that one to trigger the
> errors we got in production.
>
> My 50c on this subject, well aware of that having "ownership" of the
> LAMP stack is one prerequisite to not disclose sensitive info.
>
> r//Björn Larsson
Re: [PHP-DEV][RFC] Alternative "use" syntax for Closures
> 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 “parent" are now available in the >> “child?” This seems like it could result in some unexpected surprises as >> scope “leaks” across these boundaries. > > Just the ones which are used, like short closures. I see. So it would figure it out based on scope and only use those variables that are explicitly used. This is somewhat similar to the way $this works in closures today. I think I would be okay with this functionality, especially if this is how short closures work. -Ben signature.asc Description: Message signed with OpenPGP
Re: [PHP-DEV] [PATCH] Add configuration value to enable/disable stack trace logging
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 code:
Jun 17 15:58:01 server php[29650]: PHP Fatal error: Call to undefined
function does_not_exist() in /var/www/html/index.php on line 3
PHP 7.4 (dev):
Jun 17 15:58:01 server php[18159]: PHP Fatal error: Uncaught Error:
Call to undefined function does_not_exist() in
/var/www/html/index.php:3#012Stack trace:#012#0
/var/www/html/index.php(5): handle_password('s3cretp4ssword')#012#1
{main}#012 thrown in /var/www/html/index.php on line 3
Suggested patch:
Add a configuration value to be able to prevent exceptions from
logging stack traces.
log_exception_trace = On/Off
It would be optimal to have this disabled as default as novice
administrators would perhaps not be aware that this information would
be logged. For debugging purposes it would be helpful to be able to
enable this but maybe the default value should be set conservatively
to minimize unnecessary problems?
I've added this configuration value in Zend/zend.c as the exception
message is compiled in Zend/zend_exceptions.c. Adding it to
main/main.c would change the scope from zend_compiler_globals to
php_core_globals and I guess that you wouldn't want to mix them?
Link to pull request: https://github.com/php/php-src/pull/4281
Regards, Erik Lundin
Hi,
In our environment these kind of errors goes to the Apache error log.
We have full control of the complete LAMP stack and it's only our
ISP who can access these. So little risk for leakage of sensitive info.
Now we have a large legacy code base that has been migrated from
PHP 5.2 to PHP 7.3. Even if we have tested a lot we have had great
usage of these kind of stack traces in the production environment.
It helped us fixing the (hopefully) last issues. We also have a kind of
beta site, but we didn't got enough traffic on that one to trigger the
errors we got in production.
My 50c on this subject, well aware of that having "ownership" of the
LAMP stack is one prerequisite to not disclose sensitive info.
r//Björn Larsson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] Add configuration value to enable/disable stack tracelogging
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 process, as nobody can merge an implementation of this without consensus. Cheers Joe On Mon, 17 Jun 2019 at 20:31, Erik Lundin wrote: > 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 this should be enabled in steps? > > No stack trace (Default?) > Stack trace with obfuscated argument-data > Full stack trace > /Erik Lundin > > > > 17 juni 2019 kl. 19:45 skrev Mark Randall : > > > >> 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 to the full stack trace is, in my opinion, an essential > tool for debugging. > > > > Standard PHP Error reporting should always be disabled on production. > > > > On the other hand, security in layers, and the less information you > hold, the less probability there is of it getting out, or being > catastrophic when you do, so having the option to turn it off wouldn't hurt. > > > > As it happens I was dealing with some issues last month where my first > order exception handler was failing, and logs were being put into > stackdriver where they could potentially have been accessed by those who > don't have direct access to the processes but do have access to logging. > > > > I was wondering at the time if it would be possible to supply a public > key via the PHP.ini and have the outputs encrypted before being written - > as this is how I handle the stack traces in my userland exception logging > database and IMHO would provide best-of-both-worlds. > > > > The benefits of public key vs a symmetric key are that the logs remain > secure even with read access to php.ini. > > > > -- > > Mark Randall > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > >
Re: [PHP-DEV] Re: [PATCH] Add configuration value to enable/disable stack tracelogging
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 this should be enabled in steps? No stack trace (Default?) Stack trace with obfuscated argument-data Full stack trace /Erik Lundin > 17 juni 2019 kl. 19:45 skrev Mark Randall : > >> 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 to the full stack trace is, in my opinion, an essential tool > for debugging. > > Standard PHP Error reporting should always be disabled on production. > > On the other hand, security in layers, and the less information you hold, the > less probability there is of it getting out, or being catastrophic when you > do, so having the option to turn it off wouldn't hurt. > > As it happens I was dealing with some issues last month where my first order > exception handler was failing, and logs were being put into stackdriver where > they could potentially have been accessed by those who don't have direct > access to the processes but do have access to logging. > > I was wondering at the time if it would be possible to supply a public key > via the PHP.ini and have the outputs encrypted before being written - as this > is how I handle the stack traces in my userland exception logging database > and IMHO would provide best-of-both-worlds. > > The benefits of public key vs a symmetric key are that the logs remain secure > even with read access to php.ini. > > -- > Mark Randall > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
Re: [PHP-DEV][RFC] Alternative "use" syntax for Closures
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 result in some unexpected surprises as scope
“leaks” across these boundaries.
Just the ones which are used, like short closures.
$x = 0;
$y = 1;
$z = 2;
$closure = function($value) use (...) {
$result = $x * $y * $value;
if (something($result)) {
return $result;
}
return -1;
};
$x and $y would be captured, $z would not be. I believe this is how
short closures are implemented, but is at present only supporting a
single line.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] Add configuration value to enable/disable stack tracelogging
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 to the full stack trace is, in my opinion, an essential tool for debugging. Standard PHP Error reporting should always be disabled on production. On the other hand, security in layers, and the less information you hold, the less probability there is of it getting out, or being catastrophic when you do, so having the option to turn it off wouldn't hurt. As it happens I was dealing with some issues last month where my first order exception handler was failing, and logs were being put into stackdriver where they could potentially have been accessed by those who don't have direct access to the processes but do have access to logging. I was wondering at the time if it would be possible to supply a public key via the PHP.ini and have the outputs encrypted before being written - as this is how I handle the stack traces in my userland exception logging database and IMHO would provide best-of-both-worlds. The benefits of public key vs a symmetric key are that the logs remain secure even with read access to php.ini. -- Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Add configuration value to enable/disable stack trace logging
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 Fatal error: Call to undefined
function does_not_exist() in /var/www/html/index.php on line 3
PHP 7.4 (dev):
Jun 17 15:58:01 server php[18159]: PHP Fatal error: Uncaught Error: Call
to undefined function does_not_exist() in
/var/www/html/index.php:3#012Stack trace:#012#0
/var/www/html/index.php(5): handle_password('s3cretp4ssword')#012#1
{main}#012 thrown in /var/www/html/index.php on line 3
Suggested patch:
Add a configuration value to be able to prevent exceptions from logging
stack traces.
log_exception_trace = On/Off
It would be optimal to have this disabled as default as novice
administrators would perhaps not be aware that this information would be
logged. For debugging purposes it would be helpful to be able to enable
this but maybe the default value should be set conservatively to minimize
unnecessary problems?
I've added this configuration value in Zend/zend.c as the exception
message is compiled in Zend/zend_exceptions.c. Adding it to main/main.c
would change the scope from zend_compiler_globals to php_core_globals and
I guess that you wouldn't want to mix them?
Link to pull request: https://github.com/php/php-src/pull/4281
Regards, Erik Lundin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][RFC] Alternative "use" syntax for Closures
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 specifically when the closure is created
> and not when the closure is executed.
>
Hi Kalle,
Thanks for the background info, I've often wondered why the syntax isn't
more similar to "global" and "static" declarations. It hadn't occurred to
me before that the function signature can be processed without inspecting
the function body.
While I think the proposed syntax has its upsides, I agree with others that
adding it as an alternative at this stage doesn't add very much. People who
don't like explicit imports still won't like it, and people who are used to
the existing syntax will write style guides prohibiting the new.
When I suggested on SO chat that a long list of imports was a similarly bad
sign as a long list of parameters, I was scoffed at, so I would be
interested to see examples where large numbers of imports are justified.
Assuming there are such use cases, it seems like automatic capture will be
a better solution. I'm not personally keen on extending the arrow syntax
with a full body - "fn()=>{}" is barely shorter than "function(){}", and I
think "arrow functions are for short expressions" is a useful distinction
and constraint.
If we really need automatic capture, I'd prefer for it to be opted into in
the normal syntax, e.g. "function() use(*) { ... }". We could even have
"use(&*)" for "automatic capture by reference", if we wanted to go that far.
Regards,
--
Rowan Collins
[IMSoP]
Re: [PHP-DEV][RFC] Alternative "use" syntax for Closures
> 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
> more difficult to parse in my brain.
>
> If there was a:
>
> $x = 0;
> $y = 1;
>
> $closure = function() use (...) {
>
> };
>
> 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 result in some unexpected surprises as scope
“leaks” across these boundaries.
As others have pointed out, I think there are better ways to solve the problem
illustrated in the RFC. With a bit more code, you can use an anonymous object
to accomplish the same thing, without any use statements.
$anonymousObject = new class(
$var1,
$var2,
$var3,
$var4
) {
private $v1, $v2, $v3, $v4;
public function __construct(
$importVariable1,
&$importVariable2,
$importVariable3,
&$importVariable4
) {
$this->v1 = $importVariable1;
$this->v2 = $importVariable2;
$this->v3 = $importVariable3;
$this->v4 = $importVariable4;
}
public function __invoke(
ArgumentType $argument1,
ArgumentType $argument2,
ArgumentType $argument3,
ArgumentType $argument4
): ReturnType {
// do whatever you need here, accessing $this->v1, etc.
}
};
However, I would argue that, if you find yourself needing to do something this
complex, it’s probably best to move it into its own named class so that it’s
easier to test and maintain.
-Ben
signature.asc
Description: Message signed with OpenPGP
[PHP-DEV] Preloading experiments with Symfony
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, requiring twice a file that declares a preloaded class will not yield any error, while when preloading is not used, one will get a cannot redeclare error. On the other side, when require_once is used, a preloaded class file is not considered "already loaded", which means the require happens during execution. Would it make sense to change both these behaviors to make them more in line with normal engine behavior? i.e. "require_once" on a file that was already preloaded wouldn't require it again, and "require" on a preloaded file that contains a class declaration would yield a "cannot redeclare" fatal error? This would be more expected to me. Would it be possible? Thanks, Nicolas
[PHP-DEV] Re: Disabling arginfo argument type checks for internal functions
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 > this lands, PRs to add arginfo types (available through reflection) to > internal functions will be accepted. > > As a sanity check, debug builds will make sure that the function call > either throws or passes arginfo type checks -- this will help avoid the > additional of arginfo types that are not correct enforced by the > implementation. > These changes have now landed. This means that arginfo types (both argument and return) can now be added to internal functions. See https://github.com/php/php-src/commit/227a9c75ec01800cb2b02d58ab74ec72abccf478 for a small sample. PRs are welcome :) Nikita
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
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 long run? > > I'm just checking then why is this RFC in the pending implementation > state if basically we're on a way to have the short opening tags in > PHP for ever... Maybe we should then enable them by default to have > the other way around situation of having both tags for few 10 years > and then ditch the long one if it's not going to be deprecated in PHP > 7.4 and decided what to do with them? > > https://wiki.php.net/rfc/deprecate_php_short_tags > Girgias has put up a new implementation at https://github.com/php/php-src/pull/4263. If short_open_tag=On and
Re: [PHP-DEV][RFC] Alternative "use" syntax for Closures
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 propose; that is not feasible in PHP; why? because it would > require a preprocessor; in the case presented, it would be necessary to > import all that existing scope then making a selection; nobody wants that > to happen. > > 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, you made smile. > Please keep discussion constructive and refrain from ad hominems. If this happens again, you will be removed from this mailing list. Nikita
Re: [PHP-DEV][RFC] Alternative "use" syntax for Closures
> > ""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, you made smile. > > Please try and keep it civil. That was uncalled for. This is not the first time (nor the second) that this Mr Moe has an inappropriate conduct on this list and depsises or otherwise makes fun of other users. Maybe a word of warning would be appropriate now.
Re: [PHP-DEV][RFC] Alternative "use" syntax for Closures
""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 yourself beyond what you > can grasp; but anyhow, my dear, it's refreshing, you made smile. Please try and keep it civil. That was uncalled for. - Mark Clements (HappyDog) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
