LWN: Comments on "A literal string type for Python"

A literal string type for Python

craig.francis — Wed, 09 Nov 2022 17:00:29 +0000

Hi nye, bit weird to see you mention the PHP RFC for is_literal(), I'm the author :-)

I completely agree with everything you said - taint checking is flawed, concatenation is fine, and the extra functions PEP 675 include make me feel a bit uncomfortable as well (but, to be fair, I cannot think of a vulnerability from them, I just can't say with 100% confidence they will be fine for every single context).

Anyway... I'm just looking at how the Python implementation works, now 3.11 is out, because I need to go back to the PHP Internals Developers to try again.

As I'm not a Python developer, do you think the following is a good example of this feature being used:

https://github.com/craigfrancis/php-is-literal-rfc/blob/m...

https://eiv.dev/python-pyre/

---

As to reasons for the PHP RFC rejection... it was not clear, most people who voted against did not comment (bit weird, considering RFC stands for "Request for Comments"), two people didn't want it to support string concatenation (they believe it would help find issues, but I've found that hasn't been the case; instead it does make adoption much easier due to the amount of existing code that uses concatenation), three people believe these checks should only be done by Static Analysis (the most optimistic stat I can find is 33% of PHP developers use Static Analysis[0], which I support, and can now be done with the `literal-string` type in Psalm and PHPStan, but I don't believe it will ever get to 100%), one person believed this should be solved though better documentation... and someone thought the idea was flawed, because a *malicious* developer could write the user-value into a new PHP file (e.g. `<?php return "$user_value"; ?>`), and execute it.

[0] https://www.jetbrains.com/lp/devecosystem-2021/php/

A literal string type for Python

nye — Tue, 26 Apr 2022 15:25:02 +0000

The problem with taint checking is that experience has shown that - even if it's always correct, which it often isn't - it leads a surprising number of programmers to assume that because the evil bit isn't set, then it must therefore be good. In other words, taint checking separates data into "definitely unsafe" and "might be safe assuming you're using it correctly, whatever that might mean", whereas many developers treat is as meaning "maybe unsafe" versus "definitely safe".

By restricting the feature to simply "is this a literal string, or derived from literal strings purely by means of concatenation"[0], the meaning is well-defined and easier to understand. In other words, it depends less upon programmer education, which is a strategy that has been repeatedly proven ineffective.

There is some discussion about this in https://wiki.php.net/rfc/is_literal if you're interested - that's the proposal for a very similar feature in PHP, which sadly did not pass for reasons I've not yet investigated.

[0] This PEP is a bit broader than that and does include some operations that create substrings, which makes me uncomfortable.

A literal string type for Python

farnz — Mon, 25 Apr 2022 07:50:51 +0000

To a large extent, though, these sound like the same problem as unsafe in Rust; sure, I can wrap all sorts of crawling horrors in unsafe, and have a Safe Rust API on top so that when you look at my crate's documentation, it's not obvious that I've done this.

And similar to Unsafe Rust, the answer is tool-assisted review of code you're planning to use that highlights the areas of code that need extra attention - just as a Rust-aware review system calls out unsafe wherever it appears for extra human attention, so a Python-aware review system needs to call out manipulation of LiteralString that results in a LiteralString typed output for extra human attention.

A literal string type for Python

tialaramex — Sun, 24 Apr 2022 13:39:43 +0000

I guess my problem is that I'm less confident the problematic case is "implausible".

If I'm correct the proof of course would likely arrive too late. ie, this PEP succeeds, everybody gets used to the behaviour as documented, and then a hole is found in some code, say, a popular Django app, where users can manipulate a LiteralString so as to cause mischief. I'm certain that the instinct will be to blame the app programmer, but of course that's missing the whole point of these protections, programmers are human and as such lack foresight.

To be quite fair, the other way forward can also be dangerous. In C++ for example std::format() resolutely insists on a constant format string, so that's pretty safe (it needn't be a literal, but it can't be sensitive to user input as that's not constant), but it necessitates providing std::vformat() which does not take a constant format string, and so programmers may be tempted to call std::vformat() rather than re-factor some code to ensure the format strings are actually constant... Defensive programming is possible, maybe even encouraged, but it's probably easier to do the Wrong Thing™ in many cases than it should be.

A literal string type for Python

gbleaney — Tue, 19 Apr 2022 15:23:25 +0000

PEP author here. Appendix B provides a trivial function for turning any regular external string into a 'LiteralString':
https://peps.python.org/pep-0675/#appendix-b-limitations

If a developer want to circumvent the protections of 'LiteralString', they can easily do it. They don't even need fancy functions like the example we gave, they can just add a '# pyre-ignore' (or equivalent lint suppression comment for their typechecker of choice). The goal is to protect against accidental mistakes, not malicious or implausible behaviour by developers.

A literal string type for Python

mathstuf — Tue, 19 Apr 2022 11:06:38 +0000

> you *can't* write s[:7] or something like that

If there were LiteralNumber, one might be able to do that, but without, there's no difference between a literal 7 and a 7 coming in from "the outside" through a variable. Though there are a number of other methods that take SupportsIndex that might now be suspicious to me…

A literal string type for Python

NYKevin — Tue, 19 Apr 2022 04:58:58 +0000

Looking through Appendix C of the PEP (which lists the operations supported), I see removeprefix/removesuffix, but not slicing (__getitem__), so you would have to write something like s.removeprefix("DO NOT ") to get the outcome which you describe (i.e. you *can't* write s[:7] or something like that). If you explicitly write removeprefix("DO NOT "), then IMHO it's your own damn fault for removing a prefix which you apparently wanted to keep.

A literal string type for Python

felix.s — Sun, 17 Apr 2022 11:30:59 +0000

There is already a PEP for that, PEP 501. It was (as I recall) drafted in parallel with PEP 498, but the former was deferred because the Python developers wanted to get ‘further experience’ with naïve interpolation, as if they failed to understand that this will just incentivise developers to introduce bugs into their code by reaching for the injection-prone naïve f-strings instead, the very thing they are trying to paper over here. Or perhaps, if we take the deferral rationale seriously, they deliberately aimed for the PHP approach, where they first introduce a simplistic, half-baked design into the language, only to have to resort to painful after-the-fact fixes over the following years.

Meanwhile, JavaScript has had an equivalent to PEP 501 (tagged template strings) from the very start, added at the same time as naïve interpolation. I still find it hardly ideal (it's a bit too easy to simply forget the tag), and say what you want about the TC39, but at least they seem to understand developer incentives well. At this point, and I can’t believe I am saying this, I am starting to see JavaScript as a better Python than Python.

A literal string type for Python

tialaramex — Sat, 16 Apr 2022 21:28:07 +0000

And that's why I have a problem with:

doComplicatedStuffBasedOnUserInput("DO NOT EAT BABIES", input)

"DO NOT EAT BABIES" is blessed as a LiteralString because it is. No problem so far. But "cleverly" this proposal allows operations (such as truncation, concatenation, duplication and splitting) on LiteralString to produce a LiteralString, and so if doComplicatedStuffBasedOnUserInput has a bug, as it may well do, it can end up producing quite unexpected results, such as "EAT BABIES" and yet they're blessed as LiteralString anyway via this rationale.

Thus, the program user in fact gets arbitrary control over these strings in at least some cases, whereas that's definitively not the situation in languages where there's an actual literal string type. In exchange, Python gets to write "WO" + "RDS" and have that be a LiteralString whereas in the other languages it is not. I think that's a bad trade, despite being very clever.

A literal string type for Python

mb — Sat, 16 Apr 2022 08:56:16 +0000

The issue literal strings are trying to solve is user inputs being pasted into places where a hardcoded string is expected. That's to ensure that the program user cannot get arbitrary control over these strings.

It's not supposed to prevent the programmer from hardcoding the wrong string.

A literal string type for Python

tialaramex — Fri, 15 Apr 2022 20:28:01 +0000

Because the resulting string can be EAT BABIES, and it's entirely possible that the programmer did not anticipate the circumstances which allow that? If we're OK with that, then this entire exercise was futile, as we could have also blessed arbitrary strings.

A literal string type for Python

iabervon — Thu, 14 Apr 2022 19:17:23 +0000

A related thing I'd like to see would be something like ft"SELECT * FROM data WHERE user_id = {user_id}", that evaluates to ("SELECT * FROM data WHERE user_id = {}", ("user123",)), and then conn.execute((LiteralString, args)) could use the fact that Python has support for parsing format strings and working with the result in more interesting ways than making a new str. That is, it would replace each substitution with a "?" and add the value to the arguments, instead of replacing the substitution with the string representation of the value.

As a side note, secure coders these days have gotten really bad at writing insecure code. The example in the PEP just won't work at all, since it'll result in returning rows where data.user_id = data.user123 rather than ones where data.user_id = 'user123'. The insecure code that people would actually write is f"SELECT * FROM data WHERE user_id = '{user_id}';", with a set of single quotes that the attack could close.

A literal string type for Python

mb — Thu, 14 Apr 2022 16:45:34 +0000

Why do you think your third example is unsafe?

A literal string type for Python

tialaramex — Thu, 14 Apr 2022 16:31:18 +0000

I fear that the "it even works if you've actually done stuff with the strings" using methods we think are safe - undoes too much of the initial value of requiring literals. I understand entirely why they did it, but my instinct is that they've unlocked far too much here. Mechanically it's obviously possible to use the capabilities marked "safe" to produce arbitrary LiteralStrings at runtime, at which point these are clearly not literal strings and I think in the sort of "Oops, I am not really a programmer" code where this safety was most necessary, that's more rather than less likely to be accessible to an attacker.

"EAT BABIES" // clearly expresses your intent, it's your fault, you wrote that.

"EAT" + " BABIES" // I can see why they felt like they should make this work, they've cited examples that do this and it genuinely is still clear at this point what your intent was, although I think it should be discouraged anyway.

doComplicatedStuffBasedOnUserInput("DO NOT EAT BABIES", input) // this still type checks as LiteralString, and might be EAT BABIES yet we can hardly claim now that we're reflecting clear programmer intent when that happens.

The reason to want literals here rather than allowing arbitrary strings is to get closer to requiring intent. I'd rather give up the second example than, as this PEP does allow the third example opportunity to set fire to everything and pretend that's "safe".

Rust of necessity has to require actual literals in formatting (not merely constant strings) because the formatting work is done via the macro system, and the macro system can't see inside variables. But I think even though more sophisticated behaviour would be welcomed by many Rust programmers I personally prefer the literal requirement.

A literal string type for Python

NRArnot — Thu, 14 Apr 2022 08:39:27 +0000

Django has something similar. When ordinary strings are rendered into an HTML template, the HTML special characters are escaped ("<" into "<" etc.). The programmer can create "safe" strings (type Safestring) which behave like ordinary strings in most ways, but which do not get HTML-escaped. They remain safe until they are combined with ordinary strings by concatenation etc.

A literal string type for Python

ovitters — Thu, 14 Apr 2022 07:26:22 +0000

I didn't read the article, but the problem reminds me of why Bugzilla uses the taint mode of Perl. It was really handy to catch loads of user input handling bugs. Despite that, Bugzilla still was affected by a few user input security issues. Basically things that were marked as safe that (despite reviews) was eventually proven not to be safe. I really appreciated the taint mode and it's surprising how few programming languages lack a similar concept. This as handling user input is so common.

A literal string type for Python

milesrout — Thu, 14 Apr 2022 01:20:35 +0000

This seems like a very good design. It speaks volumes that (at least from what I can tell from reading this article) the type system did not need to be modified to make this work. Many type systems in common use today could not represent this sort of subtyping relationship, as doing LiteralString.__add__(LiteralString) would give back a str. And it all disappears into the background without getting in your way if you just want to write normal Python without type annotations.