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

[Thomas Moertel]

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.

But the speed-first policy does not offer the same protections to the
people who need the extra security but don’t know it. Without security by
default, those people are left open to preventable harm. The first time
they know it, it will be too late.

The following table summarizes the cases:

https://docs.google.com/document/d/1riApFkjMr6rFRflg9_ZDhkZ9qZwg3rbEUXxYOC3hSco/edit?usp=sharing

Both policies mean that some people are going to be inconvenienced. But
only security-first protects against the worst outcomes.

Cheers,
Tom


On Tue, Mar 19, 2013 at 12:43 PM, Johan Tibell <johan.tibell at gmail.com>wrote:

> On Tue, Mar 19, 2013 at 9:19 AM, Thomas Schilling <nominolo at googlemail.com
> > wrote:
>
>> Oh, I just realised that this proposal is to include the older version
>> of hashable.  In principle, I'm not against that, but I do wonder what
>> the upgrade path is.  I don't think the performance problems can be
>> fixed in general -- that's just the price of security.  So it becomes
>> critical what the upgrade path looks like.  Do users get a slowdown of
>> 2x by default and then have to manually make it faster again if
>> something is not security sensitive?  Do users have to explicitly opt
>> in for security (a bad default, IMO)?  Do we have any idea how that
>> switch may affect the API?
>
>
> From an API standpoints, users of unordered-containers will be unaffected
> by any changes to hashable and people who write Hashable instances are
> unlikely to be affected either, as long as they write their instances in
> terms of hashWithSalt.
>
> From a performance standpoint, it depends on what we decide to make the
> default behavior of hashable be and for what types (e.g. we could use
> SIpHash for string types but a simple hash for Int-like types). This is the
> issue that's not already settled and the reason I'm holding hashable back
> to 1.1 for the platform. I'm leaning towards fast by-default as hashing is
> just one of many security issues web frameworks already consciously have to
> deal with. It's also an issue which have many alternative fixes, which
> don't require a stronger hash function.
>
> -- Johan
>
>
> _______________________________________________
> Haskell-platform mailing list
> Haskell-platform at projects.haskell.org
> http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://projects.haskell.org/pipermail/haskell-platform/attachments/20130320/7f6addca/attachment.htm>