This post is really great but also 
https://twitter.com/nelhage/status/801472446121422848 …
If you clone a HashMap then will both HashMaps have equivalent RandomState? Why wasn't Clone impl modified too?
-
-
sorry I have no idea how they actually addressed the issue; I don't really follow Rust dev anymore (can't contrib).
-
it's common for a quick fix to land without thinking about all the issues. e.g. my mem::forget fixes to Rc/Arc missed some funcs
End of conversation
New conversation -
-
-
There's a custom clone impl for RawTable so cloning an HM probably creates a fresh map with new random state.
-
pub struct HashMap<…> { // […] prevent hash collision attacks. hash_state: S, table: RawTable<K, V>, … }
-
Also, I wonder if there are any considerations regarding caching seed in thread-local storage w.r.t. fork()/clone().
-
New attack?: 1. Insert N elems 2. Iterate; save iteration order 3. Remove all 2. Re-insert all in same HT in same order
-
Compare to this prior to "fix": 1. Insert N elems into a HT. 2. Force copy of those elems into a new HT. Both O(n**2)?
-
this doesn't work because we don't shrink; the "attack" is reliant on having a lower cap table.
-
so basically you also need to get a shrink_to_fit in there.
-
that's convoluted enough that I think it's reasonable to say "this isn't a significant concern in practice"
- 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.