[PHP-DEV] [RFC] orphan extensions cleanup

Hi! I'd like to propose an RFC to deal with extensions that currently have no maintainer: https://wiki.php.net/rfc/umaintained_extensions The main goal of the RFC is to initiate the process that by the time of 7.1 release will result in no extensions in PHP core being unmaintained. The process w

Re: [PHP-DEV] [RFC][DISCUSSION] Remove utf8_decode() and utf8_encode()

Hi! > Hi all, > > utf8_decode() and utf8_encode() are not needed and causing problems > than solving. Why you think they are not needed? Also, the manual says "utf8_encode — Encodes an ISO-8859-1 string to UTF-8". If somebody uses unknown function without even glancing at the first line of the m

Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module

Hi! > It seems there is misunderstanding. > These new functions are intended for "secure coding input validation" that > should never fail. It means something unexpected in input data that > cannot/shouldn't keep program running. Why do you need to parse > message? I think the problem here is as

Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module

Hey Yasuo, Besides what reported above by Dan, my reasoning for voting "no" is that this API can be implemented in userland, regardless if trivial or not There is no reason good enough for justifying yet another added endpoint that can even be implemented with simple function composition. In add

Re: [PHP-DEV] [RFC][DISCUSSION] Remove utf8_decode() and utf8_encode()

On github utf8_encode have ~500.000 results and utf8_decode have ~400.000. I too guess that 7.2 shouldn't introduces a BC like that. Maybe on 8.0. Currently I guess that it is a good shortcut, but I really don't know if make senses to keep it (utf16 or others are not implemented, only utf8, for o

Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module

On Mon, Aug 15, 2016 at 11:15 AM, Yasuo Ohgaki wrote: > Hi Dan, > > Thank you for sharing idea! > > > On Mon, Aug 15, 2016 at 10:25 AM, Dan Ackroyd wrote: >> >> On 15 August 2016 at 01:53, Yasuo Ohgaki wrote: >> >>> One more usual request. >>> Please describe reason(s) why you object proposal. >

[PHP-DEV] [RFC][DISCUSSION] Remove utf8_decode() and utf8_encode()

Hi all, utf8_decode() and utf8_encode() are not needed and causing problems than solving. https://wiki.php.net/rfc/remove_utf_8_decode_encode Proposal - Document deprecation them now - Remove them from 7.2 I think only few users are using and they shouldn't have problem using mbstring/iconv

Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module

Hi Dan, Thank you for sharing idea! On Mon, Aug 15, 2016 at 10:25 AM, Dan Ackroyd wrote: > > On 15 August 2016 at 01:53, Yasuo Ohgaki wrote: > >> One more usual request. >> Please describe reason(s) why you object proposal. > > > I'm not entirely sure why you ask for reasons when people vote n

Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module

Hi Yasuo, On 15 August 2016 at 01:53, Yasuo Ohgaki wrote: > One more usual request. > Please describe reason(s) why you object proposal. I'm not entirely sure why you ask for reasons when people vote no. The reasons are almost always the same as the reasons given before the voting starts. But

Re: [PHP-DEV] Namespaces internal refactoring

Hi Stas, I'll comment your PS, since I'm the author of the PR. On Sun, Aug 14, 2016 at 6:11 PM, Stanislav Malyshev wrote: > Hi! > > > - PHP 7 has private classes through anonymous/inner classes. > > It's not exactly the same, and I suspect the same is true for Ruby. It's > true that anonymous c

[PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module

Hi all, On Mon, Aug 15, 2016 at 9:20 AM, Yasuo Ohgaki wrote: > On Mon, Aug 15, 2016 at 9:15 AM, Yasuo Ohgaki wrote: >> This RFC is to add functions that are suitable for input validations >> for secure coding. IMHO, these additions are mandatory for PHP. >> >> https://wiki.php.net/rfc/add_valida

Re: [PHP-DEV] Namespaces internal refactoring

Hi Stas, On Sun, Aug 14, 2016 at 6:35 PM, Stanislav Malyshev wrote: > Hi! > > > A realization that needs to be made is that beginners would be using > > libraries that requires to make valid restrictions, preventing those > > beginners to mess up with code they shouldn't. So even if the use case

[PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module

On Mon, Aug 15, 2016 at 9:15 AM, Yasuo Ohgaki wrote: > This RFC is to add functions that are suitable for input validations > for secure coding. IMHO, these additions are mandatory for PHP. > > https://wiki.php.net/rfc/add_validate_functions_to_filter > Vote ends 2016/08/22 23:59:59 UTC > > I don'

[PHP-DEV] [RFC][VOTE] Add validation functions to filter module

Hi all, This RFC is to add functions that are suitable for input validations for secure coding. IMHO, these additions are mandatory for PHP. https://wiki.php.net/rfc/add_validate_functions_to_filter Vote ends 2016/08/22 23:59:59 UTC I don't mind suspend vote and continue discussion if there is i

Re: [PHP-DEV] Re: [RFC] get_class() disallow null parameter

Hi! > Prohibiting `get_class(NULL)` is certainly a good idea, but I have some > concerns regarding BC. While `__CLASS__` has been introduced with PHP > 4.3.0, it had the glitch to return the lower-cased class name before PHP > 5.0.0. So there *might* still be PHP 5 code around using `get_class(N

Re: [PHP-DEV] Namespaces internal refactoring

On 15.08.2016 at 00:11, Stanislav Malyshev wrote: > Also, there's a difference IMO between classes and class' properties. > Class details may be - indeed, need to be - hidden because this is what > the class is, one of it's reasons to exist - a tool to reduce complexity > by hiding irrelevant info

[PHP-DEV] Re: [RFC] get_class() disallow null parameter

On 14.08.2016 at 13:00, Dan Ackroyd wrote: > Following an earlier discussion in January, here is a small RFC to > change get_class() to disallow null being passed as parameter. > > https://wiki.php.net/rfc/get_class_disallow_null_parameter > > Allowing null to be passed to get_class() is a 'gotc

Re: [PHP-DEV] Namespaces internal refactoring

Hey Stas On 15 Aug 2016 00:35, "Stanislav Malyshev" wrote: > > Hi! > > > A realization that needs to be made is that beginners would be using > > libraries that requires to make valid restrictions, preventing those > > beginners to mess up with code they shouldn't. So even if the use case > > is

Re: [PHP-DEV] [RFC][VOTE] Add session_create_id() function

Hi all, "The default 128 bits Session ID is large enough to ignore collisions" discussion is added for new readers and people couldn't follow discussion in ML threads. https://wiki.php.net/rfc/session-create-id#discussions For the record, when session module was implemented, the way it is now is

Re: [PHP-DEV] Namespaces internal refactoring

Hi! > A realization that needs to be made is that beginners would be using > libraries that requires to make valid restrictions, preventing those > beginners to mess up with code they shouldn't. So even if the use case > is only valid for 0.01% of code producers, it might be valid for 20%+ of > co

Re: [PHP-DEV] [RFC] get_class() disallow null parameter

On 14 August 2016 at 22:48, Stanislav Malyshev wrote: > > Could you please clarify what you mean by "disallow"? It will be the standard behaviour for accepting params. The patch is just: - if (zend_parse_parameters(ZEND_NUM_ARGS(), "|o!", &obj) == FAILURE) { + if (zend_parse_parameters(ZEND_NUM_

Re: [PHP-DEV] Namespaces internal refactoring

Hi! > - PHP 7 has private classes through anonymous/inner classes. It's not exactly the same, and I suspect the same is true for Ruby. It's true that anonymous classes can not be instantiated by other code. But that is not what we were discussing here. This particular effect is somewhat similar,

Re: [PHP-DEV] [RFC] get_class() disallow null parameter

Hi! > Following an earlier discussion in January, here is a small RFC to > change get_class() to disallow null being passed as parameter. > > https://wiki.php.net/rfc/get_class_disallow_null_parameter Could you please clarify what you mean by "disallow"? I've read the RFC but I didn't find descr

Re: [PHP-DEV] [RFC][VOTE] Add session_gc() function

Hi Bishop! On Sat, Aug 13, 2016 at 4:49 AM, Bishop Bettini wrote: > On Wed, Aug 10, 2016 at 5:30 AM, Yasuo Ohgaki wrote: >> >> Hi all, >> >> This RFC is to add session_gc() function. >> >> session_gc() function is required API for periodic session GC that is >> best practice for production web s

Re: [PHP-DEV] Bug #72828

Hi! On 14.08.2016 at 10:21, Stanislav Malyshev wrote: >> You have commented on : >> >> | Unless the allocations explicitly use the system allocator (i.e. do >> | not use emalloc and variants), do NOT introduce NULL checks. >> >> Can you please elaborate, why

[PHP-DEV] [RFC: PATCH v1] Implement mt_srand_array

--- ext/standard/basic_functions.c | 5 + ext/standard/mt_rand.c | 67 ++- ext/standard/php_math.h| 1 + ext/standard/tests/math/mt_srand_array_basic.phpt | 146 ++ ext/standard/tests/math/mt_srand_array_values.p

[PHP-DEV] Re: [RFC][VOTE] Add session_create_id() function

Hi all, On Wed, Aug 10, 2016 at 6:14 PM, Yasuo Ohgaki wrote: > https://wiki.php.net/rfc/session-create-id > It requires 2/3 majority to pass. > Vote starts: 2016/08/10 - Vote ends: 2016/08/17 23:59:59 UTC There are 2 mistakes in pseudo example code in discussion section and fixed - add missing

Re: [PHP-DEV] [RFC][VOTE] Add session_create_id() function

On Mon, Aug 15, 2016 at 5:13 AM, Yasuo Ohgaki wrote: > Let me paraphrase OWASP's document to show why. > > "Now assume a 128 bit session identifier that provides 64 bits of > entropy. With a very large web site, legitimate users might creates > 10,000 new session ID per second (New and regenerated

Re: [PHP-DEV] [RFC][VOTE] Add session_create_id() function

Hi all, It seems importance of session ID validation that prevents collisions is not recognized enough. Brute force session ID hihack risk is described here. https://www.owasp.org/index.php/Insufficient_Session-ID_Length The expected number of seconds required to guess a valid session identifier

Re: [PHP-DEV] Simple variable handling.

Hey Tony, On Sun, Aug 14, 2016 at 10:50 AM, Tony Marston wrote: > "Marco Pivetta" wrote in message news:CADyq6sKZRBvYFtqyKYVYM4iU > ex+2ouujvhep1jznm56k3+h...@mail.gmail.com... > >> >> So much confusion... >> >> There are 3 (or more) types of validation in pretty much every web-app, so >> let's

Re: [PHP-DEV] [RFC] get_class() disallow null parameter

Hi Dan, On Sun, Aug 14, 2016 at 1:00 PM, Dan Ackroyd wrote: > Hi! > > Following an earlier discussion in January, here is a small RFC to > change get_class() to disallow null being passed as parameter. > > https://wiki.php.net/rfc/get_class_disallow_null_parameter > > Allowing null to be passed

Re: [PHP-DEV] Namespaces internal refactoring

Hi Stas, Answers inline. On Sun, Aug 14, 2016 at 5:14 AM, Stanislav Malyshev wrote: > Hi! > > > Today I see 2 sides in PHP Internals. One that truly believes that PHP > > should adopt more concepts of object orientation, such as Annotations, > > Generics, Overloading, Class visibility, Collecti

[PHP-DEV] Re: mt_srand with array seed?

On 2016-08-14 17:04, Tom Worster wrote: On 8/14/16, 5:45 AM, "Lauri Kenttä" wrote: On 2016-08-13 18:53, Tom Worster wrote: On 8/12/16 2:48 PM, Lauri Kenttä wrote: On 2016-08-12 21:40, Tom Worster wrote: mt_srand() will work. But what would be in the array? Integers from which the upper 32 b

[PHP-DEV] Re: mt_srand with array seed?

On 8/14/16, 5:45 AM, "Lauri Kenttä" wrote: >On 2016-08-13 18:53, Tom Worster wrote: >> On 8/12/16 2:48 PM, Lauri Kenttä wrote: >>> On 2016-08-12 21:40, Tom Worster wrote: mt_srand() will work. But what would be in the array? Integers from which the upper 32 bits, if they exist, are disc

Re: [PHP-DEV] [RFC][VOTE] Add session_create_id() function

Hi Lester, On Sun, Aug 14, 2016 at 5:35 PM, Lester Caine wrote: > On 14/08/16 01:56, Yasuo Ohgaki wrote: >> IMO. PHP should be easiest, yet secure, Web application programming language. >> I don't see any benefits, but only drawbacks, forcing users "to know session >> management details to write

[PHP-DEV] [RFC] get_class() disallow null parameter

Hi! Following an earlier discussion in January, here is a small RFC to change get_class() to disallow null being passed as parameter. https://wiki.php.net/rfc/get_class_disallow_null_parameter Allowing null to be passed to get_class() is a 'gotcha' that is almost always a mistake in someone's co

Re: [PHP-DEV] Namespaces internal refactoring

On 8/14/2016 11:14 AM, Stanislav Malyshev wrote: > Hi! > >> Today I see 2 sides in PHP Internals. One that truly believes that PHP >> should adopt more concepts of object orientation, such as Annotations, >> Generics, Overloading, Class visibility, Collections, Exceptions, etc > > Object orientat

Re: [PHP-DEV] Namespaces internal refactoring

On 14/08/16 10:14, Stanislav Malyshev wrote: >> > I do have a lengthy, detailed and complex plan of how namespace >> > refactoring could be made, what it would enable feature-wise, and how it > Before getting to the question of how, we need to pass the question of > why. And that I think is much m

[PHP-DEV] Re: mt_srand with array seed?

On 2016-08-13 18:53, Tom Worster wrote: On 8/12/16 2:48 PM, Lauri Kenttä wrote: On 2016-08-12 21:40, Tom Worster wrote: mt_srand() will work. But what would be in the array? Integers from which the upper 32 bits, if they exist, are discarded? mt19937ar.c contains init_by_array. Compability wi

Re: [PHP-DEV] Simple variable handling.

On 14/08/16 09:50, Tony Marston wrote: > If you are still writing code to perform primary validation on each > field then your coding style is way behind the times. At some point you need to know the rules that wrap each field you are working with. The sort of forms I work with have individual rul

Re: [PHP-DEV] Namespaces internal refactoring

Hi! > Today I see 2 sides in PHP Internals. One that truly believes that PHP > should adopt more concepts of object orientation, such as Annotations, > Generics, Overloading, Class visibility, Collections, Exceptions, etc Object orientation is a very broad term. You can be very well object orient

Re: [PHP-DEV] Simple variable handling.

"Marco Pivetta" wrote in message news:cadyq6skzrbvyftqykyvym4iuex+2ouujvhep1jznm56k3+h...@mail.gmail.com... So much confusion... There are 3 (or more) types of validation in pretty much every web-app, so let's please stop calling it simply "validation". 1. frontend validation (unsafe/unreliab

Re: [PHP-DEV] [RFC][VOTE] Add session_create_id() function

On 14/08/16 01:56, Yasuo Ohgaki wrote: > IMO. PHP should be easiest, yet secure, Web application programming language. > I don't see any benefits, but only drawbacks, forcing users "to know session > management details to write secure code" while it is very easy to implement > tham in Session modul

Re: [PHP-DEV] Bug #72828

Hi! > You have commented on : > > | Unless the allocations explicitly use the system allocator (i.e. do > | not use emalloc and variants), do NOT introduce NULL checks. > > Can you please elaborate, why that shouldn't be done. > > Actually, the allocations