Hello Charlie, On 2013/03/21 9:03, Charles Oliver Nutter wrote: > It had to happen eventually... > > We received a pull request recently for a change that makes JRuby's > hashing of Strings, Booleans, nil, and Symbols be consistent. > Basically, it provides hardcoded hashes for Booleans and nil, and > makes it possible to disable seeded hashes for String and Symbol. > > PR: https://github.com/jruby/jruby/pull/590 > > My question for ruby-core: at what point did you decide to make hash > for e.g. nil not be a single value (it was "4" in 1.8.7 and > different/random in 1.9.3+), and why did you do it? Yui already gave a pointer. Actually, neither NilClass nor TrueClass nor FalseClass implement #hash. All three fall back to Object. So do Symbol and Fixnum. So it seems to be mainly the result of not doing anything more than necessary in terms of implementation against the potential DOS attacks. > I think it's valid to want to be able to consistently hash these > values across runtimes, but I want to understand the implications > before I merge this patch into JRuby proper. > > Thoughts? I can't currently see a security problem with making the hash values of nil, true, and false consistent across runtimes. But then that's not a guarantee that there are none (I'm not a security expert). And I don't see a reason for making only these three stable. When it comes to Symbols, we get back to the question to what extent Symbols may/can/shouldn't be created based on data coming in from the outside of an application, which we discussed related to garbage collection of symbols. Overall, having a switch to eliminate introducing randomness into hash values may be something to consider. But it will produce problems when an application is put together from various libraries: Some of these libraries may depend on hashes being stable, while some others may be open to DOS attacks when hashes are stable. So maybe those who need stable hashes should implement #stable_hash methods, and if it turns out that this is used often, we can add it to Ruby itself. Regards, Martin.