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

[Roman Cheplyaka]

* Thomas Moertel <tom at moertel.com> [2013-03-21 15:58:58-0400]
> On Wed, Mar 20, 2013 at 5:05 PM, Johan Tibell <johan.tibell at gmail.com>wrote:
> 
> > 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.
> >
> 
> I understand that HashMap exists to provide speed, but are we sure that
> everyone who uses it for speed understands the security implications?
> 
> Regardless of whether speed-first or security-first is the default, users
> of HashMap can be partitioned into two groups: those who knowingly choose
> between speed and security, and those who do not. For the first group,
> either default is safe because members of that group will have the
> opportunity to choose the other option. But for the second group, only
> security-first is safe: if it’s not the default, members of the second
> group won’t have the option to choose it.

Why not simply educate them by placing a prominent notice in the
haddock?

> The problem for the Haskell Platform is that the second group is likely to
> be large. The whole point, after all, is to make a curated set of tools and
> libraries available to a large audience that doesn’t necessarily have the
> time or knowledge to make its own informed choices. So if we decide, on
> behalf of this audience, that the Haskell Platform is going to be less
> secure to get more speed, aren’t we exposing a lot of Haskell users to
> preventable security risks?
> 
> I’m not just arguing the case of HashMap but of the whole Haskell Platform.
> I’d like to think that a widely used platform should be safe by default and
> offer danger-with-benefits as an option.

The whole security issue is that, in some cases, the complexity of the
code may be unexpectedly bad. Unfortunately, it is already the case with
Haskell. Laziness makes it extremely hard to make guarantees about the
worst-case complexity of a non-trivial code base.

Roman