On Friday, 3 April 2015 at 20:41:26 UTC, Martin Nowak wrote:
> On 04/02/2015 02:10 PM, Kagamin wrote:
>> 
>> The vulnerability presentation suggests perl solution (random hash seed)
>> is good enough, it doesn't slow down anything. The seed can be left zero
>> and initialized by an application as needed. One can also use a longer
>> key and add more its bits every, say, 10 bytes of hashed data, not sure
>> if it will make any difference.
>
> A global random hash seed would work, but it needs to be accessible for
> reproducing test cases (druntime DRT option or in core.runtime).

At least for a library hashmap, you could provide a hash seed at compile time, or as some static value and maybe lie about purity.

On Friday, 3 April 2015 at 20:41:26 UTC, Martin Nowak wrote:
> A global random hash seed would work, but it needs to be accessible for
> reproducing test cases (druntime DRT option or in core.runtime).

I think, leave the seed zero and only provide a function to change it:
extern(C) void _d_setHashSeed(int seed);
Then applications will set it to whatever value they want. The function shouldn't be broadly exposed as only server frameworks will need it.

On 04/04/2015 05:12 PM, Kagamin wrote:
> 
> I think, leave the seed zero and only provide a function to change it:
> extern(C) void _d_setHashSeed(int seed);

Sounds good, accepting patches :). https://issues.dlang.org/show_bug.cgi?id=14414