Re: [PHP-DEV] Bugsnet: Quick fix descriptions

[Pieter Hordijk]

Hey all,

I think we can just add the reasons to the file where it is being rendered.

I am off for the weekend, but I can implement and test this after the weekend
if nobody else picked it up by then.

Pieter

- Original Message -
> From: "Peter Cowburn" 
> On Thu, 18 Jul 2019 at 12:10, Christoph M. Becker  wrote:
> 
>> On 18.07.2019 at 01:14, Stanislav Malyshev wrote:
>>
>> >> the quick fix descriptions of bugs.php.net[1] need some update.  To my
>> >> knowledge, these come from the database, so could anybody with access to
>> >> it please take a look?
>> >
>> > Ideally, I think this should be in PHP file and not database, so it will
>> > be modifyable by project members without needing shell access & DB
>> password.
>>
>> I agree that this would be the best solution in the long run, and it
>> shouldn't be hard to adapt ReasonRepository[1] to read from a file
>> instead of the DB.
>>
>> Any volunteers?
>>
> 
> I'm not sure if anyone other than us is still using this source code
> (looking at the MySQL guys).  If not, can we just include the reasons in
> the source directly, and forget about the database or a special file
> containing the reasons?
> 
> 
>>
>> [1]
>> <
>> http://git.php.net/?p=web/bugs.git;a=blob;f=src/Repository/ReasonRepository.php;h=b33d60a6bdae13dc78370aa24db481e1101ac13b;hb=HEAD
>> >
>>
>> Thanks,
>> Christoph
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>

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

Re: [PHP-DEV] [RFC] Deprecations for 7.4

[Pieter Hordijk]

 
> Also, it's unclear to me why get_called_class() should be deprecated.
> While the rest of the listed deprecations have either motivation
> written for them or are self-evidently legacy functionalities that
> nobody should be using today, this one seems to be just a case of
> "let's not have more than one way of doing things" and I'm not really
> a fan of that.

I agree with above. When looking through the list of deprecations this
one jumps out for me as being an outlier too.

Maybe it should just be removed from the RFC?

Pieter

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

Re: [PHP-DEV] Removing mysqlnd stats from phpinfo

[Pieter Hordijk]

> > There is no need for JavaScript: use  (as progressive enhancement, 
> > etc.)

> How will that work for the cli (e.g. php -i)?

The situation on CLI is arguably even worse with very long lists like that and 
indeed
things like JS or details tags would obviously not work for that.

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

[PHP-DEV] Removing mysqlnd stats from phpinfo

[Pieter Hordijk]

Hey internals,

when there is support for mysqlnd the `phpinfo()` page hows the entire list
of available mysqlnd stats.

Do we really need to show the stats here? It makes the page unnecessary long
and somewhat annoying to scroll past for no obvious (to me) reason it to be 
there.

The stats can also already be retrieved using the
APIs @ https://www.php.net/manual/en/mysqlnd.stats.php making it even
less useful to have on the page.

I created a PR to remove the stats https://github.com/php/php-src/pull/4164
Can this just be merged or is there a specific reason the stats are on the page?

Also related to https://bugs.php.net/bug.php?id=60594 which basically
states the same things as above.

Pieter

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

Re: [PHP-DEV] deprecation of set_error_level() callback $errcontext argument

[Pieter Hordijk]

> On Tue, Oct 2, 2018 at 11:37 PM Rowan Collins  wrote:
> 
>> While I can understand the desire to have debugging feature built into
>> the language "out of the box", it may be best left to extensions which
>> can capture the information to a log or wherever without providing the
>> full flexibility of the language to interact with it.
> 
> I think, since the language *did* provide this "out of the box", it's sort of
> odd to deprecate a feature that is being used by a popular product - the
> Sentry PHP package has 8 million downloads, and PHP developers rely
> on this in production to help them fix bugs. Seems pretty important?
> 
> And an extension isn't really an acceptable alternative to someone who
> was offering a product that "just worked".
> 
> For example, rather than removing this feature, might it be possible to
> deeply clone the variables and provide backwards compatibility in that
> manner? I doubt that anyone is counting on introducing side-effects via
> an error-handler, but surely it's not uncommon for error-aggregators and
> loggers to rely on this information being available?
> 

According to the sentry people here 
https://github.com/getsentry/sentry-php/issues/662#issuecomment-426550180

they don't actually use that anymore:

> I've done a little bit of digging here and there, and luckily this seems a 
> non-issue for us! 

> In the 2.0 branch that argument is not used:

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

Re: [PHP-DEV] Re: Mailing list moderation

[Pieter Hordijk]

> Hi,
> 
> "rhsoft" continues their aggressive behaviour on the bug tracker still
> too. One recent illustration is
> https://bugs.php.net/bug.php?id=76184=1
> 
> Do we have any methods to ban people from there too?
> 
> cheers,
> Derick
> 
> On Wed, 3 Jan 2018, Rasmus Lerdorf wrote:
> 
>> Ok, both have been added to the ezmlm deny list for internals
>> 
>> On Tue, Jan 2, 2018 at 2:49 AM, Nikita Popov  wrote:
>> 
>> > Hi,
>> >
>> > This mail is going to both the systems group and internals mailing list.
>> >
>> > I would like to request a mailing list suspension for the users
>> > tonymars...@hotmail.com and li...@rhsoft.net, who have recently been
>> > aggressively derailing the "Scalar Pseudo-type" thread, despite requests to
>> > moderate their participation both in that thread, and on a number of
>> > previous instances -- this is certainly not the first time these two users
>> > have converted an RFC discussion into a dick measuring contest.
>> >
>> > If these users cannot be suspended, I would like to request specific
>> > instructions under what circumstances users can be suspended from the
>> > internals list, and what procedures need to be followed to achieve this.
>> >
>> > Regards,
>> > Nikita
>> >
>> 

Yes please.

I have seen only crap behavior on the bug tracker by rhsoft.

Pieter


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

Re: [PHP-DEV] [RFC][Discussion] Make compact function reports undefined passed variables

[Pieter Hordijk]

> Hi Pieter.

>> What I am missing here is the reason why we should break well defined 
>> behavior
> > of existing functions.


> Hi Pieter.

>> What I am missing here is the reason why we should break well defined 
>> behavior
> > of existing functions.

> This is something I'd like to discuss about `compact`. I'd like to know why we
> skip undefined variables instead of report them. `compact` is use in a large
> scale by the MVC community, by passing variables in the controller and using
> them in the view.

> > How is the BC break for all existing code justified?

> I'd like to start report this undefined variables. Would be one more way to
> prevent code-smell. IMHO this belongs to the core, not to the userland.

> Thanks,

> --
> Gabriel Caruso

Regardless of the why it is like that the fact of the matter is that it is and 
imho
you would need a really good reason to break existing code.

I still don't don't see your reason for it. Nor do I see how it is a code smell 
atm.

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

Re: [PHP-DEV] [RFC][Discussion] Make compact function reports undefined passed variables

[Pieter Hordijk]

- Original Message -
> From: "Gabriel Caruso" 
> To: "internals" 
> Sent: Monday, April 2, 2018 11:17:43 AM
> Subject: [PHP-DEV] [RFC][Discussion] Make compact function reports undefined 
> passed variables

> Hello dear internals, how are you?
> 
> I'd like to propose a new RFC to PHP's core, but as this one contains a BC
> Break, let's discussed it before making anything official.
> 
> A couple of days ago, while discussing some [Coding Standards rules for
> Doctrine, forbidden the `compact` function](
> https://github.com/doctrine/coding-standard/pull/49), an argument caught my
> attention:
> 
>> The `compact` function var does not report undefined variables.
> 
> Looking in [the `compact` documentation](https://secure.php.net/compact),
> this is even emphasizes:
> 
>> Any strings that are not set will simply be skipped.
> 
> I couldn't figure out why this is done this way, but, here's what I'd like
> to propose: make the `compact` function starts to report undefined passed
> variables for it.
> 
> With [only 2 lines of code](
> https://github.com/php/php-src/compare/master...carusogabriel:warning-unknow-compact-variable),
> this is possible, but, of course, this is a BC Break.
> 
> Let me know your opinion on that, and perhaps, make it happen!
> 
> Regards,
> --
> Gabriel Caruso

Hey Gabriel,

What I am missing here is the reason why we should break well defined behavior 
of existing functions.

How is the BC break for all existing code justified?

Pieter

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

Re: [PHP-DEV] [RFC] [Voting] Class Naming

[Pieter Hordijk]

- Original Message -
> https://wiki.php.net/rfc/class-naming
> 
> Voting starts now and will be open for two weeks (July 15).
> 
> --
> Richard "Fleshgrinder" Fussenegger

https://wiki.php.net/rfc still says no RFCs are in voting.


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

Re: [PHP-DEV] [RFC] [VOTE] Restarted vote on the negative arrays

[Pieter Hordijk]

- Original Message -
> From: "nikita ppv" 
> To: "Pedro Magalhães" 
> Cc: "internals" 
> Sent: Tuesday, June 13, 2017 9:15:33 PM
> Subject: Re: [PHP-DEV] [RFC] [VOTE] Restarted vote on the negative arrays

> On Tue, Jun 13, 2017 at 8:44 PM, Pedro Magalhães  wrote:
> 
>> Hi internals,
>>
>> Based on the feedback on the original RFC targeting 7.2, I have now updated
>> the RFC to target version 8.0. Additionally, I changed the existing PR to
>> throw a E_DEPRECATED notice on the cases where this RFC will cause a BC
>> break when the change is implemented to ease the detection of such cases.
>>
>> I have closed the current vote (YES 14 - 16 NO) and opened a new one for
>> the revised RFC targeting the next major version.
>>
>> You can vote (again) at https://wiki.php.net/rfc/negative_array_index
>> until 28/6/2017 19:00 UTC.
>>
>> Regards,
>> Pedro
>>
> 
> As this is a significant change to the RFC, I'd recommend moving it back to
> discussion first.
> 
> Without some further evaluation, I am not sure whether throwing a
> deprecation from a low level hash API function like this is safe. The
> deprecation may be converted into an exception and it's not immediately
> clear that calling code will handle this correctly. In any case, even
> assuming this is safe, what is the expected behavior if the deprecation
> notice is converted into an exception? As the implementation stands right
> now, the element will still be inserted into the array. Is this intentional?
> ("We don't care" is also a valid answer -- it's an edge case.)
> 
> It would also be nice to quickly check what the performance impact of this
> change is (a micro-benchmark on array appends should be enough). The patch
> adds a number of additional checks in a very hot code-path, which may or
> may not have a measurable impact.
> 
> Regards,
> Nikita

My concern is that valid code which is working fine and will continue working
fine with the change described in the rfc will now start spitting out notices.

How often and how many? I don't know.

On top of that I agree with Nikita about the possibility of conversion to
exceptions which will (/ might) actually break existing code.

Pieter


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

Re: [PHP-DEV] [RFC][VOTE] Improve hash_hkdf() parameter

[Pieter Hordijk]

- Original Message -
> From: "Nikita Popov" <nikita@gmail.com>
> To: "Yasuo Ohgaki" <yohg...@ohgaki.net>
> Cc: "Pieter Hordijk" <i...@pieterhordijk.com>, "Joe Watkins" 
> <pthre...@pthreads.org>, "Andrey Andreev"
> <n...@devilix.net>, "internals" <internals@lists.php.net>, "phpdoc" 
> <php...@lists.php.net>
> Sent: Friday, April 14, 2017 11:24:53 AM
> Subject: Re: [PHP-DEV] [RFC][VOTE] Improve hash_hkdf() parameter

> On Thu, Apr 13, 2017 at 11:22 PM, Yasuo Ohgaki < [ mailto:yohg...@ohgaki.net |
> yohg...@ohgaki.net ] > wrote:

>> Hi Pieter and all,

>> On Thu, Apr 13, 2017 at 5:11 PM, Pieter Hordijk < [
>> mailto:i...@pieterhordijk.com | i...@pieterhordijk.com ] >
>> wrote:

>> > Is this really something we need in our official docs instead of for
>> > example
>> > on a personal blog?


>> I wrote draft doc patch.
>> Please verify.

>> Index: en/reference/hash/functions/hash-hkdf.xml
>> ===
>> --- en/reference/hash/functions/hash-hkdf.xml (リビジョン 342317)
>> +++ en/reference/hash/functions/hash-hkdf.xml (作業コピー)
>> @@ -3,7 +3,7 @@
>> http://docbook.org/ns/docbook |
>> http://docbook.org/ns/docbook ] "
>> xmlns:xlink=" [ http://www.w3.org/1999/xlink | http://www.w3.org/1999/xlink 
>> ] ">
>> 
>> hash_hkdf
>> - Generate a HKDF key derivation of a supplied key
>> input
>> + Derive secure new key from existing key by using
>> HKDF
>> 
>> 
>> 
>> @@ -16,6 +16,20 @@
>> > choice="opt">stringsalt''
>> 

>> + 
>> + RFC 5869 defines HKDF (HMAC based Key Derivation Function) which
>> + is general purpose KDF. HKDF could be useful for many PHP
>> + applications that require temporary keys, such CSRF token,
>> + pre-signed key for URI, password for password protected
>> + URI, and so on.
>> + 
>> + 
>> + 
>> + When info and length
>> + is not required for your program, more efficient
>> + hash_hmac could be used instead.
>> + 
>> + 
>> 
>> 
>> 
>> @@ -25,7 +39,7 @@
>> algo
>> 
>> 
>> - Name of selected hashing algorithm (i.e. "sha256", "sha512",
>> "haval160,4", etc..)
>> + Name of selected hashing algorithm (i.e. "sha3-256", "sha3-512",
>> "sha256", "sha512", "haval160,4", etc..)
>> See hash_algos for a list of supported
>> algorithms.
>> 
>> 
>> @@ -39,7 +53,7 @@
>> ikm
>> 
>> 
>> - Input keying material (raw binary). Cannot be empty.
>> + Input keying material. Cannot be empty.
>> 
>> 
>> 
>> @@ -60,7 +74,8 @@
>> info
>> 
>> 
>> - Application/context-specific info string.
>> + Application/context-specific info string. Info is intended for
>> + public information such as user ID, protocol version, etc.
>> 
>> 
>> 
>> @@ -71,8 +86,32 @@
>> Salt to use during derivation.
>> 
>> 
>> - While optional, adding random salt significantly improves the
>> strength of HKDF.
>> + While optional, adding random salt significantly improves the
>> + strength of HKDF. Salt could be either secret or
>> + non-secret. It is used as "Pre Shared Key" in many use cases.
>> + Strong value is preferred. e.g. Use
>> random_bytes.
>> + Optimal salt size is size of used hash algorithm.
>> 
>> + 
>> + 
>> + Although salt is the last optional parameter, salt is the
>> + most important parameter for key security. Omitted salt is
>> + indication of inappropriate design in most cases. Users must
>> + set appropriate salt value whenever it is possible. Omit salt
>> + only when it cannot be used.
>> + 
>> + 
>> + Strong salt is mandatory and must be kept secret when input
>> + key is weak, otherwise input key security will not be kept.
>> + Even when input key is strong, providing strong salt is the
>> + best practice for the best possible key security.
>> + 
>> + 
>> + Salt must not be able to be controlled by users. i.e. User
>> + must not be able to set salt value and get derived key. User
>> + controlled salt allows input key analysis to attackers.
>> + 
>> + 
>> 
>> 
>> 
>> @@ -101,6 +140,99 @@
>> 
>> 
>> 
>> + URI specific CSRF token that supports expiration by
>> hash_hkdf
>>

Re: [PHP-DEV] [RFC][VOTE] Improve hash_hkdf() parameter

[Pieter Hordijk]

- Original Message -
> From: "Yasuo Ohgaki" 
> To: "Joe Watkins" , "Andrey Andreev" 
> Cc: internals@lists.php.net
> Sent: Thursday, April 13, 2017 1:07:19 AM
> Subject: Re: [PHP-DEV] [RFC][VOTE] Improve hash_hkdf() parameter

> Hi Joe,
> 
> On Wed, Apr 12, 2017 at 7:46 PM, Joe Watkins  wrote:
> 
>> This RFC was left open for 5 days past the end of voting as declared on
>> the RFC.
>>
> 
> Thank you, I forgot about this.
> IMHO, it's a shame for us we should have inconsistent and insecure function
> signature for a new function.
> 
> I'm going to update the manual to add warning notes and example usages
> like advanced CRFS token dedicated for specific URL with expiration time.
> 
> I can think of length option only usage, but I cannot think usage that could
> be useful for majority of PHP users like advanced CSRF token.

Is this really something we need in our official docs instead of for example
on a personal blog?

To be honest I am afraid of ending up with something like the current state
of the session docs. Which are imo way too broad / opinionated, non English,
contains utterly confusing examples and / or flat out wrong and broken examples.
Above already resulted in a stream of docs bugs regarding session pages
and a lot of confused readers.

By all means describe how functions work, but don't confuse readers with things
most people won't ever need or are better suited as a (series of) blog posts / 
Stack Overflow post(s).

My €0.02

cc-ing docs discussion to get them also involved in case somebody of the docs
team has an opinion.

> Andrey,
> 
> Could you give us some length only and length/info only example
> that could be useful for most PHP users.
> It should be safe and recommended usage.
> I suppose you should have some good examples.
> 
> Thank you.
> 
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net

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

[PHP-DEV] Session improvements

[Pieter Hordijk]

Hey Internals,

I have been thinking about / working on a couple of session improvements.

This work started once I had the time to fully read the "Precise session data
management" RFC.
I was thinking about creating small and specific RFCs for specific issues to be
discussed. I planned to put this up in the coming week(s).

Most of the work isn't yet ready for prime-time, but I have already discussed it
with a couple of people.

However now that I see the discussion about the last sessions RFC is being
brought up again I thought I would give you all a heads-up that there are more
people working on improving sessions.

There will be minor overlap with Yasuo's session RFC hence I speak out now.

Pieter

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