<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#330033">
    On 1/26/2012 10:47 PM, Glenn Linderman wrote:
    <blockquote cite="mid:4F22489D.7080902@g.nevcal.com" type="cite">On
      1/26/2012 10:25 PM, Gregory P. Smith wrote:
      <blockquote
cite="mid:CAGE7PNJRaASr_bLHDSbcMmJcjJ3CmS5s1Vo_MOkY9=UokkWYGA@mail.gmail.com"
        type="cite">
        <pre wrap="">(and on top of all of this I believe we're all settled on having per
interpreter hash randomization <span class="moz-txt-underscore"><span class="moz-txt-tag">_</span>as well<span class="moz-txt-tag">_</span></span> in 3.3; but this AVL tree
approach is one nice option for a backport to fix the major
vulnerability)</pre>
      </blockquote>
      <br>
      If the tree code cures the problem, then randomization just makes
      debugging harder.  I think if it is included in 3.3, it needs to
      have a switch to turn it on/off (whichever is not default).</blockquote>
    <br>
    In case it is not clear, I meant randomization should always be able
    to be switched off.<br>
    <br>
    Another issue occurs to me: when a hash with colliding keys (one
    that has been attacked, and has trees) has a non-string key added,
    isn't the flattening process likely to have extremely poor
    performance?<br>
    <br>
    Agreed that the common HTML FORM or JSON attack vectors are unlikely
    to produce anything except string keys, but if an application grabs
    those, knows that the user keys are all strings, and adds a few more
    bits of info to the dict for convenience, using other key types,
    then ...  WHAM?<br>
    <br>
    Seems a bit unlikely, but I know I've coded things along that line
    from time to time... I don't recall doing it in Python Web
    applications...<br>
  </body>
</html>