
Tin, thanks for the feedback. I definitely agree that this is a niche feature and so far the only applications seem to be for security, but I can promise you that it came from a real need we had internally at Meta. We figured the broader Python community could benefit from us standardizing it.
is talking to SQL databases with raw strings so ubiquitous to require a typing PEP?
Most sane frameworks encourage parameterized queries which prevent SQL injection, but there is no guarantee that that parameterized query is actually a string literal. If the string that is *supposed* to be a parameterized query is instead dynamically built with attacker controlled data, you have a potential SQL injection. For example, the Python standard library has the sqlite3 module <https://docs.python.org/3/library/sqlite3.html> which runs raw SQL. Such APIs can be protected from SQL injection using StringLiteral. There are alternative APIs to SQL databases such as ORMs (which prevent the need to run SQL in most common cases), but even they offer escape hatches to run raw SQL (eg. SQLAlchemy offers the execute function <https://docs.sqlalchemy.org/en/14/core/connections.html#sqlalchemy.engine.Co...>). Those escape hatches are another place where StringLiteral should be applied.
as the PEP mentions, no logging frameworks seem to be vulnerable to injection either.
Yet :). As it stands now, the biggest known risk to logging frameworks is DOS (which shouldn't be dismissed outright, but is obviously less severe than most injection attacks) but we don't know that something more severe won't be found down the line. For logging frameworks in particular, LiteralString can provide a bit of protection against a currently known risk as well as future proof against potential future log4j style risks.
The main use case according to the PEP is preventing SQL injection
We just chose SQL injection because it was easy to understand and we wanted a consistent example throughout. We also believe StringLiteral can protect against command injection, cross site scripting, and server side template injection <https://www.python.org/dev/peps/pep-0675/#appendix-a-other-uses>. We could also prevent leaking secrets <https://podalirius.net/en/articles/python-format-string-vulnerabilities/> and (contrived cases of) RCE <https://github.com/gbleaney/python_security/blob/60d2cea66e438fc68a7ff4dd363...> through format strings using StringLiteral, but that didn't make it into the PEP. Arie Bovenberg actually came up with the logging use case <https://bugs.python.org/issue46200> after we submitted this PEP, so I also have hope that others will find use cases for LiteralString that we haven't yet considered. On Tue, Feb 1, 2022 at 2:36 PM Tin Tvrtković <tinchester@gmail.com> wrote:
Great job on the PEP to the authors but it feels a little like a solution in search of a problem.
The main use case according to the PEP is preventing SQL injection, but is talking to SQL databases with raw strings so ubiquitous to require a typing PEP? All systems I've worked with use a library that abstracts that away and you usually build the query somehow other than with strings. And, as the PEP mentions, no logging frameworks seem to be vulnerable to injection either.
That said, it's no concern of mine if folks want to spend their time implementing this but my gut feeling is it won't be all that useful.
On Tue, Feb 1, 2022 at 11:05 PM S Pradeep Kumar <gohanpra@gmail.com> wrote:
Hello all,
We've incorporated a bunch of feedback on the PEP and would like a final round of review from typing-sig.
https://www.python.org/dev/peps/pep-0675/
Main changes:
+ Naming: After all the bikeshedding here over the last two months, there was no undisputed winner :) So, we decided to go with the least bad option: `LiteralString`. We've added a section on Rejected Names along with reasons. + Provided an exhaustive list of `str` methods that preserve the literal string type (Appendix C). These would make it seamless for users, e.g., they can use `s.capitalize()` without worrying about losing the literal type of `s`. + Described the changes needed in typeshed (Appendix C). + Recommended how to use literal string types in type stubs (Appendix D).
If it looks good, we can go forward and submit it to python-dev.
Best, S Pradeep Kumar Graham Bleaney
On Tue, Jan 25, 2022 at 7:30 AM David Foster <davidfstr@gmail.com> wrote:
On 1/24/22 2:06 AM, akuviljanen17@gmail.com wrote:
What exactly is wrong with SafeStr or SafeString? The whole goal is to distinguish between arbitrary user input and strings that are known to be safe, so to me, SafeStr and SafeString are the only suggestions so far that make sense.
There are other kinds of checks spellable by Python's typing system that could result in a "safe str". Therefore using the term SafeStr here to mean a very specific type of "safe str" - specifically a constant expression - seems misleading to me.
As an example of another type of "safe str", consider the following code:
Url = NewType('Url', str)
def parse_url(s: str) -> Url|None: if ...: return cast(Url, s) else: return None
def is_url(s: str) -> TypeGuard[Url]: if ...: return True else: return False
Here, "Url" would be a kind of "safe str" type because you could only generate it through a parsing function. In particular a `str` will not implicitly convert to an `Url` because it is using a NewType.
-- David Foster | Seattle, WA, USA Contributor to TypedDict support for mypy _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: gohanpra@gmail.com
-- S Pradeep Kumar _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: tinchester@gmail.com
-- Thanks, Graham Bleaney