2013/3/19 Thomas Schilling <nomin...@googlemail.com>: > 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?
It seems reasonable for the secure algorithm to be handled with something explicit -- a newtype, a `secureHash' function -- so that a developer has real confidence that it's being used. What if the default changes back? -- Jason Dusek pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B _______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
