Hello all,
Yesterday I released and deployed BridgeDB-0.3.2, which has several major fixes and changes.
Major changes visible to users include: changing the default pluggable transport to obfs4, and users requesting bridges will note that they are again normally receiving the maximum number (3) of bridges.
The temporary decrease in bridges was due to the fact that, while rewriting BridgeDB's bridge descriptor parsers (#9380), I implemented full verification of all cryptographic data involved, including signatures and descriptor digests, in order to validate the chain of bridge information from the networkstatus document (produced by the BridgeAuthority), to bridge server-descriptors, and finally to bridge `extrainfo` descriptors (which contain information on a bridge's pluggable transports). This turned out to be somewhat of a bad idea, because the BridgeAuthority appears to not producing good networkstatus documents (see #11216, #12254, #15707, and #15866).
Changes in version 0.3.2 - 2015-05-01
* FIXES a problem with the calculation of Levenshtein distances between blacklisted email addresses and those on incoming email. This fixes a problem with the fuzzy matching implemented in #9385: https://bugs.torproject.org/9385.
* FIXES #1839 https://bugs.torproject.org/1839 BridgeDB's distributors now rotate their hashrings at configurable scheduled intervals.
* FIXES #4771 https://bugs.torproject.org/4771 BridgeDB now records which of the HTTPS Distributor's sub-hashrings are used for clients coming from Tor Exit nodes and other known proxies.
* FIXES #12504 https://bugs.torproject.org/12504 Which Pluggable Transports BridgeDB distributes is now easily configurable via the bridgedb.conf configuration file.
* FIXES #13202 https://bugs.torproject.org/13202 Old bridges running Tor-0.2.4.x with Pluggable Transports like scramblesuit and obfs4proxy have a bug which causes them to not include the PT arguments in the `transport` line they submit to the BridgeAuthority in their extrainfo descriptors. This causes BridgeDB to have broken bridge lines for these bridges. For example, scramblesuit requires a `password=` in the `ClientTransportPlugin` for clients to connect to it. If BridgeDB receives a line in that bridge's extrainfo which says `transport scramblesuit 1.2.3.4:1234` (without a password), then when BridgeDB gives clients a bridge line for that bridge, it'll look like "Bridge scramblesuit 1.2.3.4:1234" - meaning that it won't work. This fixes the issue by excluding broken transports from being distributed to clients.
* FIXES #15517 https://bugs.torproject.org/15517 For all clients who are coming from IPv6 addresses and are not using Tor, who go to https://bridges.torproject.org, BridgeDB now groups these clients together by /32. This "grouping" causes all IPv6 clients within the same IPv6 /32 to get the same bridges. Previously, BridgeDB grouped IPv6 clients by /64 (which is ridiculously small, considering standard IPv6 allocation sizes).
For all clients who are coming from IPv4 addresses and are not using Tor, BridgeDB now groups these clients together by /16. Previously, BridgeDB grouped IPv4 clients by /24. (This latter change was technically made as part of #4771.)
* FIXES #15464 https://bugs.torproject.org/15464 The setup procedure for creating a BridgeDB Continuous Integration build machine is now simplified and generalised to include build environments like Jenkins, not just TravisCI.
* FIXES #15866 https://bugs.torproject.org/15866 BridgeDB now ignores nearly all the information in the networkstatus-bridges file created by the BridgeAuthority.
* ADDS benchmark tests to BridgeDB's test suite, and some of BridgeDB's algorithms have been revised to improve their speed.
As per usual, the full CHANGELOG is available here: https://gitweb.torproject.org/bridgedb.git/tree/CHANGELOG