On Mon, 12 Jul 2021 at 14:17, Dan Ackroyd <dan...@basereality.com> wrote:
> On Mon, 12 Jul 2021 at 02:09, Craig Francis <cr...@craigfrancis.co.uk> > wrote: > > > > you can choose not to use string concatenation ... allowing anyone to > customise it to their needs > > Please can you explain how: > > i) An individual programmer can enforce that they don't accidentally > use string concatenation for stuff that is used in a security > sensitive context. > i) Usually if developers want to add specific restrictions for themselves or their team that the vast majority of a userbase would not need or use, they would use a separate tool that fills that niche to enforce their chosen coding style (like how they might want to enforce "tabs vs spaces" in their own codebase). > ii) A team of 50 programmers can enforce that they don't accidentally > use string concatenation for stuff that is used in a security > sensitive context. > ii) Same answer as i) as it scales. iii) A library can enforce that string concatenation isn't used in the > params passed to it. > iii) A library shouldn't care if the developer used concatenation, it should only care if user data has been included incorrectly (i.e. checking for an Injection Vulnerability). A library’s purpose is to ensure whether code is safe or not, not about enforcing personal coding styles. > and doesn’t improve security in any way, > > It [disallowing concatenation] prevents issues from being able to make it > through to production. > But the main reason would be to reduce the cost of using this feature > long-term. > Disallowing concatenation doesn’t guarantee that issues can’t get through to production though; for example, something that can sometimes be a non-literal, but during development defaults to a literal. >From a security point of view, it doesn’t matter whether the error is caught at the point of concatenation, or when it’s checked as the library receives it, because the injection vulnerability gets caught either way. I take it the "cost" that you’re referring to is just the debugging time? Ultimately any extra debug time that might occur, is magnitudes less than the time it would take almost every developer to check and rewrite most of the projects that exist today, which is what the idea of not supporting concatenation requires. For a developer who really finds debugging too onerous, there are other ways of debugging - using tools better suited for it such as XDebug or Static Analysis tools like Psalm (and as above, if you were wanting to force yourself/your team to not concatenate, you would be using a Static Analysis tool already (i/ii)). > you can choose not to use string concatenation (I haven't needed to). > > Wait....what? > > Is your position both that preserving literal-ness across string > concatenation is required, otherwise this feature is too hard to use, > and at the same time, you've not needed that in your own applications. > > Is that right? Because if preserving literal-ness across strings > wasn't required for you...why would it be required for every other > project? > > And to be clear, I don't think it's required. > We are trying to improve the language for the majority of developers. I’m an experienced PHP developer who is genuinely passionate about security. I find it fun, curating my code to be as secure as possible is practically a hobby. That makes me an Outlier. Like a lot of us here. My focus is on writing an RFC that works for as many developers as possible, so whether it’s ‘necessary’ in my own personal projects is irrelevant to whether a simple safety feature should exist for the community. We need to make things easy and safe for the people who are /not/ just high-level programmers, but for people who don’t know everything we do and need things to be simple and functional as possible. My projects do use a lot of string concatenation. Not an erroneously high amount, probably about normal. So let’s say we do break string concatenation: For some numbers, I've found roughly 1,300 instances of SQL and HTML concatenation in my projects. And even if I would be willing to go through such a big task to replace them, the real problem is actually finding them, because if you’re trying to use a search, well, who would have thought looking for "." would return so many results? > I think by listening to feedback from people who aren't sure it's a > good idea, who said "this is a good idea but only if it's really easy > to start using it" that this RFC has been watered down from the most > useful proposal. At the core, there is a good idea behind this RFC, > but the set of trade-offs chosen just aren't the right ones, and > aren't the "proven" trade-offs made at Google. > The proposal hasn’t changed. This is keeping to the original concept, and while you wanted to remove string concatenation support, that does not mean that anything so strict was our intention. The proposal was always meant for the greatest and easiest adoption possible, but that was your creative difference with us, which is fine, but doesn’t mean that this isn’t exactly as originally intended. The only real change to `is_literal()` that has been made since the start of this RFC is improvements to the compilation process. Otherwise it is the same as day one. If it will put your mind at ease, Krzysztof Kotowicz is probably the best placed person to provide feedback, as he is the implementor of this same principle in JavaScript. And he provided feedback to this project, saying that they trust concatenated constants, and that yes, while a programmer could go out of their way to do something *intentionally* dangerous (like building up an array of single character literals, and joining them together based on user input), the “go-safe-html” library authors decided that "the ergonomics of trusting concatenated constants far outweighs the security concern". Craig
