Hacker News Reader

Comment by noobermin | Hacker News Reader

For 1, it might be a matter of taste/familiarity. For me, interpolation in Julia makes string formatting easier to understand, at least for short strings. The issue is Julia's interpolation (I hope to god to be wrong about this, if it's wrong, someone correct me) doesn't have format specifiers, which put me in a pickle a few days ago.

For 2, can you expand upon this? Not a challenge, but I'm not able to imagine how this would be a security concern, and this might be a failure of my understanding here.

View on HN

>can you expand upon this..

It is more of a matter of breaking a general principle, which is don't mix executable stuff (expressions) with non-executable stuff (strings) implicitly. This has been a frequent cause of various security issues in the past eg: Sql injection, xss, various remote code execution vulnerabilities.

Strings should be dumb and without any ambiguity. On top of breaking this general principle of not mixing data and code, this pep also want to introduce numerous rules regarding various edge cases, which further makes it harder to reason about it, which increases the chances of slipping a vulnerability. For example, right now, you see a long string, you only need to look at the argument list to see what possible things it can do. Because the string itself is dumb, it cannot lie, and whatever execution that is required to produce that string, happens in the context of code itself. With this pep, this changes. Now a string is not dumb. It is smart. It can do 'stuff' on its own. It can 'hide' things, it can lie and masquerade as something innocent. I think this is bad.

Take an example of PHP. You can embedd php code in what ever content. In fact you can embedd php code in a valid image file in the metadata fields, and pass it as an Image. if you can call the image file as a script, then the embedded php code will execute to do your bidding. This has to be one of the most commonly used technique to hack sites running php. Here is one from last day [1].

Those are some of my reasons for the concerns..I know I am not still giving anything specific. But if we could easily think specific cases about how something could be exploited, we wouldn't be implementing that in the first place. So sometimes we must rely on general principles learned from the past while assessing the issues associated with something. Hence my concerns.

[1] https://www.reddit.com/r/PHP/comments/3gq3mh/my_site_was_hac...

So I wondered about this, but from what I understand (correct me if I'm wrong), the string must explicitly be "f", and thus, a generic string, specifically one created by taking data from input, isn't vulnerable in this way. You could, of course, act on user input inside an f string, but the fault of that lies with the developer not sanitizing inputs, which is an issue with anything.

You do have a good argument concerning not mixing of data and execution as a general principle, though, and I think may be you gave the PHP example as how this mixing can lead to certain unintended issues (not necessarily in python with this PEP implemented, if so, I apologize for misunderstanding). In my mind, this helps with short strings, with simple expressions and makes them more readable--in my opinion, as I said...it's just a convenience. Still, allowing a simple expression allows anything really to be executed, so I guess you have an argument there.

> You could, of course, act on user input inside an f string, but the fault of that lies with the developer not sanitizing inputs, which is an issue with anything....

A good language protects the experienced developers from making a stupid mistake, and forbids the novices from them to trigger a learning response and guide them to better ways.

Example: In python if you use a normal map to implement an algorithm that depends on the elements being ordered in some way, then you will get different results for each run. If I remember correctly, I think python will randomize the order of the map every time it is iterated over. You see, developers could have got away with blaming the user for using an ordinary map when they should have used ordered map. But instead, they implementation map in such a way that it would be impossible to use it incorrectly.

> I think may be you gave the PHP example as how this mixing can lead to certain unintended issues (not necessarily in python with this PEP..

Yes. correct.

>it's just a convenience..

I come from a land filled with such 'conveniences'. it is called PHP. You can compare

    var_dump("228" == "0xe4");  -> True

See? a convenience. You can compare hex and decimal strings with out explicit conversion. And what is the result? Countless exploits and security holes that leverage things like these, all that can be possible blamed on the programmer. So was this worth it? Where would you draw the line? How much correctness are you willing to trade off for a minor convenience?

I may be over-reacting. But I think this pep is a step in the wrong direction and should be aggressively corrected.

> If I remember correctly, I think python will randomize the order of the map every time it is iterated over.

No, a normal non-ordered dict in python is guaranteed to have the same iteration order as long as no keys are removed or inserted (i.e., if the only changes are changing the values associated with keys.)

Ah yes. You are right.

Reply on news.ycombinator.com