- tor-commits - lists.torproject.org

r24603: {website} bump the tor version for website builds. (website/trunk)
by Andrew Lewman 13 Apr '11

13 Apr '11

Author: phobos Date: 2011-04-13 02:09:32 +0000 (Wed, 13 Apr 2011) New Revision: 24603 Modified: website/trunk/Makefile Log: bump the tor version for website builds. Modified: website/trunk/Makefile =================================================================== --- website/trunk/Makefile 2011-04-13 01:43:57 UTC (rev 24602) +++ website/trunk/Makefile 2011-04-13 02:09:32 UTC (rev 24603) @@ -11,8 +11,8 @@ # 5. ./publish export TORGIT=/home/runa/dev/tor/.git -export STABLETAG=tor-0.2.2.23-alpha -export DEVTAG=tor-0.2.2.23-alpha +export STABLETAG=tor-0.2.2.24-alpha +export DEVTAG=tor-0.2.2.24-alpha WMLBASE=. SUBDIRS=docs eff projects press about download getinvolved donate torbutton

1 0

r24602: {website} it is time for the new tor 0.2.2.24-alpha and vidalia 0.2.12 (website/trunk/include)
by Erinn Clark 13 Apr '11

13 Apr '11

Author: erinn Date: 2011-04-13 01:43:57 +0000 (Wed, 13 Apr 2011) New Revision: 24602 Modified: website/trunk/include/versions.wmi Log: it is time for the new tor 0.2.2.24-alpha and vidalia 0.2.12 releases Modified: website/trunk/include/versions.wmi =================================================================== --- website/trunk/include/versions.wmi 2011-04-12 18:15:12 UTC (rev 24601) +++ website/trunk/include/versions.wmi 2011-04-13 01:43:57 UTC (rev 24602) @@ -1,25 +1,25 @@ <define-tag version-stable whitespace=delete>0.2.1.30</define-tag> -<define-tag version-alpha whitespace=delete>0.2.2.23-alpha</define-tag> +<define-tag version-alpha whitespace=delete>0.2.2.24-alpha</define-tag> <define-tag version-win32-stable whitespace=delete>0.2.1.30</define-tag> -<define-tag version-win32-alpha whitespace=delete>0.2.2.23-alpha</define-tag> +<define-tag version-win32-alpha whitespace=delete>0.2.2.24-alpha</define-tag> <define-tag version-win32-bundle-stable whitespace=delete>0.2.1.30</define-tag> -<define-tag version-win32-bundle-alpha whitespace=delete>0.2.2.23-alpha</define-tag> +<define-tag version-win32-bundle-alpha whitespace=delete>0.2.2.24-alpha</define-tag> <define-tag version-osx-x86-bundle-stable whitespace=delete>0.2.1.30</define-tag> -<define-tag version-osx-x86-bundle-alpha whitespace=delete>0.2.2.23-alpha</define-tag> +<define-tag version-osx-x86-bundle-alpha whitespace=delete>0.2.2.24-alpha</define-tag> <define-tag version-osx-ppc-bundle-stable whitespace=delete>0.2.1.30</define-tag> -<define-tag version-osx-ppc-bundle-alpha whitespace=delete>0.2.2.23-alpha</define-tag> +<define-tag version-osx-ppc-bundle-alpha whitespace=delete>0.2.2.24-alpha</define-tag> <define-tag version-osx-x86-stable whitespace=delete>0.2.1.30</define-tag> -<define-tag version-osx-x86-alpha whitespace=delete>0.2.2.23-alpha</define-tag> +<define-tag version-osx-x86-alpha whitespace=delete>0.2.2.24-alpha</define-tag> <define-tag version-osx-ppc-stable whitespace=delete>0.2.1.30</define-tag> -<define-tag version-osx-ppc-alpha whitespace=delete>0.2.2.23-alpha</define-tag> +<define-tag version-osx-ppc-alpha whitespace=delete>0.2.2.24-alpha</define-tag> -<define-tag version-torbrowserbundle whitespace=delete>1.3.21</define-tag> +<define-tag version-torbrowserbundle whitespace=delete>1.3.22</define-tag> <define-tag version-torbrowser-tor whitespace=delete>0.2.1.30</define-tag> <define-tag version-torbrowser-tor-components whitespace=delete>libevent-1.4.13, zlib-1.2.3, openssl-0.9.8p</define-tag> <define-tag version-torbrowser-firefox whitespace=delete>3.6.16</define-tag> @@ -27,25 +27,25 @@ <define-tag version-torbrowser-polipo whitespace=delete>1.0.4.1</define-tag> <define-tag version-torbrowser-pidgin whitespace=delete>2.7.5</define-tag> <define-tag version-torbrowser-otr whitespace=delete>3.2</define-tag> -<define-tag version-torbrowser-vidalia whitespace=delete>0.2.10</define-tag> +<define-tag version-torbrowser-vidalia whitespace=delete>0.2.12</define-tag> <define-tag version-torimbrowserbundle whitespace=delete>1.3.21</define-tag> -<define-tag version-torbrowserbundlelinux32 whitespace=delete>1.1.6</define-tag> -<define-tag version-torbrowserbundlelinux64 whitespace=delete>1.1.6</define-tag> -<define-tag version-gnu-torbrowser-tor whitespace=delete>0.2.2.23-alpha</define-tag> +<define-tag version-torbrowserbundlelinux32 whitespace=delete>1.1.7</define-tag> +<define-tag version-torbrowserbundlelinux64 whitespace=delete>1.1.</define-tag> +<define-tag version-gnu-torbrowser-tor whitespace=delete>0.2.2.24-alpha</define-tag> <define-tag version-gnu-torbrowser-tor-components whitespace=delete>libevent-2.0.10, zlib-1.2.3, openssl-0.9.8p</define-tag> <define-tag version-gnu-torbrowser-firefox whitespace=delete>3.6.16</define-tag> <define-tag version-gnu-torbrowser-torbutton whitespace=delete>1.2.5</define-tag> -<define-tag version-gnu-torbrowser-vidalia whitespace=delete>0.2.10</define-tag> +<define-tag version-gnu-torbrowser-vidalia whitespace=delete>0.2.12</define-tag> -<define-tag version-torbrowserbundleosx whitespace=delete>1.0.14</define-tag> -<define-tag version-osx-torbrowser-tor whitespace=delete>0.2.2.23-alpha</define-tag> +<define-tag version-torbrowserbundleosx whitespace=delete>1.0.15</define-tag> +<define-tag version-osx-torbrowser-tor whitespace=delete>0.2.2.24-alpha</define-tag> <define-tag version-osx-torbrowser-firefox whitespace=delete>3.6.16</define-tag> <define-tag version-osx-torbrowser-torbutton whitespace=delete>1.2.5</define-tag> <define-tag version-osx-torbrowser-polipo whitespace=delete>1.0.4.1</define-tag> -<define-tag version-osx-torbrowser-vidalia whitespace=delete>0.2.10</define-tag> +<define-tag version-osx-torbrowser-vidalia whitespace=delete>0.2.12</define-tag> -<define-tag version-vidalia-stable whitespace=delete>0.2.10</define-tag> +<define-tag version-vidalia-stable whitespace=delete>0.2.12</define-tag> <define-tag version-androidbundle-tor whitespace=delete>0.2.2.22-alpha</define-tag> <define-tag version-androidbundle-orbot whitespace=delete>1.0.4.1</define-tag> @@ -61,13 +61,13 @@ <define-tag file-win32-bundle-alpha whitespace=delete>vidalia-bundle-<version-win32-bundle-alpha>-0.2.10.exe</define-tag> <define-tag package-win32-bundle-alpha whitespace=delete>/dist/vidalia-bundles/<file-win32-bundle-alpha></define-tag> -<define-tag file-osx-x86-bundle-stable whitespace=delete>vidalia-bundle-<version-osx-x86-bundle-stable>-0.2.10-i386.dmg</define-tag> +<define-tag file-osx-x86-bundle-stable whitespace=delete>vidalia-bundle-<version-osx-x86-bundle-stable>-0.2.12-i386.dmg</define-tag> <define-tag package-osx-x86-bundle-stable whitespace=delete>/dist/vidalia-bundles/<file-osx-x86-bundle-stable></define-tag> -<define-tag file-osx-x86-bundle-alpha whitespace=delete>vidalia-bundle-<version-osx-x86-bundle-alpha>-0.2.10-i386.dmg</define-tag> +<define-tag file-osx-x86-bundle-alpha whitespace=delete>vidalia-bundle-<version-osx-x86-bundle-alpha>-0.2.12-i386.dmg</define-tag> <define-tag package-osx-x86-bundle-alpha whitespace=delete>/dist/vidalia-bundles/<file-osx-x86-bundle-alpha></define-tag> -<define-tag package-osx-ppc-bundle-stable whitespace=delete>/dist/vidalia-bundles/vidalia-bundle-<version-osx-ppc-bundle-stable>-0.2.10-ppc.dmg</define-tag> -<define-tag package-osx-ppc-bundle-alpha whitespace=delete>/dist/vidalia-bundles/vidalia-bundle-<version-osx-ppc-bundle-alpha>-0.2.10-ppc.dmg</define-tag> +<define-tag package-osx-ppc-bundle-stable whitespace=delete>/dist/vidalia-bundles/vidalia-bundle-<version-osx-ppc-bundle-stable>-0.2.12-ppc.dmg</define-tag> +<define-tag package-osx-ppc-bundle-alpha whitespace=delete>/dist/vidalia-bundles/vidalia-bundle-<version-osx-ppc-bundle-alpha>-0.2.12-ppc.dmg</define-tag> <define-tag package-osx-x86-stable whitespace=delete>/dist/osx-x86/Tor-<version-osx-stable>-i386-Bundle.dmg</define-tag> <define-tag package-osx-x86-alpha whitespace=delete>/dist/osx-x86/Tor-<version-osx-alpha>-i386-Bundle.dmg</define-tag>

1 0

[vidalia/master] Bump development version to 0.2.13-git
by chiiph＠torproject.org 13 Apr '11

13 Apr '11

commit dc1e6b513b3c83c153b6c7228e47ab2358bfc621 Author: Tomas Touceda <chiiph(a)gentoo.org> Date: Sun Apr 10 20:49:24 2011 -0300 Bump development version to 0.2.13-git --- CMakeLists.txt | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index 03c6b5f..b580959 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -13,8 +13,8 @@ set(VER_MAJOR "0") set(VER_MINOR "2") -set(VER_PATCH "12") -set(VERSION "${VER_MAJOR}.${VER_MINOR}.${VER_PATCH}") +set(VER_PATCH "13") +set(VERSION "${VER_MAJOR}.${VER_MINOR}.${VER_PATCH}-git") message(STATUS "Configuring Vidalia ${VERSION}") project(Vidalia)

1 0

[bridgedb/master] Finish first draft of bridge-db-spec.txt.
by karsten＠torproject.org 12 Apr '11

12 Apr '11

commit 9d7dad7f97a05eba479c7a84a10e6663c79205ee Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Mon Feb 14 14:52:21 2011 +0100 Finish first draft of bridge-db-spec.txt. --- bridge-db-spec.txt | 245 ++++++++++++++++++++++++++++++++++++---------------- 1 files changed, 171 insertions(+), 74 deletions(-) diff --git a/bridge-db-spec.txt b/bridge-db-spec.txt index a9e2c8f..5c8ca57 100644 --- a/bridge-db-spec.txt +++ b/bridge-db-spec.txt @@ -5,98 +5,168 @@ This document specifies how BridgeDB processes bridge descriptor files to learn about new bridges, maintains persistent assignments of bridges - to distributors, and decides which descriptors to give out upon user + to distributors, and decides which bridges to give out upon user requests. 1. Importing bridge network statuses and bridge descriptors BridgeDB learns about bridges from parsing bridge network statuses and - bridge descriptors as specified in Tor's directory protocol. BridgeDB - SHOULD parse one bridge network status file and at least one bridge - descriptor file. + bridge descriptors as specified in Tor's directory protocol. + BridgeDB SHOULD parse one bridge network status file first and at least + one bridge descriptor file afterwards. 1.1. Parsing bridge network statuses Bridge network status documents contain the information which bridges - are known to the bridge authority at a certain time. We expect bridge - network statuses to contain at least the following two lines for every - bridge in the given order: - - "r" SP nickname SP identity SP digest SP publication SP IP SP ORPort SP - DirPort NL - "s" SP Flags NL - - BridgeDB parses the identity from the "r" line and scans the "s" line - for flags Stable and Running. BridgeDB MUST discard all bridges that - do not have the Running flag. BridgeDB MAY only consider bridges as - running that have the Running flag in the most recently parsed bridge - network status. BridgeDB MUST also discard all bridges for which it - does not find a bridge descriptor. BridgeDB memorizes all remaining - bridges as the set of running bridges that can be given out to bridge - users. -# I'm not 100% sure if BridgeDB discards (or rather doesn't use) bridges -# for which it doesn't have a bridge descriptor. But as far as I can see, -# it wouldn't learn the bridge's IP and OR port in that case, so we -# shouldn't use it. Is this a bug? -KL -# What's the reason for parsing bridge descriptors anyway? Can't we learn -# a bridge's IP address and OR port from the "r" line, too? -KL + are known to the bridge authority and which flags the bridge authority + assigns to them. + We expect bridge network statuses to contain at least the following two + lines for every bridge in the given order: + + "r" SP nickname SP identity SP digest SP publication SP IP SP ORPort + SP DirPort NL + "s" SP Flags NL + + BridgeDB parses the identity from the "r" line and the assigned flags + from the "s" line. + BridgeDB MUST discard all bridges that do not have the Running flag. + BridgeDB memorizes all remaining bridges as the set of running bridges + that can be given out to bridge users. + BridgeDB SHOULD memorize assigned flags if it wants to ensure that sets + of bridges given out SHOULD contain at least a given number of bridges + with these flags. 1.2. Parsing bridge descriptors BridgeDB learns about a bridge's most recent IP address and OR port - from parsing bridge descriptors. Bridge descriptor files MAY contain - one or more bridge descriptors. We expect bridge descriptor to contain - at least the following lines in the stated order: - - "@purpose" SP purpose NL - "router" SP nickname SP IP SP ORPort SP SOCKSPort SP DirPort NL - ["opt "] "fingerprint" SP fingerprint NL - - BridgeDB parses the purpose, IP, ORPort, and fingerprint. BridgeDB - MUST discard bridge descriptors if the fingerprint is not contained in - the bridge network status(es) parsed in the same execution or if the - bridge does not have the Running flag. BridgeDB MAY discard bridge - descriptors which have a different purpose than "bridge". BridgeDB - memorizes the IP addresses and OR ports of the remaining bridges. If - there is more than one bridge descriptor with the same fingerprint, + from parsing bridge descriptors. + Bridge descriptor files MAY contain one or more bridge descriptors. + We expect bridge descriptor to contain at least the following lines in + the stated order: + + "@purpose" SP purpose NL + "router" SP nickname SP IP SP ORPort SP SOCKSPort SP DirPort NL + ["opt" SP] "fingerprint" SP fingerprint NL + + BridgeDB parses the purpose, IP, ORPort, and fingerprint from these + lines. + BridgeDB MUST discard bridge descriptors if the fingerprint is not + contained in the bridge network status parsed before or if the bridge + does not have the Running flag. + BridgeDB MAY discard bridge descriptors which have a different purpose + than "bridge". + BridgeDB memorizes the IP addresses and OR ports of the remaining + bridges. + If there is more than one bridge descriptor with the same fingerprint, BridgeDB memorizes the IP address and OR port of the most recently parsed bridge descriptor. -# I think that BridgeDB simply assumes that descriptors in the bridge -# descriptor files are in chronological order. If not, it would overwrite -# a bridge's IP address and OR port with an older descriptor, which would -# be bad. The current cached-descriptors* files should write descriptors -# in chronological order. But we might change that, e.g., when trying to -# limit the number of descriptors in Tor. Should we make the assumption -# that descriptors are ordered chronologically, or should we specify that -# we have to check that explicitly? -KL +# I confirmed that BridgeDB simply assumes that descriptors in the bridge +# descriptor files are in chronological order and that descriptors in +# cached-descriptors.new are newer than those in cached-descriptors. If +# this is not the case, BridgeDB overwrites a bridge's IP address and OR +# port with those from an older descriptor! I think that the current +# cached-descriptors* files that Tor produces always have descriptors in +# chronological order. But what if we change that, e.g., when trying to +# limit the number of descriptors that Tor memorizes. Should we make the +# assumption that descriptors are ordered chronologically, or should we +# specify that we have to check that explicitly and fix BridgeDB to do +# that? We could also look at the bridge descriptor that is referenced +# from the bridge network status by its descriptor identifier, even though +# that would require us to calculate the descriptor hash. -KL + If BridgeDB does not find a bridge descriptor for a bridge contained in + the bridge network status parsed before, it MUST discard that bridge. +# I confirmed that BridgeDB discards (or at least doesn't use) bridges for +# which it doesn't have a bridge descriptor. What's the reason for +# parsing bridge descriptors anyway? Can't we learn a bridge's IP address +# and OR port from the "r" line, too? -KL 2. Assigning bridges to distributors -# In this section I'm planning to write how BridgeDB should decide to -# which distributor (https, email, unallocated/file bucket) it assigns a -# new bridge. I should also write down whether BridgeDB changes -# assignments of already known bridges (I think it doesn't). The latter -# includes cases when we increase/reduce the probability of bridges being -# assigned to a distributor or even turn off a distributor completely. -# -KL - -3. Selecting bridges to be given out via https - -# This section is about the specifics of the https distributor, like which -# IP addresses get bridges from the same ring, how often the results -# change, etc. -KL - -4. Selecting bridges to be given out via email - -# This section is about the specifics of the email distributor, like which -# characters do we recognize in email addresses, how long we don't give -# out new bridges to the same email address, etc. -KL - -5. Selecting unallocated bridges to be stored in file buckets - -# This section is about kaner's bucket mechanism. I want to cover how -# BridgeDB decides which of the unallocated bridges to add to a file -# bucket. -KL + BridgeDB assigns bridges to distributors on a probabilistic basis and + makes these assignments persistent. + BridgeDB MAY be configured to support only a non-empty subset of the + distributors specified in this document. + BridgeDB MAY define different probabilities for assigning new bridges + to distributors. + BridgeDB MUST NOT change existing assignments of bridges to + distributors, even if probabilities for assigning bridges to + distributors change or distributors are disabled entirely. + +3. Giving out bridges upon requests + + BridgeDB gives out a subset of the bridges from a given distributor + upon request. + BridgeDB MUST only give out bridges that are contained in the most + recently parsed bridge network status and that have the Running flag + set. + BridgeDB MAY define a different number of bridges (typically 3) to be + given out depending on the distributor. + BridgeDB MAY define an arbitrary number of rules saying that a certain + number of bridges SHOULD have a given OR port or a given bridge relay + flag. + +4. Selecting bridges to be given out based on IP addresses + + BridgeDB MAY support one or more distributors that are giving out + bridges based on the requestor's IP address. + BridgeDB MUST fix the set of bridges to be returned for a defined time + period. + BridgeDB SHOULD consider two IP addresses coming from the same /24 as + the same IP address and return the same set of bridges. + BridgeDB SHOULD divide the IP address space equally into a small number + of areas (typically 4) and return different results to requests coming + from these areas. +# I found that BridgeDB is not strict in returning only bridges for a +# given area. If a ring is empty, it considers the next one. Therefore, +# it's SHOULD in the sentence above and not MUST. Is this expected +# behavior? -KL +# I also found that BridgeDB does not make the assignment to areas +# persistent in the database. So, if we change the number of rings, it +# will assign bridges to other rings. I assume this is okay? -KL + BridgeDB SHOULD be able to respect a list of proxy IP addresses and + return the same set of bridges to requests coming from these IP + addresses. + The bridges returned to proxy IP addresses SHOULD NOT come from the + same set as those for the general IP address space. + BridgeDB MAY include bridge fingerprints in replies along with bridge + IP addresses and OR ports. + +5. Selecting bridges to be given out based on email addresses + + BridgeDB MAY support one or more distributors that are giving out + bridges based on the requestor's email address. + BridgeDB SHOULD reject email addresses containing other characters than + the ones that RFC2822 allows. + BridgeDB MAY reject email addresses containing other characters it + might not process correctly. + BridgeDB MUST reject email addresses coming from other domains than a + configured set of permitted domains. + BridgeDB MAY normalize email addresses by removing "." characters and + by removing parts after the first "+" character. + BridgeDB MAY discard requests that do not have the value "pass" in + their X-DKIM-Authentication-Result header or does not have this header. + BridgeDB SHOULD NOT return a new set of bridges to the same email + address until a given time period (typically a few hours) has passed. +# Why don't we fix the bridges we give out for a global 3-hour time period +# like we do for IP addresses? This way we could avoid storing email +# addresses. -KL + BridgeDB MAY include bridge fingerprints in replies along with bridge + IP addresses and OR ports. + +6. Selecting unallocated bridges to be stored in file buckets + + BridgeDB MAY reserve a subset of bridges and not give them out via one + of the distributors. + BridgeDB MAY assign reserved bridges to one or more file buckets of + fixed sizes and write these file buckets to disk for manual + distribution. + BridgeDB SHOULD ensure that a file bucket always contains the requested + number of running bridges. + If the requested number of bridges in a file bucket is reduced or the + file bucket is not required anymore, the unassigned bridges are + returned to the reserved set of bridges. + If a bridge stops running, BridgeDB SHOULD replace it with another + bridge from the reserved set of bridges. # I'm not sure if there's a design bug in file buckets. What happens if # we add a bridge X to file bucket A, and X goes offline? We would add # another bridge Y to file bucket A. OK, but what if A comes back? We @@ -104,3 +174,30 @@ # add it to a different file bucket? Doesn't that mean that most bridges # will be contained in most file buckets over time? -KL +7. Writing bridge assignments for statistics + + BridgeDB MAY write bridge assignments to disk for statistical analysis. + The start of a bridge assignment is marked by the following line: + + "bridge-pool-assignment" SP YYYY-MM-DD HH:MM:SS NL + + YYYY-MM-DD HH:MM:SS is the time, in UTC, when BridgeDB has completed + loading new bridges and assigning them to distributors. + + For every running bridge there is a line with the following format: + + fingerprint SP distributor (SP key "=" value)* NL + + The distributor is one out of "email", "https", or "unallocated". + + Both "email" and "https" distributors support adding keys for "port" + and "flag" and the port number and flag name as values to indicate that + a bridge matches certain port or flag criteria of requests. + + The "https" distributor also allows the key "ring" with a number as + value to indicate to which IP address areas the bridge is returned. + + The "unallocated" distributor allows the key "bucket" with the file + bucket name as value to indicate which file bucket a bridge is assigned + to. +

1 0

[bridgedb/master] Respond to Nick's comments.
by karsten＠torproject.org 12 Apr '11

12 Apr '11

commit e3b46883f593271829787f42d123d9fc3bc13f33 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Apr 12 10:19:18 2011 +0200 Respond to Nick's comments. --- bridge-db-spec.txt | 82 +++++++++++++++++----------------------------------- 1 files changed, 27 insertions(+), 55 deletions(-) diff --git a/bridge-db-spec.txt b/bridge-db-spec.txt index 48a9590..89f0e5c 100644 --- a/bridge-db-spec.txt +++ b/bridge-db-spec.txt @@ -41,15 +41,8 @@ BridgeDB parses the identity from the "r" line and the assigned flags from the "s" line. - BridgeDB MUST discard all bridges that do not have the Running flag. -# I don't think that "discard" is the right word here: we don't actually -# seem to "Forget they exist". Instead, we remember that they are not -# running. (See how parseStatusFile yields a flag that says if the bridges -# are running, and how Main.load sets the bridge's status to running or -# non-running appropriately before passing it to splitter. At no point here -# does a non-running bridge get "discarded", sfaict). -NM - BridgeDB memorizes all remaining bridges as the set of running bridges - that can be given out to bridge users. + BridgeDB memorizes all bridges that have the Running flag as the set of + running bridges that can be given out to bridge users. BridgeDB SHOULD memorize assigned flags if it wants to ensure that sets of bridges given out SHOULD contain at least a given number of bridges with these flags. @@ -58,6 +51,12 @@ BridgeDB learns about a bridge's most recent IP address and OR port from parsing bridge descriptors. + In theory, both IP address and OR port of a bridge are also contained + in the "r" line of the bridge network status, so there is no mandatory + reason for parsing bridge descriptors. But this functionality is still + implemented in case we need information from the bridge descriptor in + the future. + Bridge descriptor files MAY contain one or more bridge descriptors. We expect bridge descriptor to contain at least the following lines in the stated order: @@ -68,45 +67,20 @@ BridgeDB parses the purpose, IP, ORPort, and fingerprint from these lines. - BridgeDB MUST discard bridge descriptors if the fingerprint is not - contained in the bridge network status parsed before or if the bridge - does not have the Running flag. -# See comment above -NM - BridgeDB MAY discard bridge descriptors which have a different purpose - than "bridge". -# "MAY" isn't good enough; we need to know whether it's safe to give -# bridgedb a list of non-bridge-purpose descriptors or not. If it -# discards them, then you shouldn't give bridgedb non-bridge descriptors -# if you _do_ want them handed out. If it doesn't discard them, then you -# shouldn't give bridgedb non-bridge descriptors _unless_ you want them -# handed out. + BridgeDB skips bridge descriptors if the fingerprint is not contained + in the bridge network status parsed before or if the bridge does not + have the Running flag. + BridgeDB discards bridge descriptors which have a different purpose + than "bridge". BridgeDB can be configured to only accept descriptors + with another purpose or not discard descriptors based on purpose at + all. BridgeDB memorizes the IP addresses and OR ports of the remaining bridges. If there is more than one bridge descriptor with the same fingerprint, BridgeDB memorizes the IP address and OR port of the most recently parsed bridge descriptor. -# I confirmed that BridgeDB simply assumes that descriptors in the bridge -# descriptor files are in chronological order and that descriptors in -# cached-descriptors.new are newer than those in cached-descriptors. If -# this is not the case, BridgeDB overwrites a bridge's IP address and OR -# port with those from an older descriptor! I think that the current -# cached-descriptors* files that Tor produces always have descriptors in -# chronological order. But what if we change that, e.g., when trying to -# limit the number of descriptors that Tor memorizes. Should we make the -# assumption that descriptors are ordered chronologically, or should we -# specify that we have to check that explicitly and fix BridgeDB to do -# that? We could also look at the bridge descriptor that is referenced -# from the bridge network status by its descriptor identifier, even though -# that would require us to calculate the descriptor hash. -KL -# We should just look at the 'published' dates in the bridges. Call this a bug, -# I'd say. -NM If BridgeDB does not find a bridge descriptor for a bridge contained in the bridge network status parsed before, it MUST discard that bridge. -# I confirmed that BridgeDB discards (or at least doesn't use) bridges for -# which it doesn't have a bridge descriptor. What's the reason for -# parsing bridge descriptors anyway? Can't we learn a bridge's IP address -# and OR port from the "r" line, too? -KL -# I forget. -NM 2. Assigning bridges to distributors @@ -114,22 +88,19 @@ given) to clients. The current distributors are "email", "https", and "unallocated". - BridgeDB assigns bridges to distributors on a probabilistic basis and - makes these assignments persistent. -# Not exactly probabilistic: it's based on an HMAC hash of the bridge's ID -# and a secret. -NM - Persistence is achieved by using a database to map node ID to distributor. + BridgeDB assigns bridges to distributors based on an HMAC hash of the + bridge's ID and a secret and makes these assignments persistent. + Persistence is achieved by using a database to map node ID to + distributor. Each bridge is assigned to exactly one distributor (including the "unallocated" distributor). BridgeDB MAY be configured to support only a non-empty subset of the distributors specified in this document. BridgeDB MAY define different probabilities for assigning new bridges to distributors. - BridgeDB MUST NOT change existing assignments of bridges to + BridgeDB does not change existing assignments of bridges to distributors, even if probabilities for assigning bridges to distributors change or distributors are disabled entirely. -# Why "MUST NOT" here? This seems like a potentially desirable feature. -# "Does not" would be more accurate. -MN 3. Giving out bridges upon requests @@ -215,12 +186,12 @@ might not process correctly. BridgeDB MUST reject email addresses coming from other domains than a configured set of permitted domains. - BridgeDB SHOULD normalize email addresses by removing "." characters and - by removing parts after the first "+" character. + BridgeDB SHOULD normalize email addresses by removing "." characters + and by removing parts after the first "+" character. BridgeDB MAY discard requests that do not have the value "pass" in their X-DKIM-Authentication-Result header or does not have this header. -# This means in practice that the incoming mail stack needs to check DKIM -# authentication and set X-DKIM-Authentication-Result. + The X-DKIM-Authentication-Result header is set by the incoming mail + stack that needs to check DKIM authentication. BridgeDB SHOULD NOT return a new set of bridges to the same email address until a given time period (typically a few hours) has passed. # Why don't we fix the bridges we give out for a global 3-hour time period @@ -230,12 +201,13 @@ # time values, then people get new bridges when bridges show up, as # opposed to then we decide to reset the bridges we give them. (Yes, this # problem exists for the IP distributor). -NM +# I'm afraid I don't fully understand what you mean here. -KL BridgeDB MAY include bridge fingerprints in replies along with bridge IP addresses and OR ports. BridgeDB SHOULD periodically discard old email-address-to-bridge mappings. - BridgeDB SHOULD reject too many email requires too frequently from the - same normalized address. + BridgeDB SHOULD reject too frequent email requests coming from the same + normalized address. To map previously unseen email addresses to a set of bridges, BridgeDB proceeds as follows:

1 0

[bridgedb/master] Replace MAY/MUST/SHOULD with description of what BridgeDB does.
by karsten＠torproject.org 12 Apr '11

12 Apr '11

commit 6dd09361b18adfcd6d4f70c1f7f175ae70154143 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Apr 12 11:13:13 2011 +0200 Replace MAY/MUST/SHOULD with description of what BridgeDB does. The BridgeDB specification is meant as a description what the current BridgeDB code does, not what a compatible BridgeDB implementation is expected to do. --- bridge-db-spec.txt | 141 ++++++++++++++++++++++++++-------------------------- 1 files changed, 70 insertions(+), 71 deletions(-) diff --git a/bridge-db-spec.txt b/bridge-db-spec.txt index 89f0e5c..9c64e37 100644 --- a/bridge-db-spec.txt +++ b/bridge-db-spec.txt @@ -12,14 +12,15 @@ requests. Some of the decisions here may be suboptimal: this document is meant to - specify current behavior as of Feb 2011, not to specify ideal behavior. + specify current behavior as of April 2011, not to specify ideal + behavior. 1. Importing bridge network statuses and bridge descriptors BridgeDB learns about bridges from parsing bridge network statuses and bridge descriptors as specified in Tor's directory protocol. - BridgeDB SHOULD parse one bridge network status file first and at least - one bridge descriptor file afterwards. + BridgeDB parses one bridge network status file first and at least one + bridge descriptor file afterwards. BridgeDB scans its files on sighup. @@ -43,8 +44,8 @@ from the "s" line. BridgeDB memorizes all bridges that have the Running flag as the set of running bridges that can be given out to bridge users. - BridgeDB SHOULD memorize assigned flags if it wants to ensure that sets - of bridges given out SHOULD contain at least a given number of bridges + BridgeDB memorizes assigned flags if it wants to ensure that sets of + bridges given out should contain at least a given number of bridges with these flags. 1.2. Parsing bridge descriptors @@ -53,11 +54,11 @@ from parsing bridge descriptors. In theory, both IP address and OR port of a bridge are also contained in the "r" line of the bridge network status, so there is no mandatory - reason for parsing bridge descriptors. But this functionality is still - implemented in case we need information from the bridge descriptor in - the future. + reason for parsing bridge descriptors. But the functionality described + in this section is still implemented in case we need data from the + bridge descriptor in the future. - Bridge descriptor files MAY contain one or more bridge descriptors. + Bridge descriptor files may contain one or more bridge descriptors. We expect bridge descriptor to contain at least the following lines in the stated order: @@ -80,7 +81,8 @@ BridgeDB memorizes the IP address and OR port of the most recently parsed bridge descriptor. If BridgeDB does not find a bridge descriptor for a bridge contained in - the bridge network status parsed before, it MUST discard that bridge. + the bridge network status parsed before, it removes that bridge from + the set of bridges to be given out to bridge users. 2. Assigning bridges to distributors @@ -94,10 +96,10 @@ distributor. Each bridge is assigned to exactly one distributor (including the "unallocated" distributor). - BridgeDB MAY be configured to support only a non-empty subset of the + BridgeDB may be configured to support only a non-empty subset of the distributors specified in this document. - BridgeDB MAY define different probabilities for assigning new bridges - to distributors. + BridgeDB may be configured to use different probabilities for assigning + new bridges to distributors. BridgeDB does not change existing assignments of bridges to distributors, even if probabilities for assigning bridges to distributors change or distributors are disabled entirely. @@ -106,41 +108,38 @@ Upon receiving a client request, a BridgeDB distributor provides a subset of the bridges assigned to it. - BridgeDB MUST only give out bridges that are contained in the most - recently parsed bridge network status and that have the Running flag - set. - BridgeDB MAY define a different number of bridges (typically 3) to be - given out depending on the distributor. - BridgeDB MAY define an arbitrary number of rules saying that a certain - number of bridges SHOULD have a given OR port or a given bridge relay + BridgeDB only gives out bridges that are contained in the most recently + parsed bridge network status and that have the Running flag set. + BridgeDB may be configured to give out a different number of bridges + (typically 3) depending on the distributor. + BridgeDB may define an arbitrary number of rules saying that a certain + number of bridges should have a given OR port or a given bridge relay flag. 4. Selecting bridges to be given out based on IP addresses - BridgeDB MAY support one or more distributors that gives out - bridges based on the requestor's IP address. Currently, this is - how the HTTPS distributor works. - BridgeDB MUST fix the set of bridges to be returned for a defined time + BridgeDB may be configured to support one or more distributors that + gives out bridges based on the requestor's IP address. Currently, this + is how the HTTPS distributor works. + BridgeDB fixes the set of bridges to be returned for a defined time period. - BridgeDB SHOULD consider two IP addresses coming from the same /24 as - the same IP address and return the same set of bridges. - BridgeDB SHOULD divide the IP address space equally into a small number - of areas (typically 4) and return different results to requests coming + BridgeDB considers two IP addresses coming from the same /24 as the + same IP address and return the same set of bridges. + BridgeDB divides the IP address space equally into a small number of + areas (typically 4) and return different results to requests coming from these areas. # I found that BridgeDB is not strict in returning only bridges for a -# given area. If a ring is empty, it considers the next one. Therefore, -# it's SHOULD in the sentence above and not MUST. Is this expected -# behavior? -KL +# given area. If a ring is empty, it considers the next one. Is this +# expected behavior? -KL # I also found that BridgeDB does not make the assignment to areas # persistent in the database. So, if we change the number of rings, it # will assign bridges to other rings. I assume this is okay? -KL - BridgeDB SHOULD be able to respect a list of proxy IP addresses and - return the same set of bridges to requests coming from these IP - addresses. - The bridges returned to proxy IP addresses SHOULD NOT come from the - same set as those for the general IP address space. - BridgeDB MAY include bridge fingerprints in replies along with bridge - IP addresses and OR ports. + BridgeDB maintains a list of proxy IP addresses and returns the same + set of bridges to requests coming from these IP addresses. + The bridges returned to proxy IP addresses do not come from the same + set as those for the general IP address space. + BridgeDB can be configured to include bridge fingerprints in replies + along with bridge IP addresses and OR ports. The current algorithm is as follows. An IP-based distributor splits the bridges uniformly into a set of "rings" based on an HMAC of their @@ -171,29 +170,29 @@ - The first L bridges in the ring after the position that have the port 443, and - The first M bridges in the ring after the position that have the - flag stable, and + flag stable and that it has not already decided to give out, and - The first N-L-M bridges in the ring after the position that it has not already decided to give out. 5. Selecting bridges to be given out based on email addresses - BridgeDB MAY support one or more distributors that are giving out - bridges based on the requestor's email address. Currently, this is how - the email distributor works. - BridgeDB SHOULD reject email addresses containing other characters than - the ones that RFC2822 allows. - BridgeDB MAY reject email addresses containing other characters it - might not process correctly. - BridgeDB MUST reject email addresses coming from other domains than a + BridgeDB can be configured to support one or more distributors that are + giving out bridges based on the requestor's email address. Currently, + this is how the email distributor works. + BridgeDB rejects email addresses containing other characters than the + ones that RFC2822 allows. + BridgeDB may be configured to reject email addresses containing other + characters it might not process correctly. + BridgeDB rejects email addresses coming from other domains than a configured set of permitted domains. - BridgeDB SHOULD normalize email addresses by removing "." characters - and by removing parts after the first "+" character. - BridgeDB MAY discard requests that do not have the value "pass" in - their X-DKIM-Authentication-Result header or does not have this header. - The X-DKIM-Authentication-Result header is set by the incoming mail - stack that needs to check DKIM authentication. - BridgeDB SHOULD NOT return a new set of bridges to the same email - address until a given time period (typically a few hours) has passed. + BridgeDB normalizes email addresses by removing "." characters and by + removing parts after the first "+" character. + BridgeDB can be configured to discard requests that do not have the + value "pass" in their X-DKIM-Authentication-Result header or does not + have this header. The X-DKIM-Authentication-Result header is set by + the incoming mail stack that needs to check DKIM authentication. + BridgeDB does not return a new set of bridges to the same email address + until a given time period (typically a few hours) has passed. # Why don't we fix the bridges we give out for a global 3-hour time period # like we do for IP addresses? This way we could avoid storing email # addresses. -KL @@ -201,12 +200,12 @@ # time values, then people get new bridges when bridges show up, as # opposed to then we decide to reset the bridges we give them. (Yes, this # problem exists for the IP distributor). -NM -# I'm afraid I don't fully understand what you mean here. -KL - BridgeDB MAY include bridge fingerprints in replies along with bridge - IP addresses and OR ports. - BridgeDB SHOULD periodically discard old email-address-to-bridge - mappings. - BridgeDB SHOULD reject too frequent email requests coming from the same +# I'm afraid I don't fully understand what you mean here. Can you +# elaborate? -KL + BridgeDB can be configured to include bridge fingerprints in replies + along with bridge IP addresses and OR ports. + BridgeDB periodically discards old email-address-to-bridge mappings. + BridgeDB rejects too frequent email requests coming from the same normalized address. To map previously unseen email addresses to a set of bridges, BridgeDB @@ -224,18 +223,17 @@ # Kaner should have a look at this section. -NM - BridgeDB MAY reserve a subset of bridges and not give them out via one - of the distributors. - BridgeDB MAY assign reserved bridges to one or more file buckets of - fixed sizes and write these file buckets to disk for manual - distribution. - BridgeDB SHOULD ensure that a file bucket always contains the requested + BridgeDB can be configured to reserve a subset of bridges and not give + them out via one of the distributors. + BridgeDB assigns reserved bridges to one or more file buckets of fixed + sizes and write these file buckets to disk for manual distribution. + BridgeDB ensures that a file bucket always contains the requested number of running bridges. If the requested number of bridges in a file bucket is reduced or the file bucket is not required anymore, the unassigned bridges are returned to the reserved set of bridges. - If a bridge stops running, BridgeDB SHOULD replace it with another - bridge from the reserved set of bridges. + If a bridge stops running, BridgeDB replaces it with another bridge + from the reserved set of bridges. # I'm not sure if there's a design bug in file buckets. What happens if # we add a bridge X to file bucket A, and X goes offline? We would add # another bridge Y to file bucket A. OK, but what if A comes back? We @@ -245,7 +243,8 @@ 7. Writing bridge assignments for statistics - BridgeDB MAY write bridge assignments to disk for statistical analysis. + BridgeDB can be configured to write bridge assignments to disk for + statistical analysis. The start of a bridge assignment is marked by the following line: "bridge-pool-assignment" SP YYYY-MM-DD HH:MM:SS NL @@ -264,7 +263,7 @@ a bridge matches certain port or flag criteria of requests. The "https" distributor also allows the key "ring" with a number as - value to indicate to which IP address areas the bridge is returned. + value to indicate to which IP address area the bridge is returned. The "unallocated" distributor allows the key "bucket" with the file bucket name as value to indicate which file bucket a bridge is assigned

1 0

[bridgedb/master] Answer some questions in bridge-db-spec.txt; add some text
by karsten＠torproject.org 12 Apr '11

12 Apr '11

commit cdb25a0c46db28f690ce155b78b2987a9f6e9b36 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Feb 14 14:12:12 2011 -0500 Answer some questions in bridge-db-spec.txt; add some text --- bridge-db-spec.txt | 111 ++++++++++++++++++++++++++++++++++++++++++++++++--- 1 files changed, 104 insertions(+), 7 deletions(-) diff --git a/bridge-db-spec.txt b/bridge-db-spec.txt index 5c8ca57..48a9590 100644 --- a/bridge-db-spec.txt +++ b/bridge-db-spec.txt @@ -1,5 +1,8 @@ - BridgeDB specification + BridgeDB specification + + Karsten Loesing + Nick Mathewson 0. Preliminaries @@ -8,6 +11,9 @@ to distributors, and decides which bridges to give out upon user requests. + Some of the decisions here may be suboptimal: this document is meant to + specify current behavior as of Feb 2011, not to specify ideal behavior. + 1. Importing bridge network statuses and bridge descriptors BridgeDB learns about bridges from parsing bridge network statuses and @@ -15,6 +21,12 @@ BridgeDB SHOULD parse one bridge network status file first and at least one bridge descriptor file afterwards. + BridgeDB scans its files on sighup. + + BridgeDB does not validate signatures on descriptors or networkstatus + files: the operator needs to make sure that these documents have come + from a Tor instance that did the validation for us. + 1.1. Parsing bridge network statuses Bridge network status documents contain the information which bridges @@ -30,6 +42,12 @@ BridgeDB parses the identity from the "r" line and the assigned flags from the "s" line. BridgeDB MUST discard all bridges that do not have the Running flag. +# I don't think that "discard" is the right word here: we don't actually +# seem to "Forget they exist". Instead, we remember that they are not +# running. (See how parseStatusFile yields a flag that says if the bridges +# are running, and how Main.load sets the bridge's status to running or +# non-running appropriately before passing it to splitter. At no point here +# does a non-running bridge get "discarded", sfaict). -NM BridgeDB memorizes all remaining bridges as the set of running bridges that can be given out to bridge users. BridgeDB SHOULD memorize assigned flags if it wants to ensure that sets @@ -53,8 +71,15 @@ BridgeDB MUST discard bridge descriptors if the fingerprint is not contained in the bridge network status parsed before or if the bridge does not have the Running flag. +# See comment above -NM BridgeDB MAY discard bridge descriptors which have a different purpose than "bridge". +# "MAY" isn't good enough; we need to know whether it's safe to give +# bridgedb a list of non-bridge-purpose descriptors or not. If it +# discards them, then you shouldn't give bridgedb non-bridge descriptors +# if you _do_ want them handed out. If it doesn't discard them, then you +# shouldn't give bridgedb non-bridge descriptors _unless_ you want them +# handed out. BridgeDB memorizes the IP addresses and OR ports of the remaining bridges. If there is more than one bridge descriptor with the same fingerprint, @@ -73,17 +98,29 @@ # that? We could also look at the bridge descriptor that is referenced # from the bridge network status by its descriptor identifier, even though # that would require us to calculate the descriptor hash. -KL +# We should just look at the 'published' dates in the bridges. Call this a bug, +# I'd say. -NM If BridgeDB does not find a bridge descriptor for a bridge contained in the bridge network status parsed before, it MUST discard that bridge. # I confirmed that BridgeDB discards (or at least doesn't use) bridges for # which it doesn't have a bridge descriptor. What's the reason for # parsing bridge descriptors anyway? Can't we learn a bridge's IP address # and OR port from the "r" line, too? -KL +# I forget. -NM 2. Assigning bridges to distributors + A "distributor" is a mechanism by which bridges are given (or not + given) to clients. The current distributors are "email", "https", + and "unallocated". + BridgeDB assigns bridges to distributors on a probabilistic basis and makes these assignments persistent. +# Not exactly probabilistic: it's based on an HMAC hash of the bridge's ID +# and a secret. -NM + Persistence is achieved by using a database to map node ID to distributor. + Each bridge is assigned to exactly one distributor (including + the "unallocated" distributor). BridgeDB MAY be configured to support only a non-empty subset of the distributors specified in this document. BridgeDB MAY define different probabilities for assigning new bridges @@ -91,11 +128,13 @@ BridgeDB MUST NOT change existing assignments of bridges to distributors, even if probabilities for assigning bridges to distributors change or distributors are disabled entirely. +# Why "MUST NOT" here? This seems like a potentially desirable feature. +# "Does not" would be more accurate. -MN 3. Giving out bridges upon requests - BridgeDB gives out a subset of the bridges from a given distributor - upon request. + Upon receiving a client request, a BridgeDB distributor provides a + subset of the bridges assigned to it. BridgeDB MUST only give out bridges that are contained in the most recently parsed bridge network status and that have the Running flag set. @@ -107,8 +146,9 @@ 4. Selecting bridges to be given out based on IP addresses - BridgeDB MAY support one or more distributors that are giving out - bridges based on the requestor's IP address. + BridgeDB MAY support one or more distributors that gives out + bridges based on the requestor's IP address. Currently, this is + how the HTTPS distributor works. BridgeDB MUST fix the set of bridges to be returned for a defined time period. BridgeDB SHOULD consider two IP addresses coming from the same /24 as @@ -131,30 +171,87 @@ BridgeDB MAY include bridge fingerprints in replies along with bridge IP addresses and OR ports. + The current algorithm is as follows. An IP-based distributor splits + the bridges uniformly into a set of "rings" based on an HMAC of their + ID. Some of these rings are "area" rings for parts of IP space; some + are "category" rings for categories of IPs (like proxies). When a + client makes a request from an IP, the distributor first sees whether + the IP is in one of the categories it knows. If so, the distributor + returns an IP from the category rings. If not, the distributor + maps the IP into an "area" (that is, a /24), and then uses an HMAC to + map the area to one of the area rings. + + Once the IP-based distributor knows what ring it is handing out bridges + from, it maps the current "epoch" (N-hour period) and the IP's area + (/24) to a point in the ring based on HMAC, and hands out bridges at + that point. + + "Mapping X to Y based on an HMAC" above means one of the following: + - We keep all of the elements of Y in some order, with a mapping + from all 160-bit strings to positions in Y. + - We take an HMAC of X using some fixed string as a key to get a + 160-bit value. We then map that value to the next position of Y. + + When giving out bridges based on a position in a ring, BridgeDB first + looks at flag requirements and port requirements. For example, + BridgeDB may be configured to "Give out at least L bridges with port + 443, and at least M bridges with Stable, and at least N bridges + total." To do this, BridgeDB adds to the results: + - The first L bridges in the ring after the position that have the + port 443, and + - The first M bridges in the ring after the position that have the + flag stable, and + - The first N-L-M bridges in the ring after the position that it + has not already decided to give out. + 5. Selecting bridges to be given out based on email addresses BridgeDB MAY support one or more distributors that are giving out - bridges based on the requestor's email address. + bridges based on the requestor's email address. Currently, this is how + the email distributor works. BridgeDB SHOULD reject email addresses containing other characters than the ones that RFC2822 allows. BridgeDB MAY reject email addresses containing other characters it might not process correctly. BridgeDB MUST reject email addresses coming from other domains than a configured set of permitted domains. - BridgeDB MAY normalize email addresses by removing "." characters and + BridgeDB SHOULD normalize email addresses by removing "." characters and by removing parts after the first "+" character. BridgeDB MAY discard requests that do not have the value "pass" in their X-DKIM-Authentication-Result header or does not have this header. +# This means in practice that the incoming mail stack needs to check DKIM +# authentication and set X-DKIM-Authentication-Result. BridgeDB SHOULD NOT return a new set of bridges to the same email address until a given time period (typically a few hours) has passed. # Why don't we fix the bridges we give out for a global 3-hour time period # like we do for IP addresses? This way we could avoid storing email # addresses. -KL +# The 3-hour value is probably much too short anyway. If we take longer +# time values, then people get new bridges when bridges show up, as +# opposed to then we decide to reset the bridges we give them. (Yes, this +# problem exists for the IP distributor). -NM BridgeDB MAY include bridge fingerprints in replies along with bridge IP addresses and OR ports. + BridgeDB SHOULD periodically discard old email-address-to-bridge + mappings. + BridgeDB SHOULD reject too many email requires too frequently from the + same normalized address. + + To map previously unseen email addresses to a set of bridges, BridgeDB + proceeds as follows: + - It normalizes the email address as above, by stripping out dots, + removing all of the localpart after the +, and putting it all + in lowercase. (Example: "John.Doe+bridges(a)example.COM" becomes + "johndoe(a)example.com".) + - It maps an HMAC of the normalized address to a position on its ring + of bridges. + - It hands out bridges starting at that position, based on the + port/flag requirements, as specified at the end of section 4. 6. Selecting unallocated bridges to be stored in file buckets +# Kaner should have a look at this section. -NM + BridgeDB MAY reserve a subset of bridges and not give them out via one of the distributors. BridgeDB MAY assign reserved bridges to one or more file buckets of

1 0

[bridgedb/master] Merge branch 'spec'
by karsten＠torproject.org 12 Apr '11

12 Apr '11

commit 7e9562b68cdcae531040bbd03507e8639dd40805 Merge: c69bc14 2254335 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Apr 12 20:46:22 2011 +0200 Merge branch 'spec' bridge-db-spec.txt | 281 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 281 insertions(+), 0 deletions(-)

1 0

[bridgedb/master] Add two sentences from the old proposal idea.
by karsten＠torproject.org 12 Apr '11

12 Apr '11

commit 2254335a591cf15e4759378887e9dbb7b22fbccb Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Tue Apr 12 11:20:01 2011 +0200 Add two sentences from the old proposal idea. --- bridge-db-spec.txt | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/bridge-db-spec.txt b/bridge-db-spec.txt index 9c64e37..a90b934 100644 --- a/bridge-db-spec.txt +++ b/bridge-db-spec.txt @@ -121,6 +121,11 @@ BridgeDB may be configured to support one or more distributors that gives out bridges based on the requestor's IP address. Currently, this is how the HTTPS distributor works. + The goal is to avoid handing out all the bridges to users in a similar + IP space and time. +# Someone else should look at proposals/ideas/old/xxx-bridge-disbursement +# to see if this section is missing relevant pieces from it. -KL + BridgeDB fixes the set of bridges to be returned for a defined time period. BridgeDB considers two IP addresses coming from the same /24 as the @@ -179,6 +184,11 @@ BridgeDB can be configured to support one or more distributors that are giving out bridges based on the requestor's email address. Currently, this is how the email distributor works. + The goal is to bootstrap based on one or more popular email service's + sybil prevention algorithms. +# Someone else should look at proposals/ideas/old/xxx-bridge-disbursement +# to see if this section is missing relevant pieces from it. -KL + BridgeDB rejects email addresses containing other characters than the ones that RFC2822 allows. BridgeDB may be configured to reject email addresses containing other

1 0

[bridgedb/master] Add first version of bridge-db-spec.txt.
by karsten＠torproject.org 12 Apr '11

12 Apr '11

commit 6136c48d95d3e6ffb1fef8c9f918038e5bcf6c9b Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Sun Feb 13 21:24:40 2011 +0100 Add first version of bridge-db-spec.txt. --- bridge-db-spec.txt | 106 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 106 insertions(+), 0 deletions(-) diff --git a/bridge-db-spec.txt b/bridge-db-spec.txt new file mode 100644 index 0000000..a9e2c8f --- /dev/null +++ b/bridge-db-spec.txt @@ -0,0 +1,106 @@ + + BridgeDB specification + +0. Preliminaries + + This document specifies how BridgeDB processes bridge descriptor files + to learn about new bridges, maintains persistent assignments of bridges + to distributors, and decides which descriptors to give out upon user + requests. + +1. Importing bridge network statuses and bridge descriptors + + BridgeDB learns about bridges from parsing bridge network statuses and + bridge descriptors as specified in Tor's directory protocol. BridgeDB + SHOULD parse one bridge network status file and at least one bridge + descriptor file. + +1.1. Parsing bridge network statuses + + Bridge network status documents contain the information which bridges + are known to the bridge authority at a certain time. We expect bridge + network statuses to contain at least the following two lines for every + bridge in the given order: + + "r" SP nickname SP identity SP digest SP publication SP IP SP ORPort SP + DirPort NL + "s" SP Flags NL + + BridgeDB parses the identity from the "r" line and scans the "s" line + for flags Stable and Running. BridgeDB MUST discard all bridges that + do not have the Running flag. BridgeDB MAY only consider bridges as + running that have the Running flag in the most recently parsed bridge + network status. BridgeDB MUST also discard all bridges for which it + does not find a bridge descriptor. BridgeDB memorizes all remaining + bridges as the set of running bridges that can be given out to bridge + users. +# I'm not 100% sure if BridgeDB discards (or rather doesn't use) bridges +# for which it doesn't have a bridge descriptor. But as far as I can see, +# it wouldn't learn the bridge's IP and OR port in that case, so we +# shouldn't use it. Is this a bug? -KL +# What's the reason for parsing bridge descriptors anyway? Can't we learn +# a bridge's IP address and OR port from the "r" line, too? -KL + +1.2. Parsing bridge descriptors + + BridgeDB learns about a bridge's most recent IP address and OR port + from parsing bridge descriptors. Bridge descriptor files MAY contain + one or more bridge descriptors. We expect bridge descriptor to contain + at least the following lines in the stated order: + + "@purpose" SP purpose NL + "router" SP nickname SP IP SP ORPort SP SOCKSPort SP DirPort NL + ["opt "] "fingerprint" SP fingerprint NL + + BridgeDB parses the purpose, IP, ORPort, and fingerprint. BridgeDB + MUST discard bridge descriptors if the fingerprint is not contained in + the bridge network status(es) parsed in the same execution or if the + bridge does not have the Running flag. BridgeDB MAY discard bridge + descriptors which have a different purpose than "bridge". BridgeDB + memorizes the IP addresses and OR ports of the remaining bridges. If + there is more than one bridge descriptor with the same fingerprint, + BridgeDB memorizes the IP address and OR port of the most recently + parsed bridge descriptor. +# I think that BridgeDB simply assumes that descriptors in the bridge +# descriptor files are in chronological order. If not, it would overwrite +# a bridge's IP address and OR port with an older descriptor, which would +# be bad. The current cached-descriptors* files should write descriptors +# in chronological order. But we might change that, e.g., when trying to +# limit the number of descriptors in Tor. Should we make the assumption +# that descriptors are ordered chronologically, or should we specify that +# we have to check that explicitly? -KL + +2. Assigning bridges to distributors + +# In this section I'm planning to write how BridgeDB should decide to +# which distributor (https, email, unallocated/file bucket) it assigns a +# new bridge. I should also write down whether BridgeDB changes +# assignments of already known bridges (I think it doesn't). The latter +# includes cases when we increase/reduce the probability of bridges being +# assigned to a distributor or even turn off a distributor completely. +# -KL + +3. Selecting bridges to be given out via https + +# This section is about the specifics of the https distributor, like which +# IP addresses get bridges from the same ring, how often the results +# change, etc. -KL + +4. Selecting bridges to be given out via email + +# This section is about the specifics of the email distributor, like which +# characters do we recognize in email addresses, how long we don't give +# out new bridges to the same email address, etc. -KL + +5. Selecting unallocated bridges to be stored in file buckets + +# This section is about kaner's bucket mechanism. I want to cover how +# BridgeDB decides which of the unallocated bridges to add to a file +# bucket. -KL +# I'm not sure if there's a design bug in file buckets. What happens if +# we add a bridge X to file bucket A, and X goes offline? We would add +# another bridge Y to file bucket A. OK, but what if A comes back? We +# cannot put it back in file bucket A, because it's full. Are we going to +# add it to a different file bucket? Doesn't that mean that most bridges +# will be contained in most file buckets over time? -KL +

1 0