[Python-ideas] Custom string prefixes

[Devin Jeanpierre]

On Wed, May 29, 2013 at 8:37 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> The loss of backwards compatibility makes this a Python 4000 idea.

Definitely this was against a hypothetical SQL API, showcasing its
benefit. One could replace it with, for example, a templating library.
Then the risk that is mitigated is accidental XSS vulnerabilities,
rather than accidental SQL injection vulnerabilities. Templating
libraries are far more common, and non-standard, so they can make this
change more easily than the DB-API can.

> But putting that aside, it has to be a built-in type only accessible as a
> literal, because if it is a function that takes a string argument, say,
> sql(), then you'll have exactly the same issue.

What's the problem with that? If the registry of prefix transformers
is kept private by Python, then it's not easy at all to retrieve a
function from that registry (although you can do it via ctypes). You
can delete any references to the function that are not in the
registry, and this is effectively hidden without crazy ctypes magic.

And then, because this is Python, you can also add an unsafe API for
users that need the flexibility and are aware of the security
implications.

The point isn't to make insecure code impossible -- that itself is
impossible. But it'd be nice to make it obvious, when it's being done,
that it is in fact insecure.

> Given that Python is a language which allows the programmer to shoot
> themselves in the foot if they so choose, I'm not really so sure that even
> in Python 4000 we should be going to extraordinary efforts to prevent *this
> specific* toe from being shot off.

There are many instances where Python does try to protect people from
shooting themselves in the foot (for example, immutable tuples*).

But anyway, I think it's a little callous to dismiss at all the idea
of protecting people from security-related problems. It's not
programmers' feet I'm worried about. When programmers make
security-related mistakes, the people that suffer are their users.
It's not as if it's only a little suffering, either. It can be a lot
of suffering. And I see this mistake very, very often.

If adding this feature would enable better APIs in the future, that
prevented pain in the future... maybe that prevented pain would
outweigh the effort spent adding and maintaining yet another feature
to Python, and any pain of additional work ("with unsafe"). If the
only reason not to do it is a philosophical objection to helping
people help themselves, then I think that philosophy should be
ignored.

-- Devin

.. [*] The wound being prevented is that tuples could be hashable and
mutable, but if they were placed inside a dict or set, and mutated in
such a way that their hash changed, their bucket would not change.
This makes them pseudo-invisible. A similar (but different) thing
happens if you insert NaN, but Python does not protect you there. Of
course, nothing is impossible when you use ctypes...