Re: [PHP-DEV] Request for karma to vote on RFCs

Hi! I think PHP’s biggest strength is its large and active community. But in my opinion, PHP (source/internals) often miss to benefit from our great community. I am happy to help making changes, but I feel like it is an impossible task for me… I mean, I cannot even update an outdated wiki entry.

Re: [PHP-DEV] [RFC] [VOTE] is_literal

Good morning, On Mon, Jul 19, 2021 at 9:11 AM Jordan LeDoux wrote: > > > Are there documented SQL injection opportunities when using emulated > prepares? I'm not aware of any. > > This was from my reading of the actual source, which of course may be > flawed. It appeared that if emulated prepares

[PHP-DEV] License for PHP 8.x?

I was just checking to see what the license was for PHP and this page[1] states: "PHP 4, PHP 5 and PHP 7 are distributed under the PHP License v3.01, copyright (c) the PHP Group." Can I assume that PHP 8 is also distributed under the PHP License v3.01 and that this page on PHP.net

Re: [PHP-DEV] Request for karma to vote on RFCs

Thank you Kalle for the reply. I do admire and respect Ondřej and his work on PHPStan. He is really talented and from what I hear a really nice person. But please don’t confuse Ondřej’s 8 packages with over 100.000 monthly downloads with my 50 packages plus another 100 in the Symfony organizat

Re: [PHP-DEV] [RFC] [VOTE] is_literal

> Are there documented SQL injection opportunities when using emulated prepares? I'm not aware of any. This was from my reading of the actual source, which of course may be flawed. It appeared that if emulated prepares were used the values were escaped and then passed as strings as part of the que

Re: [PHP-DEV] [RFC] [VOTE] is_literal

> > There's some BC-breaks to be aware of when switching emulated prepares. > One example I know of is that when using emulated prepares you can reuse > the same placeholder (as in the following example), but with emulated > prepares disabled this does not work. > > $sql = "SELECT * FROM table WHER

Re: [PHP-DEV] Request for karma to vote on RFCs

Hi Den søn. 18. jul. 2021 kl. 21.47 skrev Tobias Nyholm : > > Hey. > I would like to get karma to be able to vote on RFCs. I understand that > voting karma isn’t usually given out to people who write their first mailing > list entry. I'm not comfortable with this if this is indeed your first p

[PHP-DEV] Request for karma to vote on RFCs

Hey. I would like to get karma to be able to vote on RFCs. I understand that voting karma isn’t usually given out to people who write their first mailing list entry. But I do believe I qualify as “Lead developers of PHP based projects (frameworks, cms, tools, etc.)” For those of you who don’t

Re: [PHP-DEV] standardize php builtin functions

On 18/07/2021 10:08, Abdul Haq Sheikh wrote: Hello Internals, PHP has built in functions for string, array and math etc. But some string and array functions start with Str_* and array_* but not all. If we standardize php builtin functions so all string functions start with str_*, and all array

[PHP-DEV] standardize php builtin functions

Hello Internals, PHP has built in functions for string, array and math etc. But some string and array functions start with Str_* and array_* but not all. If we standardize php builtin functions so all string functions start with str_*, and all array functions start with array_* and all math functi

Re: [PHP-DEV] [RFC] [VOTE] is_literal

That sounds like something that would require both a deprecation and an RFC for the change then, even if the actual change in the source is small. It still may be worth exploring, since this surely gives a large number of people false confidence in protection against injection attacks, as nearly e

Re: [PHP-DEV] [RFC] [VOTE] is_literal

On 18/07/2021 03:41, Jordan LeDoux wrote: Related to the general topic of injection attacks, I was considering submitting a PR to change the default of PDO::ATTR_EMULUATE_PREPARES to FALSE, since this mistakenly can lead people to believe that using prepared statements with PDO and MySQL protec