lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Roberto Ierusalimschy wrote:
> I still think this whole problem is somewhat overstated. As Jay Carlson
> put it (Jan 20), there are many other forms of DoS attacks that most
> sites are not resistant to.


In fact, nobody should _ever_ write their own HTTP handler! This
is absolutely not a trivial task, if you want it to be DoS-proof.
Even most of the 'batteries included' HTTP handlers of other
languages are just toys. There's only handful of web servers
packages that have seen the necessary scrutiny and that stand a
chance to survive an attack from a single client. But even those
will go down from a concerted DoS attack, unless you throw tons of
hardware at it or fight it at the network-level.

So, yes ... some expert with the right skills _could_ write a
targeted program that exploits some weakness in the hash
implementation three layers down an application -- given
sufficient effort. But it's orders of magnitude cheaper to rent a
bot net with exactly the same effect. Your site goes down and they
have a much lower chance of getting caught. Now, guess what the
bad guys will do?

> The main reasons we are changing Lua
> are that we like this idea of long non-internalized strings

That, I'm not so sure about. I'll freely admit: it does have a
certain appeal. But I'd want to see convincing, quantitative proof
that the resulting increase in complexity does not adversely
affect the performance of the common case. The simplicity of the
current solution and the resulting stability is a very convincing
argument against such a big change, too.

> and for propaganda.

Ok, that's tough. There's always someone with a vested interest,
who'd want to give this story a certain spin ('developer refuses
to fix gaping security hole'). And the topic is way too complex,
to defend your position in layman terms.