In demerphq's own words:
bulk88> I disagree there is a measurable cost to the current implementation of
bulk88> REHASH. If the rehash code is so rare, maybe it should be removed from
bulk88> hv_common and placed in its own func, but looking at the asm, the
bulk88> overhead is so tiny I dont think the rehash code even matters compared
bulk88> to the rest of the design of hv_common. I don't see any performance
bulk88> gains by removing it.
demerphq Yes, I am unable to show any actual performance gains either.
So, not for performance (gain) reasoning.
Also in his own words:
demerphq So I think that the current rehash mechanism is about as secure as the
random hash seed proposal.
And:
demerphqPersonally I dont think its worth the effort of doing much more than
thinking about this until someone demonstrates at least a laboratory
grade attack. IMO in a real world environment with multi-host web
sites, web servers being restarted, load balancers, and etc, that
simple hash randomization is sufficient. Seems like any attack would
require large numbers of fetch/response cycles and in general would
just not be effective in a real production environment. I would assume
that the administrators would notice the weird request pattern before
an attacker could discover enough information to cause damage. Same
argument for non-web services IMO.
And it doesn't make anything more secure.
And Dave_the_m said:
Indeed, based on the thread starting at
Message-ID: <2003101002...@perlsupport.com>
it looks like the primary motivation for moving to rehash was to restore
the binary compatibility within the 5.8.x branch inadvertently broken by
5.8.1.
I'm not particularly keen on having hashes always randomised - it makes
debugging harder, and reproducing a reported issue nigh-on impossible;
but if Yves can show a measurable performance gain without the rehash
checks, then I'll approve, as long as the hash seed can still be
initialised with the env var PERL_HASH_SEED=0 - otherwise debugging
becomes impossible.
Which mirrors the OPs objections.
So, significant consequences
So, why? What did Perl gain?
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.