Re: [PHP-DEV] Proposal: clamp

2021-06-22 Thread Marco Pivetta
Hey Kim On Wed, Jun 23, 2021, 02:25 Kim Hallberg wrote: > This function is very easy to implement, has no side effects or backward > compatibility issues, unless a userland implementation already has the > function declared, > I like the function, the name, and its simplicity. The problem is

[PHP-DEV] Proposal: clamp

2021-06-22 Thread Kim Hallberg
Greetings internals, I present to you a proposal for a new basic math function: clamp. The main goal of this function is to contain a number inside a given bound. And return the number if it is inside of that bound, and if not, and the number is outside of the given bound, the nearest bound is

Re: [PHP-DEV] [RFC] is_trusted - was is_literal

2021-06-22 Thread Moritz Friedrich
> Am 22.06.2021 um 20:38 schrieb Stephen Reay : > > It took me about a minute to think of this: > > "select * from customer_purchases where {$column} = :value”. > > The developer inadvertently passes the same “trusted value” in as the > `$column` substitute and the value parameter. It must be

Re: [PHP-DEV] [RFC] Deprecate boolean to string coercion

2021-06-22 Thread tyson andre
Hi George P. Banyard, > With Ilija we are proposing a short RFC to deprecate coercion from bool to > string: > https://wiki.php.net/rfc/deprecate-boolean-string-coercion > > As this is the final day for any RFC to be even able to land in PHP 8.1 > the voting is expected to start in two weeks on

[PHP-DEV] [RFC] Deprecate boolean to string coercion

2021-06-22 Thread G. P. B.
Hello Internals, With Ilija we are proposing a short RFC to deprecate coercion from bool to string: https://wiki.php.net/rfc/deprecate-boolean-string-coercion As this is the final day for any RFC to be even able to land in PHP 8.1 the voting is expected to start in two weeks on the 6th of July.

[PHP-DEV] Re: Add mysqi_stmt->query? (Was Sql Object Model Parser & Sanitizer)

2021-06-22 Thread Kamil Tekiela
Sounds good to me. Looking forward to your PoC.

[PHP-DEV] Add mysqi_stmt->query? (Was Sql Object Model Parser & Sanitizer)

2021-06-22 Thread Mike Schinkel
> On Jun 22, 2021, at 12:54 PM, Kamil Tekiela wrote: > While it's true that a lot of the internet is using mysqli due to WordPress, > this doesn't change the fact that PHP already offers a solution to the > problem. Both PDO and mysqli support server-side prepared statements. > Hi Kamil,

Re: [PHP-DEV] [RFC] is_trusted - was is_literal

2021-06-22 Thread Stephen Reay
Sent from my iPhone > On 23 Jun 2021, at 03:08, Lauri Kenttä wrote: > > On 2021-06-22 21:38, Stephen Reay wrote: On 22 Jun 2021, at 21:38, Craig Francis wrote: >>> If you can point me to an example where including integers in this has >>> introduced a security vulnerability then please

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

2021-06-22 Thread Kamil Tekiela
FWIW, I would prefer is_literal, but without integers in scope. Modern code is often type hinted. I would expect that a lot of libraries would accept only strings and then check whether it's a literal string. I don't think accepting integers in scope increases security or improves ease of use.

Re: [PHP-DEV] [RFC] is_trusted - was is_literal

2021-06-22 Thread Lauri Kenttä
On 2021-06-22 21:38, Stephen Reay wrote: On 22 Jun 2021, at 21:38, Craig Francis wrote: If you can point me to an example where including integers in this has introduced a security vulnerability then please do, and I mean it, that’s what this process is for, I genuinely want people to come

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

2021-06-22 Thread Derick Rethans
On 22 June 2021 19:11:05 BST, Craig Francis wrote: >Hi Internals, > >As the name `is_trusted()` seems to be causing contention, I think more >than the alternative option would. Since we want to get this right, and >we >still have time before the feature freeze, this might be worth >re-looking

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

2021-06-22 Thread Craig Francis
On Tue, 22 Jun 2021 at 20:38, Mel Dafert wrote: > Another idea - `is_internal()`, since it is not external code, and > internal would be the > opposite of external. Unfortunately, because we cannot record internal vs external integers (too big of a change to how integers are stored), we are

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

2021-06-22 Thread Mel Dafert
>- `is_trusted()` - suggested by Moritz and separately by Mike, was the >second option in the original vote, and was based on the idea that what is >returned can be 'trusted' to be free from external code. Another idea - `is_internal()`, since it is not external code, and internal would be the

Re: [PHP-DEV] [RFC] is_trusted - was is_literal

2021-06-22 Thread Stephen Reay
> On 22 Jun 2021, at 21:38, Craig Francis wrote: > > If you can point me to an example where including integers in this has > introduced a security vulnerability then please do, and I mean it, that’s > what this process is for, I genuinely want people to come forward with them > so we can

[PHP-DEV] [RFC] Name issue - is_literal/is_trusted

2021-06-22 Thread Craig Francis
Hi Internals, As the name `is_trusted()` seems to be causing contention, I think more than the alternative option would. Since we want to get this right, and we still have time before the feature freeze, this might be worth re-looking at. Particularly if you are one of those unsure about it, read

Re: [PHP-DEV] Sql Object Model Parser & Sanitizer (was [RFC] is_literal)

2021-06-22 Thread Kamil Tekiela
This is open to SQL injection: $queryBuilder ->select(...$_GET['columns']) ->from($_GET['table']) ->where($_GET['where']) ; All below statements produce 42. This is valid SQL: SELECT `42 FROM TABLE`() FROM dual; SELECT `⠀` FROM `⠀`; SELECT * FROM "42"; -- With ANSI_QUOTES SELECT *

Re: [PHP-DEV] Sql Object Model Parser & Sanitizer (was [RFC] is_literal)

2021-06-22 Thread Larry Garfield
On Tue, Jun 22, 2021, at 11:46 AM, Mike Schinkel wrote: > Maybe this will help. There are a billion XML schemas, but DomDocument > and its related classes can process them all. A SqlObjectModel would be > similar; it would know how to process text queries where the dialect > interface

Re: [PHP-DEV] Sql Object Model Parser & Sanitizer (was [RFC] is_literal)

2021-06-22 Thread Kamil Tekiela
While it's true that a lot of the internet is using mysqli due to WordPress, this doesn't change the fact that PHP already offers a solution to the problem. Both PDO and mysqli support server-side prepared statements. We don't talk about WordPress. They should not hold back PHP. That project is

Re: [PHP-DEV] Sql Object Model Parser & Sanitizer (was [RFC] is_literal)

2021-06-22 Thread Mike Schinkel
> On Jun 22, 2021, at 11:41 AM, Larry Garfield wrote: > > On Tue, Jun 22, 2021, at 8:39 AM, Mike Schinkel wrote: >>> On Jun 22, 2021, at 9:00 AM, Kamil Tekiela wrote: >>> >>> Hi Mike, >>> >>> Please don't do this. We already have PDO with prepared statements. The >>> data must be bound.

Re: [PHP-DEV] Sql Object Model Parser & Sanitizer (was [RFC] is_literal)

2021-06-22 Thread Mike Schinkel
> On Jun 22, 2021, at 11:56 AM, Pierre wrote: > > Le 22/06/2021 à 17:35, Mike Schinkel a écrit : >> https://github.com/WordPress/WordPress/blob/master/wp-includes/wp-db.php#L2050 > Sorry for the discussion pollution here but, but ouch, plugins are still > using this unsafe form ? Reminds when

Re: [PHP-DEV] Sql Object Model Parser & Sanitizer (was [RFC] is_literal)

2021-06-22 Thread Pierre
Le 22/06/2021 à 17:35, Mike Schinkel a écrit : https://github.com/WordPress/WordPress/blob/master/wp-includes/wp-db.php#L2050 Sorry for the discussion pollution here but, but ouch, plugins are still using this unsafe form ? Reminds when I was a student, I learnt to parametrize queries there,

Re: [PHP-DEV] Sql Object Model Parser & Sanitizer (was [RFC] is_literal)

2021-06-22 Thread Larry Garfield
On Tue, Jun 22, 2021, at 8:39 AM, Mike Schinkel wrote: > > On Jun 22, 2021, at 9:00 AM, Kamil Tekiela wrote: > > > > Hi Mike, > > > > Please don't do this. We already have PDO with prepared statements. The > > data must be bound. This is the secure way of writing SQL queries. > > The problem

Re: [PHP-DEV] Sql Object Model Parser & Sanitizer (was [RFC] is_literal)

2021-06-22 Thread Mike Schinkel
> On Jun 22, 2021, at 10:35 AM, Stephen Reay wrote: > >> On 22 Jun 2021, at 20:39, Mike Schinkel wrote: >> >>> On Jun 22, 2021, at 9:00 AM, Kamil Tekiela wrote: >>> >>> Hi Mike, >>> >>> Please don't do this. We already have PDO with prepared statements. The >>> data must be bound. This is

Re: [PHP-DEV] [RFC] is_trusted - was is_literal

2021-06-22 Thread Craig Francis
On Tue, 22 Jun 2021 at 3:05 pm, Stephen Reay wrote: > > On 22 Jun 2021, at 20:13, Craig Francis wrote: > > On Tue, 22 Jun 2021 at 09:59, Stephen Reay > wrote: > >> So I just want to make sure I understand the progression on this so far. >> It started out with people wanting a way to check that

Re: [PHP-DEV] Sql Object Model Parser & Sanitizer (was [RFC] is_literal)

2021-06-22 Thread Stephen Reay
> On 22 Jun 2021, at 20:39, Mike Schinkel wrote: > >> On Jun 22, 2021, at 9:00 AM, Kamil Tekiela wrote: >> >> Hi Mike, >> >> Please don't do this. We already have PDO with prepared statements. The data >> must be bound. This is the secure way of writing SQL queries. > > The problem is

Re: [PHP-DEV] [RFC] is_trusted - was is_literal

2021-06-22 Thread Stephen Reay
> On 22 Jun 2021, at 20:13, Craig Francis wrote: > > On Tue, 22 Jun 2021 at 09:59, Stephen Reay > wrote: > So I just want to make sure I understand the progression on this so far. It > started out with people wanting a way to check that a string was a literal

Re: [PHP-DEV] Sql Object Model Parser & Sanitizer (was [RFC] is_literal)

2021-06-22 Thread Mike Schinkel
> On Jun 22, 2021, at 9:00 AM, Kamil Tekiela wrote: > > Hi Mike, > > Please don't do this. We already have PDO with prepared statements. The data > must be bound. This is the secure way of writing SQL queries. The problem is that over 40% of the web currently runs on PHP code that using

Re: [PHP-DEV] Sql Object Model Parser & Sanitizer (was [RFC] is_literal)

2021-06-22 Thread Pierre
Le 22/06/2021 à 15:00, Kamil Tekiela a écrit : Hi Mike, Please don't do this. We already have PDO with prepared statements. The data must be bound. This is the secure way of writing SQL queries. The idea behind SQL builder is to generate SQL, not to allow the data to be sanitized. Every time I

Re: [PHP-DEV] [RFC] is_trusted - was is_literal

2021-06-22 Thread Craig Francis
On Tue, 22 Jun 2021 at 09:59, Stephen Reay wrote: > So I just want to make sure I understand the progression on this so far. > It started out with people wanting a way to check that a string was a > literal string, in code somewhere, and does not come from user input. Ok > makes sense. The name

Re: [PHP-DEV] Sql Object Model Parser & Sanitizer (was [RFC] is_literal)

2021-06-22 Thread Kamil Tekiela
Hi Mike, Please don't do this. We already have PDO with prepared statements. The data must be bound. This is the secure way of writing SQL queries. The idea behind SQL builder is to generate SQL, not to allow the data to be sanitized. Every time I hear the word sanitize I get goose bumps. You

[PHP-DEV] Re: Sql Object Model Parser & Sanitizer (was [RFC] is_literal)

2021-06-22 Thread Pierre
Le 22/06/2021 à 14:45, Mike Schinkel a écrit : I think we are talking two different things here.  And I will admit I am probably the one that is not using exactly the right term.  I had envisioned something, and then Dan said "SQL Builder" I used that term. Let me clarify

[PHP-DEV] Sql Object Model Parser & Sanitizer (was [RFC] is_literal)

2021-06-22 Thread Mike Schinkel
> On Jun 22, 2021, at 6:45 AM, Pierre wrote: > > Le 22/06/2021 à 11:28, Dan Ackroyd a écrit : >> On Tue, 22 Jun 2021 at 10:25, Mike Schinkel wrote: >>> Should(n't?) PHP add a basic SQL builder class that can be extended for >>> special cases, e.g. different flavors of SQL? >>> >> No. Or at

Re: [PHP-DEV] [RFC] is_literal

2021-06-22 Thread Lauri Kenttä
On 2021-06-15 10:19, Joe Watkins wrote: It's just that existing implementation details - RETURN_CHAR using interned strings, and literal constant strings being interned by the compiler - lead to a literal string being "re-used". This is just a natural consequence of literal strings retaining

Re: [PHP-DEV] [RFC] is_trusted - was is_literal

2021-06-22 Thread Craig Francis
On Tue, 22 Jun 2021 at 11:31 am, Hans Henrik Bergan wrote: > How is one supposed to use this? like > > if(!is_trusted($val)){ > $val = htmlentities($str, ENT_QUOTES | ENT_HTML401 | ENT_SUBSTITUTE | > ENT_DISALLOWED, 'UTF-8', true); > } > echo "$val"; No, if anything that’s the opposite,

Re: [PHP-DEV] [RFC] is_literal

2021-06-22 Thread Pierre
Le 22/06/2021 à 11:28, Dan Ackroyd a écrit : On Tue, 22 Jun 2021 at 10:25, Mike Schinkel wrote: Should(n't?) PHP add a basic SQL builder class that can be extended for special cases, e.g. different flavors of SQL? No. Or at least not yet. This type of thing is much better done in userland,

Re: [PHP-DEV] [RFC] is_trusted - was is_literal

2021-06-22 Thread Hans Henrik Bergan
How is one supposed to use this? like if(!is_trusted($val)){ $val = htmlentities($str, ENT_QUOTES | ENT_HTML401 | ENT_SUBSTITUTE | ENT_DISALLOWED, 'UTF-8', true); } echo "$val"; (...) if(!is_trusted($val)){ $val = $mysqli->real_escape_string($val); } $mysqli->query("INSERT INTO tbl

Re: [PHP-DEV] [RFC] is_literal

2021-06-22 Thread Lauri Kenttä
On 2021-06-22 12:15, Dan Ackroyd wrote: Dan Ackroyd wrote: If people aren't going to make using a non-literal where a literal is expected, be an error, the only alternative I can see is logging it. Please correct me if you think people should be doing something other than those two things.

Re: [PHP-DEV] [RFC] is_trusted - was is_literal

2021-06-22 Thread Lauri Kenttä
On 2021-06-21 23:25, Craig Francis wrote: - Integers are now included, which will help adoption: https://wiki.php.net/rfc/is_literal Thanks for the great improvements! sprintf seems to have some issues, though. Currently you're checking the parameter types, not the formats. The parameter

Re: [PHP-DEV] [RFC] is_literal

2021-06-22 Thread Mike Schinkel
> On Jun 22, 2021, at 5:28 AM, Dan Ackroyd wrote: > > On Tue, 22 Jun 2021 at 10:25, Mike Schinkel wrote: >> >> Should(n't?) PHP add a basic SQL builder class that can be extended for >> special cases, e.g. different flavors of SQL? >> > > No. Or at least not yet. > > This type of thing is

Re: [PHP-DEV] [RFC] is_literal

2021-06-22 Thread Dan Ackroyd
On Tue, 22 Jun 2021 at 10:25, Mike Schinkel wrote: > > Should(n't?) PHP add a basic SQL builder class that can be extended for > special cases, e.g. different flavors of SQL? > No. Or at least not yet. This type of thing is much better done in userland, where the api can evolve at a fast rate,

Re: [PHP-DEV] [RFC] is_literal

2021-06-22 Thread Mike Schinkel
> On Jun 22, 2021, at 4:53 AM, Dan Ackroyd wrote: > > The whole point of the idea of literal strings is to make it be easier > to write some code that: > > i) is safe. > ii) can be reasoned about at scale. > > Passing bare strings around is not so great for either of those > things. You have

Re: [PHP-DEV] [RFC] is_literal

2021-06-22 Thread Dan Ackroyd
Dan Ackroyd wrote: >> The developer who made that change would run the tests, >> see the tests pass and then push their code live. At which point, it >> would cause an error in production, as the string returned would not >> pass the is_literal check. Craig Francis wrote: > No, the only way

Re: [PHP-DEV] [RFC] is_trusted - was is_literal

2021-06-22 Thread Mike Schinkel
> On Jun 21, 2021, at 7:18 PM, Benjamin Morel wrote: > > On Tue, 22 Jun 2021 at 01:06, Derick Rethans wrote: > >> On 21 June 2021 23:37:56 BST, Yasuo Ohgaki wrote: >>> >>> The name "is_trusted" is misleading. >>> Literal is nothing but literal. >> >> I agree with this. The name is_trusted

Re: [PHP-DEV] [PROPOSAL] Bare name array literals (again)

2021-06-22 Thread Rowan Tommins
On 22/06/2021 01:03, tyson andre wrote: If linters and automatic fixers were set up for a project to enforce it (e.g. phpcbf), there would only be one way that literals would be used in a project either way. The only way to be consistent across a whole project would be to never use the new

Re: [PHP-DEV] [RFC] is_trusted - was is_literal

2021-06-22 Thread Stephen Reay
> On 22 Jun 2021, at 15:58, Stephen Reay wrote: > > > >> On 22 Jun 2021, at 06:28, Craig Francis > > wrote: >> >> On Tue, 22 Jun 2021 at 12:18 am, Benjamin Morel > >

Re: [PHP-DEV] [RFC] is_trusted - was is_literal

2021-06-22 Thread Stephen Reay
> On 22 Jun 2021, at 06:28, Craig Francis wrote: > > On Tue, 22 Jun 2021 at 12:18 am, Benjamin Morel > > wrote: > >> On Tue, 22 Jun 2021 at 01:06, Derick Rethans wrote: >> >>> On 21 June 2021 23:37:56 BST, Yasuo Ohgaki wrote: The name

Re: [PHP-DEV] [RFC] is_literal

2021-06-22 Thread Dan Ackroyd
On Mon, 14 Jun 2021 at 14:27, Thomas Nunninger wrote: > Thomas Nunninger wrote: Thomas Nunninger wrote: > Only some (infrastructure or > end-to-end) test that covers the business logic plus the corresponding > infrastructure by accident would uncover an error. I think testing will be much

Re: [PHP-DEV] [PROPOSAL] Bare name array literals (again)

2021-06-22 Thread Mike Schinkel
> On Jun 21, 2021, at 1:34 PM, Rowan Tommins wrote: > > On 21/06/2021 17:54, tyson andre wrote: >> In every place where `key` is a valid php identifier >> (e.g. can be used in PHP 8.0's named parameters), >> I propose to allow `[key: expr]` to be used instead of `['key' => expr]`. > > This is