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

[Scott Arciszewski]

On Wed, Jun 23, 2021, 9:23 PM Bruce Weirdan  wrote:

> On Thu, Jun 24, 2021 at 3:41 AM Scott Arciszewski 
> wrote:
> > The failure condition of this query is
> > "return all rows from the table already being queried", not "return
> > arbitrary data the attacker selects from any table that the
> > application can read".
>
> Imagine that was a DELETE rather than SELECT and the failure condition
> becomes 'the table is emptied'.
> It may have less disastrous consequences (depending on how good your
> backup / restore procedures are) compared to arbitrary reads you
> demonstrated, but it is still, quite clearly, a glaring security hole
> caused by user input in SQL query - AKA SQL injection in layman's
> terms.
>
> > it differs from Injection vulnerabilities in one
> > fundamental way: The attacker cannot change the structure of the SQL
> > query being executed.
>
> I would say replacing a column name with value is changing the
> structure of SQL query, and, basically, in exactly the way you
> describe SQL injection: confusing the code (column name) with data.
>
> I wholeheartedly welcome this RFC as it was originally proposed:
> is_literal() doing exactly what it says on the tin, without any
> security claims. But it has gone far from there real quick and now
> people can't even name the thing.
>
>
> --
>   Best regards,
>   Bruce Weirdan mailto:
> weir...@gmail.com



We can agree that it is a bug. We don't agree on the definition of SQL
injection.

Changing a column name to a number (which prepared statements shouldn't
allow in the first place) is a bug. This changes the effect of the command,
but the *structure* of the query remains unchanged.

>
>

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

[Bruce Weirdan]

On Thu, Jun 24, 2021 at 3:41 AM Scott Arciszewski  wrote:
> The failure condition of this query is
> "return all rows from the table already being queried", not "return
> arbitrary data the attacker selects from any table that the
> application can read".

Imagine that was a DELETE rather than SELECT and the failure condition
becomes 'the table is emptied'.
It may have less disastrous consequences (depending on how good your
backup / restore procedures are) compared to arbitrary reads you
demonstrated, but it is still, quite clearly, a glaring security hole
caused by user input in SQL query - AKA SQL injection in layman's
terms.

> it differs from Injection vulnerabilities in one
> fundamental way: The attacker cannot change the structure of the SQL
> query being executed.

I would say replacing a column name with value is changing the
structure of SQL query, and, basically, in exactly the way you
describe SQL injection: confusing the code (column name) with data.

I wholeheartedly welcome this RFC as it was originally proposed:
is_literal() doing exactly what it says on the tin, without any
security claims. But it has gone far from there real quick and now
people can't even name the thing.


--
  Best regards,
  Bruce Weirdan mailto:weir...@gmail.com

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

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

[Scott Arciszewski]

On Wed, Jun 23, 2021 at 8:09 PM Bruce Weirdan  wrote:
>
> > - String + int concatenation isn't an injection risk.
>
> I think this demonstrates it very well could be:
> https://externals.io/message/114988#115038
>
> --
>   Best regards,
>   Bruce Weirdan 
> mailto:weir...@gmail.com

Respectfully, the example you linked is **not** an example of an
Injection vulnerability. The failure condition of this query is
"return all rows from the table already being queried", not "return
arbitrary data the attacker selects from any table that the
application can read".

Being able to arbitrarily select a column is a bad design (and you
should feel bad, as per the meme, if you let this happen in
production), but it differs from Injection vulnerabilities in one
fundamental way: The attacker cannot change the structure of the SQL
query being executed.

Here's an example of an injection vulnerability:

`$pdo->prepare("SELECT b, c, d, e FROM table WHERE a = '$foo'");`

If you set $foo to `' UNION SELECT NULL, NULL, NULL, pwhash FROM
accounts WHERE username = 'Admin`, you'll leak contents from *another
table* in the SQL result. This is the danger posted by
string-to-string concatenation, and what we mean by SQL Injection.

This doesn't have to stop all dumb things that PHP developers can do.
It's enough to only stop the catastrophically dumb things (especially
if we don't call the function `is_trusted()`).

You can still invent scenarios where int-to-string concatenation
results in buggy behavior, but it isn't the game-over security
vulnerability that string-to-string concatenation is. And that's the
entire point.

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

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

[Craig Francis]

On Thu, 24 Jun 2021 at 1:09 am, Bruce Weirdan  wrote:

> > - String + int concatenation isn't an injection risk.
>
> I think this demonstrates it very well could be:
> https://externals.io/message/114988#115038




That’s the developer choosing to use a variable, and it’s no different than
the developer using a library to add the value via proper quoting/escaping.

Craig

Re: [PHP-DEV] [RFC] clamp

[tyson andre]

Hello Kim Hallberg,

> The RFC for the clamp function is now open and under discussion, you now have 
> 2 weeks 
> to discuss, suggest improvements and open issues before voting is considered.


>From https://wiki.php.net/rfc/clamp - 

> Current userland implementations are handled in several ways, some of which 
> use min and max to check the bound,
> which is costly and slow when called often.
> Because userland implementations are for the most part not cost-effective 
> when called multiple times,
> a language implementation is desired.

I'd strongly prefer an actual benchmark for context and accuracy - is it 
actually faster or slower than the most efficient userland implementation and 
by how much?
E.g. in an optimized NTS build with `CFLAGS=-O2`, opcache 
enabled(zend_extension=opcache, opcache.enable=1,opcache.enable_cli=1),
and no debug configure flags, how many calls per second can be made on variable 
values of $num for both?
(I'd assume over twice as fast as calling both min/max from another function, 
but possibly slower than efficient_clamp, but haven't run this)

For userland implementations that did use min/max, they probably weren't 
performance sensitive for the application.

```php
function efficient_clamp(int|float $num, int|float $min, int|float $max): 
int|float {
return $num < $min ? $min : ($num > $max ? $max : $num);
}
```

Thanks,
Tyson

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

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

[Bruce Weirdan]

> - String + int concatenation isn't an injection risk.

I think this demonstrates it very well could be:
https://externals.io/message/114988#115038

-- 
  Best regards,
  Bruce Weirdan mailto:weir...@gmail.com

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

Re: [PHP-DEV] [RFC] Add parse_query_string as an alternative to parse_str

[David Rodrigues]

I really prefer the Sara suggestion, instead of creating a new function
to do the same thing. parse_str($str): array.


Atenciosamente,
David Rodrigues


Em qua., 23 de jun. de 2021 às 20:20, Sara Golemon 
escreveu:

> On Wed, Jun 23, 2021 at 5:02 PM Kamil Tekiela 
> wrote:
>
> > I would like to propose a new simple RFC that aims to add a new function
> > called parse_query_string as an alternative to parse_str.
> >
> > https://wiki.php.net/rfc/parse_str_alternative
> >
> > The functionality stays the same, only the name and the way of returning
> > the array changes. While it is a rather insignificant change, I believe
> it
> > is one step closer to making PHP cleaner.
> >
> >
> There's a potential alternative option that doesn't require adding a new,
> parallel function.  We can use execute_data->return_value_used to figure
> out if parse_str() was called with the result assigned to a local var.
> This is overloady and probably a bad idea, but it's an option.
>
> if (ZEND_NUM_ARGS() == 2) {
>   // Put result into by-ref second arg
>   // parse_str($str, $refResult);
> } else if (EX(return_value_used)) {
>   // Put result into return_value
>   // $result = parse_str($str);
> } else {
>   // Put result into EG(local_symbol_table)
>   // parse_str($str);
>   php_error(E_DEPRECATED, ...);
> }
>
> Realistically, your approach is probably better simply because it doesn't
> depend on the assignment as a side-effect, and it'll be good to have a
> migration route, especially one which gives us a function with, frankly, a
> much better name.
>
> That said, and I'll sound like a broken record here, but this is another
> case of being something that can be sorted in userspace trivially:
>
> function parse_query_string(string $str): array {
>   parse_str($str, $ret);
>   return $ret;
> }
>
> Kinda +/- 0 on it at the moment.  I'm less hostile to it than
> str_contains()/str_left()/str_right()/etc...
>
> -Sara
>

Re: [PHP-DEV] [RFC] clamp

[tyson andre]

Hi Kim Hallberg,

> The RFC for the clamp function is now open and under discussion, you now have 
> 2 weeks 
> to discuss, suggest improvements and open issues before voting is considered.
> 
> Any and all feedback is welcomed.
> 
> The RFC is available for viewing here: https://wiki.php.net/rfc/clamp
> The implementation is available in a PR here: 
> https://github.com/php/php-src/pull/7191

https://wiki.php.net/rfc/howto mentions:

> Listen to the feedback, and try to answer/resolve all questions.
> **Update your RFC to document all the issues and discussions.
> Cover both the positive and negative arguments.** Put the RFC URL into all 
> your replies.

So I think the major objections are that:

1. This is easy to implement in userland and there's negligible performance 
benefit
   (in code that is a performance sensitive loop, it may still be worse 
compared to `$num < $min ? $min : ($num > $max : $max : $num)` when validity of 
types and min/max are known, especially with the JIT)
2. People not being sure if they'd ever use it personally, especially with the 
ability to customize parameter order and permitted argument types in userland
3. It's inconsistent with min() and max(), which support any comparable type 
such as GMP(https://www.php.net/manual/en/class.gmp)
   (arbitrary precision numbers), DateTime, etc., and that may lead to 
surprises.
   Although PHP's comparison operator and 
https://www.php.net/manual/en/function.min.php have many, many inconsistencies, 
already

   (Though special casing GMP is probably a bad idea due to it being optional 
and having an incompatible license with core for packagers)
4. I'm not sure what this is meant to do with the float NAN (Not A Number) from 
the RFC description, but that's solvable

```
php > var_dump(min(gmp_init('123'), gmp_init('456')));
object(GMP)#1 (1) {
  ["num"]=>
  string(3) "123"
}
php > var_dump(max(new DateTime('@0'), new DateTime()));
object(DateTime)#2 (3) {
  ["date"]=>
  string(26) "2021-06-23 23:44:47.302531"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(3) "UTC"
}
php > echo json_encode(max([0,2],[0,1]));
[0,2]
```

The RFC should probably link to this RFC announcement thread 
https://externals.io/message/115076 as well.

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

Re: [PHP-DEV] [Vote] make Reflection*#setAccessible() no-op

[tyson andre]

Mi Marco Pivetta,

> I'm opening the vote for making `Reflection*#setAccessible()`.
> 
> Voting starts today (2021-06-23) and ends in 14 days (2021-07-07).
> 
> Vote at https://wiki.php.net/rfc/make-reflection-setaccessible-no-op
> 
> Discussion: https://marc.info/?l=php-internals=162360269505048=2
> 
> Discussion^2: https://externals.io/message/114841

I'm in favor of this even without adding isAccessible(),
but just to note:

https://wiki.php.net/rfc/howto mentions:

> Listen to the feedback, and try to answer/resolve all questions.
> **Update your RFC to document all the issues and discussions.
> Cover both the positive and negative arguments.** Put the RFC URL into all 
> your replies.

1. This should probably link to the RFC discussions in a References section,
   not everyone who votes reads the mailing list.
2. https://externals.io/message/114841#114845  is the only thing that resembled 
an objection for a "Discussion" 
   section or future scope, though

   > I think that isAccessible should be added if any applications actually did 
depend on ReflectionException
   > being thrown for correctness - they could throw their own exception if 
isAccessible was false.
   > (e.g. for code meant to handle possibly undefined public typed properties 
by checking for initialization
   > then getting the value)
   >
   > I can't actually remember needing this (anything other than 
setAccessible(true)) personally, though, since `$obj->{$method}(...$args)` 
could be used.
   > I've only used this to access private and protected properties/methods.

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

Re: [PHP-DEV] [RFC] Add parse_query_string as an alternative to parse_str

[Sara Golemon]

On Wed, Jun 23, 2021 at 5:02 PM Kamil Tekiela  wrote:

> I would like to propose a new simple RFC that aims to add a new function
> called parse_query_string as an alternative to parse_str.
>
> https://wiki.php.net/rfc/parse_str_alternative
>
> The functionality stays the same, only the name and the way of returning
> the array changes. While it is a rather insignificant change, I believe it
> is one step closer to making PHP cleaner.
>
>
There's a potential alternative option that doesn't require adding a new,
parallel function.  We can use execute_data->return_value_used to figure
out if parse_str() was called with the result assigned to a local var.
This is overloady and probably a bad idea, but it's an option.

if (ZEND_NUM_ARGS() == 2) {
  // Put result into by-ref second arg
  // parse_str($str, $refResult);
} else if (EX(return_value_used)) {
  // Put result into return_value
  // $result = parse_str($str);
} else {
  // Put result into EG(local_symbol_table)
  // parse_str($str);
  php_error(E_DEPRECATED, ...);
}

Realistically, your approach is probably better simply because it doesn't
depend on the assignment as a side-effect, and it'll be good to have a
migration route, especially one which gives us a function with, frankly, a
much better name.

That said, and I'll sound like a broken record here, but this is another
case of being something that can be sorted in userspace trivially:

function parse_query_string(string $str): array {
  parse_str($str, $ret);
  return $ret;
}

Kinda +/- 0 on it at the moment.  I'm less hostile to it than
str_contains()/str_left()/str_right()/etc...

-Sara

Re: [PHP-DEV] Introduce str_left/right In 8.1

[Sara Golemon]

On Wed, Jun 23, 2021 at 2:10 PM Mike Schinkel  wrote:

> I have frequently heard the justification of maintenance burden mentioned
> as an objection to adding specific features.  And in many cases, it is easy
> to see why future maintenance burden would be a concern.
>
> However, it *seems* in this case that these functions are so trivial to
> implement that once written and documented they would likely never need to
> be touched again. But as I do not yet know the internals of PHP I obviously
> do not know that to be a fact.
>
> Honest question: Would you mind explaining the type of maintenance
> required for simple functions like this?  What is likely to change in the
> future that would require maintenance?  And would you mind giving a few or
> at least one example of a trivial function that did need to be maintained
> after it was written?
>
>
Honest answer. I won't personally feel any pain from adding these
functions. No more than I felt when str_contains() was added over my
objections.  Nobody maintaining PHP will feel significant burden from
them.  They'll sit in ext/standard/string.c doing their trivial work,
opaque to the jit, and they'll get used or not.  If cluttering the kitchen
sink with one more unwashed utensil makes someone happy, then fine.  I'm
not going to vote for it though, because it belongs in composer/packagist
land, not in core.  I've listed the reasons for this in the str_contains()
threads, feel free to reference those, they're still valid and correct.

-Sara

P.S. - I don't actually think the octet versus codepoint versus grapheme
argument can be particularly persuasive given that our core string
functions aren't encoding aware in the slightest.  That ship has sailed.
It is, however, another argument for doing this in userspace where the
tradeoff is far more obvious, and dealing with alternative multibyte
engines and/or polyfills is much more facile.

[PHP-DEV] [RFC] Add parse_query_string as an alternative to parse_str

[Kamil Tekiela]

Hi Internals,

I would like to propose a new simple RFC that aims to add a new function
called parse_query_string as an alternative to parse_str.

https://wiki.php.net/rfc/parse_str_alternative

The functionality stays the same, only the name and the way of returning
the array changes. While it is a rather insignificant change, I believe it
is one step closer to making PHP cleaner.

Regards,
Kamil

Re: [PHP-DEV] Introduce str_left/right In 8.1

[Rowan Tommins]

On 23/06/2021 22:28, Christoph M. Becker wrote:

substr() is about bytes, not characters.  They all may have upvoted the
wrong answer.  The only correct answer has just 17 upvotes.



Just to out-pedant you, I'll point out that what most people would think 
of as a "character" is neither a byte nor a code point, but a grapheme, 
so I would say *none* of the answers on that page is correct.


$string = 'Zoë'; // "Zoe\u{0308}" not "Zo\u{00EB}"

var_dump(substr($string, -1));
var_dump(mb_substr($string, -1));
var_dump(grapheme_substr($string, -1));

string(1) "�"
string(2) "̈"
string(3) "ë"

https://3v4l.org/IMoWQ


Regards,

--
Rowan Tommins
[IMSoP]

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

Re: [PHP-DEV] Introduce str_left/right In 8.1

[Christoph M. Becker]

On 23.06.2021 at 21:10, Mike Schinkel wrote:

> Replying to both Sara's and G.P.B.'s emails below:
>
>> On Jun 23, 2021, at 12:48 PM, Sara Golemon  wrote:
>>
>> Using some context, I would assume you mean this:
>>
>> function str_left(string $str, int $len): string {
>>  return substr($str, 0, $len);
>> }
>>
>> function str_right(string $str, int $len): string {
>>  return substr($str, -$len);
>> }
>>
>> If that's the case, then why?  As you can see, the existing
>> functionality available is trivial to write.
>> 
>> Am I misunderstanding what these proposed functions should do, or am I
>> underestimating the difficulty of typing a zero or negative sign on certain
>> keyboards?
>
> I can't speak for Hamza, but one reason I can see for why — at least for 
> str_right() — is that using a negative index might not occur to many people. 
> Hell, I even forgot substr() worked that way until you mentioned it.
>
> But, since objective evidence is better than opinion, a non-trivial number of 
> people have searched how to get the last 'n' characters from a string in PHP, 
> found the answer, and then went to the effort to upvote it on StackOverflow.  
> If the 90-9-1 rule holds, then that's about 6200 people who have been 
> confused, searched and found the answer here:
>
> https://stackoverflow.com/questions/10542310/how-can-i-get-the-last-7-characters-of-a-php-string
>  
> 

substr() is about bytes, not characters.  They all may have upvoted the
wrong answer.  The only correct answer has just 17 upvotes.

Christoph

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

Re: [PHP-DEV] [VOTE] Deprecate autovivification on false

[Kamil Tekiela]

Hi All,

The voting on https://wiki.php.net/rfc/autovivification_false has been
closed. The RFC is accepted with score 34:2 (94%)

Thanks,
Kamil

Re: [PHP-DEV] Introduce str_left/right In 8.1

[Mike Schinkel]

Replying to both Sara's and G.P.B.'s emails below:

> On Jun 23, 2021, at 12:48 PM, Sara Golemon  wrote:
> 
> Using some context, I would assume you mean this:
> 
> function str_left(string $str, int $len): string {
>  return substr($str, 0, $len);
> }
> 
> function str_right(string $str, int $len): string {
>  return substr($str, -$len);
> }
> 
> If that's the case, then why?  As you can see, the existing
> functionality available is trivial to write.  
> 
> Am I misunderstanding what these proposed functions should do, or am I
> underestimating the difficulty of typing a zero or negative sign on certain
> keyboards?

I can't speak for Hamza, but one reason I can see for why — at least for 
str_right() — is that using a negative index might not occur to many people. 
Hell, I even forgot substr() worked that way until you mentioned it.

But, since objective evidence is better than opinion, a non-trivial number of 
people have searched how to get the last 'n' characters from a string in PHP, 
found the answer, and then went to the effort to upvote it on StackOverflow.  
If the 90-9-1 rule holds, then that's about 6200 people who have been confused, 
searched and found the answer here:

https://stackoverflow.com/questions/10542310/how-can-i-get-the-last-7-characters-of-a-php-string
 


For future people to whom it does not occur that substr() accepts negative 
arguments, or for people who forget that fact, str_right() would provide an 
obvious solution that would be easy to find in IDE autocomplete or when 
scanning the list of functions on PHP.net.  

At which point it would make sense to also at str_left() for symmetry.  

That said, my world won't change if these functions are not added, but adding 
them would be nice a little improvement to daily PHP developer experience.

> On Jun 23, 2021, at 10:52 AM, G. P. B.  wrote:
> 
> All this to say that the burden of maintenance for such a specialized
> function makes it very unsuitable to be in core.

I have frequently heard the justification of maintenance burden mentioned as an 
objection to adding specific features.  And in many cases, it is easy to see 
why future maintenance burden would be a concern.

However, it *seems* in this case that these functions are so trivial to 
implement that once written and documented they would likely never need to be 
touched again. But as I do not yet know the internals of PHP I obviously do not 
know that to be a fact.

Honest question: Would you mind explaining the type of maintenance required for 
simple functions like this?  What is likely to change in the future that would 
require maintenance?  And would you mind giving a few or at least one example 
of a trivial function that did need to be maintained after it was written?  

Thank you in advance for taking the time and effort to answer.

-Mike

[PHP-DEV] [RFC] clamp

[Kim Hallberg]

Hello internals,

The RFC for the clamp function is now open and under discussion, you now have 2 
weeks 
to discuss, suggest improvements and open issues before voting is considered.

Any and all feedback is welcomed.

The RFC is available for viewing here: https://wiki.php.net/rfc/clamp 
 
The implementation is available in a PR here: 
https://github.com/php/php-src/pull/7191 


Thank you,
Kim Hallberg

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

[Scott Arciszewski]

On Wed, Jun 23, 2021 at 10:54 AM Craig Francis  wrote:
>
> On Wed, 23 Jun 2021 at 14:37, Larry Garfield  wrote:
>
> > I'm still very torn on is_literal; I fear that the people who would
> > benefit from it are the very people that don't use the tools that would
> > leverage it (DBALs et al), and so the net benefit will be small.
> >
>
>
> This RFC will not help those who aren’t using libraries (DBALs), that’s
> something we could look at in the future (I have a suggestion in the Future
> Scope section, but whatever that involves, it will need to use this flag,
> so it would need to be in place first).
>
> But - and why I’m here - my experience is that it’s still a big issue for
> those who *do* use libraries. It frequently comes up at software
> agencies/companies that maintain their code (built with free
> libraries/frameworks), and employ junior developers (i.e. the cheapest),
> who make many "quick edits" (time is money), and in doing so introduce the
> issues the RFC covers (and not to say we more experienced coders don’t
> occasionally make mistakes too!). While non-library users are the main
> cause, the library users are still a big part of why Injection
> Vulnerabilities remain at the top of the OWASP Top 10.
>
> Craig

Hi,

I was asked for my thoughts on this RFC (and its naming) from a
security engineering perspective.

The old is_literal() isn't correct if it includes non-string values
(i.e. integers).
The new is_trusted() is potentially misleading, especially to people
who don't read the docs.

My knee-jerk reaction was simply, "Why not is_untainted()?" but that
invokes the imagery of taint-checking, which the RFC explicitly
doesn't implement. A better name might be is_noble(), where we get to
define the concept of noble inputs (name inspired by the Noble gases
from Chemistry).

The main reason I don't like is_trusted() is that everyone's threat
model and risk tolerance is different, and trust is too nebulous a
concept for a built-in function. But also, it's really easy to jump
the guard-rail: https://3v4l.org/4GM8Q#focus=rfc.literals

One concern that Joe Watkins asked about is: Is it reasonable to cover
both integers and strings that are not influenceable by potential
external attackers (n.b. ones that can't already overwrite your source
code)? Outside the chr()/pack()/sprintf()/etc. technique demonstrated
above, there's no risk of injection inherent to concatenating a
trusted string with an untrusted integer.

Injection attacks (SQL injection, LDAP injection, XSS, etc.) are, at
their core, an instance of type confusion between data and code. In
order for the injection to *do* anything, it needs to be in the same
input domain as the language the code is written in. Try as you might,
there is no integer that will, upon concatenation with a string,
produce a control character for HTML (i.e. `>`) or SQL (i.e. `'`).

Therefore, if the concern is Injection attacks, integer inputs do not
need to be tracked to provide a security gain.

This is only true for integers, not all numeric types. I haven't
investigated the safety of floats in every possible context, and the
`e`, `+`, and `.` characters could be problematic in corner cases.

TL;DR
- Why not is_noble()?
- String + int concatenation isn't an injection risk.

Cheers,
Scott

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

Re: [PHP-DEV] Introduce str_left/right In 8.1

[Guilliam Xavier]

On Wed, Jun 23, 2021 at 6:49 PM Sara Golemon  wrote:

> On Wed, Jun 23, 2021 at 9:15 AM Hamza Ahmad 
> wrote:
>
> >
> > Since feature freeze for 8.1 is approaching, I want to request two useful
> > string functions that exist in various languages-especially those that
> run
> > on web servers and used in databases. These are respectively `left();`
> and
> > `right();`
> >
> >
> Sorry, you spent several paragraphs insisting that these are
> common functions, but you didn't explain what they're meant to actually do.
>
> Using some context, I would assume you mean this:
>
> function str_left(string $str, int $len): string {
>   return substr($str, 0, $len);
> }
>
> function str_right(string $str, int $len): string {
>   return substr($str, -$len);
> }
>

I assume the same.


>
> If that's the case, then why?  As you can see, the existing
> functionality available is trivial to write.  You don't even need to know
> any particular amount of math (which I've been recently informed shouldn't
> be a prerequisite to writing software -- shakes fist at clouds).
>
> Am I misunderstanding what these proposed functions should do, or am I
> underestimating the difficulty of typing a zero or negative sign on certain
> keyboards?
>

I think that's more about "semantics" ("conveying intent to readers") than
typing...

That said, I tend to agree with George (but maybe I'm "too" used to seeing
substr()?)

Regards,

-- 
Guilliam Xavier

[PHP-DEV] Re: Requesting RFC karma

[Christoph M. Becker]

On 23.06.2021 at 17:56, Kim Hallberg wrote:

> With the initial attitude for the clamp proposal being mostly positive
> I am moving ahead with the RFC and am therefore requesting RFC karma
> to create this RFC.
>
> If anyone would like to grant me this karma my username for the wiki is: 
> thinkverse

RFC karma granted.  Best of luck! :)

Christoph

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

Re: [PHP-DEV] Introduce str_left/right In 8.1

[Sara Golemon]

On Wed, Jun 23, 2021 at 9:15 AM Hamza Ahmad 
wrote:

>
> Since feature freeze for 8.1 is approaching, I want to request two useful
> string functions that exist in various languages-especially those that run
> on web servers and used in databases. These are respectively `left();` and
> `right();`
>
>
Sorry, you spent several paragraphs insisting that these are
common functions, but you didn't explain what they're meant to actually do.

Using some context, I would assume you mean this:

function str_left(string $str, int $len): string {
  return substr($str, 0, $len);
}

function str_right(string $str, int $len): string {
  return substr($str, -$len);
}

If that's the case, then why?  As you can see, the existing
functionality available is trivial to write.  You don't even need to know
any particular amount of math (which I've been recently informed shouldn't
be a prerequisite to writing software -- shakes fist at clouds).

Am I misunderstanding what these proposed functions should do, or am I
underestimating the difficulty of typing a zero or negative sign on certain
keyboards?

-Sara

[PHP-DEV] Requesting RFC karma

[Kim Hallberg]

Hi internals,

With the initial attitude for the clamp proposal being mostly positive 
I am moving ahead with the RFC and am therefore requesting RFC karma 
to create this RFC.

If anyone would like to grant me this karma my username for the wiki is: 
thinkverse

Thank you,
Kim Hallberg.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [Vote] make Reflection*#setAccessible() no-op

[Marco Pivetta]

On Wed, Jun 23, 2021 at 5:49 PM Guilliam Xavier 
wrote:

>
> Meanwhile, if anybody knows why the RFC isn't listed on `/rfc`, lemme know
>> :D
>>
>
> You have to add it manually, cf https://wiki.php.net/rfc/howto 3.4
> (yeah...)
>

Excellent, thanks :-D

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] [Vote] make Reflection*#setAccessible() no-op

[Guilliam Xavier]

Meanwhile, if anybody knows why the RFC isn't listed on `/rfc`, lemme know
> :D
>

You have to add it manually, cf https://wiki.php.net/rfc/howto 3.4
(yeah...)

Cheers

-- 
Guilliam Xavier

[PHP-DEV] [Vote] make Reflection*#setAccessible() no-op

[Marco Pivetta]

Hey folks,

I'm opening the vote for making `Reflection*#setAccessible()`.


Voting starts today (2021-06-23) and ends in 14 days (2021-07-07).

Vote at https://wiki.php.net/rfc/make-reflection-setaccessible-no-op

Discussion: https://marc.info/?l=php-internals=162360269505048=2

Discussion^2: https://externals.io/message/114841

Meanwhile, if anybody knows why the RFC isn't listed on `/rfc`, lemme know
:D

Greets,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

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

[Craig Francis]

On Wed, 23 Jun 2021 at 14:37, Larry Garfield  wrote:

> I'm still very torn on is_literal; I fear that the people who would
> benefit from it are the very people that don't use the tools that would
> leverage it (DBALs et al), and so the net benefit will be small.
>


This RFC will not help those who aren’t using libraries (DBALs), that’s
something we could look at in the future (I have a suggestion in the Future
Scope section, but whatever that involves, it will need to use this flag,
so it would need to be in place first).

But - and why I’m here - my experience is that it’s still a big issue for
those who *do* use libraries. It frequently comes up at software
agencies/companies that maintain their code (built with free
libraries/frameworks), and employ junior developers (i.e. the cheapest),
who make many "quick edits" (time is money), and in doing so introduce the
issues the RFC covers (and not to say we more experienced coders don’t
occasionally make mistakes too!). While non-library users are the main
cause, the library users are still a big part of why Injection
Vulnerabilities remain at the top of the OWASP Top 10.

Craig

Re: [PHP-DEV] Introduce str_left/right In 8.1

[G. P. B.]

On Wed, 23 Jun 2021 at 15:15, Hamza Ahmad 
wrote:

> Hello Internals,
>
> Since feature freeze for 8.1 is approaching, I want to request two useful
> string functions that exist in various languages-especially those that run
> on web servers and used in databases. These are respectively `left();` and
> `right();`
>
> Whether it is VBScript or MySQL, these two functions are available there.
> When I learnt PHP more than half a decade ago, I wondered why PHP had no
> functions that provide the same functionality as these two languages
> provide.
>
> Although both of these functions can be created in the userland, I request
> to build them in core for the following reasons:
> 1. They are standard functions in various languages. This article
> <
> https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(string_f
> unctions)#left>, available on Wikipedia, compares various languages in
> regard to string functions and recognizes left and right functions as a
> general term to make sense of the attitude of these functions.
> 2. To achieve the effect of these functions, one needs to use `substr();`.
> If these functions are introduced, it will be clear on the readers' level
> the actual purpose of the use of that string function.
> 3. There may be libraries that provide with the similar functionality; why
> not add this popular function to the core and make it available for
> everyone
> to use? IT will not require people to include such heavy libraries to their
> projects for such little and useful functions.
> 4. In the recent versions, PHP did include "str_contains", "str_ends_with",
> "str_starts_with", "array_key_first", and "array_key_last" functions. All
> of
> these functions are buildable in the userland, yet they have managed to
> make
> place to the core because of their popularity. Why not these two functions?
>
> If one has issues with the name choice, this is something that can be
> discussed.
>
> This request also takes inspiration from Kim Hallberg's proposal for
> `clamp();` function. His email encouraged me to put my word on the table.
>
> I am positive that senior developers would provide me with the feedback on
> my suggestion. I am also positive that my request will be added to 8.1. I
> thank you all for reading through my message and dropping a word.
>
> Best Regards
>
> Hamza Ahmad
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Sorry, but I really don't see the point of these functions.
Most other programming languages, by the link you've provided don't have
such
a function and use either a function similar to substr() or offset ranges.

Contrasting this to the clamp() proposal which necessitates multiple
function calls
to achieve the same result which *could* mean a performance penalty if such
a
function is in a hot loop (e.g. Machine Learning).

To address point 4, yes these convenience functions have been added
recently,
but they are *extremely* common and their alternatives were rather confusing
or cumbersome. And even then there was resistance to add them.

All this to say that the burden of maintenance for such a specialized
function
makes it very unsuitable to be in core.

Best regards,

George P. Banyard

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

[Sara Golemon]

Resending this, because the mail daemon sent it back as spam, and we
shouldn't be running our own mail server any more than we should have been
running our own git server.
Seriously. What about this looks spammy, I ask you?

On Wed, Jun 23, 2021 at 9:36 AM Sara Golemon  wrote:

> On Mon, Jun 21, 2021 at 6:29 PM Craig Francis 
> wrote:
> > On Tue, 22 Jun 2021 at 12:18 am, Benjamin Morel <
> benjamin.mo...@gmail.com> 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 is going to be the same naming
> > >> mistake as "safe mode" was. Developers will put their trust in it
> that it
> > >> is 100% guaranteed safe.
> > >
> > >
> > > FWIW, agreed, too. Trusted is vague and may imply some false sense of
> > > security. Literal is literally what it says on the tin.
> > >
> >
>
> Yasuo's contrived "faking it" eval example aside, I 100% agree with
> Derick, Benjamin, Levi,
>  and everyone saying that `is_trusted` is quite possibly the worst name
> that could be
> chosen for this. ((Okay, they didn't say that, but I am))
>
> Why not call it `is_safe` and really embrace the bad idea that was
> safe_mode properly.
> No. Nope. Hard no.
>
> > I can follow up properly tomorrow, but by popular request we do support
> > integers as well (could be seen as stretching the definition of
> “literal” a
> > bit).
> >
>
> Is a hard coded integer not a literal value?
> Nothing about the name 'literal' speaks to type, only to provenance.
>
> > Then someone said they wanted to check if an integer was a literal too -
> > but because of technical limitations, it now allows any integer,
> > regardless of where it came from, to be treated as a literal.
> >
>
> Oh, I missed this.  Yeah. No.
> If the provenance of an integer is unknown then it is neither literal nor
> trusted.
> It's a grenade and precisely the kind of thing that breaks any attempt at
> safety.
> Why can this not be tracked?  Is there no space in the zval to track
> IS_LITERAL
> as a flag rather than (and I'm making guesses about the current
> implementation here)
> storing it off the zend_string?  As a zval flag, it becomes theoretically
> applicable
> to any type (though for obvious reasons resources and objects have a hard
> time
> demonstrating literality).
>
> > That said, I’m really glad that the only issue we seem to have is the
> name.
> >
>
> As I've said off-list more than once, I'm not a fan of this feature in
> general as
> it provides a false sense of security, so no... the name is not the only
> issue.
> Using a loaded word like 'trusted' just makes the false-security
> implication worse.
>
> Take all that as you will because I'm probably still -1 on the feature
> overall
> regardless of the name, so my opinion on the name probably doesn't matter
> in that respect, but for me at least, it turns my probable -1 into a
> definite -1.
>
> -Sara
>

[PHP-DEV] Introduce str_left/right In 8.1

[Hamza Ahmad]

Hello Internals,

Since feature freeze for 8.1 is approaching, I want to request two useful
string functions that exist in various languages-especially those that run
on web servers and used in databases. These are respectively `left();` and
`right();`

Whether it is VBScript or MySQL, these two functions are available there.
When I learnt PHP more than half a decade ago, I wondered why PHP had no
functions that provide the same functionality as these two languages
provide.

Although both of these functions can be created in the userland, I request
to build them in core for the following reasons:
1. They are standard functions in various languages. This article
, available on Wikipedia, compares various languages in
regard to string functions and recognizes left and right functions as a
general term to make sense of the attitude of these functions.
2. To achieve the effect of these functions, one needs to use `substr();`.
If these functions are introduced, it will be clear on the readers' level
the actual purpose of the use of that string function.
3. There may be libraries that provide with the similar functionality; why
not add this popular function to the core and make it available for everyone
to use? IT will not require people to include such heavy libraries to their
projects for such little and useful functions.
4. In the recent versions, PHP did include "str_contains", "str_ends_with",
"str_starts_with", "array_key_first", and "array_key_last" functions. All of
these functions are buildable in the userland, yet they have managed to make
place to the core because of their popularity. Why not these two functions?

If one has issues with the name choice, this is something that can be
discussed.

This request also takes inspiration from Kim Hallberg's proposal for
`clamp();` function. His email encouraged me to put my word on the table.

I am positive that senior developers would provide me with the feedback on
my suggestion. I am also positive that my request will be added to 8.1. I
thank you all for reading through my message and dropping a word.

Best Regards

Hamza Ahmad

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

Re: [PHP-DEV] [Vote] Partial Function Application

[Peter Bowyer]

On Wed, 16 Jun 2021 at 17:17, Larry Garfield  wrote:

> Hi folks.  The vote for the Partial Function Application RFC is now open,
> and will run until 30 June.
>
> https://wiki.php.net/rfc/partial_function_application
>

I like. People have either experienced the need for this or they haven't.
Ask me a month ago and I would have said "pfft, waste of time and language
bloat" but I changed my mind recently after running into issues in
JavaScript and discovering I needed partial function application to fix it
cleanly (vs a mess of mixed function calls and closure-wrapped function
calls).

I am a little ambivalent as I do feel the RFC's complexity has grown - I
would be happy without the variadic placeholder being included if it's a
choice between no partial function application or placeholders only. But if
I don't want to use variadic placeholders, hey I can omit them from my code.

Peter

[PHP-DEV] Re: Proposal: clamp

[Kim Hallberg]

> On 23 Jun 2021, at 2:25 AM, Kim Hallberg  wrote:
> 
> Greetings internals,
> 
> I present to you a proposal for a new basic math function: clamp.
> 
> function clamp(int|float $num, int|float $min, int|float $max): int|float {}

Instead of answering each response individually I’ll post a reply here instead.

Since the majority seems to have a pretty positive position on this proposal.
I am moving ahead with an RFC for this, and am now requesting RFC karma.

If anyone would like to grant me the privilege to create this RFC you can grant 
me karma for the username: thinkverse on the wiki. A pull request into source 
will be submitted right after RFC has been written.

Thank you,
Kim.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Craig Francis]

On Wed, 23 Jun 2021 at 11:27 am, Guilliam Xavier 
wrote:

> Alternatively, if integers are too controversial, how about reverting the
> implementation to `is_literal()`
>


Starting to look like that, yeah.

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

[Larry Garfield]

On Wed, Jun 23, 2021, at 8:05 AM, Hossein Baghayi wrote:
> Hello,
> What about `is_vulnerable`? Its behaviour would be the inverse of
> is_literal.
> I mean we don't have to avoid the other side of the coin.

That has the same core problem as is_trusted.  It's making a claim about the 
probable security status of a value, which I promise you, you will not get 
right 100% of the time.  is_literal, is asserting only that the value came from 
the source code originally, not from user input.  That is something you can 
assert one way or another and be guaranteed correct.  What the *implications* 
are for what you can then do with it are an entirely separate, and highly 
squishy and use-case-specific, question.

I'm still very torn on is_literal; I fear that the people who would benefit 
from it are the very people that don't use the tools that would leverage it 
(DBALs et al), and so the net benefit will be small, but misuse of it will make 
DBALs weaker and less able to handle the highly-dynamic cases that I am used to 
working with.  I may be convinced of is_literal if the major DBAL authors back 
it, but I'm still not sure.

I am definitely -1 on is_trusted or any other claim of fit-for-purpose, rather 
than a claim of origin.  That's guaranteed to be incorrect often enough that it 
makes things worse rather than better.

--Larry Garfield

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

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

[Hossein Baghayi]

Hello,
What about `is_vulnerable`? Its behaviour would be the inverse of
is_literal.
I mean we don't have to avoid the other side of the coin.

On Tue, 22 Jun 2021 at 22:41, 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
> at. Particularly if you are one of those unsure about it, read on.
>
>
>
> The name `is_trusted()` was chosen by a community vote over several days.
> While I’m of a similar opinion that "trusted" might be misleading for some
> in the strength of its word, I do not want to simply override 18 of the 21
> people, who I assume read the RFC, asked questions to clarify on the
> mailing list, understood how it works, and have chosen that name.
>
> However, clearly some people missed the vote and its discussion time, and
> some voted but then perhaps wanted clarifying on what the RFC was fully
> about later. If we say that's about five people, then assuming there is a
> larger audience who reads but does not post (as the voting numbers
> indicated) then I'm inclined to guesstimate that maybe that means 3x the
> number of people share those feelings. And with that number it starts to
> feel like maybe we should double-check here.
>
> While a one-word name is always going to be misunderstood by some people,
> we want to be as clear as possible.
>
> The Function:
> - Is a security-based function that prevents Injection Vulnerabilities in
> PHP.
> - Flags strings written by the developer, including when concatenated.
> - Also accepts integer values, which as purely numerical cannot contain
> code/dangerous characters. (Due to technical limitations within PHP, it's
> not possible for these to be flagged as user or developer in the codebase
> itself without performance issues).
>
> (RFC for full breakdown: https://wiki.php.net/rfc/is_literal)
>
> Ideally we want a one-word name that suggests this as best we can - one
> word to be consistent with other `is_*()` functions.
>
> - `is_literal()` was my original placeholder name. However, given that it's
> not just literal strings, but also supports concatenation and integers I
> felt it may be misleading with the definition of 'literal' stretched so far
> it might get confusing, and is why I didn't include my original name for it
> in the poll. However, if you feel it would be more accurate my mind isn't
> fixed on it.
>
> - `is_known()` - suggested by Joe, who created the implementation, was one
> of two options in the original vote, and was based on the principle that
> the value be 'known' to the developer to be free from external code and be
> within a 'known' understanding of the values that should be going in it.
>
> - `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.
>
> I suggest that people who are serious in their feelings about this, offer
> the name that they would prefer (including potentially making one
> themselves that fits the RFC content and style mentioned above) so we can
> assess whether the current name needs a second look.
>
> Thanks,
> Craig
>

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

[Rowan Tommins]

On 22 June 2021 10:09:50 BST, Mike Schinkel  wrote:
>For my inspiration take a look at Trusted Types API in Javascript:
>
>https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API
>


There is an extremely important difference here: there is no single type in 
that system called "TrustedString", there are separate types for each context 
("injection sink"). The W3C article calls this out explicitly:

> Note: This allows the authors to specify the intention when creating a given 
> value, and the user agents to introduce checks based on the type of such 
> value to preserve the authors' intent. For example, if authors intend a value 
> to be used as an HTML snippet, an attempt to load a script from that value 
> would fail.

This is not just an implementation detail, it's an absolutely essential part of 
the concept.



So let me add my name to the chorus saying that is_trusted() is a bad name, and 
the added features that led to its selection make this feature worse not better.



Most of a "trusted types" implementation can be written in pure PHP, because 
all you need is an object with a private string property and some appropriate 
constructors. 

The one part you can't do is trust strings provided in source differently from 
strings provided by the user, and the original proposal provided a 
straightforward mechanism for that purpose.

There is no reason why is_literal itself needs to know about "trusted value 
objects", or have a long list of special cases to construct a string that is 
"not actually a literal but we can't think of any way to exploit it". That can 
all be handled by the userland code:

* Create a class called TrustedSql
* Accept a parameter of type string|TrustedSql. If the parameter is a string, 
reject it if is_literal returns false
* Or, if a pseudo-type is provided as well, just accept 
literal_string|TrustedSql
* If the user wants to provide dynamic SQL, they need to construct a TrustedSql 
object using whatever mechanism the library wants to provide. That can include 
an audited sprintf pattern, imploding arrays of integers, whatever turns out to 
be useful.


I think the engine should leave the complexities of defining "trusted" to APIs 
specialising in a particular "injection sink", and provide the low-level 
building block they need, which is the original simple is_literal function.


Regards,

-- 
Rowan Tommins
[IMSoP]

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

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

[Guilliam Xavier]

On Tue, Jun 22, 2021 at 8:11 PM Craig Francis 
wrote:

>
> The Function:
> - Is a security-based function that prevents Injection Vulnerabilities in
> PHP.
> - Flags strings written by the developer, including when concatenated.
> - Also accepts integer values, which as purely numerical cannot contain
> code/dangerous characters. (Due to technical limitations within PHP, it's
> not possible for these to be flagged as user or developer in the codebase
> itself without performance issues).
>

- `is_safe_from_injections()`?
- `is_secure_against_injections()`?
- `can_be_trusted_to_not_contain_injection_vulnerabilities()`? (okay not
this one)

Alternatively, if integers are too controversial, how about reverting the
implementation to `is_literal()` but provide a function like
`to_literal(int $int): string` (or just a "polyfill" for userland, could be
a one-liner `implode(array_map(fn ($c) =>
['0','1','2','3','4','5','6','7','8','9','-'=>'-'][$c],
str_split((string)$int)))`), so that those `implode(',', [1,2,3])` could
use `implode(',', array_map('to_literal', [1,2,3]))`?

Regards,

-- 
Guilliam Xavier

Re: [PHP-DEV] Proposal: clamp

[Ayesh Karunaratne]

> 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 returned.
>
> Now, does this need an RFC? The behaviour can be implemented in userland
> in a number of ways, one of which is to compare the values in a if statement.
> Another is to use the min and max math functions.
>
> max($min, min($max, $num));
>
> I don’t have any schpeel as to why this should be in core, only that I 
> thought it already was.
> Considering it is part of other languages standard math library, and it is a 
> useful function.
>
> Can see this being useful in image manipulation, server-side rendering and 
> math just to name few.
>
> The proposed signature follows the convention of other math related functions.
>
> function clamp(int|float $num, int|float $min, int|float $max): int|float {}
>
> This function is very easy to implement, has no side effects or backward
> compatibility issues, unless a userland implementation already has the 
> function declared,
> in which case PHP will throw a fatal error since the function cannot be 
> redeclared.
>
> I've implemented this feature a few months ago already.
> - Link: https://github.com/thinkverse/php-src/pull/1 
> 
>
> What are your opinions on this function?
>
> Regards,
> Kim Hallberg.


 +1 from me as well.

We recently added `str_contains`/`starts_with`/`ends_with`, which were
welcome additions. I think `clamp` would be a nice addition too.

I found three user-land `clamp` function declarations on a search on
GitHub public repos.

 - 
[doubleleft/hook](https://github.com/doubleleft/hook/blob/master/src/bootstrap/helpers.php#L129)
- 764 stars, Last activity in 2016.
 - 
[GetSimpleCMS/GetSimpleCMS](https://github.com/GetSimpleCMS/GetSimpleCMS/blob/master/admin/inc/basic.php#L2489)
- 336 stars, Has recent activity.
 - 
[shish/shimmie2](https://github.com/shish/shimmie2/blob/master/core/polyfills.php#L477)
- 267 stars, Has recent activity.

I think it's safe to say that these libraries will be updated to
accommodate the `clamp` function in PHP core; I'd even happily send
pull requests to them. `doubleleft/hook` probably wouldn't be updated
because it doesn't show recent activity, but that's an acceptable BC
impact for a nice addition IMO.

Thank you,

---
Ayesh.

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

Re: [PHP-DEV] Proposal: clamp

[Ilija Tovilo]

Hi Kim

> I present to you a proposal for a new basic math function: clamp.
> ...
> What are your opinions on this function?

I for one think this is a good candidate for PHPs standard library.
It's simple, unopinionated and standardized in other languages. Even
though it's simple to implement in userland (as many other internal
functions would be) there's no good reason to require users to
implement it themselves or require a package for simple functions.

+1 from me.

Ilija

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

Re: [PHP-DEV] Proposal: clamp

[Pierre]

Le 23/06/2021 à 10:28, Lynn a écrit :

On Wed, Jun 23, 2021 at 3:07 AM Marco Pivetta  wrote:


The problem is exactly the fact that it is trivial to implement in
userland: why not do it there instead?


My 2cents: because people won't use it when the barrier is too high to get
it. There are a ton of great libraries that have functionality like clamp,
and some more elaborate, like an array replacement. In the end -based on my
experience- people go to the php documentation and look for functions that
they can use, or they use their IDE autocomplete functionality to see
what's hinted at. Having these functions spread through the ecosystem means
discoverability is low. I've needed the "clamp" function in the past and
didn't even consider looking for a library to do this for me. Why would I
even install a library to have a single function anyway? It feels like a
massive overhead. I've seen coworkers use funky SPL functionality I didn't
even know existed to avoid using external dependencies that have already
solved their problem in a neat way, which were in fact already installed
through composer. They found the solution through google and ended up in
the official php documentation.

I'd love to see these small additions in the core, they make the language
feel more complete. The fact that they are easy to implement in userland
means that we can have great forward compatibility through polyfills and
already start using them in codebases that haven't been upgraded yet to the
latest PHP version. I've been very happy to have been able to use
str_starts_with, str_ends_with, and str_contains in 7.3, as they came in
with a generic php polyfill.

With a "see also: clamp" in the min/max function documentation, this would
be easy to find as well.

+1 for this, I often use the min/max pattern to achieve the same result, 
having a single method would be much more readable.


Regards,

--

Pierre

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

Re: [PHP-DEV] Proposal: clamp

[Lynn]

On Wed, Jun 23, 2021 at 3:07 AM Marco Pivetta  wrote:

> The problem is exactly the fact that it is trivial to implement in
> userland: why not do it there instead?
>

My 2cents: because people won't use it when the barrier is too high to get
it. There are a ton of great libraries that have functionality like clamp,
and some more elaborate, like an array replacement. In the end -based on my
experience- people go to the php documentation and look for functions that
they can use, or they use their IDE autocomplete functionality to see
what's hinted at. Having these functions spread through the ecosystem means
discoverability is low. I've needed the "clamp" function in the past and
didn't even consider looking for a library to do this for me. Why would I
even install a library to have a single function anyway? It feels like a
massive overhead. I've seen coworkers use funky SPL functionality I didn't
even know existed to avoid using external dependencies that have already
solved their problem in a neat way, which were in fact already installed
through composer. They found the solution through google and ended up in
the official php documentation.

I'd love to see these small additions in the core, they make the language
feel more complete. The fact that they are easy to implement in userland
means that we can have great forward compatibility through polyfills and
already start using them in codebases that haven't been upgraded yet to the
latest PHP version. I've been very happy to have been able to use
str_starts_with, str_ends_with, and str_contains in 7.3, as they came in
with a generic php polyfill.

With a "see also: clamp" in the min/max function documentation, this would
be easy to find as well.

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

[Pierre Joye]

Hello Craig,

Very well written RFC, good job!

Others have said it already, but here are my thoughts. Many moons ago,
I was on this way as well and the filter extension came out. As it
fits for some projects, the actual gains were very far, to say the
least, from what I would have expected.

Since quite some time, and that thinking is intensified with the
support of native annotation, is that such a thing does not fit into
the core language(s). It will never be "trustable" 100%, which defeats
its main purpose or existance.

The large majority of apps or frameworks out there provide their own
interface to deal with external data input. Advanced ones like Symfony
can provide you an Entity where a parameter is the ID of that entity,
handling all safety checks. Others will provide a Request
implementation with getters as specific types, etc. This allows it to
be tightly linked to the actual usage or logic. It is impossible to
even agree on such an interface in the core.

As well intended as it looks, I think input data filtering is better
implemented in userland. And we may keep ourselves from reintroducing
trusted or safe mode, no matter where. I hope I don't sound too
negative, I am really convinced this is a bad idea and introducing it
again in 8.x will hunt the core for a decade to  come. :)

Best,

On Tue, Jun 22, 2021 at 3:25 AM Craig Francis  wrote:
>
> On Sat, 12 Jun 2021 at 18:00, Craig Francis 
> wrote:
>
> > I'd like to start the discussion on the is_literal() RFC:
> > https://wiki.php.net/rfc/is_literal
> >
>
>
> To recap,
>
> - We have chosen the name is_trusted(), based 18 votes for, vs 3 against.
>
> - Integers are now included, which will help adoption:
>
> https://wiki.php.net/rfc/is_literal
>
> (Joe’s currently updating the implementation to have the new name, but all
> the functionality is there).
>
> I’m glad this RFC has been well received; and thank you for all the
> feedback, I really think it‘s benefitting the implementation.
>
> Craig



-- 
Pierre

@pierrejoye | http://www.libgd.org

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