From: Charles Oliver Nutter <headius@...>
Date: 2009-11-03T03:43:40+09:00
Subject: [ruby-core:26487] Re: Disabling tainting

On Wed, Oct 7, 2009 at 8:59 AM, Kornelius Kalnbach <murphy@rubychan.de> wrote:
> I would find it confusing to have Ruby versions with different features.
> code that works on one Ruby would no longer work on the
> Ruby-w/o-tainting version, or the other way round. it's complictaed
> enough to have Ruby 1.8.6, 1.8.7, and 1.9.1 for now.
>
> so, no, in my view it would not be a good idea to use a compile-time
> switch that make Rubys with different feature sets.
>
> but it would still be very interesting to measure the performance impact
> of some features :)
>
> does JRuby have such a switch?

I did an experiment to turn off tainting in JRuby, running a benchmark
that manually reverses a long string several times. With no
modifications, JRuby's best time on the benchmark was 3.409s (compare
to Ruby 1.9's time of 7.08s). With tainting and untrust removed,
performance improved to 3.28s, but it was pretty noisy, usually faster
but sometimes slower. So there's a small, possibly measurable
improvement from eliminating taint, but it's rather small.

The unfortunate thing is that although tainting (and now the
additional "untrust" flag in 1.9) don't have a high perf impact, they
have a very large implementation impact. The codebase essentially has
to be littered with taint checks, which makes it possibly the worst
way to do security (very high chance of minor changes introducing
security holes). I'm not sure any alternative implementation (other
than JRuby) has even come close to getting tainting right, and we
don't even use the value since we don't support SAFE levels (which
require a whole other set of checks, equally as fragile).

- Charlie