Proposal: Add the unordered-containers package and the hashable package to the Haskell Platform

[Bardur Arantsson]

On 03/20/2013 10:05 PM, Johan Tibell wrote:
> On Wed, Mar 20, 2013 at 1:04 PM, Thomas Moertel <tom at moertel.com> wrote:
> 
>> On the speed vs. security trade-off, there’s a good argument for the
>> Haskell Platform to choose security as its default policy: speed problems
>> are obvious and have understandable consequences and remedies, but security
>> problems are hidden and have poorly understood consequences and often lack
>> remedies altogether. You can’t go back in time to remedy being pwned.
>>
>> Therefore, if we make speed the default, we leave open to harm everybody
>> who fails to fully understand the security implications of their libraries’
>> default choices, which is just about everybody. But if we make security the
>> default, nobody will be taken unaware, either by speed or preventable
>> security problems.
>>
>> Yes, those people who need the extra speed will have to suffer the cost of
>> opting-in to the faster implementations, but that cost is predictable and
>> relatively small. The point is that nobody is going to be taken unaware by
>> failing to make the right choice up front. The first time you run your code
>> and it’s too slow, you’ll know.
>>
> 
> The problem is that if the secure hashing makes HashMap as slow as Map,
> there's no point in having the former in the first place, as it only exists
> to provide speed.
> 

The really unfortunate issue with the insecure HashMap is that it
"leaks" -- if any package in the whole dependency tree of a world-facing
component of an application (let's call it $APP) switches from Map to
HashMap for performance reasons, $APP may suddenly become vulnerable to
DoS -- depending on arbitrarily complex flows of data which determine
whether any user-supplied data ultimately ends up being used as a key in
a map. (I don't want to make this sound like it's the end of the world
-- it's clearly not a huge problem in practice given the "market share"
of world-facing Haskell applications, but it just seems "wrong" somehow.)

Maybe the best thing is just to document the issue clearly and loudly in
the Haddocks? You'll still be vulnerable to a dependency switching to
the "fast" HashMap, but at least the implementers of that dependency
will be made aware of the issue and won't just choose HashMap "because
it's faster". It's not much, but maybe it helps a little.

Aside: Given the current VM-introspection API, is it possible -- in
principle -- for a Haskell web framework to detect misbehaving clients
which are hogging CPU and killing them (possibly banning by IP for a
short while)? Since most of them are based on Haskell threads, the CPU
accounting would have to happen per-thread. If so, that'll certainly
alleviate most of the concerns, I think.

Lastly: It's a small thing, but Map requires an Ord instance whereas
HashMap doesn't. (Though, I suppose given a Hashable instance one could
always define an Ord instance based on the outcome of that. It'd be
pretty ugly, though.)

Regards,