Royce WilliamsWhy did they remove from Ruby the equivalent of Perl's data "taintedness" tracing mechanism?
Matt Palmer@tychotithonus it was a source of bugs, and common libraries (eg rack) didn't use it. https://bugs.ruby-lang.org/issues/16131
@womble I guess so, but, I mean, lots of stuff can be a "source of bugs". I'm just not clear of why many languages don't think that it's worth adding and keeping current. Feels like a huge security win.
@tychotithonus I'm sure if it were actually used by the common entry points for untrusted data, like rack, it would have been kept and maintained, but if nobody's using it, the need to account for it in all new interpreter dev is just overhead. For my money, the kinds of type confusion that a single "tainted" flag prevents are only a subset of the available sources of vulns; if you actually want to kill that whole bug class you need a proper, enforced type system.
@womble Fair, though I'm not clear enough on how typing always works to understand that something could be the correct type, but still unwanted data (but maybe this is too belt-and-suspenders)
(in other words, I use Perl's "detainting must work by matching a regex" to constrain input much more closely than "this must be alphanumeric")
@tychotithonus the limit of tainting is that it can only say a string is "safe" or "unsafe", without answering the question "safe for *what*?". If you untaint the value with a "safe for HTML" regex, but then it gets eval'd instead, Unpleasantness will result. The solution is to have separate "safe for HTML" and "safe for eval" data types, and the only values accepted by methods that construct HTML or eval code are the relevant "safe for" types. Yes, it's more faffing around, but far more secure.
@womble Ah, absolutely makes sense!