- Mar 31, 2015
-
-
Isis Lovecruft authored
* FIXES #15522: https://bugs.torproject.org/15522
-
Isis Lovecruft authored
* FIXES a bug exposed by the test committed in 9edb6956. * CHANGES b.s.ScheduledInterval.intervalStart() to convert any timestamps which are passd into it to integers.
-
Isis Lovecruft authored
ScheduledInterval.intervalStart(), when called with a float, i.e. as is returned from time.time() which is used by the email distributor to pass timestamps into ScheduledInterval.intervalStart(), returns a float. This could cause bugs in other parts of the code which expect ints for timestamps.
-
Isis Lovecruft authored
-
Isis Lovecruft authored
-
Isis Lovecruft authored
-
Isis Lovecruft authored
-
Isis Lovecruft authored
This implements configuration of the hashring rotation periods for BridgeDB's distributors via the configuration file. The behaviour for hashring rotation for the EmailBasedDistributor is such that, when `bridgedb.email.autoresponder.createResponseBody()` calls `EmailBasedDistributor.getBridgesForEmail(EMAIL_ADDRESS, EPOCH)` with the `EPOCH` set to the start of the current EMAIL_ROTATION_PERIOD, the client's position in the hashring is determined by the HMAC of the string `"<EPOCH>EMAIL_ADDRESS"`. Therefore, the EMAIL_ROTATION_PERIOD directly effects where the client is placed in the hashring, resulting in different bridges for the user, depending on whether the period has elapsed. With the default setting of `"1 day"`, and taking into account also that the EmailBasedDistributor only responds to a particular user once per three hours, this results in the client being able to ask for (and receive) vanilla bridges (starting from hashring position A) at 9:00, obfs3 bridges (also from position A) at 12:00, obfs4 bridges (from position A again) at 15:00, and so on, and finally different vanilla bridges (from hashring position B) the next morning at 9:00. For the IPBasedDistributor, the behaviour for hashring rotation is that the client's hashring position is determined by the HMAC of the string `"<EPOCH>AREA"` where `EPOCH` is again the start of the current HTTPS_ROTATION_PERIOD, and the `AREA` is the `/16` subnet which the client's IP address resides within. If the client is using Tor or some other open proxy, then the client's hashring position is determined by `"known-proxy<EPOCH>GROUP"` where `EPOCH` is the same as before, and `GROUP` is a number (currently 1 through 4, inclusive) deterministically derived from the IP address of the Tor Exit relay or open proxy that the client is using. Using `GROUP` causes there to only be 4 sets of bridges available to any and all Tor/proxy users at a given time. Hence additionally using `EPOCH` rotates the set of 4 bridges available. The default setting is `"3 hours"`, causing all Tor/proxy users to have 4 different sets of bridges every three hours, while non-Tor users have a new set of bridges (probably) unique to their IP address available every three hours. These defaults for HTTPS_ROTATION_PERIOD and EMAIL_ROTATION_PERIOD will likely need to be changed and fiddled with to make the behaviour an optimum balance between user-friendly and resilient to enumeration. * FIXES #1839: https://bugs.torproject.org/1839. This implement Roger's suggestion to add the rotation periods as configuration file options.
-
Isis Lovecruft authored
-
Isis Lovecruft authored
See https://trac.torproject.org/projects/tor/ticket/4771#comment:23 * FIXES part of #4771.
-
Isis Lovecruft authored
-
Isis Lovecruft authored
See https://trac.torproject.org/projects/tor/ticket/4771#comment:14 for more information. Essentially, by using the `area` (which is the client's IP address, truncated to the /24, i.e. if the client's IP is 1.2.3.4, then the `area` would be 1.2.3) in the HMAC for placing the client into the hashring, the resulting HMAC would be different for each Tor Exit (but not for Exits in the same /24). This would enable clients who changed their Exit relay to get new bridges. Instead, we now group Tor/proxy users into four groups, based on their Exit relay's or proxy's IP address. Regardless of how many times a client changes their Exit or proxy, they will only get up to four sets of bridge lines (per period).
-
Isis Lovecruft authored
* FIXES #4771: https://bugs.torproject.org/4771
-
Isis Lovecruft authored
-
Isis Lovecruft authored
-
- Mar 30, 2015
-
-
Isis Lovecruft authored
-
Isis Lovecruft authored
IP address log sanitisation happens automatically now, so we don't need to use logSafely().
-
- Mar 28, 2015
-
-
Isis Lovecruft authored
Checking `if proxySet` when the ProxySet was empty (as at server startup, particularly when loading the PROXY_LIST_FILES), would evaluate to False, cause the proxies from the files *not* to be loaded into the empty ProxySet. This did not effect loading the list of Tor Exit relays, since we use scripts/get-tor-exits and load the list into memory while calling ProxySet.add() for each one (rather than loading Tor Exit relays from a downloaded file, like we used to do).
-
Isis Lovecruft authored
-
Isis Lovecruft authored
-
Isis Lovecruft authored
I added these earlier this week for debugging purposes, but it turns out that they print *so* many times that it is impossible to follow the logfiles.
-
Isis Lovecruft authored
-
Isis Lovecruft authored
-
-
- Mar 27, 2015
-
-
Isis Lovecruft authored
-
Isis Lovecruft authored
-
Isis Lovecruft authored
-
Isis Lovecruft authored
Conflicts: lib/bridgedb/test/test_bridges.py
-
- Mar 26, 2015
-
-
Isis Lovecruft authored
-
Isis Lovecruft authored
-
Isis Lovecruft authored
-
Isis Lovecruft authored
-
Isis Lovecruft authored
-
Isis Lovecruft authored
Doing: >>> from bridgedb import bridges >>> b = bridges.Bridge() >>> b.setStatus(stable=True) Results in: >>> b.stable True >>> b.flags.stable False When it should result in: >>> b.stable True >>> b.flags.stable True
-
Isis Lovecruft authored
-
Isis Lovecruft authored
-
Isis Lovecruft authored
* ADD bridgedb.bridges.PluggableTransport._checkArguments() method, which raises a MalformedPluggableTransport exception if a known transport (which should have one of some sets of arguments) has missing or incorrect arguments. * CHANGE bridgedb.bridges.Bridge.updateFromExtraInfoDescriptor() method to catch MalforedPluggableTransport exceptions raised when attempting to add or update a PluggableTransport. * FIXES #13202: https://bugs.torproject.org/13202 Until Tor-0.2.4.x is deprecated and no longer in use, this is a temporary fix for #13202.
-
Isis Lovecruft authored
-
Isis Lovecruft authored
-
Isis Lovecruft authored
-