[PHP-DEV] Request RFC karma

[Steven Penny]

please and thank you

https://github.com/php/php-src/pull/3918

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] FFI class introduces non-standard method types (can be called statically and non-statically)

[Mark Clements (HappyDog)]

Hi there,

I've been reading with interest about the new FFI class that has been
introduced in PHP 7.4 [1].

However, I was surprised to see that the class includes bivalent methods,
that is to say methods that can be called both statically and
non-statically.  For example, new() [2], which can be called as:

   FFI::new(...)

or non-statically:

  $objFFI->new(...)

(Note that the latter is not simply a short-cut to the former, as it
accesses the instance properties.)

As you can see, this is a very useful design pattern, but it is one that is
currently disallowed in userland code:

* If you declare a method as static, you can call it in both ways, but in
neither case can you access the instance properties or any other instance
functionality ($this is undefined).
* If you don't declare the method as static, and call it statically, you get
a deprecation notice:

   Deprecated: Non-static method MyClass::MyMethod() should not be called
   statically in file.php on line X

This FFI class is therefore introducing an inconsistency in the language.
My understanding is that the general direction of travel is to try and
remove language inconsistencies, where possible, so introducing new ones
seems like something that should be strongly avoided where possible.

My preference would be to resolve this inconsistency by un-deprecating the
uses of non-static methods in a static context.  As per the example in the
FFI class, there are clearly use-cases where both methods of calling a
function are desirable.  We have a number of such examples in our code (e.g.
we have a GetMonthName() function in our date class, which can either
operate on an instantiated object or be called statically with any date-like
argument).  These functions currently detect the context and only access
$this when called non-statically.  Correctly implemented, this type of
overloading leads to very clean interfaces (though I understand the risks
that inexperienced programmers might face).

Alternatively, the FFI class should implement two different methods for the
different contexts.

This should be resolved before 7.4 is released.

Kind regards,

- Mark Clements (HappyDog)


[1] https://www.php.net/manual/en/class.ffi.php
[2] https://www.php.net/manual/en/ffi.new.php




-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: commit 374f76998 causes getenv to be define with Xdebug loaded

[Joe Watkins]

For reference, and because it may be easier to debug than xdebug:

https://github.com/nbs-system/snuffleupagus/issues/293

Cheers
Joe

On Thu, 13 Jun 2019 at 20:50, Dmitry Stogov  wrote:

> I'll try to check what was wrong with this commit and xdebug.
>
>
> Thanks. Dmitry.
> --
> *From:* Joe Watkins 
> *Sent:* Wednesday, June 12, 2019 9:38:54 PM
> *To:* Derick Rethans
> *Cc:* Dmitry Stogov; PHP Developers Mailing List
> *Subject:* Re: commit 374f76998 causes getenv to be define with Xdebug
> loaded
>
> Hi all,
>
> My clumsy ass reverted that in PHP-7.4, totally and utterly by accident,
> and since it resolved Dericks problem, I went ahead and reverted in master
> also rather than make maybe unnecessary noise.
>
> Very very sorry about that, I totally intended to get Dmitry's
> approval/opinion.
>
> Terrible form, I'm sorry, I just pushed in the wrong shell.
>
> If the revert is terrible, feel free to shout at me and revert the revert.
>
> Cheers
> Joe
>
> On Wed, 12 Jun 2019 at 20:04, Derick Rethans  wrote:
>
> Hi Dmitry,
>
> I've just fetch the latest PHP-7.4 source from GIT to finalise Xdebug
> support for it, and after compiling PHP and Xdebug, I now run into the
> following error:
>
> Warning: define() expects at least 2 parameters, 1 given in
> /home/derick/dev/php/derickr-xdebug/run-xdebug-tests.php on line 2749
>
> Line 2749 is not using define, and instead is:
> $JUNIT = getenv('TEST_PHP_JUNIT');
>
> I have tracked this down with git bisect to be this commit:
> https://github.com/php/php-src/commit/374f76998
>
> Could you have a look and let me know what's up? Joe suggests that this
> might need reverting.
>
> cheers,
> Derick
>
> --
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
> or become my Patron: https://www.patreon.com/derickr
> twitter: @derickr and @xdebug
>
>

[PHP-DEV] Re: commit 374f76998 causes getenv to be define with Xdebug loaded

[Dmitry Stogov]

I'll try to check what was wrong with this commit and xdebug.


Thanks. Dmitry.


From: Joe Watkins 
Sent: Wednesday, June 12, 2019 9:38:54 PM
To: Derick Rethans
Cc: Dmitry Stogov; PHP Developers Mailing List
Subject: Re: commit 374f76998 causes getenv to be define with Xdebug loaded

Hi all,

My clumsy ass reverted that in PHP-7.4, totally and utterly by accident, and 
since it resolved Dericks problem, I went ahead and reverted in master also 
rather than make maybe unnecessary noise.

Very very sorry about that, I totally intended to get Dmitry's approval/opinion.

Terrible form, I'm sorry, I just pushed in the wrong shell.

If the revert is terrible, feel free to shout at me and revert the revert.

Cheers
Joe

On Wed, 12 Jun 2019 at 20:04, Derick Rethans 
mailto:der...@php.net>> wrote:
Hi Dmitry,

I've just fetch the latest PHP-7.4 source from GIT to finalise Xdebug
support for it, and after compiling PHP and Xdebug, I now run into the
following error:

Warning: define() expects at least 2 parameters, 1 given in
/home/derick/dev/php/derickr-xdebug/run-xdebug-tests.php on line 2749

Line 2749 is not using define, and instead is:
$JUNIT = getenv('TEST_PHP_JUNIT');

I have tracked this down with git bisect to be this commit:
https://github.com/php/php-src/commit/374f76998

Could you have a look and let me know what's up? Joe suggests that this
might need reverting.

cheers,
Derick

--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
or become my Patron: https://www.patreon.com/derickr
twitter: @derickr and @xdebug

Re: [PHP-DEV] Re: [RFC][Vote] Covariant Returns and Contravariant Parameters

[Nikita Popov]

On Wed, May 8, 2019 at 6:51 PM Levi Morrison  wrote:

> On Wed, May 8, 2019 at 2:06 AM Nikita Popov  wrote:
> >
> > On Tue, Jan 22, 2019 at 6:59 PM Levi Morrison  wrote:
> >>
> >> On Tue, Jan 15, 2019 at 1:27 PM Christoph M. Becker 
> wrote:
> >> >
> >> > On 04.01.2019 at 20:17, Levi Morrison wrote:
> >> >
> >> > > I intend to close the vote in a day or two, unless I hear of new>
> issues from Dmitry or others.
> >> > Any news here?
> >> >
> >> > --
> >> > Christoph M. Becker
> >>
> >> I sent this a week ago to Christoph only; oops.
> >>
> >> I have not heard any news. The vote is now closed. The RFC passes 39
> >> in favor to 1 against.
> >>
> >> Special thanks to Nikita and Dmitry who have helped find issues and
> >> review the patch. It will not be merged until the implementation
> >> quality is satisfactory.
> >
> >
> > As we're moving steadily towards 7.4 feature freeze, I'd like to discuss
> what we want to do with this RFC... The current implementation doesn't work
> correctly (I've done some more work in
> https://github.com/nikic/php-src/commits/variance-7.4, but it's also
> incomplete) and I have some doubts about how we're approaching this in
> general.
> >
> > This RFC really has two parts:
> > 1. The actual variance change. This is a very straightforward change and
> there are no issues here.
> > 2. The ability to check variance across multiple consecutive class
> definitions. This allows type declarations to reference classes that are
> declared later in the same file (but within one "block" of declarations).
> >
> > The second part is technically more dicey and somewhat arbitrary when
> seen in the wider scope of how class hoisting and early binding work in
> PHP: While PHP supports declaring classes "out of order" in some very
> simple cases like this...
> >
> > class B extends A {}
> > class A {}
> >
> > ...it will not work for anything more involved than that, for example
> >
> > class C extends B {}
> > class B extends A {}
> > class A {}
> >
> > will already generate a "class not found" error.
> >
> > Now the variance RFC tackles one very specific part of this
> long-standing issue: The types referenced in parameter and return types may
> be declared later in the file (even if used variantly), but all other uses
> of the types still need to respect the declaration order.
> >
> > I think that we should be separating these two issues (variance and
> declaration order), and land the simple variance support in 7.4, while
> tackling the declaration order problem *in full* separately (in PHP 8,
> because I think we may want to make some BC breaking changes, in particular
> by making the class hoisting unconditional.)
> >
> > Thoughts on this approach?
> >
> > Nikita
>
> I fully support this approach. I will prepare a patch for simple
> variance in PHP 7.4. I intend to leave the existing test cases that
> will fail without supporting consecutive declarations, but marked as
> expected failures.
>
> I think in PHP 8 we can already benefit from the [always generate
> fatal error for incompatible method signatures RFC][1]. We might also
> be able to make some improvements with compile-time errors on invalid
> "parent::" usage (previously done for PHP 7.4 but [backed out][2]),
> which might make things a bit more straightforward (it might not --
> turns out parent is not exactly what I thought it was).
>
>   [1]: https://wiki.php.net/rfc/lsp_errors
>   [2]:
> https://github.com/php/php-src/commit/deb44d405eb27a6654ad9a57c1e5f641218b22a4


An update on this: The last part of covariance support has landed [1] a few
days ago and is part of 7.4 alpha 1. As already described, full variance is
only supported in conjunction with autoloading. When working in a single
file or with explicit includes, the requirement that classes need to be
declared before being referenced (including reference in variant type
declarations) remains.

This feature turned out to be a *lot* harder than anticipated. My initial
assumption that this would mostly "just work" if we ignore the single file
case was very wrong...

Nikita

[1]
https://github.com/php/php-src/commit/8f8fcbbd397370b407dc2552c4bd6ee4ccb0e93b

Re: [PHP-DEV] The real world ...

[Lester Caine]

On 13/06/2019 15:51, Rowan Collins wrote:

In this case, you already did "wait until later" - you waited until the
client saw it, and had the time and inclination to mention it to you. There
are far better solutions out there, as others have mentioned, that make
sure*you*  see the message in good time. Then you can call up the client
and say "don't use this screen I think it's corrupting the data", rather
than them calling you up after they've entered 1000 corrupted records.


Still can't establish why the 'deprecated' message resulted in the image 
upload failing to complete. The message was down to a missing 'static' 
on a function that was triggered by the image metadata combined with the 
'auto-rotate' of that particular image. Actually the image did not want 
to be rotated but that is another matter. Plug in the missing 'static' 
and the image loads, rotates and thumbnails. But without the message it 
was not obvious the load had not completed. As it happens the next batch 
of images did not see the problem which is obviously why it had been 
missed. I had to go back to the image that I'd already manually fixed 
and reload it to see the problem for myself :( Can you ever guarantee 
perfect coverage of testing?


Several other sites are using the same code so one might expect it to 
have turned up sooner and this machine has been through 7.0 and is now 
running 7.2 so in this case am I just being clobbered by not picking it 
up when moving from PHP5? A lot of the original single use functions 
have grown static versions over the years since the deprecation and I 
suspect there may still be others that may need work :(


By the way the site I posted originally has been completely down since I 
emailed them about it ... which is annoying as I want to chase the order 
I placed Monday ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] The real world ...

[Rowan Collins]

On Thu, 13 Jun 2019 at 14:46, Lester Caine  wrote:

> Had I HIDDEN the warning the client would just have
> ploughed on but now I can divert to fix the faulty bits of data and sort
> the problem! It will be some silly thing missed, but in 20+ years of
> code that are still a lot of those and simply hiding something and
> waiting until later to clear the problems created is never going to be
> right :(
>


Don't underestimate the ability of users to plough on in the face of the
most obvious errors (and then on another day stop dead given the tiniest
unexpected message).

In this case, you already did "wait until later" - you waited until the
client saw it, and had the time and inclination to mention it to you. There
are far better solutions out there, as others have mentioned, that make
sure *you* see the message in good time. Then you can call up the client
and say "don't use this screen I think it's corrupting the data", rather
than them calling you up after they've entered 1000 corrupted records.

A generic message on PHP's default 500 error in place of the notorious
white screen would probably be useful, but it should be limited to
something like:

> A system error has occurred.
> Please contact the site administrator.
> If you are the site administrator, please check your error logs for
details of the error.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] Proposal for a RFC

[Marco Pivetta]

On Thu, Jun 13, 2019 at 4:23 PM Steven Wade  wrote:

> > I guess that's what it comes down to, what *specific* use cases would
> this
> > feature be intended to help with? Is there some code of your own that
> > inspired you to propose it, or something you've seen publically that
> would
> > benefit from it?
>
> Originally, it was inspired by seeing Laravel's use of Arrayable as an
> interface and if something implements that, calling that class' `toArray()`
> method, and wishing that was built in so that frameworks didn't re-invent
> the wheel every time.
>

Interestingly, my work day today is spent mostly removing this kind of
behavior from a codebase riddled by it, replacing it with explicit
conversions where needed.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

[PHP-DEV] Re: Feedback on state of some PHP extensions, functions, etc.

[Christoph M. Becker]

On 12.06.2019 at 17:32, G. P. B. wrote:

> I've been going through the documentation again to remove mentions of PHP 4
> and found some extensions, functions, etc. on which I'd like to know the
> state of them and if it would be wise to deprecate them.
>
> I know I've thrown in some function aliases again, but only those which I
> think wouldn't have widespread usage. If those should still be kept in your
> opinion please let me know.
>
> The list are more rough notes that I took while reading the doc so if
> something seems unclear let me know.
>
>
>- The FILE_USE_INCLUDE_PATH constant in the Filesystem extension being
>an integer makes it unusable with strict types for file_get_contents() [6]
>however it is also used for a flag argument where it can be combined with
>other constants with a binary OR [7] [8].
>Should this be just considered a Doc Bug?

I don't think there's still a bug in the docs regarding
FILE_USE_INCLUDE_PATH.  See the respective note for the
$use_include_path parameter.

>- Unbundle the NSAPI Extension (if this is already the case, there is
>doc error in the membership state of the extension) as it seems obsolete in
>this day and age as it handles Sun/Netscape servers [24]

The NSAPI is removed as of PHP 7.0.0, so the docs should be fixed.

>- Unbundle the XML-RPC extension as it is considered experimental [25]

I wouldn't unbundle ext/xmlrpc because it is documented as being
experimental, but rather because nobody really looks after it, we're
bundling a modified ancient version of libxmlrpc, and even the upstream
libxmlrpc-epi isn't maintained for years.

Thanks,
Christoph

> [6] https://www.php.net/manual/en/function.file-get-contents.php
> [7] https://www.php.net/manual/en/function.file-put-contents.php
> [8] https://www.php.net/manual/en/function.file.php
> [24] https://www.php.net/manual/en/book.nsapi.php
> [25] https://www.php.net/manual/en/intro.xmlrpc.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] The real world ...

[Dustin Wheeler]

On Thu, Jun 13, 2019 at 9:36 AM Marco Pivetta  wrote:
>
> You'd still see the DSN in the traces.
>

My understanding is that if using pdo.dsn.mysql via INI, you wouldn't
see the username / password in traces. I only learned about this
configuration reading through Sjon's PR, but looks reasonable.

To the original issue Lester faces:

The crux of all this is "don't use exceptions to do customer support"!

Most, if not all, log aggregation software (Splunk, ELK-stack, etc.)
give you the ability to configure dashboards or reports to highlight
different levels of "fail-boat" in the environment. We do this in our
environment, which is very heterogeneous and uncontrolled; filled with
undergraduates, graduates, faculty, staff, other IT organizations and
everything in-between. Not only do I have to deal with *my* logs, but
I also have to help facilitate improvements to tenant applications. If
it were me, I would be looking to your system administrators to
improve the configuration and management of your application
monitoring. If you don't have any automated monitoring (Splunk or ELK
(free), Telegraf/InfluxDB, Nagios even), look into these things.
Configure these to solve this problem rather than having customers be
the "free" monitoring solution as a default.

If I tried to pitch to my team that we would just use our users as THE
monitoring solution, I'd not only get some strange looks, but also a
can of surströmming thrown in my face. As developers and system
administrators, we can do better by our users to prevent these types
of errors before they hit them. We can do this through improvements to
our software design life cycle (or, to keep it simple... write tests
and develop somewhere other than production). Ultimately, we're never
going to catch everything... but customers reporting literal
exceptions should be... exceptional :)

P.S. I fully understand the "real world" sentiment even if I perceive
a different reality than yours. In the "real world", people get set in
their ways and higher-ed is no better a place that I have found to
observe this. However, in my experience, even the saltiest of faculty
with their 50 year old "Fortran codes" are amenable to change if it
makes their lives easier. Applying some of these strategies *will*
improve quality of work-life and *will* improve your business. Having
customers report low-level exceptions / stack-traces cannot be "good
for business" and must lower confidence in the product.

Cheers,

-- 
Dustin Wheeler | Software Developer
NC State University
mdwhe...@ncsu.edu
"If you don't know where you're going, it's easy to iteratively not get there."

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposal for a RFC

[Steven Wade]

Apologies for the super late response:

> A recursive method would certainly have more value, because it actually
> does something more than translate one syntax to another. On the other
> hand, the use case that comes to mind is serialization, and we already have
> more specific methods and systems for that.

How could this new magic method be recursive? If it only works if you manually 
declare __toArray() in your class, wouldn't you then as the user be in charge 
of casting anything manually in your method implementation?

> 
> I guess that's what it comes down to, what *specific* use cases would this
> feature be intended to help with? Is there some code of your own that
> inspired you to propose it, or something you've seen publically that would
> benefit from it?

Originally, it was inspired by seeing Laravel's use of Arrayable as an 
interface and if something implements that, calling that class' `toArray()` 
method, and wishing that was built in so that frameworks didn't re-invent the 
wheel every time. 

As far as in my code, collections being cast as an array easily would be nice. 
Models with relationships, being able to implement that cast and control how 
your model and its children are (or aren't) represented. That's useful for 
returning an array in a controller for an API, or for simply adding context to 
a log message.

IMO, the point is, it's another tool in the developers arsenal that they can 
use when they see fit. Not everyone will use it and not everyone will see the 
benefit of it, and that's ok, but for those that would and could, __toArray() 
is for them (and me).

--
Steven Wade
stevenwad...@gmail.com




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] [VOTE] Numeric Literal Separator

[Theodore Brown]

On Thu, May 30, 2019 at 7:50 AM Theodore Brown wrote:
 
> Voting has now started on the Numeric Literal Separator RFC:
> https://wiki.php.net/rfc/numeric_literal_separator
> 
> This feature is widely supported in other languages, and can be very
> helpful for improving code readability and clarifying intent.
> 
> Voting will end in two weeks, on 2019-06-13.

Hi internals,

I'm pleased to announce that this RFC has been accepted, with 33
votes in favor and 11 against. Thank you to everyone who voted!

Best regards,
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] The real world ...

[Andreas Heigl]

Am 13.06.19 um 15:30 schrieb Sjon Hortensius:
> FWIW - hiding database passwords (when using PDO) would be possible when
> https://github.com/php/php-src/pull/2684 gets included

I was more thinking of a more general approach as PDO is not the only
place where passwords are transfered. So having a generic Password-VO
that could be used like a password-string for BC but would not show up
in stack-traces - or at least not the cleartext-password - might improve
the security aspect regardless of where the password will be used. Yes,
at one point the cleartext-password needs to be handed over to the VO
and before that it will appear in stack-traces.


I did a userland-implementation but it still requires to hand over the
cleartext-password to relevant functions in PHP and there the stacktrace
can again leak the password. So having such a functionality in the core
would improve things.

Cheers

Andreas
> 
> Cheers,
> Sjon
> 
> On Thu, Jun 13, 2019 at 9:56 AM Andreas Heigl  wrote:
> 
>> Hey All
>>
>> Am 13.06.19 um 09:41 schrieb Nikita Popov:
>>> On Thu, Jun 13, 2019 at 9:35 AM Lester Caine  wrote:
>>>
 Seen in the wild ... company name sanitised

 Warning: mysqli::mysqli(): (HY000/2002): No such file or directory in
 /home/888/public_html/system/library/db/mysqli.php on line 7

 Fatal error: Uncaught exception 'Exception' with message 'Error: >>> />Error No: ' in /home/888/public_html/system/library/db/mysqli.php:10
 Stack trace: #0
 /home/888/public_html/system/nitro/core/nitro_db.php(29):
 DB\MySQLi->__construct('localhost', '888_4y65f5...',
 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #1
 /home/888/public_html/system/nitro/core/nitro_db.php(13):
 NitroDb->__construct('mysqli', 'localhost', '888_4y65f5...',
 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #2

>> /home/888/public_html/system/storage/modification/system/library/db.php(11):

 NitroDb::getInstanceWithParams('mysqli', 'localhost', '888_4y65f5...',
 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #3
 /home/888/public_html/system/framework.php(36):
 DB->__construct('mysqli', 'localhost', '888_4y65f5...',
 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #4
 /home/888/public_html/vqmod/vqcache/vq2-system_startup.php(124):
 require_once('/home/888 in
 /home/888/public_html/system/library/db/mysqli.php on line 10
 你的代码出错了：

 I presume something has been updated that they have not been aware of
 since it's library file that triggered the warning ... but it's not the
 first time in recent years I've seen this sort of information on
 commercial sites and while my own clients just get white screens, those
 are created by the likes of Wordpress when 'automatic updates' happen.

 Many years ago the response was "well don't update", but 'current
 practice' takes that out of OUR hands! So isn't it time that the
 triggering exceptions like this did produce a more user secure response
 to protect against leaks like this and provide a better alternative than
 a white screen?

 In the case of this live site, I actually placed an order as it was only
 some links that triggered the fault, which may explain why they were not
 even aware there was a problem :( From the 'development' side, NitroDb->
 should obviously be handling the problem anyway.

>>>
>>> display_errors=Off in production.
>>>
>>
>> While that makes absolute sense perhaps thinking whether there is a way
>> to mark password-parameters in core-functions and hide them in
>> Stack-traces might improve security as that would also hide
>> user-provided credentials in log-files.
>> That would not target userland methods/functions. Though having a
>> Core-Value-object for credentials might even allow *that*
>>
>> Just my 0.02 €
>>
>> Cheers
>>
>> Andreas
>> --
>>   ,,,
>>  (o o)
>> +-ooO-(_)-Ooo-+
>> | Andreas Heigl   |
>> | mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
>> | http://andreas.heigl.org   http://hei.gl/wiFKy7 |
>> +-+
>> | http://hei.gl/root-ca   |
>> +-+
>>
>>
> 

-- 
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org   http://hei.gl/wiFKy7 |

Re: [PHP-DEV] The real world ...

[Lester Caine]

On 13/06/2019 13:30, Andrey Andreev wrote:

What I meant is, all a user needs to report to you is that there was a
problem, and since you have logs you can lookup whatever it was
(possibly asking just for a timestamp and/or IP address to pinpoint
the visitor).


JUST had a report of a problem ...
Deprecated: Non-static method LibertyMime::storeMetaData() should not be 
called statically


I need to investigate why it thinks it's non-static but the irritating 
bit here is that "It's just a warning" yet the operation has not 
completed properly. Had I HIDDEN the warning the client would just have 
ploughed on but now I can divert to fix the faulty bits of data and sort 
the problem! It will be some silly thing missed, but in 20+ years of 
code that are still a lot of those and simply hiding something and 
waiting until later to clear the problems created is never going to be 
right :(


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] The real world ...

[Sjon Hortensius]

As literally explained in the PR - dsns are already hidden from userspace.
See https://github.com/php/php-src/pull/2684#issuecomment-32567

Cheers, Sjon

On Thu, Jun 13, 2019 at 3:36 PM Marco Pivetta  wrote:

> On Thu, Jun 13, 2019 at 3:30 PM Sjon Hortensius 
> wrote:
>
>> FWIW - hiding database passwords (when using PDO) would be possible when
>> https://github.com/php/php-src/pull/2684 gets included
>>
>> Cheers,
>> Sjon
>>
>
> You'd still see the DSN in the traces.
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>

Re: [PHP-DEV] The real world ...

[Marco Pivetta]

On Thu, Jun 13, 2019 at 3:30 PM Sjon Hortensius  wrote:

> FWIW - hiding database passwords (when using PDO) would be possible when
> https://github.com/php/php-src/pull/2684 gets included
>
> Cheers,
> Sjon
>

You'd still see the DSN in the traces.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] The real world ...

[Sjon Hortensius]

FWIW - hiding database passwords (when using PDO) would be possible when
https://github.com/php/php-src/pull/2684 gets included

Cheers,
Sjon

On Thu, Jun 13, 2019 at 9:56 AM Andreas Heigl  wrote:

> Hey All
>
> Am 13.06.19 um 09:41 schrieb Nikita Popov:
> > On Thu, Jun 13, 2019 at 9:35 AM Lester Caine  wrote:
> >
> >> Seen in the wild ... company name sanitised
> >>
> >> Warning: mysqli::mysqli(): (HY000/2002): No such file or directory in
> >> /home/888/public_html/system/library/db/mysqli.php on line 7
> >>
> >> Fatal error: Uncaught exception 'Exception' with message 'Error:  >> />Error No: ' in /home/888/public_html/system/library/db/mysqli.php:10
> >> Stack trace: #0
> >> /home/888/public_html/system/nitro/core/nitro_db.php(29):
> >> DB\MySQLi->__construct('localhost', '888_4y65f5...',
> >> 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #1
> >> /home/888/public_html/system/nitro/core/nitro_db.php(13):
> >> NitroDb->__construct('mysqli', 'localhost', '888_4y65f5...',
> >> 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #2
> >>
> /home/888/public_html/system/storage/modification/system/library/db.php(11):
> >>
> >> NitroDb::getInstanceWithParams('mysqli', 'localhost', '888_4y65f5...',
> >> 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #3
> >> /home/888/public_html/system/framework.php(36):
> >> DB->__construct('mysqli', 'localhost', '888_4y65f5...',
> >> 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #4
> >> /home/888/public_html/vqmod/vqcache/vq2-system_startup.php(124):
> >> require_once('/home/888 in
> >> /home/888/public_html/system/library/db/mysqli.php on line 10
> >> 你的代码出错了：
> >>
> >> I presume something has been updated that they have not been aware of
> >> since it's library file that triggered the warning ... but it's not the
> >> first time in recent years I've seen this sort of information on
> >> commercial sites and while my own clients just get white screens, those
> >> are created by the likes of Wordpress when 'automatic updates' happen.
> >>
> >> Many years ago the response was "well don't update", but 'current
> >> practice' takes that out of OUR hands! So isn't it time that the
> >> triggering exceptions like this did produce a more user secure response
> >> to protect against leaks like this and provide a better alternative than
> >> a white screen?
> >>
> >> In the case of this live site, I actually placed an order as it was only
> >> some links that triggered the fault, which may explain why they were not
> >> even aware there was a problem :( From the 'development' side, NitroDb->
> >> should obviously be handling the problem anyway.
> >>
> >
> > display_errors=Off in production.
> >
>
> While that makes absolute sense perhaps thinking whether there is a way
> to mark password-parameters in core-functions and hide them in
> Stack-traces might improve security as that would also hide
> user-provided credentials in log-files.
> That would not target userland methods/functions. Though having a
> Core-Value-object for credentials might even allow *that*
>
> Just my 0.02 €
>
> Cheers
>
> Andreas
> --
>   ,,,
>  (o o)
> +-ooO-(_)-Ooo-+
> | Andreas Heigl   |
> | mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
> | http://andreas.heigl.org   http://hei.gl/wiFKy7 |
> +-+
> | http://hei.gl/root-ca   |
> +-+
>
>

Re: [PHP-DEV] The real world ...

[BohwaZ/PHP]

Le 13/06/2019 14:20, Lester Caine a écrit :

On 13/06/2019 13:04, Andrey Andreev wrote:

You have logs to see the errors; relying on your users to report the
actual error messages to you is the worst way to do it.


How many website logs can you manage on a daily basis? Given the
volume of material in heavily used website. I am STILL trying to get
long established sites back to a state where that would be a practical
approach. Especially when adding material is first element on the
to-do list. I've several hours of such work to get cleared first and
prompts in that traffic is easier to manage than then working through
several machines worth of logs ...


Have you considered using solutions like Sentry? 
https://sentry.io/welcome/


It gets added to the error handler and will report errors to a server. 
Quite handy.


Another solution is to use the shutdown and error handler to send an 
email to you when there is an error:


https://stackoverflow.com/questions/277224/how-do-i-catch-a-php-fatal-error

We used that solution for quite some time, but it can quickly overload 
your email server when you have millions of requests producing errors ;)


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] The real world ...

[Andrey Andreev]

Hi,

On Thu, Jun 13, 2019 at 3:21 PM Lester Caine  wrote:
>
> On 13/06/2019 13:04, Andrey Andreev wrote:
> > You have logs to see the errors; relying on your users to report the
> > actual error messages to you is the worst way to do it.
>
> How many website logs can you manage on a daily basis? Given the volume
> of material in heavily used website. I am STILL trying to get long
> established sites back to a state where that would be a practical
> approach. Especially when adding material is first element on the to-do
> list. I've several hours of such work to get cleared first and prompts
> in that traffic is easier to manage than then working through several
> machines worth of logs ...
>

There's a lot to say about how one can be effective at monitoring
logs, but that's not what I meant.

What I meant is, all a user needs to report to you is that there was a
problem, and since you have logs you can lookup whatever it was
(possibly asking just for a timestamp and/or IP address to pinpoint
the visitor).

Cheers,
Andrey.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] The real world ...

[Lester Caine]

On 13/06/2019 13:04, Andrey Andreev wrote:

You have logs to see the errors; relying on your users to report the
actual error messages to you is the worst way to do it.


How many website logs can you manage on a daily basis? Given the volume 
of material in heavily used website. I am STILL trying to get long 
established sites back to a state where that would be a practical 
approach. Especially when adding material is first element on the to-do 
list. I've several hours of such work to get cleared first and prompts 
in that traffic is easier to manage than then working through several 
machines worth of logs ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] The real world ...

[BohwaZ/PHP]

If you're so keen on providing the user something to see without having
to use display_errors=on: Have you had a look at
https://php.net/register_shutdown_function ?

You can always use that to figure out whether there was a fatal error
and then display something nice to the user.

No leaked stacktrace, no leaked credentials, user is informed, everyone
is happy :-)


Yup everyone should do that.

I personally like Tracy from Nette which has a production mode that will 
show a nice error page: https://tracy.nette.org/en/guide


Perhaps PHP should display a page like that instead of a blank page when 
display_errors is on "Off" no?


I've seen newcomers to PHP getting quite disturbed by just getting a 
blank page and nothing else.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] The real world ...

[Andrey Andreev]

Hi,

I too am in favor of a mechanism to strip out sensitive data from
error messages. But Lester, man, you have it all backwards ...

On Thu, Jun 13, 2019 at 11:37 AM Lester Caine  wrote:
>
> On 13/06/2019 08:55, Andreas Heigl wrote:
> >> display_errors=Off in production.
>
> Which give a white screen ... fine for security but useless for people
> using the site!
>

People using the site are not there to debug it. Whether they see a
white screen or an unhandled error that was never meant for them to
see, it's still bad user experience and of no use to anybody.

> Personally I STILL use display_errors=on and just make sure that
> sensitive information is not displayed in the stack. Most of the time it
> IS just the warnings one gets and clients can report them and see they
> are cleared ... so some sort of middle ground between off and on would
> be helpful?
>

You have logs to see the errors; relying on your users to report the
actual error messages to you is the worst way to do it.

Cheers,
Andrey.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP 7.4.0alpha1 is available for testing

[Derick Rethans]

PHP 7.4.0alpha1 has just been released and can be downloaded from:



Or use the git tag: php-7.4.0alpha1

Windows binaries are available at: 

Please test it carefully, and report any bugs in the bug system.
7.4.0alpha2 should be expected in 2 weeks, i.e. on June 27th, 2019.

Hash values and PGP signatures can be found below or at
.

Thank you, and happy testing!

Regards,
Peter Kokot & Derick Rethans

--

php-7.4.0alpha1.tar.gz
SHA256 hash: 
b199158e0cd2823b4e39379c7f83f41e7e8142b268f48acfc5bb6d48437a1ef1
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl0A39sACgkQkQ3rRvU+
oxJVWw/+Nzfw37yTVS5M7LU/tAhvR+8q2vltZK74ZKgvzs+N/pyOm7UIw0ZKwBvP
wLVOBVP/Z+PjP8L4sHuG7oBFDHmV036WaByjPIYxNM3opBGir7Zhcvu4U8yEh50z
sM0tIayGqob+bZapBOmtEe0k4PFtVCNaCKObEUyvdRpOW03HaqlgLzX4HDltjc4G
l1OUQ08ShTJo9u3QnWY+IeFXS12r83NTdNaPWjvYUCZKILe+lUDUudcPoIM2Hd6+
m2VIZVH/EgguK1EDRRH0ZpIFSQPq+5dZr5NfWxig3kTDTXkUqaBpVORLGtVfj8Uj
xlfC0aXjvBgpaf5ndkKOPUWKK0+ZNIWyRezEgJHA3eWTOh7SpSWFRuCQlVxkBVnl
SSoF1qLmd3b7xyoaFj51Dg3MUNQdUN1I0i0VZ4Ge6U45wpOpysm2q79o8nCEAKGU
B4CYHdyBNuzU5D+N/3inRFrYgIENCopKZv2pJE3VdnTe+x7rIVdGBjkHDXc7OzZX
zDPlBu4NZxgG/3ymbdk9QSrFzxliEYXxeCHhbC++am5iGE8AurH+7iNSEgeJr6i2
JsA1D+TSc2MdxfXvnZECqnKBdodXLyP8ON0hO91A2EwViqjkWunI7YfeH7K5ljJJ
xz1aeEy6gvo2KXaJlkzMJzqH9cTbD64Z1n1qR7AuHvrM5/LNnxI=
=b22l
-END PGP SIGNATURE-

php-7.4.0alpha1.tar.bz2
SHA256 hash: 
b431ac5c35946657be97294951f88fe251a279f0a9eaac3d445b61b71674db36
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl0A390ACgkQkQ3rRvU+
oxLGyQ//ar+fH156Fza2Z5hM34dcsBKP8yW0rqtfxVxTagBHCMHEehqccodvUlYs
tc4S//swg2iS0e/bkGyDOQgUgWxGESKq8ITDxWH1q2JDaANKTLvCPw/jZdWxDtCk
rEHcDhWQniOvIG4QUe69hwu8novdlG9HAlulnGAP7NeaHK4WQQgexhlTVZUAVJi5
rP9igxc4gNhSAw3Rzl0Hgqk7pAv5OGYJByZlpDgCulzNk4ys2CQDAobc2a0Q5wd9
deG0YfRP2TkfiU8qMb2kWXzqrVlpMcwwfb8GnU6CohLTfprl5UiuL8BV1AUyeRMV
3vQ9yulqOLvaWbfYDl7yORrhQ/e9GxQLFLQkXdQghs5oLNDgPAGOJBa9NlyK4PF7
SxCb70ZlsEmGslwHEAjongjVTx4lHfV6QcY5Z0btgMncCae5wln9TAQAElyGBqRJ
7e2iuoHPiQAIBWQ0G2IJOHcjEqmmLWlLjkmkmEUZpx87hFPjwLkEzsvVqXNA2WFl
NoiFp/bxk6UUFYHMlE93DsjFpQ/W/NvU3LEJ+Lng3dp7CmC+QW9iZuH4E2zb2R+c
R8ZpoGBloT05POZKKNoTSmzYXFtSSfmbnMWGhnMLaDzBqyOEtkg6u5sGL8fqvX+I
Tfc4RmiR1L7ULmhYaEBuWc6IQDaO6Jik49hMt5mS9T114+NXPOo=
=au9x
-END PGP SIGNATURE-

php-7.4.0alpha1.tar.xz
SHA256 hash: 
378400b6eced6e358f5db750413a7f9959517b0daef6580b16d640190b7dc364
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAl0A394ACgkQkQ3rRvU+
oxK1whAAztee8g0ab22yMBUnbNFvhnVkDhvw3NDH+kYeJ1UzWHZhsFgrNjX9U8+U
PWIM3O0AIZZoCOcxeHDIBXqqyjuTIxyLraKiILB2elhtka9J9CM3X+75sNBc7IqQ
h9nIdTAIPDigMm0K2bH31CRyW1cAOdCUnp6G8F3R0+sxoo1awNPXaRK/S4SL4h+i
ap9yzUNC7EnU7m6Zg2Y6FlMUXcMV9hWAkRAAt4/8X1ZYdouOGbC5QHhmGaKzta3o
Qzar3RFnzWC6+J1n2B/eP4SBMv9mffvakUdHzUmkBNVkz+/lWyyrETIwiZ+IMtPN
BeTyVX8zfNs5BfElaEGru741NmgiKnYpQs0YBGZG0GKttS4vizeF7e7nFyyTiDRd
Jsnv4hbd1gOWZ9NGvHaNbEjz7eNpRjPxXCnQ4VyHCSoAJYeD67U9MD8TDqpxlHq7
Y3B4OYc5onB9P/biq91TqHLm8fmQsbAjSaZCAsGr+QHmWTA/kpB2wuvWCJy5NPD6
WGBQ/Ni5xu1Th+PuGWyf2hzsdRvIh/42mCn2TrCDd68yu66SemZxJzvTYYCLgJtQ
9lo3Qbc/6ffFSONIQqWPYuuOfoTnxop32a9b+hBgmCB420o7AdxfU4jdepOYJBUC
JQ28rVwPg1HI/EORicucUTZM80HVl15jgLmmoTCcU9c+FQZtOrM=
=/d+Y
-END PGP SIGNATURE-


-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
or become my Patron: https://www.patreon.com/derickr
twitter: @derickr and @xdebug

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] The real world ...

[Andreas Heigl]

Hey Lester, hey All

Am 13.06.19 um 10:36 schrieb Lester Caine:
> On 13/06/2019 08:55, Andreas Heigl wrote:
>>> display_errors=Off in production.
> 
> Which give a white screen ... fine for security but useless for people
> using the site!
> 
>> While that makes absolute sense perhaps thinking whether there is a way
>> to mark password-parameters in core-functions and hide them in
>> Stack-traces might improve security as that would also hide
>> user-provided credentials in log-files.
>> That would not target userland methods/functions. Though having a
>> Core-Value-object for credentials might even allow*that*
> 
> Sanitising things would be a nice to have especially where log files are
> on 'cloud' storage, but the ability to give an end user some indication
> that there is a problem WHILE display_errors=Off would be helpful? I
> know the white screen problem has been discussed many time over the
> years ...
> 
> Personally I STILL use display_errors=on and just make sure that
> sensitive information is not displayed in the stack. Most of the time it
> IS just the warnings one gets and clients can report them and see they
> are cleared ... so some sort of middle ground between off and on would
> be helpful?

If you're so keen on providing the user something to see without having
to use display_errors=on: Have you had a look at
https://php.net/register_shutdown_function ?

You can always use that to figure out whether there was a fatal error
and then display something nice to the user.

No leaked stacktrace, no leaked credentials, user is informed, everyone
is happy :-)

Cheers

Andreas
-- 
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org   http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca   |
+-+



signature.asc
Description: OpenPGP digital signature

[PHP-DEV] PHP 7.3.7RC1 is available for testing

[Christoph M. Becker]

PHP 7.3.7RC1 has just been released and can be downloaded from:



Or use the git tag: php-7.3.7RC1

Windows binaries are available at: 

Please test it carefully, and report any bugs in the bug system.
7.3.7 should be expected in 2 weeks, i.e. on June 27th, 2019.

Hash values and PGP signatures can be found below or at
.

Thank you, and happy testing!

Regards,
Stanislav Malyshev & Christoph M. Becker

--

php-7.3.7RC1.tar.bz2
SHA256 hash:
26ecfdf49bed30a15a29eddffdaea17bb56e196c4a4804a0b6e12ae01548aee7
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAlz/jJ0MHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2cKYP/1z/JL23F7pXTUbFrGIxAnVGf1EZqMdo951vQCDl
wsbStq45+KqnyWKrSOkedCyBKrFeZqHqx/qlxvbbuenY3vA6yBhKWocBp9tP7uY+
RSLvF0RtxqB18ga8n6lZunnlUIuVvKHj1LbwBAoP74tJQYp+n8WSEtYrUg5Q+iq7
p1O8lZv/9Qmt6TnHFxlZ71hG+qNOxOxkdcjBIhIFC8grCWoBy1fQQ+ssRMSydW+B
xjgHraPs91rV5ZaCSb0krmPObpiWfr4Urya77+WIvS26tAXQggDTbDxbI4u7krpb
N4RhNZ5/s4lCzOAJ7te+839E3zQdGPKTGEMeVFVVmUhVmzX2zMCvX1sxewiNTdgb
wsZK6gDtcCU77Di2YegdHZ8OoLbOy/fgCvtjnnl0DC6iwcie7w0PPRI8f9wBQVUN
aNNvtAxWGumcFA9FvaaxwAoC7yHl3YY7XJoen/N49yXGuvVUYNqXGsoHcCfPjQWR
9uLtwLGmnY6wUddpbF3X5YLpLk1jua8JBRUTCu2+lpj7hlSx9GHRtGNgHTOIuQHO
m4GY2XtOh4BFF/gCWMu/Cz3Gqt1MZ4uqVDOOUGiE8UGzAkiwvNO8z5cWoVxcNKok
tZ9U+p+W5VQrhR6PSV93e/p5be3Ouq6tSjWs+b48Kpm40YM/GpGmmBH14vwxidIl
8Pr1
=6VQ8
-END PGP SIGNATURE-


php-7.3.7RC1.tar.gz
SHA256 hash:
e129fc7f71246ed338d5a2ac85309ce6739382c4edcf1a26569e12b2bf0f61fc
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAlz/jJ0MHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2xNMP/jAYv398CfbLqTET0zxOI1FECYcPNqRcOmf2o8Lj
RJQI8bieO2qDj+ty9wHW0Fr4Lpt74l0gC2bcoOuPPrxmb9uTXEOl3VUwd2Z8yFbK
8bgIQT7AvlapkaCLzIKgebLFTrTSe4egtYzkLhis139d7bcHZkjJj9adcYyyxiIa
+1MC3aC89oju5x0U2XgplRl1Q0dT1ojXq2mC+xVTvKuW9pyX5dp2N4JaxrfSfdSY
dNPxs3XVcaJKLiR9qVlh7wudJIsvywZWnm4mAN9yxaHep1PIMGA0KbcQ+T78HxWJ
G/ETlzO68ulQOTW/mW7ALF2IKLD5Ufob3jtRnT4PR1mZF8aoVt8PsGRYEmMEsxwS
C3JIez6mep+h00Ph3sNYxuV7X8HbvsmSFQ5UB9PHGQOKNELPjuR8JOTKgW86v7N1
tfG2rwxn10AzAFqVMNrLtBBVUdU0c2GWcqk15qWVLr83lDT1LXzdBPzULLG2Q2KD
BgAmicfOxd9ZEiWTjnqpBIvKPqKuTHzgs/LEq+Xuh2ISryfzsg6atoIsYE++V7df
2AbR/7pZ5jSlu7Q2DlJTje0vrcLu9sDQZzaGQl421iZJoUy+Pqvkt7u0ow/ItGKC
q9cqFVW5DGuFbw7t6qRPa9I7OUHrlLzdLwZNWjt41nh9wmwv7lFSWn5tNJ6rXufU
OXzN
=fBEP
-END PGP SIGNATURE-


php-7.3.7RC1.tar.xz
SHA256 hash:
a914a9044cbc84cf607e8b2c781b9c190f2904c5d16e76364b62cf3ac29a26e9
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAlz/jJ4MHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2C/kP/R0ZLg92lFZKn9zUgvSyL8JGnO9tnYQease4EGAf
jJgZmOLKV/2RLHH5j8nWTy3qRuZuDF4X82sxyF7huWjDsWrEB24AE2sruXyE5r0V
5xvaKouVw953iL9g1+rJv2MBWUptIIcMOrzTfZb/4O5HvHEM3u66yVohRaBZycA1
blro6r9YNSpgnjCGtMSpQAn3esvuSQ015aOr/xQQqPIvnJJJmssdYfrFuWZSQ/H6
it4pzbKAtukkJHo5jKt7DgKI+TcLTRv2yLz1iQsC8O4zjjVZR5y5GJJDtYnKvI1O
q1NLDfGSW3wNzyYUz1BZKkLw6WL+Rvuv7NXM3PnGEBcplcQ3iGpEh770omwNizqU
dCdyl2OFjjIXs082XsFeN2wypsuW22MfLbo5ilZG5azD3eIs4V+dvAgk/eNwlX79
s0/KZNi2OP8KbY28R7k7fKqrqaqs94uEUy1UCuyaneheSO5zEg3PekA9JaiIKGUP
V3bLtEY06T5AueH3cFnZvrfeje0J7ZEb+p9Jjij2m++sTz8uUxTfJ/q3i5giEdow
yFWf69bVIiBj2JH/c0u1azveKzuYIAIRx57XyhYddV9ULjVurVNvv/jXrIejt/2z
iMkF3DHv1jLHco0rkaQDp9XDfQCb2kifxBZytP/ixM7Zn1nEoiEdKHw3QD0d1vuI
ETtL
=/xRG
-END PGP SIGNATURE-

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] The real world ...

[Marco Pivetta]

On Thu, Jun 13, 2019, 10:36 Lester Caine  wrote:

> On 13/06/2019 08:55, Andreas Heigl wrote:
> >> display_errors=Off in production.
>
> Which give a white screen ... fine for security but useless for people
> using the site!
>

Error logging is how this is to be approached.

Personally I STILL use display_errors=on and just make sure that
> sensitive information is not displayed in the stack. Most of the time it
> IS just the warnings one gets and clients can report them and see they
> are cleared ... so some sort of middle ground between off and on would
> be helpful?
>

Logging, logging, logging.

Displaying traces just gives malicious third parties a tasty data
exfiltration endpoint.

[PHP-DEV] PHP version 7.2.20RC1 is available for testing

[Remi Collet]

Hi,

PHP 7.2.20 RC1 was just released and can be downloaded from:

https://downloads.php.net/~remi/

Or using the git tag: php-7.2.20RC1

The Windows binaries are available at: http://windows.php.net/qa/

Please test it carefully, and report any bugs in the bug system.
7.2.20 should be expected in 2 weeks on June 27th, 2019.

Hash Values and GPG signatures can be found below.


Thank you, and happy testing!


Regards,
Sara Golemon & Remi Collet




php-7.2.20RC1.tar.gz
SHA256 hash:
b9a3484a6cd28380fcfb718c627c9fe8ba70f283763b036a94768ba45773d962
PGP signature:
-BEGIN PGP SIGNATURE-

iQIcBAABAgAGBQJc/3w2AAoJENyf+NPuWvJ/oiIQAK5qOU/VubLDhRhRvKGiEJqv
XQ5ODSLkfqOOLa6WU1CoEqNCIC6OpFPAYgCJJAn/pAYkjZx7hHOcTd5tUMsBpUgY
E07Qpy3vSrTgk5AIdXNfuZHNGa4ksKIT90R6ZuiieWeAOaFsOwzj2gdfDWBF/pIO
HelXBKHYtHQxV1/PQlhisdAtGLmJkRoTwg1PhLUf3eb/sSkVlXT5fCr8o/pDDH3c
3PM3j5B5QroxpWfYloYKfgnpfsCQRzj7fK7edlFNrpY1TsfAG+KRWzQ2st6GfbuL
b1kRGCdl1BWL7wVyjDpjLWyaLiUU7pVVvgE690E3L4VSuJ83gHHDwFPQMQx00N2O
LKRGGP3BlvxzMs9pcJpWSvpv994uhFUOydFHeTWzrRRjAmk3zVSOLaCM2TCqQRWT
FbYVBMOAEWr+9S1FL/HMOmikydrhk64RFZ2fynGpAcGz1V5Zj8+RJp+IzJ8yu7jU
YD+pkMc9udVDkOIzTUmcS4zsNk5S3bSuTAIeJPo5NTmWoqOsTKONsiBjrbJOzWZW
mMqVLHeE7SDwgYc3lc+Tq3I0jjPW/tn7A6PQnpTdewTK7GluxPG805BxBudQ9Rhj
z7pghyPRlrOGedGjH+Y8ogLnHpGLWdT/3sTML4ym9SoQqP7YjgPF46gi7ZCRZi3M
L37x0dd214LVWCIA/x2V
=TwE/
-END PGP SIGNATURE-

php-7.2.20RC1.tar.bz2
SHA256 hash:
b73a1ebcc4528429b7efac1def721cae29d15d66f69a9e9ff58feabe80a9e78e
PGP signature:
-BEGIN PGP SIGNATURE-

iQIcBAABAgAGBQJc/3w6AAoJENyf+NPuWvJ/7a8P/3xKVSfRP5MbMNOubFTQTYQ4
r+Jb55Oostq2+yFmCo/eT461pBXVJe3oxVT6XNoygXQLGX4gjBwrwQG8NmPNT+MA
NmvHT4X3ItbE02wGv0hsAd1kgyJdgxxq3eaBvA0qbQ5v9MRtV15m7ywftlHZod9K
aVPSj9BD3hnh+OYD4AEuTQ6OY1FBKz4DpNOdt1Eofqnh0mSnt+G2m7HLnHOx3Sx5
Q2yAz0KnWAqVilwY1vFR8n7vGtAj5pG17nj9uPNDC7QhvSAoGGtzSQY8N4Hgpm2T
rJKXeI46ekYRerK4F0TYaj9LqqaJgfa1m2OhETxk9ZFhtkj+xBTZNububR1bJZmz
sy2OEGplrK5YYKXs5ndXJE8LXaqQojpD4AwbxeRTihzFj8clJXF4IGgUQmU1ClAS
NWleN1JhYptSU0Zzl/hJGeCuuUIfPeohdbBBhjmm6TlJ19d2+U6cruwfA5Tl8teq
hV/tNcJur73g8gwY1DuI2nKA6DJa3djdvvDKIpzTN8fEryAR8yit5SD17qqsD3KJ
K8Qz6rqM76iDOmHE0JNaUIy2ND0SEFG4F3NTEYek0YIE62TXFp8NteHEuuCNT3kC
UKmkKmUQef8sMOBob41CIIMsgV7V5d90TF0qUINvpbZwgKw9nx4oYkGPVC2qph7p
YeeF9dxCXrjOyIrAOBbK
=eTHY
-END PGP SIGNATURE-

php-7.2.20RC1.tar.xz
SHA256 hash:
d403da2e675f2a9aa9e3e34e81686c26580376e98a3b03b1df97eb43c638dd08
PGP signature:
-BEGIN PGP SIGNATURE-

iQIcBAABAgAGBQJc/3w8AAoJENyf+NPuWvJ/rFUP/3nEc1UeQWGQ2HITsKtkBy8K
VwAoRYMY/KsD2VBD/mB5DWCIakQ8O8pO1AxpyC9ed32dzlSQvTSWlO2Dl6rT+vfI
wprcBncsX3Ga9dPIwRo/InJwvqsqBL/7nxoxFj3v0xWkFm8S6h7m1cS6Uk63Joph
vaLOtscEzCk5NWXD2Ggd38JqsLKHDnUmAdaouylxBdNSIPoTWkWnyCf+5WZd++Ef
jO+Xl5cOQnBS1uZdrmEuKTGbLscu87JwaWLXNxqmMQ+ymFrIqfIxIpslfzFHEMQQ
4N+iu5jVkqsJREcPgYPHGI2LoqlclJUjBcIyj3hFAexZlrJ+9768OJ1Pn/XM9ska
fjhzhmDELu8JbOM1m9maCDiDXZ/KVCExofaqXYZMUX5HJMXRH4eeRwx6niyH6c3h
j/SxI/WlepCGeme4CFevQrGN2axn3D0sCpomPsXX77zqS+MUU1KNSIh1ylOLa/W0
rZlRqLORa0i5pp+1InRPBtSAHhh4vH4Yx16xOIEu5rX+sZZORZO06LVOR4wycTAT
P1gTwRWE4K0rocf30aqQ05Mpu551HKR9gEqqEbUV0ux6xkGF39K93B5egwGY4Gt3
Ztvy8PVNvqkaI27/b48IILSmsP2viKKoxJZ7gt4XxgqFJxta3XDF/9NrC/u9bf65
PXsbyvULWmtRUV5wv3d4
=JVqi
-END PGP SIGNATURE-

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] The real world ...

[Lester Caine]

On 13/06/2019 08:55, Andreas Heigl wrote:

display_errors=Off in production.


Which give a white screen ... fine for security but useless for people 
using the site!



While that makes absolute sense perhaps thinking whether there is a way
to mark password-parameters in core-functions and hide them in
Stack-traces might improve security as that would also hide
user-provided credentials in log-files.
That would not target userland methods/functions. Though having a
Core-Value-object for credentials might even allow*that*


Sanitising things would be a nice to have especially where log files are 
on 'cloud' storage, but the ability to give an end user some indication 
that there is a problem WHILE display_errors=Off would be helpful? I 
know the white screen problem has been discussed many time over the 
years ...


Personally I STILL use display_errors=on and just make sure that 
sensitive information is not displayed in the stack. Most of the time it 
IS just the warnings one gets and clients can report them and see they 
are cleared ... so some sort of middle ground between off and on would 
be helpful?


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] The real world ...

[Andreas Heigl]

Hey All

Am 13.06.19 um 09:41 schrieb Nikita Popov:
> On Thu, Jun 13, 2019 at 9:35 AM Lester Caine  wrote:
> 
>> Seen in the wild ... company name sanitised
>>
>> Warning: mysqli::mysqli(): (HY000/2002): No such file or directory in
>> /home/888/public_html/system/library/db/mysqli.php on line 7
>>
>> Fatal error: Uncaught exception 'Exception' with message 'Error: > />Error No: ' in /home/888/public_html/system/library/db/mysqli.php:10
>> Stack trace: #0
>> /home/888/public_html/system/nitro/core/nitro_db.php(29):
>> DB\MySQLi->__construct('localhost', '888_4y65f5...',
>> 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #1
>> /home/888/public_html/system/nitro/core/nitro_db.php(13):
>> NitroDb->__construct('mysqli', 'localhost', '888_4y65f5...',
>> 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #2
>> /home/888/public_html/system/storage/modification/system/library/db.php(11):
>>
>> NitroDb::getInstanceWithParams('mysqli', 'localhost', '888_4y65f5...',
>> 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #3
>> /home/888/public_html/system/framework.php(36):
>> DB->__construct('mysqli', 'localhost', '888_4y65f5...',
>> 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #4
>> /home/888/public_html/vqmod/vqcache/vq2-system_startup.php(124):
>> require_once('/home/888 in
>> /home/888/public_html/system/library/db/mysqli.php on line 10
>> 你的代码出错了：
>>
>> I presume something has been updated that they have not been aware of
>> since it's library file that triggered the warning ... but it's not the
>> first time in recent years I've seen this sort of information on
>> commercial sites and while my own clients just get white screens, those
>> are created by the likes of Wordpress when 'automatic updates' happen.
>>
>> Many years ago the response was "well don't update", but 'current
>> practice' takes that out of OUR hands! So isn't it time that the
>> triggering exceptions like this did produce a more user secure response
>> to protect against leaks like this and provide a better alternative than
>> a white screen?
>>
>> In the case of this live site, I actually placed an order as it was only
>> some links that triggered the fault, which may explain why they were not
>> even aware there was a problem :( From the 'development' side, NitroDb->
>> should obviously be handling the problem anyway.
>>
> 
> display_errors=Off in production.
> 

While that makes absolute sense perhaps thinking whether there is a way
to mark password-parameters in core-functions and hide them in
Stack-traces might improve security as that would also hide
user-provided credentials in log-files.
That would not target userland methods/functions. Though having a
Core-Value-object for credentials might even allow *that*

Just my 0.02 €

Cheers

Andreas
-- 
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org   http://hei.gl/wiFKy7 |
+-+
| http://hei.gl/root-ca   |
+-+



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] The real world ...

[Nikita Popov]

On Thu, Jun 13, 2019 at 9:35 AM Lester Caine  wrote:

> Seen in the wild ... company name sanitised
>
> Warning: mysqli::mysqli(): (HY000/2002): No such file or directory in
> /home/888/public_html/system/library/db/mysqli.php on line 7
>
> Fatal error: Uncaught exception 'Exception' with message 'Error:  />Error No: ' in /home/888/public_html/system/library/db/mysqli.php:10
> Stack trace: #0
> /home/888/public_html/system/nitro/core/nitro_db.php(29):
> DB\MySQLi->__construct('localhost', '888_4y65f5...',
> 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #1
> /home/888/public_html/system/nitro/core/nitro_db.php(13):
> NitroDb->__construct('mysqli', 'localhost', '888_4y65f5...',
> 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #2
> /home/888/public_html/system/storage/modification/system/library/db.php(11):
>
> NitroDb::getInstanceWithParams('mysqli', 'localhost', '888_4y65f5...',
> 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #3
> /home/888/public_html/system/framework.php(36):
> DB->__construct('mysqli', 'localhost', '888_4y65f5...',
> 'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #4
> /home/888/public_html/vqmod/vqcache/vq2-system_startup.php(124):
> require_once('/home/888 in
> /home/888/public_html/system/library/db/mysqli.php on line 10
> 你的代码出错了：
>
> I presume something has been updated that they have not been aware of
> since it's library file that triggered the warning ... but it's not the
> first time in recent years I've seen this sort of information on
> commercial sites and while my own clients just get white screens, those
> are created by the likes of Wordpress when 'automatic updates' happen.
>
> Many years ago the response was "well don't update", but 'current
> practice' takes that out of OUR hands! So isn't it time that the
> triggering exceptions like this did produce a more user secure response
> to protect against leaks like this and provide a better alternative than
> a white screen?
>
> In the case of this live site, I actually placed an order as it was only
> some links that triggered the fault, which may explain why they were not
> even aware there was a problem :( From the 'development' side, NitroDb->
> should obviously be handling the problem anyway.
>

display_errors=Off in production.

Nikita

[PHP-DEV] The real world ...

[Lester Caine]

Seen in the wild ... company name sanitised

Warning: mysqli::mysqli(): (HY000/2002): No such file or directory in 
/home/888/public_html/system/library/db/mysqli.php on line 7


Fatal error: Uncaught exception 'Exception' with message 'Error: />Error No: ' in /home/888/public_html/system/library/db/mysqli.php:10 
Stack trace: #0 
/home/888/public_html/system/nitro/core/nitro_db.php(29): 
DB\MySQLi->__construct('localhost', '888_4y65f5...', 
'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #1 
/home/888/public_html/system/nitro/core/nitro_db.php(13): 
NitroDb->__construct('mysqli', 'localhost', '888_4y65f5...', 
'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #2 
/home/888/public_html/system/storage/modification/system/library/db.php(11): 
NitroDb::getInstanceWithParams('mysqli', 'localhost', '888_4y65f5...', 
'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #3 
/home/888/public_html/system/framework.php(36): 
DB->__construct('mysqli', 'localhost', '888_4y65f5...', 
'J?vJr+j5iCju-bo...', '888_4y65f5...', '3306') #4 
/home/888/public_html/vqmod/vqcache/vq2-system_startup.php(124): 
require_once('/home/888 in 
/home/888/public_html/system/library/db/mysqli.php on line 10

你的代码出错了：

I presume something has been updated that they have not been aware of 
since it's library file that triggered the warning ... but it's not the 
first time in recent years I've seen this sort of information on 
commercial sites and while my own clients just get white screens, those 
are created by the likes of Wordpress when 'automatic updates' happen.


Many years ago the response was "well don't update", but 'current 
practice' takes that out of OUR hands! So isn't it time that the 
triggering exceptions like this did produce a more user secure response 
to protect against leaks like this and provide a better alternative than 
a white screen?


In the case of this live site, I actually placed an order as it was only 
some links that triggered the fault, which may explain why they were not 
even aware there was a problem :( From the 'development' side, NitroDb-> 
should obviously be handling the problem anyway?


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php