Post by Marc FeeleyAdd a feature request issue for this. Non-determinism is bad for
debugging. And I view âproduction runsâ as debugging because when
something goes wrong in production once in a blue moon you need to debug
that particular run.
If Gambit were to salt its hashes, the salt(s) and/or the random seed
used to compute the salt(s) ought to be setable by users early enough
(if needs be on the command-line).
Adam: can the salt be per-table (or per-type) or does it have to be
global? Can you do it in user-space?
As I understand it, the salt can be both per table and global. There is no
reason that the user would not be allowed to specify the salt per table. If
random u8vector may not be super fast, then maybe just copy the default
per-table salt from a global variable that's generated once at startup.
Having salt randomization on by default would follow a "secure by default"
reasoning - someone could use a hashtable in an exploitable place, and not
be aware of the DDOS implications hashtables can have.
Of course as a user you can add hash salting on top of Gambit's hashtables
yourself, by cons:ing on a random constant to all your table keys, or by
implementing your own hashing function and telling Gambit to use it.
(Some more thoughts,
I see the point about determinism of software execution, however isn't the
only effect of the randomization that table operations will have slightly
different execution times which mean nondeterminism, aren't there some
other common sources of nondeterminism around such as variance in OS thread
execution speed or IO speed, that could complicate debugging already and
even more than hashtable behavior -
Anyhow an optional salt works too. Hashtable DDOS security is really not a
normally notable threat, it just occurred to me to bring it up for
completeness, that was all. Yep should add a feature request.)