No subject

default behavior of hashable be and for what types (e.g. we could use
SIpHash for string types but a simple hash for Int-like types). This is the
issue that's not already settled and the reason I'm holding hashable back
to 1.1 for the platform. I'm leaning towards fast by-default as hashing is
just one of many security issues web frameworks already consciously have to
deal with. It's also an issue which have many alternative fixes, which
don't require a stronger hash function.

-- Johan

--047d7bdc8b0abc1b4904d849cd64
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 19, 2013 at 9:19 AM, Thomas Schilling <span dir=3D"ltr">&lt;<a =
href=3D"mailto:nominolo at googlemail.com" target=3D"_blank">nominolo at googlema=
il.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">

Oh, I just realised that this proposal is to include the older version<br>
of hashable. =A0In principle, I&#39;m not against that, but I do wonder wha=
t<br>
the upgrade path is. =A0I don&#39;t think the performance problems can be<b=
r>
fixed in general -- that&#39;s just the price of security. =A0So it becomes=
<br>
critical what the upgrade path looks like. =A0Do users get a slowdown of<br=
>
2x by default and then have to manually make it faster again if<br>
something is not security sensitive? =A0Do users have to explicitly opt<br>
in for security (a bad default, IMO)? =A0Do we have any idea how that<br>
switch may affect the API?</blockquote><div><br></div><div>From an API stan=
dpoints, users of unordered-containers will be unaffected by any changes to=
 hashable and people who write Hashable instances are unlikely to be affect=
ed either, as long as they write their instances in terms of hashWithSalt.<=
/div>

<div><br></div><div>From a performance standpoint, it depends on what we de=
cide to make the default behavior of hashable be and for what types (e.g. w=
e could use SIpHash for string types but a simple hash for Int-like types).=
 This is the issue that&#39;s not already settled and the reason I&#39;m ho=
lding hashable back to 1.1 for the platform. I&#39;m leaning towards fast b=
y-default as hashing is just one of many security issues web frameworks alr=
eady=A0consciously=A0have to deal with. It&#39;s also an issue which have m=
any alternative fixes, which don&#39;t require a stronger hash function.</d=
iv>

<div><br></div><div>-- Johan</div><div><br></div></div>

--047d7bdc8b0abc1b4904d849cd64--