On Tue, 22 Jun 2021 at 3:05 pm, Stephen Reay <php-li...@koalephant.com> wrote:
> > On 22 Jun 2021, at 20:13, Craig Francis <cr...@craigfrancis.co.uk> wrote: > > On Tue, 22 Jun 2021 at 09:59, Stephen Reay <php-li...@koalephant.com> > 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 makes sense too. >> > > > > The primary reason was never just to define literal strings, the intention > has always been to create a practical, implementable solution to address > the issue of Injection Vulnerabilities (SQl/HTML/CLI/etc). > > > Preventing injection vulnerabilities may be your *goal* but I’m talking > about the *intended behaviour of this one function*. > I understand this is not the one true perfect solution, but that solution does not exist without tanking performance and never being accepted solely on that basis alone. 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 refine this. The only thing that you could suggest as an alternative is to not include integers at all. That is not realistic for the reasons I’ve stated not just here, but in replies to others, and the RFC itself. So if we can’t do that, and we can’t mark developer-integers for reasons mentioned before, what else is there? That we just don’t do it?? Torpedoing the idea because it is not 100% idealistically perfect, and ignoring the fact that it, (as it stands right now with integers and all), **Prevents Injection Vulnerabilities** - the most common security vulnerability that dominates the top of the leaderboards again and again - and does that without adding in any new security vulnerabilities, is just nonsensical. Craig
