141–150 of 155 posts
Earlier quoted context omitted.
But we don't want the string escaped. We want it interpreted.
yes, basically eval is evil
[0] it also supports mapping and sequence lookups IIRC but that's about the same thing
This sidesteps the problem because only literal strings are formatted.
Earlier quoted context omitted.
Why would a template engine allow for free access to the native platforms string capabilities in the first place?
Native vs. non-native is irrelevant. A non-native formatting system could have the features of the python formatter that are dangerous. Or, if Python's native formatter lacked these dangerous features, there'd be no reason not to use it.
Hardly irrelevant. The idea is that a non-native formatting system is build specifically for the templating engine, and so the developers controls what it can do and gives it non-dangerous features.
>Or, if Python's native formatter lacked these dangerous features, there'd be no reason not to use it
Even if it did lack them, it's not under the control of the template platform author, so they should not rely on it for such a crucial part of the template engine as string formatting.
(Which is exactly the case here: Python lacked those features before, but got them, and bit the template engine in the back).
Earlier quoted context omitted.
Shouldn't that be based not on the built-in string capabilities, but on a template engine, that must also take care for much more narrow cases of abuse (e.g. SQL injection, or access to only of a restricted number of helper functions within the template)?
What does the template engine have to do with SQL? Not really following you there.
Here they talk of using it for translation, with arbitrary user provided strings for example. Another could use it to create an SQL helper (accounting themselves for injection) etc.
In any case, it should not contain dangerous helper methods of capabilities not fit for strictly templating, just because the native string class allows them.
Earlier quoted context omitted.
I'd love to hear your perspectives on Ruby if this bothers you that much.
What does Ruby have to do with any of this?
Earlier quoted context omitted.
What does Ruby have to do with any of this?
Like PHP and JS's template literals, it has full on string interpolation.
Earlier quoted context omitted.
The reasoning why printf strings in C are unsafe is not applicable in python though. You cannot access memory directly, and %n doesn't exist (nor other other fun POSIX requirements that write to random places on the stack). In fact, Python's C-style formatting strings are immune to this problem (even the extended form that allows you to name arguments).
That's pointless nitpicking. The point is that user specified format strings allow the user to access things they shouldn't be able to access. It's the same in every language that has format strings.
It's not nitpicking. Go's format strings don't allow you to access stuff you shouldn't be able to. In fact, Go's templating language[1] doesn't allow you to access anything that you haven't explicitly provided to the template instance.
Allowing users to format text is not an impossible problem. It's the fault of language creators that they don't make this easier.
Earlier quoted context omitted.
Native vs. non-native is irrelevant. A non-native formatting system could have the features of the python formatter that are dangerous. Or, if Python's native formatter lacked these dangerous features, there'd be no reason not to use it.
> Native vs. non-native is irrelevant. A non-native formatting system could have the features of the python formatter that are dangerous. Hardly irrelevant. The idea is that a non-native formatting system is build specifically for the templating engine, and so the developers controls what it can do and gives it non-dangerous features. > Or, if Python's native formatter lacked these dangerous features, there'd be no r…
This doesn't really matter. If it does what you want, it's not like they're going to change the formatter's behavior from under your feet if it's part of the language's default runtime.
Earlier quoted context omitted.
Which immediately becomes a security risk because classes can overload __getattr__ and __getitem__. So now you're executing random code. Of course, %s does the same thing (__str__) but at least %s doesn't take any arguments.
The assumption behind string.format and friends is that people who override __getattr__ and __getitem__ know what they're doing. Which is probably a reasonably safe tradeoff in order to allow attribute access. I'm not worried about executing arbitrary code, because it's not user-supplied and it's normal for a templating library to access attributes of objects you pass to it (if it was unsafe you shouldn't have done t…