February 2014 - tor-commits - lists.torproject.org

[bridgedb/master] Add a CHANGELOG.
by isis＠torproject.org 04 Feb '14

04 Feb '14

commit aa495a95b1072565b4f093117b0b8e55eaeba39b Author: Isis Lovecruft <isis(a)torproject.org> Date: Tue Jan 28 22:23:24 2014 +0000 Add a CHANGELOG. --- CHANGELOG | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+) diff --git a/CHANGELOG b/CHANGELOG new file mode 100644 index 0000000..27415f9 --- /dev/null +++ b/CHANGELOG @@ -0,0 +1,69 @@ +Changes in version 0.1.0 - 2014-XXX +BridgeDB 0.1.1 includes fixes for the following bugs: + * FIXES #9127 + * FIXES #10737 + +Including the following general changes: + * ADDS A general simple error page to display rather than + webserver tracebacks. See #6127. + +Changes in version 0.1.0 - 2014-01-14 +BridgeDB 0.1.0 includes fixes for the following bugs: + * FIXES #1606 Write a BridgeDB spec + * FIXES #3573 bridges.torproject.org doesn't have a robots.txt + * FIXES #6127 bridges.tpo runs in development mode + * FIXES #9013 BridgeDB should pass pluggable transport + shared-secrets to clients + * FIXES #9157 Persian and Arabic should be right aligned on bridges.tpo + * FIXES #9462 BridgeDB netstatus descriptor parsers need refactoring + * FIXES #9959 BridgeDB seems to be missing English translations + * FIXES #9865 Add automated code coverage report generation + * FIXES #9872 Create a test runner for BridgeDB unittests + * FIXES #9873 Convert BridgeDB's old unittests to use twisted.trial + * FIXES #9937 Create fake non-sanitised bridge descriptors for + BridgeDB testing purposes + * FIXES #10333 Indexing list-like objects by 0L in + Bridges.getConfigLine + * FIXES #10446 BridgeDB is/was using a GeoIP module which is + incompatible with virtualenvs + * FIXES #10559 BridgeDB writes `keyid=` before fingerprints + +Including the following general changes: + * ADD Numerous unittests and automated continuous integration testing. + * ADD Patches by sysrqb to correctly render right-to-left languages. + * FIXES fallback languages for translations. + * ADD Sphinx makefiles, substantial amounts of documentation. + * ADD Documentations builds (currently at + https://para.noid.cat/bridgedb) + +Changes in version 0.0.1 - 2013-08-20 +BridgeDB 0.0.1 includes fixes for the following bugs: + * FIXES #5332 Update BridgeDB documentation with deployment + instructions + * FIXES #9156 BridgeDB: Users try to add obfsbridges to their + normal TBB + These commits were added to fix a compatibility issue with + Vidalia, though they may be reverted to switch back to the old + behaviour of returning bridge lines in the form: + Bridge [transport_method] address:port [keyid=fingerprint] [K=v] […] + in order to work with torrc files and the new TBB-3.x packages + which use TorLauncher instead of Vidalia. + * PARTIAL FIX #9264 Problem with transport lines in BridgeDB's + bridge pool assignment files. + * FIXES #9425 Create and document a better BridgeDB (re)deployment + strategy + +Including the following general changes: + * UPDATE translations files with finished files from Transifex for + the strings for the newly-refactored web interface created by + gsathya. + * ADD an automatic version-numbering system as part of developing + a better deployment strategy. + * CHANGE setup.py script to automatically install Python-based + dependencies from requirements.txt. + * REMOVE MANIFEST.in and put equivalent 'include' directives into + setup.py (the less places we have for manually keeping track of + files, the better). + * REMOVE the "bridge " prefix from the lines returned on the web + interface. +

1 0

[bridgedb/master] Update social bridge distributor proposal to include terminology.
by isis＠torproject.org 04 Feb '14

04 Feb '14

commit 578abc670ad7e9576f9977d78584a2c8779184c0 Author: Isis Lovecruft <isis(a)torproject.org> Date: Tue Oct 22 02:42:18 2013 +0000 Update social bridge distributor proposal to include terminology. * ADD beginning of threat model as well. * ADD defⁿ table for constants/variable names in doc/proposal/XXX-bridgedb-social-distributor.txt. --- doc/proposals/XXX-bridgedb-social-distribution.txt | 101 ++++++++++++++++---- 1 file changed, 85 insertions(+), 16 deletions(-) diff --git a/doc/proposals/XXX-bridgedb-social-distribution.txt b/doc/proposals/XXX-bridgedb-social-distribution.txt index 199302c..538f6ae 100644 --- a/doc/proposals/XXX-bridgedb-social-distribution.txt +++ b/doc/proposals/XXX-bridgedb-social-distribution.txt @@ -16,7 +16,7 @@ Status: Open such malicious users and/or censoring entities from joining the pool of Tor clients who are able to receive distributed bridges. -* II. Motivation and Problem Scope +* II. Motivation & Problem Scope As it currently stands, Tor bridges which are stored within BridgeDB may be freely requested by any entity at nearly any time. While the openness, that @@ -69,9 +69,72 @@ Status: Open roughly 1000 bridges in the Email Distributor's pool, distributing 3 bridges per email response, -* III. Design +* III. Terminology & Notations +** III.A. Terminology Definitions + + User := A client connecting to BridgeDB in order to obtain bridges. + +** III.B. Notations + +|--------------------+---------------------------------------------------------------------------------------------| +| Symbol | Definition | +|--------------------+---------------------------------------------------------------------------------------------| +| U | A user connecting to BridgeDB in order to obtain bridges, identified by a User Credential | +| D | The bridge distributor, i.e. BridgeDB | +| Gᵐᵃˣ | Upper limit (maximum) number of bridge users for a bridge Bᵢ | +| Gˢᵗᵃʳᵗ | Number of starting users | +| Gᵃᵛᵍ | Average number of users per bridge | +| M | Fraction of users which are malicious | +| B | A bridge | +| {B₁, …, Bᵢ, …, Bₖ} | The set of bridges assigned and given to user U | +| k | The number of bridges which have been given to user U | +| Tᵐⁱⁿ | The minimum time which a bridge must remain reachable | +| Tᶜᵘʳ | The current time, given in Unix Era (UE) seconds notation (an integer, seconds since epoch) | +| Tᵐᵃˣ | The upper bound on the time for which a user U can earn coins from Bᵢ | +| τᵢ | The time when bridge Bᵢ was first given to user U | +| tᵢ | The time from when U was first given Bᵢ to either Tᶜᵘʳ or ßᵢ, whichever is greater | +| ßᵢ | The time when bridge Bᵢ was first considered blocked; if not blocked, ßᵢ = 0 | +| ϕ | Total coins owned by user U | +| φᵢ | The coins which user U has earned thus far from bridge Bᵢ | +| ϱᵢ | Rate of earning coins from bridge Bᵢ | +| λᵢ | The probability that bridge Bᵢ has been blocked | +| ω | The last time that U requested and Invite Ticket from D | +|--------------------+---------------------------------------------------------------------------------------------| + +** III.C. Unicode characters + +* III. Threat Model + + In the original rBridge scheme, there are two separate proposals: the first + does not make any attempt to hide information such as the user's (U) + identity, the list of bridges given to U, the from BridgeDBBridgeDB is + + In our modifications to the rBridge social bridge distribution scheme, + BridgeDB is considered a trusted party, that is to say, BridgeDB is + assumed to be honest in all protocols, and no protections are taken to + protect clients from malicious behaviour from BridgeDB. + +** III.A. Modifications -** III.A. Overview + + + Modification: allow BridgeDB to be a malicious actor (protecting against it + at this point is too costly, instead we want to eliminate BridgeDB's + ability to obtain a social graph for Tor bridge users.) + + +*** 1. BridgeDB is permitted to know the following information: + + + + + XXX finishme + + + +* IV. Design + +** IV.A. Overview As mentioned, most of this proposal is based upon §IV of the rBridge paper, which is the non-privacy preserving portion of the paper. [0] The @@ -88,15 +151,7 @@ Status: Open XXX finishme -** III.B. Threat Model - - Modification: allow BridgeDB to be a malicious actor (protecting against it - at this point is too costly, instead we want to eliminate BridgeDB's - ability to obtain a social graph for Tor bridge users.) - - XXX finishme - -** III.C. Data Formats +** IV.C. Data Formats *** 1. User Credential @@ -136,9 +191,9 @@ Status: Open *** XXX other formats -* IV. Databases +* V. Databases -** IV.A. Scalability Requirements +** V.A. Scalability Requirements Databases SHOULD be implemented in a manner which is ammenable to using a distributed storage system; this is necessary because certain types of data @@ -214,6 +269,13 @@ Status: Open XXX evaluation on data by calling the sha1 for a serverside Lua script [#] [#]: http://redis.io/commands/evalsha + XXX mediawiki notes and references on switching to redis + [#]: https://www.mediawiki.org/wiki/Redis + + XXX using redis as a message queue for job scheduling + [#]: http://www.restmq.com/ + + **** 2.a. Data Structures which should be stored in a RDBMS - User Credentials @@ -222,9 +284,9 @@ Status: Open - Spent Credits -* IV. Open Questions +* VI. Open Questions -** IV.A. In which component of the Tor ecosystem should the client application code go? +** VI.A. In which component of the Tor ecosystem should the client application code go? *** 1. Should this be done as a Pluggable Transport? @@ -290,3 +352,10 @@ Status: Open [6]: https://github.com/andymccurdy/redis-py/ [7]: http://www.dr-josiah.com/2012/03/why-we-didnt-use-bloom-filter.html [8]: http://redis.io/topics/data-types §"Strings" + +[#]: Naor, Moni, and Benny Pinkas. "Efficient oblivious transfer protocols." + Proceedings of the twelfth annual ACM-SIAM symposium on Discrete algorithms. + Society for Industrial and Applied Mathematics, 2001. + http://www.wisdom.weizmann.ac.il/%7Enaor/PAPERS/eotp.ps + https://gitweb.torproject.org/user/isis/bridgedb.git/tree/refs/heads/featur… +

1 0

[bridgedb/master] First cobbled together social distributor proposal
by isis＠torproject.org 04 Feb '14

04 Feb '14

commit 4e26736660fb285f8ffb8a6bb7b1c2ad58d72eed Author: Isis Lovecruft <isis(a)torproject.org> Date: Sat Oct 19 12:56:38 2013 +0000 First cobbled together social distributor proposal --- doc/proposals/XXX-bridgedb-social-distribution.txt | 292 ++++++++++++++++++++ 1 file changed, 292 insertions(+) diff --git a/doc/proposals/XXX-bridgedb-social-distribution.txt b/doc/proposals/XXX-bridgedb-social-distribution.txt new file mode 100644 index 0000000..199302c --- /dev/null +++ b/doc/proposals/XXX-bridgedb-social-distribution.txt @@ -0,0 +1,292 @@ +# -*- coding: utf-8 ; mode: org -*- + +Filename: XXX-social-bridge-distribution.txt +Title: Social Bridge Distribution +Author: Isis Agora Lovecruft +Created: 18 July 2013 +Status: Open + +* I. Overview + + This proposal specifies a system for social distribution of the + centrally-stored bridges within BridgeDB. It is primarily based upon Part + IV of the rBridge paper, [0] utilising a coin-based incentivisation scheme + to ensure that malicious users and/or censoring entities are deterred from + blocking bridges, as well as socially-distributed invite tickets to prevent + such malicious users and/or censoring entities from joining the pool of + Tor clients who are able to receive distributed bridges. + +* II. Motivation and Problem Scope + + As it currently stands, Tor bridges which are stored within BridgeDB may be + freely requested by any entity at nearly any time. While the openness, that + is to say public accessibility, of any anonymity system certainly + provisions its users with the protections of a more greatly diversified + anonymity set, the damages to usability, and the efficacy of such an + anonymity system for censorship circumvention, are devastatingly impacted + due to the equal capabilities of both a censoring/malicious entity and an + honest user to request new Tor bridges. + + Thus far, very little has been done to protect the volunteered bridges from + eventually being blocked in various regions. This severely restricts the + overall usability of Tor for clients within these regions, who, arguably, + can be even more in need of the identity protections and free speech + enablement which Tor can provide, given their political contexts. + +** II.A. Current Tor bridge distribution mechanisms and known pitfalls: + +*** 1. HTTP(S) Distributor + + At https://bridges.torproject.org, users may request new bridges, provided + that they are able to pass a CAPTCHA test. Requests through the HTTP(S) + Distributor are not allowed to be made from any current Tor exit relay, + and a hash of the user's actual IP address is used to place them within a + hash ring so that only a subset of the bridges allotted to the HTTP(S) + Distributor's pool may become known to a(n) adversary/user at that IP + address. + +**** 1.a. Known attacks/pitfalls: + + 1) An adversary with a diverse and large IP address space can easily + retrieve some significant portion of the bridges in the HTTPS + Distributor pool. + + 2) The relatively low cost of employing humans to solve CAPTCHAs is not + sufficient to deter adversaries with requisite economic resources from + doing so to obtain bridges. [XXX cost of employment] + +*** 2. Email Distributor + + Clients may send email to bridges(a)bridges.torproject.org with the line + "get bridges" in the body of the email to obtain new bridges. Such emails + must be sent from a Gmail or Yahoo! account, which is required under the + assumption that such accounts are non-trivial to obtain. + +**** 2.a. Known attacks/pitfalls: + + 1) Mechanisms for purchasing pre-registered Gmail accounts en masse + exists, charging between USD$0.25 and USD$0.70 per account. With + roughly 1000 bridges in the Email Distributor's pool, distributing 3 + bridges per email response, + +* III. Design + +** III.A. Overview + + As mentioned, most of this proposal is based upon §IV of the rBridge + paper, which is the non-privacy preserving portion of the paper. [0] The + reasons for deferring implementation of §V include: + + - Adding a simpler out-of-band distribution of bridges. Requiring users to + copy+paste Bridge lines into their torrc is ridiculous. + + - XXX + + Modifications: + + - Remove OT, keep blind signatures and Pedersen's Commitments. + + XXX finishme + +** III.B. Threat Model + + Modification: allow BridgeDB to be a malicious actor (protecting against it + at this point is too costly, instead we want to eliminate BridgeDB's + ability to obtain a social graph for Tor bridge users.) + + XXX finishme + +** III.C. Data Formats + +*** 1. User Credential + + A Credential is a signed document obtained from BridgeDB. It contains all + of the state required to verify honest client behavior, and is formatted + as a JSON object with the following format: + + { "Bridges" : [ + { "BridgeLine" : BridgeLine, + "LearnedTS" : TimeStamp, + "CreditsEarned" : INT + }, + ... + ], + "CrenditialTS" : TimeStamp, + "TotalUnspentCredits" : INT + } NL + + BridgeLine := <Bridge line from BridgeDB> + TimeStamp := INT + NumCredits := INT + + The Timestamp in this case is the time which a user first learned the + existence of that bridge. + + Example: + + {'Bridges': [ + {'BridgeLine': '1.2.3.4:6666 obfs3 adc83b19e793491b1c6ea0fd8b46cd9f32e592fc', + 'CreditsEarned': 5, + 'Timestamp': 1382078292.864117}, + {'BridgeLine': '6.6.6.6:1234 d929c82d2ee727ccbea9c50c669a71075249899f', + 'CreditsEarned': 5, + 'LearnedTS': 1382078292.864117}], + 'CredentialTS': 982398423, + 'TotalUnspentCredits': 10} + +*** XXX other formats + +* IV. Databases + +** IV.A. Scalability Requirements + + Databases SHOULD be implemented in a manner which is ammenable to using a + distributed storage system; this is necessary because certain types of data + MUST be stored permanently, such as the list of hashes of spent tokens, or + the list of hashes of used invite tickets. + + Additionally, doing so promotes modularisation the components of BridgeDB, + such that the BridgeDistributor XXX can be separated from the backend + storage system, BridgeDB. + +*** 1. Distributed Database System + + A distributed database system SHOULD be used for BridgeDB, in order to + scale resources as the number of Tor bridge users grows. This database + system, hereafter referred to as DDBS. + + The DDBS MUST be capable of working within Twisted's asynchronous + framework. If possible, a Object-Relational Mapper (ORM) SHOULD be used to + abstract the database backend's structure and query syntax from the + Twisted Python classes which interact with it, so that the type of + database may be swapped out for another with less code refactoring. + + The DDBM SHALL be used for persistent storage of complex data structures + such as the bridges, which MAY include additional information from both + the XXX @type-bridge-relay descriptors and the @type-bridge-extra-info + descriptors. + + [#]: https://github.com/couchbase/couchbase-python-client#twisted-api + +**** 1.a. Data Structures which should be stored in a DDBS: + + - RedactedDB - The Database of Blocked Bridges + + The RedactedDB will hold entries of bridges which have been discovered + to be unreachable from BridgeDB network vantage point, or have been + reported unreachable by clients. + + - + +*** 2. Relational Database Mapping Server + + For simpler data structures which must be persistently stored, such as the + list of hashes of previously seen Invite Tickets, or the list of + previously spent Tokens, a Relational Database Mapping Server (RDBMS) + SHALL be used for optimisation of queries. + + Redis and Memcached are two examples of RDBMS which are well tested and + are known to work well with Twisted. The major difference between the two + is that Memcached is volatile, while Redis supports command for + transferring objects into persistent on-disk storage. There are several + (see Twisted's MemCacheProtocol class [1] [2] or txyam [3] for Memcached, + and txredis [4] or txredisapi [5] for Redis). For non-Twisted Python Redis + APIs, there is redis-py, which provides a connection pool that could + likely be interfaced with from Twisted Python without too much + difficultly. [6] + + In order to further decrease the need for lookups in the backend + databases, Bloom Filters can used to eliminate extraneous + queries. However, this optimization would only be beneficial for string + lookups, i.e. querying for a user's credential, and SHOULD NOT be used for + queries within any of the hash lists, i.e. the list of hashes of + previously seen invite tickets. [7] It might be possible to use Redis' + GETBIT and SETBIT commands to store a Bloom Filter within a Redis cache + system; [8] doing so would offload the severe memory requirements of + loading the Bloom Filter into memory in Python when inserting new entries, + reducing the time complexity to order O(1) from some (polynomial) time + complexity that is proportional to the integral of the number of bridge + users over the rate of change of bridge users over time. + + XXX expire credentials [#] redis key datatype + [#]: http://redis.io/commands/pexpireat + + XXX evaluation on data by calling the sha1 for a serverside Lua script [#] + [#]: http://redis.io/commands/evalsha + +**** 2.a. Data Structures which should be stored in a RDBMS + + - User Credentials + + - Invite Tickets + + - Spent Credits + +* IV. Open Questions + +** IV.A. In which component of the Tor ecosystem should the client application code go? + +*** 1. Should this be done as a Pluggable Transport? + + Considerations: + +**** a. It doesn't need to modify the user's application-level traffic + + The clientside will eventually need to be able to build a circuit to the + BridgeDB backend, but it is not necessary that the clientside handle + any of the user's application level traffic. However, the clientside + system of rBridge must start when TBB (or tor) is started. + +**** b. It needs to be able to start tor. + + This is necessary because the lines: + {{{ + UseBridges 1 + Bridge [...] + }}} + must be present before tor is started; tor will not reload these + settings via SIGHUP. + +**** c. TorLaucher is not the correct place for this functionality. + + I am *not* adding this to TorLauncher. The clientside of rBridge will + eventually need to handle a lot of complicated new cryptographic + primitives, including commitments and zero-knowledge proofs. This is + dangerous enough, period, because there aren't really any libraries + for Pairing-Based Cryptography yet (though Tanya Lange has mentioned + to me that a student of theirs should have a good one finished some + time this year -- but I'm still going to count that as existing like + a unicorn). If I am to write this, I am doing it in + C/Python/Python-extensions. Not JS. + +***** c.i It could possibly launch TorLauncher + + In other words, this thing edits the torrc according to it's state, + and then either launches tor (if the user wants to use an installed + tor binary) or launches TorLauncher if we're running TBB. + +**** d. Little-t tor is not the correct place for this either. + + It might be possible, instead of (b) or (c), to add this to little-t + tor. However, I feel like the bridge distribution problem is a + separate to tor, which should be (more or less) strictly an + implementation of the onion-routing design. Additionally, I do not + wish to pile more code or maintenance upon eith Nick or Andrea, nor + do I wish to make little-t tor more monolithic. + + I talked with Nick briefly about this at the Summer 2013 Tor Dev + meeting in München, and he agreed that little-t tor isn't where this + code should go. + + +* References + +[0]: http://www-users.cs.umn.edu/~hopper/rbridge_ndss13.pdf +[1]: https://twistedmatrix.com/documents/current/api/twisted.protocols.memcache.… +[2]: http://stackoverflow.com/a/5162203 +[3]: http://findingscience.com/twisted/python/memcache/2012/06/09/txyam:-yet-ano… +[4]: https://pypi.python.org/pypi/txredis +[5]: https://github.com/fiorix/txredisapi +[6]: https://github.com/andymccurdy/redis-py/ +[7]: http://www.dr-josiah.com/2012/03/why-we-didnt-use-bloom-filter.html +[8]: http://redis.io/topics/data-types §"Strings"

1 0

[bridgedb/master] Add example extrainfo `transport` line for scramblesuit.
by isis＠torproject.org 04 Feb '14

04 Feb '14

commit 58884217ad83a4c5711e6e2c54aaa846af890e4e Author: Isis Lovecruft <isis(a)torproject.org> Date: Tue Jan 14 20:13:56 2014 +0000 Add example extrainfo `transport` line for scramblesuit. Philipp Winter's scramblesuit paper has a section on creating easily handwritable shared secrets. [0] To my memory, this excludes using the character `O` (capital o) and the integer `1`, because they are easily confused for the integer '0' and the character 'l', respectively. However, Philipp mentioned on IRC that scramblesuit `password=` fields in the `transport` line are actually just the set of base32 characters. [1] * ADD a line to doc/DESCRIPTORS.md which shows an example scramblesuit-enabled bridge which uses a shared secret passed through BridgeDB. See #9013. [0]: http://arxiv.org/abs/1305.3199 [1]: https://tools.ietf.org/html/rfc4648 --- doc/DESCRIPTORS.md | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/DESCRIPTORS.md b/doc/DESCRIPTORS.md index 8a456b7..226f368 100644 --- a/doc/DESCRIPTORS.md +++ b/doc/DESCRIPTORS.md @@ -170,6 +170,7 @@ obproxy pluggable transport types: dirreq-v3-tunneled-dl complete=12,timeout=0,running=0 transport obfs3 10.0.1.111:3333 transport obfs2 10.0.1.111:2222 + transport scramblesuit 10.0.1.111:4444 password=ABCDEFGHIJKLMNOPQRSTUVWXYZ234567 bridge-stats-end 2013-10-21 13:04:24 (86400 s) bridge-ips ca=8 bridge-ip-versions v4=8,v6=0

1 0

[bridgedb/master] Fix a typo in doc/DESCRIPTORS.md.
by isis＠torproject.org 04 Feb '14

04 Feb '14

commit ee1b3360f88f72e689f78bed8e63c141c8374050 Author: Isis Lovecruft <isis(a)torproject.org> Date: Tue Jan 14 19:56:20 2014 +0000 Fix a typo in doc/DESCRIPTORS.md. --- doc/DESCRIPTORS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/DESCRIPTORS.md b/doc/DESCRIPTORS.md index 087d4e0..8a456b7 100644 --- a/doc/DESCRIPTORS.md +++ b/doc/DESCRIPTORS.md @@ -130,7 +130,7 @@ Optionally followed by: bridge-stats-end 2013-10-21 17:28:15 (86400 s) bridge-ips de=8,nl=8,us=8 -And, if it include the `bridge-ips` line, it MAY include the following right +And, if it includes the `bridge-ips` line, it MAY include the following right afterwards: bridge-ip-versions v4=16,v6=8

1 0

[bridgedb/master] Merge branch 'master' into develop
by isis＠torproject.org 04 Feb '14

04 Feb '14

commit fe285af43012ecb3f963949ee5d3e19d4737701b Merge: 38af253 380820f Author: Isis Lovecruft <isis(a)torproject.org> Date: Sun Jan 12 05:37:20 2014 +0000 Merge branch 'master' into develop

1 0

[bridgedb/master] Comment out print()s and sys.stdout.write()s in setup.py.
by isis＠torproject.org 04 Feb '14

04 Feb '14

commit bdc23b29901f78356ec5e2d65206ae61b9f89893 Author: Isis Lovecruft <isis(a)torproject.org> Date: Sun Jan 19 19:04:38 2014 +0000 Comment out print()s and sys.stdout.write()s in setup.py. --- setup.py | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/setup.py b/setup.py index 4359fed..5ec2d79 100644 --- a/setup.py +++ b/setup.py @@ -163,7 +163,7 @@ def get_supported_langs(): for line in langsfile.readlines(): if line.startswith('supported'): line = "supported = %s\n" % supported - print("REWROTE supported langs: %s" % line) + #print("REWROTE supported langs: %s" % line) new_langs_lines.append(line) with open(repo_langs, 'w') as newlangsfile: for line in new_langs_lines: @@ -226,7 +226,7 @@ def get_data_files(filesonly=False): for ldir, lfile in zip(lang_dirs, lang_files): data_files.append((ldir, [lfile,])) - [sys.stdout.write("Added data_file '%s'\n" % x) for x in data_files] + #[sys.stdout.write("Added data_file '%s'\n" % x) for x in data_files] return data_files @@ -257,12 +257,8 @@ class runTests(setuptools.Command): sys.path = old_path -requires, deplinks = get_requirements() -print('Found requirements:') -[print('\t%s' % name) for name in requires] -print('Found dependency links:') -[print('\t%s' % uri) for uri in deplinks] +requires, deplinks = get_requirements() setuptools.setup( name='bridgedb',

1 0

[bridgedb/master] Sync bridgedb.conf with bridgedb-admin.git (no settings changed).
by isis＠torproject.org 04 Feb '14

04 Feb '14

commit 6068a5ec52c8b3177f7ad47d2dcb8f1454893e83 Author: Isis Lovecruft <isis(a)torproject.org> Date: Fri Jan 17 16:41:20 2014 +0000 Sync bridgedb.conf with bridgedb-admin.git (no settings changed). --- bridgedb.conf | 85 +++++++++++++++++++++++++++++++++++++-------------------- 1 file changed, 56 insertions(+), 29 deletions(-) diff --git a/bridgedb.conf b/bridgedb.conf index a0a1f57..bf97077 100644 --- a/bridgedb.conf +++ b/bridgedb.conf @@ -8,12 +8,34 @@ # pretend you're writing Python, and everything will be peachy keen. #______________________________________________________________________________ # -# This file is part of BridgeDB, a Tor bridge distribution system. +# Part of BridgeDB, a Tor bridge distribution system. # -# :copyright: (c) 2007-2013, The Tor Project, Inc. +# :authors: The Tor Project, Inc. +# :license: This file is freely distributed as part of BridgeDB, see LICENSE +# for details. +# :copyright: (c) 2007-2013 The Tor Project, Inc. # (c) 2007-2013, all sentient entities within the AUTHORS file -# :license: see LICENSE for licensing information -#______________________________________________________________________________ +# :version: 0.0.3 +#=============================================================================== +# +# CHANGELOG: +# ~~~~~~~~~~ +# Changes in version 0.0.3 - 2014-01-17 +# * UPDATE config from bridgedb.git/bridgedb.conf, without changing any of the +# settings. +# +# Changes in version 0.0.2 - 2014-01-17 +# * ADD missing settings, EMAIL_GPG_SIGNING_ENABLED and EMAIL_GPG_SIGNING_KEY. +# +# Changes in version 0.0.1 - 2013-08-30 +# * ADD version of config file in use on ponticum. +# - Two config variables, RECAPTCHA_PUB_KEY and RECAPTCHA_PRIV_KEY, have +# been removed, they can be found in: +# patches/001-bridgedb-conf-recaptcha-vars.patch. +# * CLEANUP the config file slightly (such as adding these headers) and +# fixing the linewraps. No other variables were touched. +# +#=============================================================================== #===========================# # General-purpose options # @@ -33,6 +55,10 @@ # can read it. #------------------------------------------------------------------------------ +# We chdir to this directory when we start; all files with relative pathnames +# are created under this directory +#RUN_IN_DIR = "/srv/bridges.torproject.org/run" + # List of filenames from which we read ``@type bridge-server-descriptor``s, on # startup and on SIGHUP. BRIDGE_FILES = ["bridge-descriptors"] @@ -62,9 +88,6 @@ HTTPS_KEY_FILE="privkey.pem" # Either a file to log to, or None if we should log to the console. LOGFILE = "bridgedb.log" -# File to which we dump bridge pool assignments for statistics. -ASSIGNMENTS_FILE = "assignments.log" - # File in which to write our pid PIDFILE = "bridgedb.pid" @@ -93,7 +116,7 @@ PROXY_LIST_FILES = [] # Be sure to also see the LOGFILE option above! #------------------------------------------------------------------------------ -# One of "DEBUG", "INFO", "WARNING", "ERROR"... +# One of "DEBUG", "INFO", "WARNING", "ERROR", or "FATAL: LOGLEVEL = "DEBUG" # If true, we scrub all potentially identifying information before we log it @@ -103,10 +126,12 @@ SAFELOGGING = True LOGFILE_COUNT = 5 LOGFILE_ROTATE_SIZE = 10000000 - # Only consider routers whose purpose matches this string. BRIDGE_PURPOSE = "bridge" +# File to which we dump bridge pool assignments for statistics. +ASSIGNMENTS_FILE = "assignments.log" + # How many clusters do we group IPs in when distributing bridges based on IP? # Note that if PROXY_LIST_FILES is set (below), what we actually do here # is use one higher than the number here, and the extra cluster is used @@ -118,7 +143,7 @@ N_IP_CLUSTERS = 4 FORCE_PORTS = [(443, 1)] # If possible, always give a certain number of answers with a given flag. -# Only "stable" is now supported. This is a list of (flag,minimum) tuples. +# Only "Stable" is now supported. This is a list of (flag,minimum) tuples. FORCE_FLAGS = [("Stable", 1)] #------------------------------- @@ -131,7 +156,7 @@ FORCE_FLAGS = [("Stable", 1)] # your SSL certificate and key! #------------------------------------------------------------------------------ -# Set to ``True`` to enable distribution via HTTP or HTTPS; False otherwise. +# (boolean) True to enable distribution via HTTP or HTTPS; False otherwise. HTTPS_DIST = True # (string or None) The IP address where we listen for HTTPS connections. If @@ -141,7 +166,7 @@ HTTPS_BIND_IP = '127.0.0.1' # (integer or None) The port to listen on for incoming HTTPS connections. HTTPS_PORT = 6789 -# How many bridges do we give back in an answer? +# How many bridges do we give back in an answer (either HTTP or HTTPS)? HTTPS_N_BRIDGES_PER_ANSWER = 3 # Should we tell http users about the bridge fingerprints? Turn this on @@ -160,14 +185,10 @@ HTTP_UNENCRYPTED_BIND_IP = None # (integer or None) The port to listen on for incoming HTTP connections. HTTP_UNENCRYPTED_PORT = None -# Same as the ``HTTPS_USE_IP_FROM_FORWARDED_HEADER`` option, but for +# (boolean) Same as the HTTPS_USE_IP_FROM_FORWARDED_HEADER option, but for # unencrypted connections. HTTP_USE_IP_FROM_FORWARDED_HEADER = False -# The number of bridges to hand out per response by the unencrypted HTTP -# distributor -HTTP_N_BRIDGES_PER_ANSWER = 3 - #------------------------------- # Email Distribution Options \ #------------------------------------------------------------------------------ @@ -181,11 +202,14 @@ HTTP_N_BRIDGES_PER_ANSWER = 3 # True if we are enabling distribution via Email; false otherwise. EMAIL_DIST = True -# What email addresses do we use for outgoing email? EMAIL_FROM_ADDR goes -# in the From: line in outgoing headers, and EMAIL_SMTP_FROM_ADDR goes in -# the MAIL FROM header in outgoing SMTP. +# What email addresses do we use for outgoing email? + +# EMAIL_FROM_ADDR goes in the 'From:' header on outgoing emails: EMAIL_FROM_ADDR = "bridges(a)torproject.org" + +# EMAIL_SMTP_FROM_ADDR goes in the 'Mail-From:' header in outgoing SMTP: EMAIL_SMTP_FROM_ADDR = "bridges(a)torproject.org" + EMAIL_SMTP_HOST = "127.0.0.1" EMAIL_SMTP_PORT = 25 @@ -196,8 +220,8 @@ EMAIL_USERNAME = "bridges" EMAIL_DOMAINS = ["gmail.com", "yahoo.com"] # Map from unofficial domain to canonical domain. -EMAIL_DOMAIN_MAP = { "mail.google.com" : "gmail.com", - "googlemail.com" : "gmail.com"} +EMAIL_DOMAIN_MAP = {"mail.google.com": "gmail.com", + "googlemail.com": "gmail.com"} # Map from canonical domain to list of options for that domain. Recognized # options are: @@ -206,19 +230,19 @@ EMAIL_DOMAIN_MAP = { "mail.google.com" : "gmail.com", # with the value "pass", then drop the message. # # Note that unrecognized options are ignored; be sure to spell them right! -EMAIL_DOMAIN_RULES = { 'gmail.com' : ["ignore_dots", "dkim"], - 'yahoo.com' : ["dkim"]} +EMAIL_DOMAIN_RULES = {'gmail.com': ["ignore_dots", "dkim"], + 'yahoo.com': ["dkim"]} # If there are any IPs in this list, only allow incoming connections from # those IPs. EMAIL_RESTRICT_IPS = [] # IP and port to listen on for email connections. Debugging only. -EMAIL_BIND_IP="127.0.0.1" -EMAIL_PORT=6725 +EMAIL_BIND_IP = "127.0.0.1" +EMAIL_PORT = 6725 # How many bridges do we give back in an answer? -EMAIL_N_BRIDGES_PER_ANSWER=3 +EMAIL_N_BRIDGES_PER_ANSWER = 3 # Should we tell http users about the bridge fingerprints? Turn this on # once we have the vidalia/tor interaction fixed for everbody. @@ -243,7 +267,8 @@ EMAIL_GPG_SIGNING_KEY = 'gnupghome/TESTING.subkeys.sec' # it stays there; there is currently no mechanism for changing a bridge's # hashring allocation. # -# The bridges are allocated to these groups with the following proportions: +# Once a bridge is assigned to either of the first two groups, it stays there +# persistently. The bridges are allocated to these groups in a proportion of # # ``HTTPS_SHARE`` : ``EMAIL_SHARE`` : ``RESERVED_SHARE`` # ------------------------------------------------------------------------------ @@ -264,7 +289,9 @@ RESERVED_SHARE = 2 # the number of bridges. FILE_BUCKETS = {} -# Options related to recaptcha support. +# Recaptcha Options +# ----------------- + # Enable/Disable recaptcha RECAPTCHA_ENABLED = False

1 0

[bridgedb/master] Add docstrings to HTTPServer.WebRoot class and render_GET() method.
by isis＠torproject.org 04 Feb '14

04 Feb '14

commit 0f2f138f16e98110ee723cf9845b49dc52345482 Author: Isis Lovecruft <isis(a)torproject.org> Date: Fri Jan 24 03:37:45 2014 +0000 Add docstrings to HTTPServer.WebRoot class and render_GET() method. --- lib/bridgedb/HTTPServer.py | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/lib/bridgedb/HTTPServer.py b/lib/bridgedb/HTTPServer.py index be5bc44..153918b 100644 --- a/lib/bridgedb/HTTPServer.py +++ b/lib/bridgedb/HTTPServer.py @@ -292,11 +292,23 @@ class WebResource(twisted.web.resource.Resource): rtl=rtl) class WebRoot(twisted.web.resource.Resource): + """The parent resource of all other documents hosted by the webserver.""" + isLeaf = True + def render_GET(self, request): + """Handles requests for the webserver root document. + + For example, this function handles requests for + https://bridges.torproject.org/. + + :type request: :api:`twisted.web.server.Request` + :param request: An incoming request. + """ rtl = usingRTLLang(request) return lookup.get_template('index.html').render(rtl=rtl) + def addWebServer(cfg, dist, sched): """Set up a web server. cfg -- a configuration object from Main. We use these options:

1 0

[bridgedb/master] Fix Sphinx directives in HTTPServer.usingRTLLang().
by isis＠torproject.org 04 Feb '14

04 Feb '14

commit f964f7e8c95258b8ec572374dce772221886ecbf Author: Isis Lovecruft <isis(a)torproject.org> Date: Fri Jan 24 03:39:30 2014 +0000 Fix Sphinx directives in HTTPServer.usingRTLLang(). --- lib/bridgedb/HTTPServer.py | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/lib/bridgedb/HTTPServer.py b/lib/bridgedb/HTTPServer.py index 153918b..ea10e0b 100644 --- a/lib/bridgedb/HTTPServer.py +++ b/lib/bridgedb/HTTPServer.py @@ -371,8 +371,7 @@ def addWebServer(cfg, dist, sched): return site def usingRTLLang(request): - """ - Check if we should translate the text into a RTL language + """Check if we should translate the text into a RTL language Retrieve the headers from the request. Obtain the Accept-Language header and decide if we need to translate the text. Install the requisite @@ -380,8 +379,11 @@ def usingRTLLang(request): support. Choose the first language from the header that we support and return True if it is a RTL language, else return False. - :param request twisted.web.server.Request: Incoming request - :returns bool: Language is right-to-left + :type request: :api:`twisted.web.server.Request` + :param request: An incoming request. + :rtype: bool + :returns: ``True`` if the preferred language is right-to-left; ``False`` + otherwise. """ langs = setLocaleFromRequestHeader(request)

1 0