This is a pre-production deployment of Warehouse, however changes made here WILL affect the production instance of PyPI.
Latest Version Dependencies status unknown Test status unknown Test coverage unknown
Project Description

BridgeDB is a collection of backend servers used to distribute Tor Bridges. Currently, it mainly consists of a webserver with an HTTPS interface, an email responder, and an SQLite database.

What are Tor Bridges?

Tor Bridges are special Tor relays which are not listed in the public relay directory. They are used to help circumvent censorship by providing users with connections to the public relays in the Tor network.

Tor Bridges are different from normal relays in another important way: they can run what are called Pluggable Transports.

What’s a Pluggable Transport?

A Pluggable Transport is a program which is pluggable — meaning that it is meant to work with lots of other anonymity and censorship circumvention software, not just Tor — and is a transport — meaning that it transports your internet traffic, usually in a way which makes it look different. For example, Obfsproxy is a Pluggable Transport which disguises your traffic by adding an obfuscating layer of encryption.

So how do I use this?

Well, probably, you don’t. But if you’re looking for bridges, you can use the web interface of the BridgeDB instance deployed by the Tor Project, which has instructions on getting the Pluggable Transports-capable Tor Browser Bundle, as well as instructions for getting extra Bridges.

Maintainer Setup

If you’d like to hack on BridgeDB, you might wish to read BridgeDB’s developer documentation. The rest of this document mainly concerns mainenance and installation instructions.

Dependencies and installation

BridgeDB requires the following OS-level dependencies:

As well as any Python dependencies in the requirements.txt file.

Deploying BridgeDB

BridgeDB should work with or without a Python virtualenv.

  • Install Python 2.7, and other OS-level dependencies. On Debian, you can do:

    sudo apt-get install build-essential openssl python python-dev \
      python-setuptools sqlite3 gnupg2 libgeoip-dev geoip-database
  • Install Pip 1.3.1 or later. Debian has this version, but if for some reason that or a newer version isn’t available, the easiest way to install a newer Pip is to use the Pip development teams’s getpip script:

    sudo python
  • (virtualenv installs only) Use Pip to install virtualenv and virtualenvwrapper:

    sudo pip install --upgrade virtualenv virtualenvwrapper
  • (virtualenv installs only) Configure virtualenvwrapper and create a virtualenv for BridgeDB:

    export WORKON_HOME
    mkdir -p $WORKON_HOME
    source $(which
    git clone && cd bridgedb
    mkvirtualenv -a $PWD -r requirements.txt --unzip-setuptools --setuptools bridgedb

    From now on, to use BridgeDB’s virtualenv, just do $ workon bridgedb (after sourcing, as before). To exit the virtualenv without exiting the shell, do $ deactivate.

  • (virtualenv installs only) To install, set PYTHONPATH to include the root directory of the virtualenv:

    export PYTHONPATH=$PYTHONPATH:${VIRTUAL_ENV}/lib/python2.7/site-packages
  • Then, proceed as usual:

    python install --record installed-files.txt

Enabling additional features


Using New Translations:

This should be done when newly completed translations are available in Transifex.

Piece of cake. Running maint/get-completed-translations will take care of cloning only the bridgedb_completed branch of Tor’s translations repo and placing all the updated files in their correct locations.

Requesting Translations for Altered/Added Source Code:

This should be done whenever any of the strings requiring translation – _("the ones inside the weird underscore function, like this") – are changed, or new ones are added. See lib/bridgedb/

Translations for Tor Project repos are kept in a separate repo. You’ll need to extract the strings from BridgeDB’s source code into .pot templates, and place these .po files into the translation repo in the bridgedb branch. After than the .po files should be put into Transifex (don’t ask me how this works…) and translated. After the translations are complete, the finished .po files should be placed into the bridgedb_completed branch.

  • To extract all strings from BridgeDB’s source:

    python extract_messages

    A .pot file will be created in ./i18n/templates/bridgedb.pot

  • Initialise catalogs for each desired language:

    python init_catalog -l LANG

    where LANG is the 2 or 4 letter country-code, eg. ‘es’. If you’ve already initialised a particular language, do instead:

    python update_catalog

Enabling HTTPS

Create a self-signed certificate with:


Or, place an existing certificate in the path specified in bridgedb.conf by the HTTPS_CERT_FILE option, and a private key where HTTPS_KEY_FILE points to. The defaults are ‘cert’ and ‘privkey.pem’, respectively.

Enabling CAPTCHA Support

BridgeDB has two ways to use CAPTCHAs on webpages. The first uses reCaptcha, an external Google service (this requires an account with them), which BridgeDB fetches the CAPTCHAs images from for each incoming request from a client. The second method uses a local cache of pre-made CAPTCHAs, created by scripting Gimp using gimp-captcha. The latter cannot easily be run on headless server, unfortunately, because Gimp requires an X server to be installed.


To enable fetching CAPTCHAs from the reCaptcha API server, set these options in bridgedb.conf:



To enable using a local cache of CAPTCHAs, set the following options:


GnuPG email signing:

In your bridgedb.conf file, make sure that:


and edit the following option to add the full fingerprint of the GnuPG key that should be used to by BridgeDB to sign outgoing emails:


The key specified by EMAIL_GPG_PRIMARY_KEY_FINGERPRINT can be a master key, or a subkey (with or without the private portions of its corresponding master key), but it must be inside the secring.gpg and pubring.gpg keyrings inside the directory specified in the bridgedb.conf option:


If the key has requires a passphrase for signing, you’ll also need to set either of:


Preventing already-blocked bridges from being distributed:

Uncomment or add COUNTRY_BLOCK_FILE to your bridgedb.conf. This file should contain one bridge entry per line, in the format:

fingerprint <bridge fingerprint> country-code <country code>

If the COUNTRY_BLOCK_FILE file is present, bridgedb will filter blocked bridges from the responses it gives to clients requesting bridges.

Testing BridgeDB

Before running to any of BridgeDB’s test suites, make sure you have the additional dependencies in the Pip requirements file, .test.requirements.txt installed:

pip install -r .test.requirements.txt

To create a bunch of fake bridge descriptors to test BridgeDB, do:

bridgedb mock [-n NUMBER_OF_DESCRIPTORS]

Note that you will need to install leekspin in order to run the bridgedb mock command. See doc/ for details.

And finally, to run the test suites, do:

make coverage

If you just want to run the tests, and don’t care about code coverage statistics, see the bridgedb trial and bridgedb test commands.

Running BridgeDB

To run BridgeDB, simply make any necessary changes to bridgedb.conf, and do:


And remember that all files/directories in bridgedb.conf are assumed relative to the runtime directory. By default, BridgeDB uses the current working directory; you can, however specify an a different runtime directory:

bridgedb -r /srv/

Make sure that the files and directories referred to in bridgedb.conf exist. However, many of them, if not found, will be touched on disk so that attempts to read/write from/to them will not raise excessive errors.

Reloading Bridges From Their Descriptor Files:

When you have new lists of bridges from the Bridge Authority, replace the old files and do:

bridgedb --reload

Or just give it a SIGHUP:

kill -s SIGHUP `cat .../run/`

To extract bucket files of all unallocated bridges:

Edit the configuration file value FILE_BUCKETS according to your needs. For example, the following is a possible configuration:

FILE_BUCKETS = { "name1": 10, "name2": 15, "foobar": 3 }

This configuration for buckets would result in 3 files being created for bridge distribution: name1-2010-07-17.brdgs, name2-2010-07-17.brdgs and foobar-2010-07-17.brdgs. The first file would contain 10 bridges from BridgeDB’s ‘unallocated’ pool. The second file would contain 15 bridges from the same pool and the third one similarly 3 bridges. These files can then be handed out to trusted parties via mail or fed to other distribution mechanisms such as Twitter.

To dump all buckets to their files, send BridgeDB a SIGUSR1 signal by doing:

kill -s SIGUSR1 `cat .../run/`

Using a BridgeDB Instance

Obviously, you’ll have to feed it bridge descriptor files from a BridgeAuthority. There’s currently only one BridgeAuthority in the entire world, but Tor Project is, of course, very interested in adding support for multiple BridgeAuthorities so that we can scale our own network, and make it easier for individual and organisations who wish to run a lot of Tor bridge relays have an easier time distributing those bridges themselves (if they wish to do so). If you’d like to fund our work on this, please contact!

Accessing the HTTPS User Interface

Just connect to the appropriate port. (See the HTTPS_PORT and HTTP_UNENCRYPTED_PORT options in the bridgedb.conf file.)

The HTTPS interface for our BridgeDB instance can be found here.

Accessing the Email User Interface

Any mail sent to the EMAIL_PORT with a destination username as defined by the EMAIL_USERNAME configuration option (the default is 'bridge', e.g. bridges@…) and sent from an,, or address (by default, but configurable with the EMAIL_DOMAINS option).

You can email our BridgeDB instance here.

Contact & Support

Send your questions, patches, and suggestions to the tor-dev mailing list or isis.

Release History

Release History


This version

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More


History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More


History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

Download Files

Download Files

TODO: Brief introduction on what you do with files - including link to relevant help section.

File Name & Checksum SHA256 Checksum Help Version File Type Upload Date
bridgedb-0.3.6-py2.7.egg (1.0 MB) Copy SHA256 Checksum SHA256 2.7 Egg Jul 29, 2016
bridgedb-0.3.6.tar.gz (277.5 kB) Copy SHA256 Checksum SHA256 Source Jul 29, 2016 (328.9 kB) Copy SHA256 Checksum SHA256 Source Jul 29, 2016

Supported By

WebFaction WebFaction Technical Writing Elastic Elastic Search Pingdom Pingdom Monitoring Dyn Dyn DNS HPE HPE Development Sentry Sentry Error Logging CloudAMQP CloudAMQP RabbitMQ Heroku Heroku PaaS Kabu Creative Kabu Creative UX & Design Fastly Fastly CDN DigiCert DigiCert EV Certificate Rackspace Rackspace Cloud Servers DreamHost DreamHost Log Hosting