tor-commits May 2014

tor-commits@lists.torproject.org

25 participants
1732 discussions

[bridgedb/master] Update Sphinx formatting in docstrings in bridgedb.parse.networkstatus.
by isis＠torproject.org 16 May '14

16 May '14

commit 0ff6962764d1b5b3995e2b5efae6ffa1923a909e Author: Isis Lovecruft <isis(a)torproject.org> Date: Tue Apr 22 23:17:27 2014 +0000 Update Sphinx formatting in docstrings in bridgedb.parse.networkstatus. --- lib/bridgedb/parse/networkstatus.py | 57 ++++++++++++++++++++--------------- 1 file changed, 32 insertions(+), 25 deletions(-) diff --git a/lib/bridgedb/parse/networkstatus.py b/lib/bridgedb/parse/networkstatus.py index 9304009..8592cd3 100644 --- a/lib/bridgedb/parse/networkstatus.py +++ b/lib/bridgedb/parse/networkstatus.py @@ -5,23 +5,27 @@ # :authors: Isis Lovecruft 0xA3ADB67A2CDB8B35 <isis(a)torproject.org> # please also see AUTHORS file # :copyright: (c) 2013 Isis Lovecruft -# (c) 2007-2013, The Tor Project, Inc. -# (c) 2007-2013, all entities within the AUTHORS file +# (c) 2007-2014, The Tor Project, Inc. +# (c) 2007-2014, all entities within the AUTHORS file # :license: 3-clause BSD, see included LICENSE for information -"""Parsers for ``@type bridge-network-status 1.0`` descriptors. +"""Parsers for bridge networkstatus descriptors. +.. py:module:: bridgedb.parse.networkstatus + :synopsis: Parsers for ``@type bridge-network-status`` descriptors_. .. _descriptors: https://metrics.torproject.org/formats.html#descriptortypes -**Module Overview:** +bridgedb.parse.networkstatus +============================ +:: + + networkstatus + |_ isValidRouterNickname - Determine if a nickname is according to spec + |_ parseRLine - Parse an 'r'-line from a networkstatus document + |_ parseALine - Parse an 'a'-line from a networkstatus document + \_ parseSLine - Parse an 's'-line from a networkstatus document .. - parse - \_networkstatus - |_ isValidRouterNickname - Determine if a nickname is according to spec - |_ parseRLine - Parse an 'r'-line from a networkstatus document - |_ parseALine - Parse an 'a'-line from a networkstatus document - \_ parseSLine - Parse an 's'-line from a networkstatus document """ import binascii @@ -67,25 +71,28 @@ def parseRLine(line): """Parse an 'r'-line from a networkstatus document. From torspec.git/dir-spec.txt, commit 36761c7d553d L1499-1512: + | "r" SP nickname SP identity SP digest SP publication SP IP SP ORPort + | SP DirPort NL | - |"r" SP nickname SP identity SP digest SP publication SP IP SP ORPort - | SP DirPort NL - | - | [At start, exactly once.] - | - | "Nickname" is the OR's nickname. "Identity" is a hash of its - | identity key, encoded in base64, with trailing equals sign(s) - | removed. "Digest" is a hash of its most recent descriptor as - | signed (that is, not including the signature), encoded in base64. - | "Publication" is the - | publication time of its most recent descriptor, in the form - | YYYY-MM-DD HH:MM:SS, in UTC. "IP" is its current IP address; - | ORPort is its current OR port, "DirPort" is its current directory - | port, or "0" for "none". + | [At start, exactly once.] | + | "Nickname" is the OR's nickname. "Identity" is a hash of its + | identity key, encoded in base64, with trailing equals sign(s) + | removed. "Digest" is a hash of its most recent descriptor as + | signed (that is, not including the signature), encoded in base64. + | "Publication" is the + | publication time of its most recent descriptor, in the form + | YYYY-MM-DD HH:MM:SS, in UTC. "IP" is its current IP address; + | ORPort is its current OR port, "DirPort" is its current directory + | port, or "0" for "none". :param string line: An 'r'-line from an bridge-network-status descriptor. - + :returns: + A 7-tuple of:: + (nickname, identityDigest, descriptorDigest, timestamp, + orAddress, orPort, dirport) + where each value is set according to the data parsed from the + **line**, or ``None`` if nothing suitable could be parsed. """ (nickname, ID, descDigest, timestamp, ORaddr, ORport, dirport) = (None for x in xrange(7))

1 0

[bridgedb/master] Update bridgedb.parse.addr module docstring.
by isis＠torproject.org 16 May '14

16 May '14

commit 846cb78871b1c131f6bec9d3c9a70a4938a0d535 Author: Isis Lovecruft <isis(a)torproject.org> Date: Tue Apr 22 23:15:20 2014 +0000 Update bridgedb.parse.addr module docstring. --- lib/bridgedb/parse/addr.py | 186 +++++++++++++++++++++++++------------------- 1 file changed, 107 insertions(+), 79 deletions(-) diff --git a/lib/bridgedb/parse/addr.py b/lib/bridgedb/parse/addr.py index f34f416..a9c62cc 100644 --- a/lib/bridgedb/parse/addr.py +++ b/lib/bridgedb/parse/addr.py @@ -9,136 +9,164 @@ # (c) 2007-2013, all entities within the AUTHORS file # :license: 3-clause BSD, see included LICENSE for information -"""Utilities for parsing IP addresses. +"""Utilities for parsing IP and email addresses. -** Module Overview: ** +.. py:module:: bridgedb.parse.addr + :synopsis: Parsers for finding and validating IP addresses, email + addresses, and port ranges. + + +bridgedb.parse.addr +=================== :: - parse - ||_ parse.addr - | | |_ extractEmailAddress - Validate a :rfc:2822 email address. - | | |_ isIPAddress - Check if an arbitrary string is an IP address. - | | |_ isIPv4 - Check if an arbitrary string is an IPv4 address. - | | |_ isIPv6 - Check if an arbitrary string is an IPv6 address. - | | \_ isValidIP - Check that an IP address is valid. - | | - | |_ :class:`PortList` - A container class for validated port ranges. + + parse.addr + | |_ extractEmailAddress() - Validate a :rfc:2822 email address. + | |_ isIPAddress() - Check if an arbitrary string is an IP address. + | |_ isIPv4() - Check if an arbitrary string is an IPv4 address. + | |_ isIPv6() - Check if an arbitrary string is an IPv6 address. + | \_ isValidIP() - Check that an IP address is valid. | - |__ :mod:`bridgedb.parse.headers` - |__ :mod:`bridgedb.parse.options` - \__ :mod:`bridgedb.parse.versions` + |_ PortList - A container class for validated port ranges. -:: +.. + + +How address validity is determined +---------------------------------- -Private IP Address Ranges: -'''''''''''''''''''''''''' +The following terms define addresses which are **not** valid. All other +addresses are taken to be valid. + + +Private IP Address Ranges +^^^^^^^^^^^^^^^^^^^^^^^^^ .. glossary:: - 10.0.0.0 - 10.255.255.255 (10.0.0.0/8 prefix) - 172.16.0.0 - 172.31.255.255 (172.16.0.0/12 prefix) - 192.168.0.0 - 192.168.255.255 (192.168.0.0/16 prefix) - These Address ranges are reserved by IANA for private intranets, and not - routable to the Internet. For additional information, see :rfc:`1918`. + Private Address + These address ranges are reserved by IANA for private intranets, and not + routable to the Internet:: + 10.0.0.0 - 10.255.255.255 (10.0.0.0/8) + 172.16.0.0 - 172.31.255.255 (172.16.0.0/12) + 192.168.0.0 - 192.168.255.255 (192.168.0.0/16) + For additional information, see :rfc:`1918`. -Reserved and Special Use Addresses: -''''''''''''''''''''''''''''''''''' + +Reserved and Special Use Addresses +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. glossary:: Unspecified Address Default Route - ex. ``0.0.0.0/8`` - ex. ``::/128`` - Current network (only valid as source address). See :rfc:`1122`. An - **Unspecified Address** in the context of firewalls means "all addresses - of the local machine". In a routing context, it is usually termed the - **Default Route**, and it means the default route (to "the rest of" the - internet). See :rfc:`1700`. + Current network (only valid as source address). See :rfc:`1122`. An + **Unspecified Address** in the context of firewalls means "all addresses + of the local machine". In a routing context, it is usually termed the + **Default Route**, and it means the default route (to "the rest of" the + internet). See :rfc:`1700`. + For example:: + 0.0.0.0/8 + ::/128 Loopback Address - ex. ``127.0.0.0`` - Reserved for loopback and IPC on the localhost. See :rfc:`1122`. + Reserved for loopback and IPC on the localhost. See :rfc:`1122`. + Example:: + 127.0.0.0 Localhost Address - ex. ``127.0.0.1 - 127.255.255.254`` (``127.0.0.0/8``) - ex. ``::1`` - Loopback IP addresses (refers to self). See :rfc:`5735`. + Loopback IP addresses (refers to self). See :rfc:`5735`. + Examples include:: + 127.0.0.1 - 127.255.255.254 (127.0.0.0/8) + ::1 Link-Local Address - ex. ``169.254.0.0/16`` - ex. ``fe80::/64`` - These are the link-local blocks, used for communication between hosts on - a single link. See :rfc:`3927`. + These are the link-local blocks, used for communication between hosts on + a single link. See :rfc:`3927`. + Examples:: + 169.254.0.0/16 + fe80::/64 Multicast Address - ex. ``224.0.0.0 - 239.255.255.255`` (``224.0.0.0/4``) - Reserved for multicast addresses. See :rfc:`3171`. + Reserved for multicast addresses. See :rfc:`3171`. + For example:: + 224.0.0.0 - 239.255.255.255 (224.0.0.0/4) Private Address - ex. ``10.0.0.0/8`` - ex. ``172.16.0.0/12`` - ex. ``192.168.0.0/16`` - Reserved for private networks. See :rfc:`1918`. + Reserved for private networks. See :rfc:`1918`. + Some examples include:: + 10.0.0.0/8 + 172.16.0.0/12 + 192.168.0.0/16 Reserved Address - ex. ``240.0.0.0 - 255.255.255.255`` (``240.0.0.0/4``) - Reserved (former Class E network). See :rfc:`1700`, :rfc:`3232`, and - :rfc:`5735`. The one exception to this rule is the :term:`Limited - Broadcast Address`, ``255.255.255.255`` for which packets at the IP - layer are not forwarded to the public internet. + Reserved (former Class E network). See :rfc:`1700`, :rfc:`3232`, and + :rfc:`5735`. The one exception to this rule is the :term:`Limited + Broadcast Address`, ``255.255.255.255`` for which packets at the IP + layer are not forwarded to the public internet. For example:: + 240.0.0.0 - 255.255.255.255 (240.0.0.0/4) Limited Broadcast Address - ex. ``255.255.255.255`` - Limited broadcast address (limited to all other nodes on the LAN). See - :rfc:`919`. For IPv4, ``255`` in any part of the IP is reserved for - broadcast addressing to the local LAN. + Limited broadcast address (limited to all other nodes on the LAN). See + :rfc:`919`. For IPv4, ``255`` in any part of the IP is reserved for + broadcast addressing to the local LAN, e.g.:: + 255.255.255.255 .. warning:: The :mod:`ipaddr` module (as of version 2.1.10) does not understand the following reserved_ addresses: - .. _reserved: https://tools.ietf.org/html/rfc5735#page-4 .. glossary:: Reserved Address (Protocol Assignments) - ex. ``192.0.0.0/24`` - Reserved for IETF protocol assignments. See :rfc:`5735`. + Reserved for IETF protocol assignments. See :rfc:`5735`. + Example:: + 192.0.0.0/24 Reserved Address (6to4 Relay Anycast) - ex. ``192.88.99.0/24`` - IPv6 to IPv4 relay. See :rfc:`3068`. + IPv6 to IPv4 relay. See :rfc:`3068`. + Example:: + 192.88.99.0/24 Reserved Address (Network Benchmark) - ex. ``198.18.0.0/15`` - Network benchmark tests. See :rfc:`2544`. + Network benchmark tests. See :rfc:`2544`. + Example:: + 198.18.0.0/15 Reserved Address (TEST-NET-1) - ex. ``192.0.2.0/24`` - Reserved for use in documentation and example code. It is often used in - conjunction with domain names ``example.com`` or ``example.net`` in - vendor and protocol documentation. See :rfc:`1166`. + Reserved for use in documentation and example code. It is often used in + conjunction with domain names ``example.com`` or ``example.net`` in + vendor and protocol documentation. See :rfc:`1166`. + For example:: + 192.0.2.0/24 Reserved Address (TEST-NET-2) - ex. ``198.51.100.0/24`` - TEST-NET-2. See :rfc:`5737`. + TEST-NET-2. See :rfc:`5737`. + Example:: + 198.51.100.0/24 Reserved Address (TEST-NET-3) - ex. ``203.0.113.0/24`` - TEST-NET-3. See :rfc:`5737`. + TEST-NET-3. See :rfc:`5737`. + Example:: + 203.0.113.0/24 Shared Address Space - ex. ``100.64.0.0/10`` - See :rfc:`6598`. + See :rfc:`6598`. + Example:: + 100.64.0.0/10 Site-Local Address Unique Local Address - ex. ``ff00::0/8`` - ex. ``fec0::/10`` (:rfc:`3513` §2.5.6) - Similar uses to :term:`Limited Broadcast Address`. For IPv6, everything - becomes convoluted_ and complicated_, and then redefined_. See - :rfc:`4193`, :rfc:`3879`, and :rfc:`3513`. The - :meth:`ipaddr.IPAddress.is_site_local` method *only* checks to see if - the address is a **Unique Local Address** vis-á-vis :rfc:`3513` §2.5.6. + Similar uses to :term:`Limited Broadcast Address`. For IPv6, everything + becomes convoluted_ and complicated_, and then redefined_. See + :rfc:`4193`, :rfc:`3879`, and :rfc:`3513`. The + :meth:`ipaddr.IPAddress.is_site_local` method *only* checks to see if + the address is a **Unique Local Address** vis-á-vis :rfc:`3513` §2.5.6, + e.g.:: + ff00::0/8 + fec0::/10 + +.. .. _convoluted: https://en.wikipedia.org/wiki/IPv6_address#Multicast_addresses .. _complicated: https://en.wikipedia.org/wiki/IPv6_address#IPv6_address_scopes

1 0

[bridgedb/master] Fix libgpgme signing error due to Python2.7 buffer() interface changes.
by isis＠torproject.org 16 May '14

16 May '14

commit 3debed96a8e04894b0064e8075ffd8c1dd4ce10b Author: Isis Lovecruft <isis(a)torproject.org> Date: Wed Apr 23 05:08:10 2014 +0000 Fix libgpgme signing error due to Python2.7 buffer() interface changes. See https://mail.python.org/pipermail/python-dev/2010-October/104917.html https://docs.python.org/2/c-api/buffer.html https://github.com/SoftwareIntrospectionLab/MininGit/issues/101#issuecommen… We have to test if our Python2.7 version has the new or old builtin buffer() interface. --- lib/bridgedb/crypto.py | 27 +++++++++++++++++++++++++-- 1 file changed, 25 insertions(+), 2 deletions(-) diff --git a/lib/bridgedb/crypto.py b/lib/bridgedb/crypto.py index 4ce30b2..2feb556 100644 --- a/lib/bridgedb/crypto.py +++ b/lib/bridgedb/crypto.py @@ -61,6 +61,24 @@ from twisted.internet import ssl #: The hash digest to use for HMACs. DIGESTMOD = hashlib.sha1 +# Test to see if we have the old or new style buffer() interface. Trying +# to use an old-style buffer on Python2.7 prior to version 2.7.5 will produce: +# +# TypeError: 'buffer' does not have the buffer interface +# +#: ``True`` if we have the new-style +#: `buffer <https://docs.python.org/2/c-api/buffer.html>` interface. +NEW_BUFFER_INTERFACE = False +try: + io.BytesIO(buffer('test')) +except TypeError: + logging.warn( + "This Python version is too old! "\ + "It doesn't support new-style buffer interfaces: "\ + "https://mail.python.org/pipermail/python-dev/2010-October/104917.html") +else: + NEW_BUFFER_INTERFACE = True + class RSAKeyGenerationError(Exception): """Raised when there was an error creating an RSA keypair.""" @@ -395,8 +413,13 @@ def gpgSignMessage(gpgmeCtx, messageString, mode=None): if not mode: mode = gpgme.SIG_MODE_CLEAR - msgFile = io.BytesIO(buffer(messageString)) - sigFile = io.BytesIO() + if NEW_BUFFER_INTERFACE: + msgFile = io.BytesIO(buffer(messageString)) + sigFile = io.BytesIO() + else: + msgFile = io.StringIO(unicode(messageString)) + sigFile = io.StringIO() + sigList = gpgmeCtx.sign(msgFile, sigFile, mode) sigFile.seek(0) signature = sigFile.read()

1 0

[bridgedb/master] Remove doc/bridge-db-spec.txt; it lives in torspec.git now.
by isis＠torproject.org 16 May '14

16 May '14

commit 639cef05249121692cb4280034e97a3ed6ffb4df Author: Isis Lovecruft <isis(a)torproject.org> Date: Wed Apr 23 05:27:49 2014 +0000 Remove doc/bridge-db-spec.txt; it lives in torspec.git now. https://gitweb.torproject.org/torspec.git/blob/HEAD:/bridgedb-spec.txt --- doc/bridge-db-spec.txt | 391 ------------------------------------------------ 1 file changed, 391 deletions(-) diff --git a/doc/bridge-db-spec.txt b/doc/bridge-db-spec.txt deleted file mode 100644 index c897226..0000000 --- a/doc/bridge-db-spec.txt +++ /dev/null @@ -1,391 +0,0 @@ - - BridgeDB specification - - Karsten Loesing - Nick Mathewson - -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 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 August 2013, not to specify ideal - behavior. - -1. Importing bridge network statuses and bridge descriptors - - BridgeDB learns about bridges by parsing bridge network statuses, - bridge descriptors, and extra info documents as specified in Tor's - directory protocol. BridgeDB parses one bridge network status file - first and at least one bridge descriptor file and potentially one extra - info 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 of which bridges - 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 (format fully specified in Tor's - directory protocol): - - "r" SP nickname SP identity SP digest SP publication SP IP SP ORPort - SP DirPort NL - "a" SP address ":" port NL (no more than 8 instances) - "s" SP Flags NL - - BridgeDB parses the identity and the publication timestamp from the "r" - line, the OR address(es) and ORPort(s) from the "a" line(s), and the - assigned flags from the "s" line, specifically checking the assignment - of the "Running" and "Stable" flags. - BridgeDB memorizes all bridges that have the Running flag as the set of - running bridges that can be given out to bridge users. - 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 - - 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 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. - We expect a 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 - "published" SP timestamp - ["opt" SP] "fingerprint" SP fingerprint NL - "router-signature" NL Signature NL - - BridgeDB parses the purpose, IP, ORPort, nickname, and fingerprint - from these lines. - BridgeDB skips bridge descriptors if the fingerprint is not contained - in the bridge network status parsed earlier 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. - If BridgeDB does not find a bridge descriptor for a bridge contained in - the bridge network status parsed before, it does not add that bridge - to the set of bridges to be given out to bridge users. - -1.3. Parsing extra-info documents - - BridgeDB learns if a bridge supports a pluggable transport by parsing - extra-info documents. - Extra-info documents contain the name of the bridge (but only if it is - named), the bridge's fingerprint, the type of pluggable transport(s) it - supports, and the IP address and port number on which each transport - listens, respectively. - - Extra-info documents may contain zero or more entries per bridge. We expect - an extra-info entry to contain the following lines in the stated order: - - "extra-info" SP name SP fingerprint NL - "transport" SP transport SP IP ":" PORT ARGS NL - - BridgeDB parses the fingerprint, transport type, IP address, port and any - arguments that are specified on these lines. BridgeDB skips the name. If - the fingerprint is invalid, BridgeDB skips the entry. BridgeDB memorizes - the transport type, IP address, port number, and any arguments that are be - provided and then it assigns them to the corresponding bridge based on the - fingerprint. Arguments are comma-separated and are of the form k=v,k=v. - Bridges that do not have an associated extra-info entry are not invalid. - -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 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 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. - -3. Giving out bridges upon requests - - Upon receiving a client request, a BridgeDB distributor provides a - subset of the bridges assigned to it. - BridgeDB only gives out bridges that are contained in the most recently - parsed bridge network status and that have the Running flag set (see - Section 1). - BridgeDB may be configured to give out a different number of bridges - (typically 4) depending on the distributor. - BridgeDB may define an arbitrary number of rules. These rules may - specify the criteria by which a bridge is selected. Specifically, - the available rules restrict the IP address version, OR port number, - transport type, bridge relay flag, or country in which the bridge - should not be blocked. - -4. Selecting bridges to be given out based on IP addresses - - BridgeDB may be configured to support one or more distributors which - 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 all IP addresses coming from the same /24 network - as the same IP address and returns the same set of bridges. From here on, - this non-unique address will be referred to as the IP address's 'area'. - BridgeDB divides the IP address space equally into a small number of -# Note, changed term from "areas" to "disjoint clusters" -MF - disjoint clusters (typically 4) and returns different results for requests - coming from addresses that are placed into different clusters. -# 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. Is this -# expected behavior? -KL -# -# This does not appear to be the case, anymore. If a ring is empty, then -# BridgeDB simply returns an empty set of bridges. -MF -# -# 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 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. - BridgeDB can be configured to display a CAPTCHA which the user must solve - prior to returning the requested bridges. - - 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. - - When the IP-based distributor determines from which area ring it is handing - out bridges, it identifies which rules it will use to choose appropriate - bridges. Using this information, it searches its cache of rings for one - that already adheres to the criteria specified in this request. If one - exists, then BridgeDB maps the current "epoch" (N-hour period) and the - IP's area (/24) to a point on the ring based on HMAC, and hands out - bridges at that point. If a ring does not already exist which satisfies this - request, then a new ring is created and filled with bridges that fulfill - the requirements. This ring is then used to select bridges as described. - - "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 most N bridges - total." To do this, BridgeDB combines 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 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. - - After BridgeDB selects appropriate bridges to return to the requestor, it - then prioritises the ordering of them in a list so that as many criteria - are fulfilled as possible within the first few bridges. This list is then - truncated to N bridges, if possible. N is currently defined as a - piecewise function of the number of bridges in the ring such that: - - / - | 1, if len(ring) < 20 - | - N = | 2, if 20 <= len(ring) <= 100 - | - | 3, if 100 <= len(ring) - \ - - The bridges in this sublist, containing no more than N bridges, are the - bridges returned to the requestor. - -5. Selecting bridges to be given out based on email addresses - - 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 - characters it might not process correctly. -# I don't think we do this, is it worthwhile? -MF - BridgeDB rejects email addresses coming from other domains than a - configured set of permitted domains. - 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 -# 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 -# I'm afraid I don't fully understand what you mean here. Can you -# elaborate? -KL -# -# Assuming an average churn rate, if we use short time periods, then a -# requestor will receive new bridges based on rate-limiting and will (likely) -# eventually work their way around the ring; eventually exhausting all bridges -# available to them from this distributor. If we use a longer time period, -# then each time the period expires there will be more bridges in the ring -# thus reducing the likelihood of all bridges being blocked and increasing -# the time and effort required to enumerate all bridges. (This is my -# understanding, not from Nick) -MF -# Also, we presently need the cache to prevent replays and because if a user -# sent multiple requests with different criteria in each then we would leak -# additional bridges otherwise. -MF - BridgeDB can be configured to include bridge fingerprints in replies - along with bridge IP addresses and OR ports. - BridgeDB can be configured to sign all replies using a PGP signing key. - 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 - 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. - - See section 4 for the details of how bridges are selected from the ring - and returned to the requestor. - -6. Selecting unallocated bridges to be stored in file buckets - -# Kaner should have a look at this section. -NM - - 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 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 -# 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 -# -# This should be handled the same as if the file bucket is reduced in size. -# If X returns, then it should be added to the appropriate distributor. -MF - -7. Displaying Bridge Information - - After bridges are selected using one of the methods described in - Sections 4 - 6, they are output in one of two formats. Bridges are - formatted as: - - <address:port> NL - - Pluggable transports are formatted as: - - <transportname> SP <address:port> [SP arglist] NL - - where arglist is an optional space-separated list of key-value pairs in - the form of k=v. - - Previously, each line was prepended with the "bridge" keyword, such as - - "bridge" SP <address:port> NL - - "bridge" SP <transportname> SP <address:port> [SP arglist] NL - -# We don't do this anymore because Vidalia and TorLauncher don't expect it. -# See the commit message for b70347a9c5fd769c6d5d0c0eb5171ace2999a736. - -8. Writing bridge assignments for statistics - - 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 - - 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", - "flag" and "transport". Respectively, the port number, flag name, and - transport types are the values. These are used to indicate that - a bridge matches certain port, flag, transport criteria of requests. - - The "https" distributor also allows the key "ring" with a number as - 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 - to. -

1 0

[bridgedb/master] Merge branch 'hotfix/11522-gpg-signing' into develop
by isis＠torproject.org 16 May '14

16 May '14

commit cbb078b63c844cf7f0ee9926f9c8f92367a01790 Merge: e1b5588 3debed9 Author: Isis Lovecruft <isis(a)torproject.org> Date: Wed Apr 23 05:14:44 2014 +0000 Merge branch 'hotfix/11522-gpg-signing' into develop lib/bridgedb/crypto.py | 27 +++++++++++++++++++++++++-- 1 file changed, 25 insertions(+), 2 deletions(-)

1 0

[bridgedb/develop] Update bridgedb.pot translations template file.
by isis＠torproject.org 16 May '14

16 May '14

commit 5557f6c7d4ca29e3120da44c771d9d5aa0af5b57 Author: Isis Lovecruft <isis(a)torproject.org> Date: Fri May 16 18:42:35 2014 +0000 Update bridgedb.pot translations template file. --- lib/bridgedb/i18n/templates/bridgedb.pot | 93 ++++++++++++++++++------------ 1 file changed, 56 insertions(+), 37 deletions(-) diff --git a/lib/bridgedb/i18n/templates/bridgedb.pot b/lib/bridgedb/i18n/templates/bridgedb.pot index ea228b4..e3738bd 100644 --- a/lib/bridgedb/i18n/templates/bridgedb.pot +++ b/lib/bridgedb/i18n/templates/bridgedb.pot @@ -6,11 +6,11 @@ #, fuzzy msgid "" msgstr "" -"Project-Id-Version: bridgedb 0.1.6-235-g5652c17\n" +"Project-Id-Version: bridgedb 0.1.6-278-gfe45b79\n" "Report-Msgid-Bugs-To: " "'https://trac.torproject.org/projects/tor/newticket?component=BridgeDB&keywo…" "=bridgedb-reported,msgid&cc=isis,sysrqb&owner=isis'\n" -"POT-Creation-Date: 2014-05-07 17:18+0000\n" +"POT-Creation-Date: 2014-05-16 18:39+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: Isis Lovecruft <isis(a)torproject.org>\n" "Language-Team: LANGUAGE <LL(a)li.org>\n" @@ -33,7 +33,7 @@ msgstr "" #. "Tor" #. "Tor Browser" #. "TBB" -#: lib/bridgedb/HTTPServer.py:122 +#: lib/bridgedb/HTTPServer.py:124 msgid "Sorry! Something went wrong with your request." msgstr "" @@ -61,12 +61,35 @@ msgstr "" msgid "Welcome to BridgeDB!" msgstr "" -#. TRANLATORS: Please DO NOT tranlate the words "transport" or "TYPE". +#. TRANSLATORS: Please DO NOT translate the words "transport" or "TYPE". #: lib/bridgedb/strings.py:29 -msgid "Currently supported tranport TYPEs:" +msgid "Currently supported transport TYPEs:" msgstr "" -#: lib/bridgedb/strings.py:33 +#: lib/bridgedb/strings.py:30 +#, python-format +msgid "Hey, %s!" +msgstr "" + +#: lib/bridgedb/strings.py:31 +msgid "Hello, friend!" +msgstr "" + +#: lib/bridgedb/strings.py:32 lib/bridgedb/templates/base.html:100 +msgid "Public Keys" +msgstr "" + +#. TRANSLATORS: This string will end up saying something like: +#. "This email was generated with rainbows, unicorns, and sparkles +#. for alice(a)example.com on Friday, 09 May, 2014 at 18:59:39." +#: lib/bridgedb/strings.py:36 +#, python-format +msgid "" +"This email was generated with rainbows, unicorns, and sparkles\n" +"for %s on %s at %s." +msgstr "" + +#: lib/bridgedb/strings.py:42 #, python-format msgid "" "BridgeDB can provide bridges with several %stypes of Pluggable Transports%s,\n" @@ -77,14 +100,14 @@ msgid "" "\n" msgstr "" -#: lib/bridgedb/strings.py:39 +#: lib/bridgedb/strings.py:48 msgid "" "Some bridges with IPv6 addresses are also available, though some Pluggable\n" "Transports aren't IPv6 compatible.\n" "\n" msgstr "" -#: lib/bridgedb/strings.py:43 +#: lib/bridgedb/strings.py:52 #, python-format msgid "" "Additionally, BridgeDB has plenty of plain-ol'-vanilla bridges %s without any" @@ -95,20 +118,20 @@ msgid "" "\n" msgstr "" -#: lib/bridgedb/strings.py:56 +#: lib/bridgedb/strings.py:65 msgid "What are bridges?" msgstr "" -#: lib/bridgedb/strings.py:57 +#: lib/bridgedb/strings.py:66 #, python-format msgid "%s Bridges %s are Tor relays that help you circumvent censorship." msgstr "" -#: lib/bridgedb/strings.py:62 +#: lib/bridgedb/strings.py:71 msgid "I need an alternative way of getting bridges!" msgstr "" -#: lib/bridgedb/strings.py:63 +#: lib/bridgedb/strings.py:72 #, python-format msgid "" "Another way to get bridges is to send an email to %s. Please note that you " @@ -117,77 +140,77 @@ msgid "" "%s or %s." msgstr "" -#: lib/bridgedb/strings.py:70 +#: lib/bridgedb/strings.py:79 msgid "My bridges don't work! I need help!" msgstr "" -#: lib/bridgedb/strings.py:71 +#: lib/bridgedb/strings.py:80 #, python-format msgid "If your Tor doesn't work, you should email %s." msgstr "" -#: lib/bridgedb/strings.py:72 +#: lib/bridgedb/strings.py:81 msgid "" "Try including as much info about your case as you can, including the list of\n" "bridges and Pluggable Transports you tried to use, your Tor Browser version,\n" "and any messages which Tor gave out, etc." msgstr "" -#: lib/bridgedb/strings.py:79 +#: lib/bridgedb/strings.py:88 msgid "Here are your bridge lines:" msgstr "" -#: lib/bridgedb/strings.py:80 +#: lib/bridgedb/strings.py:89 msgid "Get Bridges!" msgstr "" -#: lib/bridgedb/strings.py:84 +#: lib/bridgedb/strings.py:93 msgid "Please select options for bridge type:" msgstr "" -#: lib/bridgedb/strings.py:85 +#: lib/bridgedb/strings.py:94 msgid "Do you need IPv6 addresses?" msgstr "" -#: lib/bridgedb/strings.py:86 +#: lib/bridgedb/strings.py:95 #, python-format msgid "Do you need a %s?" msgstr "" -#: lib/bridgedb/strings.py:90 +#: lib/bridgedb/strings.py:99 msgid "Your browser is not displaying images properly." msgstr "" -#: lib/bridgedb/strings.py:91 +#: lib/bridgedb/strings.py:100 msgid "Enter the characters from the image above..." msgstr "" -#: lib/bridgedb/strings.py:95 +#: lib/bridgedb/strings.py:104 msgid "How to start using your bridges" msgstr "" -#: lib/bridgedb/strings.py:96 +#: lib/bridgedb/strings.py:105 #, python-format msgid "" "To enter bridges into Tor Browser, follow the instructions on the %s Tor\n" "Browser download page %s to start Tor Browser." msgstr "" -#: lib/bridgedb/strings.py:99 +#: lib/bridgedb/strings.py:108 msgid "" "When the 'Tor Network Settings' dialogue pops up, click 'Configure' and " "follow\n" "the wizard until it asks:" msgstr "" -#: lib/bridgedb/strings.py:102 +#: lib/bridgedb/strings.py:111 msgid "" "Does your Internet Service Provider (ISP) block or otherwise censor " "connections\n" "to the Tor network?" msgstr "" -#: lib/bridgedb/strings.py:105 +#: lib/bridgedb/strings.py:114 msgid "" "Select 'Yes' and then click 'Next'. To configure your new bridges, copy and\n" "paste the bridge lines into the text input box. Finally, click 'Connect', and" @@ -196,24 +219,24 @@ msgid "" "button in the 'Tor Network Settings' wizard for further assistance." msgstr "" -#: lib/bridgedb/strings.py:113 +#: lib/bridgedb/strings.py:122 msgid "Displays this message." msgstr "" -#: lib/bridgedb/strings.py:114 +#: lib/bridgedb/strings.py:123 msgid "Request vanilla bridges." msgstr "" -#: lib/bridgedb/strings.py:115 +#: lib/bridgedb/strings.py:124 msgid "Request IPv6 bridges." msgstr "" -#. TRANLATORS: Please DO NOT tranlate the word the word "TYPE". -#: lib/bridgedb/strings.py:117 +#. TRANSLATORS: Please DO NOT translate the word the word "TYPE". +#: lib/bridgedb/strings.py:126 msgid "Request a Pluggable Transport by TYPE." msgstr "" -#: lib/bridgedb/strings.py:118 +#: lib/bridgedb/strings.py:127 msgid "Get a copy of BridgeDB's public GnuPG key." msgstr "" @@ -233,10 +256,6 @@ msgstr "" msgid "Contact" msgstr "" -#: lib/bridgedb/templates/base.html:100 -msgid "Public Keys" -msgstr "" - #: lib/bridgedb/templates/bridges.html:65 msgid "Uh oh, spaghettios!" msgstr ""

1 0

[bridgedb/develop] Merge branch 'translations/2014-05-16-update' into develop
by isis＠torproject.org 16 May '14

16 May '14

commit b0f56a699e5a65448f0c9a9bb35ce355faa0cbeb Merge: fe45b79 5557f6c Author: Isis Lovecruft <isis(a)torproject.org> Date: Fri May 16 18:43:43 2014 +0000 Merge branch 'translations/2014-05-16-update' into develop lib/bridgedb/i18n/templates/bridgedb.pot | 93 ++++++++++++++++++------------ 1 file changed, 56 insertions(+), 37 deletions(-)

1 0

[bridgedb/develop] Add CHANGELOG entries for bridgedb-0.2.1.
by isis＠torproject.org 16 May '14

16 May '14

commit fe45b79d296a4de14d472c873c83b62783a3fc0c Author: Isis Lovecruft <isis(a)torproject.org> Date: Fri May 16 18:37:31 2014 +0000 Add CHANGELOG entries for bridgedb-0.2.1. --- CHANGELOG | 101 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 95 insertions(+), 6 deletions(-) diff --git a/CHANGELOG b/CHANGELOG index 23ddd1e..76fe023 100644 --- a/CHANGELOG +++ b/CHANGELOG @@ -1,13 +1,102 @@ -Changes in version 0.2.1 - - * +Changes in version 0.2.1 - 2014-05-16 + * FIXES #5463 https://trac.torproject.org/projects/tor/ticket/5463 + Emails sent from BridgeDB's email distributor should now be signed. + - BridgeDB's emails will be signed with its online GnuPG keypair. The + public key has the following fingerprint: + DF81 1109 E17C 8BF1 34B5 EEB6 8DC4 3A28 4882 1E32 + The online keypair rotates (a new one is placed on the server once + per year), and it will ALWAYS be signed with BridgeDB's offline + keypair. + - The online keypair above contains two subkeys. The signing subkey + has the fingerprint: + 9FE3 9D1A 7438 9223 3B3F 66F2 21B5 54E9 5938 F4D0 + - BridgeDB's offline keypair has the following fingerprint: + 7B78 4370 15E6 3DF4 7BB1 270A CBD9 7AA2 4E8E 472E + All of BridgeDB's keys may be found on the public keyservers, as + well as at https://bridges.torproject.org/keys + + * FIXES #7547 https://trac.torproject.org/projects/tor/ticket/7547 + BridgeDB's email distributor will now send you a message + explaining how to use it, including valid commands and the list of + Pluggable Transport TYPES currently supported. To receive help + with the email distributor, simply send an email to + mailto:bridges@torproject.org. + - Any emails which do not contain a valid command will receive + the help text in response. + - Otherwise, to specifically request the help text, just say + "get help" + in the body of your email. + + * FIXES #7550 https://trac.torproject.org/projects/tor/ticket/7550 + BridgeDB's email responder is now interactive, as described in the + above entry for ticket #7547. + + * FIXES #8241 https://trac.torproject.org/projects/tor/ticket/8241 + BridgeDB's HTTP distributor won't tell you how to get obfs3 + bridges through email, although a blank email, or an email + containing "get help" will. + + * CLOSES #9678 https://trac.torproject.org/projects/tor/ticket/9678 + A "Select Language" button was requested for the HTTP distributor + on https://bridges.torproject.org. Instead, translated pages are + distributed automatically (via detecting the "Accept-Language" + header which can be set in the Settings panel of all modern + browers). + - To request a specific translation, the "lang=LOCALE" argument + can be added to the URL of any page. For example: + https://bridges.torproject.org/options?lang=ar + will provide the bridge options selection page in Arabic. + + * FIXES #11215 https://trac.torproject.org/projects/tor/ticket/11215 + BridgeDB's usage of gimp-captcha, which creates a local cache of + CAPTCHA for use on the HTTP distributor, now supports timeouts. If + a CAPTCHA is not solved within 30 minutes of being served to a + client, the solution is invalid regardless of its correctness. + + * FIXES #11475 https://trac.torproject.org/projects/tor/ticket/11475 + BridgeDB's email responder, up until this point, explained how to + use bridges with Vidalia. It now uses the same help text as found + at https://bridges.torproject.org/howto which explains how to + enter bridges into TorLauncher (used by Tor Browser and Tails). + + * FIXES #11522 https://trac.torproject.org/projects/tor/ticket/11522 + There were several errors and bugs in BridgeDB's email + distributor. The entire system of server supporting BridgeDB's + email distribution system was rewritten. + + * FIXES #11664 https://trac.torproject.org/projects/tor/ticket/11664 + Due to changes in the Python language builtin `buffer` in Python3, + which were backported to Python 2.7.6, but neither backported to + Python 2.6.x nor to Python <= 2.7.5, BridgeDB's use of + `io.StringIO` and `io.BytesIO` combined with buffers had to be + revised to support both the new and old Python `buffer` APIs. + + * FIXES #11753 https://trac.torproject.org/projects/tor/ticket/11753 + BridgeDB's emails should now be translated. + - The translations system for BridgeDB, as well as the template + system for emails, was completely rewritten. By default, email + responses are in English. To receive an alternate translation, + send an email to bridges+LOCALE(a)torproject.org, where "LOCALE" is + a locale specifier. + - For example, to receive BridgeDB emails translated into + Chinese, use mailto:bridges+zh_CN@torproject.org. + - Or for Farsi translations, use mailto:bridges+fa@torproject.org. + - For the full list of currently supported LOCALE codes, see + https://gitweb.torproject.org/user/isis/bridgedb.git/tree/HEAD:/lib/bridged… And includes the following general changes: - * UPDATE Italian (it) gettext file. - Thanks to Francesca Ciceri. + * UPDATES the Italian (it) gettext file. + Thanks to Francesca Ciceri. * ADD Welsh (cy) translations. - Thanks to huwwaters and littlegreykida. + Thanks to huwwaters and littlegreykida. * ADD Slovak (sk) translations. - Thanks to Michelozzo and Svistwarrior273. + Thanks to Michelozzo and Svistwarrior273. + * UPDATES the bridgedb.pot translation template file. All the new + strings in the email and HTTP user interfaces will now need + translation! To help out with translations, please see: + https://www.transifex.com/projects/p/torproject/resource/2-bridgedb-bridged… + * FIXES several typos in the BridgeDB's code documentation. + * ADDS code documentation for several previously undocumented modules. Changes in version 0.2.0 - 2014-04-19 * FIXES #5232 Perform long running and blocking transactions in

1 0

[user-manual/master] Added a note about system clock and timezone.
by mttp＠torproject.org 16 May '14

16 May '14

commit 7759fc327f469f2b37332be05beca329cc68b706 Author: Matt Pagan <mttp(a)torproject.org> Date: Fri May 16 10:27:06 2014 -0500 Added a note about system clock and timezone. --- C/known-issues.page | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/C/known-issues.page b/C/known-issues.page index 07b49cc..33e0c7e 100644 --- a/C/known-issues.page +++ b/C/known-issues.page @@ -13,6 +13,11 @@ <list> <item> + <p> + Tor needs your system clock (and your time zone) set to the correct time. + </p> + </item> + <item> <p>The following firewall software have been known to interfere with Tor and may need to be temporarily disabled:</p> <list>

1 0

[tor/master] Bump maint-0.2.4 version to 0.2.4.22-dev
by nickm＠torproject.org 16 May '14

16 May '14

commit 8d9602c21ccc0d93c82c651d94791df88cf4c9ad Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri May 16 09:16:54 2014 -0400 Bump maint-0.2.4 version to 0.2.4.22-dev (See discussion on #9553) --- configure.ac | 2 +- contrib/tor-mingw.nsi.in | 2 +- src/win32/orconfig.h | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index 42096db..1463af7 100644 --- a/configure.ac +++ b/configure.ac @@ -3,7 +3,7 @@ dnl Copyright (c) 2004-2006, Roger Dingledine, Nick Mathewson dnl Copyright (c) 2007-2013, The Tor Project, Inc. dnl See LICENSE for licensing information -AC_INIT([tor],[0.2.4.10-alpha-dev]) +AC_INIT([tor],[0.2.4.22-dev]) AC_CONFIG_SRCDIR([src/or/main.c]) AC_CONFIG_MACRO_DIR([m4]) AM_INIT_AUTOMAKE diff --git a/contrib/tor-mingw.nsi.in b/contrib/tor-mingw.nsi.in index d5379bd..d72072e 100644 --- a/contrib/tor-mingw.nsi.in +++ b/contrib/tor-mingw.nsi.in @@ -8,7 +8,7 @@ !include "LogicLib.nsh" !include "FileFunc.nsh" !insertmacro GetParameters -!define VERSION "0.2.4.10-alpha-dev" +!define VERSION "0.2.4.22-dev" !define INSTALLER "tor-${VERSION}-win32.exe" !define WEBSITE "https://www.torproject.org/" !define LICENSE "LICENSE" diff --git a/src/win32/orconfig.h b/src/win32/orconfig.h index f5d5cf4..9e0a41a 100644 --- a/src/win32/orconfig.h +++ b/src/win32/orconfig.h @@ -241,7 +241,7 @@ #define USING_TWOS_COMPLEMENT /* Version number of package */ -#define VERSION "0.2.4.10-alpha-dev" +#define VERSION "0.2.4.22-dev"

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits May 2014