Changes between Initial Version and Version 1 of Ticket #1839, comment 11


Ignore:
Timestamp:
May 1, 2015, 7:26:04 AM (5 years ago)
Author:
isis
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #1839, comment 11

    initial v1  
    11Okay, I merged [https://trac.torproject.org/projects/tor/ticket/1839#comment:9 the changes mentioned above] for bridgedb-0.3.2. This at least fixes the issues with getting #4771 deployed. I'm decreasing the priority, because it's no longer blocking.
    22
    3 However, I think we still want separated hashrings, were only one subhashring of a hashring is available per period. This ''sounds'' like a good idea. I'm not sure how compatible it will be with running BridgeDB's distributors on separate machines (#12506), since in that model, each distributor will pretty much get assigned a chunk of bridges and be able to do whatever it wants with them. However, if we have generalised hashring classes that can be easily configured to do this subhashring rotation behaviour (see #12505 for hashring refactoring), this can be easily used by distributor implementations who wish to better protect their bridges from any attack enabling rapid bridge enumeration.
     3However, I think we still want separated hashrings, where only one subhashring of a hashring is available per period. This ''sounds'' like a good idea. I'm not sure how compatible it will be with running BridgeDB's distributors on separate machines (#12506), since in that model, each distributor will pretty much get assigned a chunk of bridges and be able to do whatever it wants with them. However, if we have generalised hashring classes that can be easily configured to do this subhashring rotation behaviour (see #12505 for hashring refactoring), this can be easily used by distributor implementations who wish to better protect their bridges from any attack enabling rapid bridge enumeration.