3 ms·

Yes that is just one way in which PHP is annoying. I think they actually refer to it as an "associative array", which as far as I can tell is exactly a hash, bu

Yes that is just one way in which PHP is annoying. I think they actually refer to it as an "associative array", which as far as I can tell is exactly a hash, but they never refer to it as one. On a side note, Ruby does not appear to have that same problem as similar code executes in .02 seconds. I think it is probably because Ruby's hash function is superior.

nikic 15y ago
Actually this is not specific to PHP at all. Ruby just uses a different hashing algorithm so you need to set different keys to get these results. This is a problem that hashtables have in general (unless they are randomized).
- mdwrigh2 15y ago
  Ruby 1.9's hash function has been randomized for awhile now, and I believe that 1.8.7 got a patch fixing this yesterday.
dangrossman 15y ago
Ruby's not immune to this... http://www.ocert.org/advisories/ocert-2011-003.html http://www.ocert.org/advisories/ocert-2011-003.html
- alinajaf 15y ago
  Well hold up a second... quote from that link: _ In the case of the Ruby language, the 1.9.x branch is not affected by the predictable collision condition since this version includes a randomization of the hashing function._ So there is some merit to what the commenter is saying, though I doubt he knew the above. Actual ruby arrays (which are arrays and not hashes) will obviously not exhibit this problem though. I think for all practical purposes, unless you're doing something really weird, the likelyhood of hash function collisions is rare enough that we don't need to think too much about it.
  - damncabbage 15y ago
    I think for all practical purposes, unless you're doing something really weird, the likelyhood of hash function collisions is rare enough that we don't need to think too much about it. Except that, like with PHP, the worrying part is that someone can stuff rack.request.form_hash or rack.request.query_hash (a la PHP's $_POST and $_GET). (Unlike PHP, though, the Ruby community can head off these particular attacks by releasing a new version of Rack, while waiting for a new 1.8.x release containing a security patch.)
- subwindow 15y ago
  Yes it is, and it has been for at least a year.
mechanical_fish 15y ago
Having just done this research... Ruby 1.9 has apparently had randomized hash functions for years. Ruby 1.8.7 and JRuby were apparently vulnerable until yesterday, but both released fixed versions yesterday. Meanwhile PHP will presumably do a similar set of fixes, though I haven't seen the announcement yet. There are workarounds for web apps that involve using extensions to limit the size of POST requests and/or the acceptable number of parameters in a POST request.

nikic 15y ago

Actually this is not specific to PHP at all. Ruby just uses a different hashing algorithm so you need to set different keys to get these results. This is a problem that hashtables have in general (unless they are randomized).

mdwrigh2 15y ago
Ruby 1.9's hash function has been randomized for awhile now, and I believe that 1.8.7 got a patch fixing this yesterday.

dangrossman 15y ago

Ruby's not immune to this... http://www.ocert.org/advisories/ocert-2011-003.html http://www.ocert.org/advisories/ocert-2011-003.html

alinajaf 15y ago
Well hold up a second... quote from that link: _ In the case of the Ruby language, the 1.9.x branch is not affected by the predictable collision condition since this version includes a randomization of the hashing function._ So there is some merit to what the commenter is saying, though I doubt he knew the above. Actual ruby arrays (which are arrays and not hashes) will obviously not exhibit this problem though. I think for all practical purposes, unless you're doing something really weird, the likelyhood of hash function collisions is rare enough that we don't need to think too much about it.
- damncabbage 15y ago
  I think for all practical purposes, unless you're doing something really weird, the likelyhood of hash function collisions is rare enough that we don't need to think too much about it. Except that, like with PHP, the worrying part is that someone can stuff rack.request.form_hash or rack.request.query_hash (a la PHP's $_POST and $_GET). (Unlike PHP, though, the Ruby community can head off these particular attacks by releasing a new version of Rack, while waiting for a new 1.8.x release containing a security patch.)
subwindow 15y ago
Yes it is, and it has been for at least a year.

mechanical_fish 15y ago

Having just done this research... Ruby 1.9 has apparently had randomized hash functions for years. Ruby 1.8.7 and JRuby were apparently vulnerable until yesterday, but both released fixed versions yesterday. Meanwhile PHP will presumably do a similar set of fixes, though I haven't seen the announcement yet. There are workarounds for web apps that involve using extensions to limit the size of POST requests and/or the acceptable number of parameters in a POST request.