- tor-commits - lists.torproject.org

[torspec/master] add first stab at generic GetTor spec
by ioerror＠torproject.org 22 Aug '11

22 Aug '11

commit 9f386a18c9d437ae5e32d51f0262ac83e411ac5e Author: Jacob Appelbaum <jacob(a)appelbaum.net> Date: Mon Aug 22 12:21:57 2011 +0200 add first stab at generic GetTor spec --- gettor-spec.txt | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 69 insertions(+), 0 deletions(-) diff --git a/gettor-spec.txt b/gettor-spec.txt new file mode 100644 index 0000000..43b126f --- /dev/null +++ b/gettor-spec.txt @@ -0,0 +1,69 @@ + + GetTor specification + Jacob Appelbaum + +0. Preface + + This document describes GetTor and how to properly implementation GetTor. + +1. Overview + + GetTor was created to resolve direct and indirect censorship of Tor's software. + In many countries and networks Tor's main website is blocked and would be Tor + users are unable to download even the source code to the Tor program. Other + software hosted by the Tor Project is similarly censored. The filtering + of the possible download sites is sometimes easy to bypass by using our TLS enabled + website. In other cases the website and all of the mirrors are entirely + blocked; this is a situation where a user seems to actually need Tor to fetch + Tor. We discovered that it is feasible to use alternate transport methods such + as SMTP between a non-trusted third party or with IRC and XDCC. + +2. Implementation + + Any compliant GetTor implementation will implement at least a single transport + to meet the needs of a certain class of users. It should be i18n and l10n compliant + for all user facing interactions; users should be able to manually set their + language and this should serve as their preference for localization of any + software delivered. The implementation must be free software and it should be + freely available by request from the implementation that they interface with + to download any of the other software available from that GetTor instance. + Security and privacy considerations should be described on a per transport + basis. + +3. SMTP transport + + The SMTP transport for GetTor should allow users to send any RFC822 compliant message + in any known human language; GetTor should respond in whatever language is + detected with supplementary translations in the same email. GetTor shall offer + a list of all available software in the body of the email - it should offer the + software as a list of packages and their subsequent descriptions. + +3.1 SMTP transport security considerations + + Any GetTor instance that offers SMTP as a transport should optionally implement + the checking of DKIM signatures to ensure that email is not forged. + Optionally GetTor should take an OpenPGP key from the user and encrypt the + response with a blinded message. + +3.2 SMTP transport privacy considerations + + Any GetTor instance that offers SMTP as a transport must at least store the + requester's address for the time that it takes to process a response. This + should not be written to any permanent storage medium; GetTor should function + without any long term storage excepting a cache of files that it will send to + any user who requests it. + + GetTor may optionally collect anonymized usage statistics to better understand + how GetTor[1] is in use. This must not include any personally identifying + information about any of the requester beyond language selection. + +4. Other transports + + At this time no other transports have been specified. IRC XDCC is a likely useful + system as is XMPP/Jabber with the newest OTR file sharing transport. + +5. Implementation suggestions + + It is suggested that any compliant GetTor instance should be written in a so + called "safe" language such as Python. +

1 0

[gettor/master] update the strings based on the #3383 fix
by arma＠torproject.org 22 Aug '11

22 Aug '11

commit 093b8196f9bdb93fade943a6c94905898d363416 Author: Roger Dingledine <arma(a)torproject.org> Date: Sun Aug 21 21:53:38 2011 -0400 update the strings based on the #3383 fix --- i18n/templates/gettor.pot | 9 ++++----- 1 files changed, 4 insertions(+), 5 deletions(-) diff --git a/i18n/templates/gettor.pot b/i18n/templates/gettor.pot index 4f49701..1cc52a5 100644 --- a/i18n/templates/gettor.pot +++ b/i18n/templates/gettor.pot @@ -8,7 +8,7 @@ msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2011-02-27 00:10+0100\n" +"POT-Creation-Date: 2011-08-21 21:50-0400\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" "Language-Team: LANGUAGE <LL(a)li.org>\n" @@ -244,24 +244,23 @@ msgstr "" #: lib/gettor/i18n.py:536 msgid "" -"Thank you for your request. \n" "It was successfully understood. Your request is currently being processed.\n" "Your package should arrive within the next ten minutes." msgstr "" -#: lib/gettor/i18n.py:540 +#: lib/gettor/i18n.py:539 msgid "" "If it doesn't arrive, the package might be too big for your mail provider.\n" "Try resending the mail from a GMAIL.COM or YAHOO.COM account." msgstr "" -#: lib/gettor/i18n.py:543 +#: lib/gettor/i18n.py:542 msgid "" "Unfortunately we are currently experiencing problems and we can't fulfill\n" "your request right now. Please be patient as we try to resolve this issue." msgstr "" -#: lib/gettor/i18n.py:546 +#: lib/gettor/i18n.py:545 msgid "" "Unfortunately there is no split package available for the package you\n" "requested. Please send us another package name or request the same package \n"

1 0

r24960: {website} change our "should i be a relay or a bridge" answer, and lin (website/trunk/docs/en)
by Roger Dingledine 22 Aug '11

22 Aug '11

Author: arma Date: 2011-08-22 01:36:47 +0000 (Mon, 22 Aug 2011) New Revision: 24960 Modified: website/trunk/docs/en/bridges.wml website/trunk/docs/en/faq.wml Log: change our "should i be a relay or a bridge" answer, and link to it from the bridge page Modified: website/trunk/docs/en/bridges.wml =================================================================== --- website/trunk/docs/en/bridges.wml 2011-08-20 20:29:55 UTC (rev 24959) +++ website/trunk/docs/en/bridges.wml 2011-08-22 01:36:47 UTC (rev 24960) @@ -149,11 +149,12 @@ <hr> - If you want to help out and you can't run a <a href="<page - docs/tor-doc-relay>">normal Tor relay</a>, you should - run a bridge relay. You can configure it either way: + If you want to help out, you should <a href="<page + docs/faq>#RelayOrBridge">decide whether you want to run a normal Tor + relay or a bridge relay</a>. You can configure your bridge either + manually or graphically: <ul> - <li> manually <a href="<page docs/faq>#torrc">edit + <li>manually <a href="<page docs/faq>#torrc">edit your torrc file</a> to be just these four lines: <pre><code> SocksPort 0 Modified: website/trunk/docs/en/faq.wml =================================================================== --- website/trunk/docs/en/faq.wml 2011-08-20 20:29:55 UTC (rev 24959) +++ website/trunk/docs/en/faq.wml 2011-08-22 01:36:47 UTC (rev 24960) @@ -1255,20 +1255,21 @@ publically or not. - Right now, there are a small number of places in the world that filter - connections to the Tor network. So getting a lot of bridges running - right now is mostly a backup measure, a) in case the Tor network does - get blocked in more places, and b) for people who want an extra layer of - security because they're worried somebody will recognize that it's a - public Tor relay IP address they're contacting. + Right now, China is the main place in the world that filters + connections to the Tor network. So bridges are useful a) for users in + China, b) as a backup measure in case the Tor network gets blocked in + more places, and c) for people who want an extra layer of security + because they're worried somebody will recognize that it's a public + Tor relay IP address they're contacting. - So should you run a normal relay or bridge relay? If you have - lots of bandwidth, you should definitely run a normal relay — - bridge relays see very little use these days. If you're willing to - <a href="#ExitPolicies">be an exit</a>, you should definitely run a normal - relay, since we need more exits. If you can't be an exit and only have - a little bit of bandwidth, then flip a coin. Thanks for volunteering! + So should you run a normal relay or bridge relay? If you have lots + of bandwidth, you should definitely run a normal relay — the + average bridge doesn't see much load these days. If you're willing + to <a href="#ExitPolicies">be an exit</a>, you should definitely + run a normal relay, since we need more exits. If you can't be an + exit and only have a little bit of bandwidth, be a bridge. Thanks + for volunteering! <hr>

1 0

[torouter/master] Fixing minor typo while hunting down another bug
by runa＠torproject.org 21 Aug '11

21 Aug '11

commit d26ec7d068a3dc30a6464c5ea250d32d365bf699 Author: Runa A. Sandvik <runa.sandvik(a)gmail.com> Date: Sun Aug 21 22:05:38 2011 +0100 Fixing minor typo while hunting down another bug --- packages/torouter-prep/src/torouter_config.sh | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/packages/torouter-prep/src/torouter_config.sh b/packages/torouter-prep/src/torouter_config.sh index deaa72b..791a7b2 100644 --- a/packages/torouter-prep/src/torouter_config.sh +++ b/packages/torouter-prep/src/torouter_config.sh @@ -6,7 +6,7 @@ echo "This program will now reconfigure your Debian system into a Torouter" # For every file we touch, move it to the temp_dir and then tar it up in the end export temp_dir="`mktemp -d`" -export config_dir="/usr/share/torouter-prep/example-configs/" +export config_dir="/usr/share/torouter-prep/example-configs" # Add a user to administrate the Torouter later export ADMINUSER="torouter"

1 0

[gettor/master] Add a hack for the 'torfarsi1@torproject.org' email address.
by kaner＠torproject.org 21 Aug '11

21 Aug '11

commit e896a09ce20bcf8c59cd0118c903b72e1133d79a Author: Christian Fromme <kaner(a)strace.org> Date: Sun Aug 21 12:24:23 2011 +0200 Add a hack for the 'torfarsi1(a)torproject.org' email address. --- lib/gettor/filters.py | 11 +++++++++++ lib/gettor/requests.py | 5 ++++- 2 files changed, 15 insertions(+), 1 deletions(-) diff --git a/lib/gettor/filters.py b/lib/gettor/filters.py index 558e945..4deacb0 100644 --- a/lib/gettor/filters.py +++ b/lib/gettor/filters.py @@ -43,3 +43,14 @@ def checkAddressHack(userAddress): # User address looks good. return True + +def doToAddressHack(toAddress): + """Large HACK alert: If we received an email to the address + 'torfarsi1(a)torproject.org', we understand it to reply in Farsi to that + email. + """ + if re.compile(".*torfarsi1(a)torproject.org.*").match(toAddress): + return "<gettor+fa(a)torproject.org>" + else: + return toAddress + diff --git a/lib/gettor/requests.py b/lib/gettor/requests.py index a61ac14..9cadef5 100644 --- a/lib/gettor/requests.py +++ b/lib/gettor/requests.py @@ -9,6 +9,7 @@ import logging import gettor.utils import gettor.packages +import gettor.filters class requestMail: def __init__(self, config): @@ -33,7 +34,9 @@ class requestMail: in our reply should reflect that. So, use the `To:' field from the incoming mail, but filter out everything except the gettor@ address. """ - regexGettor = '.*(<)?(gettor.*(a)torproject.org)+(?(1)>).*' + regexGettor = '.*(<)?(gettor.*@.*torproject.org)+(?(1)>).*' + toField = gettor.filters.doToAddressHack(toField) + logging.debug("toField: %s" % toField) match = re.match(regexGettor, toField) if match: return match.group(2)

1 0

[flashproxy/master] Make facilitator requests block until a reg is available.
by dcf＠torproject.org 21 Aug '11

21 Aug '11

commit 90510d7bf565f0cc9876665aa6e85b55c8e5a3c1 Author: David Fifield <david(a)bamsoftware.com> Date: Sun Aug 21 01:20:22 2011 -0700 Make facilitator requests block until a reg is available. When a GET request happens, no longer return an empty string when there are no registrations to hand out. Instead, let the HTTP connection hang until there is something, then return. It can happen that the HTTP client (a flash proxy) disconnects before receiving its response; if we fail to send the reg that has just become available, add it back to the front of the queue to be handed out again. --- facilitator.py | 36 +++++++++++++++++++++++------------- 1 files changed, 23 insertions(+), 13 deletions(-) diff --git a/facilitator.py b/facilitator.py index b2f8304..4e14408 100755 --- a/facilitator.py +++ b/facilitator.py @@ -183,11 +183,23 @@ class RegSet(object): finally: self.cv.release() + def add_front(self, reg): + self.cv.acquire() + try: + if reg not in list(self.set): + self.set.append(reg) + self.cv.notify() + return True + else: + return False + finally: + self.cv.release() + def fetch(self): self.cv.acquire() try: - if not self.set: - return None + while not self.set: + self.cv.wait() return self.set.pop(0) finally: self.cv.release() @@ -212,13 +224,16 @@ class Handler(BaseHTTPServer.BaseHTTPRequestHandler): return reg = REGS.fetch() - if reg: + + try: + self.send_client(reg) log(u"proxy %s gets %s, relay %s (now %d)" % (proxy_addr_s, unicode(reg), options.relay_spec, len(REGS))) - self.send_client(reg) - else: + except socket.error: + # Something went wrong; likely the proxy disconnected without + # receiving a reg. Restore the reg to the front of the queue. + REGS.add_front(reg) log(u"proxy %s gets none" % proxy_addr_s) - self.send_client(None) def do_POST(self): client_addr_s = format_addr(self.client_address) @@ -286,13 +301,8 @@ class Handler(BaseHTTPServer.BaseHTTPRequestHandler): % (format_addr(self.client_address), repr(msg))) def send_client(self, reg): - if reg: - client_str = str(reg) - else: - # Send an empty string rather than a 404 or similar because Flash - # Player's URLLoader can't always distinguish a 404 from, say, - # "server not found." - client_str = "" + client_str = str(reg) + self.send_response(200) self.send_header("Content-Type", "x-www-form-urlencoded") self.send_header("Cache-Control", "no-cache")

1 0

[flashproxy/master] Log the socket error when we fail to send a reg.
by dcf＠torproject.org 21 Aug '11

21 Aug '11

commit c3ea89cb2a2c1e5f8496ec526b9d1c7451e2d06d Author: David Fifield <david(a)bamsoftware.com> Date: Sun Aug 21 01:57:34 2011 -0700 Log the socket error when we fail to send a reg. --- facilitator.py | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/facilitator.py b/facilitator.py index 4e14408..86b924c 100755 --- a/facilitator.py +++ b/facilitator.py @@ -229,11 +229,11 @@ class Handler(BaseHTTPServer.BaseHTTPRequestHandler): self.send_client(reg) log(u"proxy %s gets %s, relay %s (now %d)" % (proxy_addr_s, unicode(reg), options.relay_spec, len(REGS))) - except socket.error: + except socket.error, e: # Something went wrong; likely the proxy disconnected without # receiving a reg. Restore the reg to the front of the queue. REGS.add_front(reg) - log(u"proxy %s gets none" % proxy_addr_s) + log(u"proxy %s gets none (%s)" % (proxy_addr_s, str(e))) def do_POST(self): client_addr_s = format_addr(self.client_address)

1 0

[flashproxy/master] Document the facilitator's waiting until a reg is available.
by dcf＠torproject.org 21 Aug '11

21 Aug '11

commit 91cceeef62061d66732be7039d559f5fff49e8ef Author: David Fifield <david(a)bamsoftware.com> Date: Sun Aug 21 02:02:31 2011 -0700 Document the facilitator's waiting until a reg is available. --- design.txt | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/design.txt b/design.txt index 2d5ad2b..9b79724 100644 --- a/design.txt +++ b/design.txt @@ -151,8 +151,8 @@ Design of Flash proxies client=[<rtmfp-id>]&relay=<address>:<port> - If the value for the client parameter is empty, it means that there are no - client registrations for this proxy. + The facilitator keeps the HTTP session alive and does not send a + registration until one is available. The Flash proxy may serve more than one relay–client pair at once.

1 0

[flashproxy/master] Handle old-style socket.error in EPIPE handler.
by dcf＠torproject.org 21 Aug '11

21 Aug '11

commit 8d677ae0584524bbaa9a54cf953afd9291e72203 Author: David Fifield <david(a)bamsoftware.com> Date: Sun Aug 21 05:33:38 2011 -0400 Handle old-style socket.error in EPIPE handler. --- facilitator.py | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/facilitator.py b/facilitator.py index f7a4ba9..bea3957 100755 --- a/facilitator.py +++ b/facilitator.py @@ -319,7 +319,14 @@ class Handler(BaseHTTPServer.BaseHTTPRequestHandler): try: fn(self, *args) except socket.error, e: - if e.errno != errno.EPIPE: + try: + err_num = e.errno + except AttributeError: + # Before Python 2.6, exception can be a pair. + err_num, errstr = e + except: + raise + if err_num != errno.EPIPE: raise log(u"%s broken pipe" % format_addr(self.client_address)) return ret

1 0

[flashproxy/master] Lowercase "flash" when we're not specifically talking about Adobe Flash.
by dcf＠torproject.org 21 Aug '11

21 Aug '11

commit b4d17e5b2a2054c888ad26cc2aeb603bde2acb30 Author: David Fifield <david(a)bamsoftware.com> Date: Sun Aug 21 02:06:22 2011 -0700 Lowercase "flash" when we're not specifically talking about Adobe Flash. --- README | 8 ++++---- design.txt | 46 +++++++++++++++++++++++----------------------- facilitator.py | 2 +- 3 files changed, 28 insertions(+), 28 deletions(-) diff --git a/README b/README index cd6b7dd..c0c8f6f 100644 --- a/README +++ b/README @@ -1,15 +1,15 @@ == Introduction This is a set of tools that make it possible to connect Tor through an -Adobe Flash proxy running on another computer. The Flash proxy can be +browser-based proxy running on another computer. The flash proxy can be run just by opening a web page in a computer that has Flash Player installed. There are five main parts. Our terminology for each part is in quotes. 1. The Tor "client," running on someone's localhost. -2. A "connector," which waits for connections from the Flash proxy and +2. A "connector," which waits for connections from the flash proxy and the Tor client, and joins them together. -3. A Flash "proxy," running in someone's web browser. This piece is +3. A "flash proxy," running in someone's web browser. This piece is called swfcat because it is like a netcat implemented in Flash. 4. A "facilitator," a pseudo-HTTP server that keeps a list of clients that want a connection, and hands them out to proxies. @@ -139,7 +139,7 @@ Clients register with the facilitator by sending an HTTP message: POST / HTTP/1.0\r\n \r\n client=<ip-addr/rtmfp-id> -The Flash proxy also gets a client address over HTTP: +The flash proxy also gets a client address over HTTP: GET / HTTP/1.0\r\n \r\n The server sends back address specifications of a client and a relay in diff --git a/design.txt b/design.txt index 9b79724..f33468c 100644 --- a/design.txt +++ b/design.txt @@ -1,4 +1,4 @@ -Design of Flash proxies +Design of flash proxies 0. Problem statement @@ -13,7 +13,7 @@ Design of Flash proxies that themselves can reach the Tor network. We call this subset the unrestricted Internet. - A browser-based proxy (Flash proxy), running in a web page in the + A browser-based proxy (flash proxy), running in a web page in the unrestricted Internet, proxies connections between the restricted Internet and the Tor network. These proxies are expected to be temporary and short-lived, but their number will be great enough that @@ -23,7 +23,7 @@ Design of Flash proxies networking technologies is complicated by restrictions that prevent it being a straightforward proxy. Chief among these is the lack of listening sockets. Flash and, for example, WebSockets, can only - initiate outgoing connections, not receive incoming ones. The Flash + initiate outgoing connections, not receive incoming ones. The flash proxy can only connect to external hosts by connecting directly to them. The other significant restriction is that the proxy cannot connect to just any destination: Adobe Flash player requires the @@ -33,15 +33,15 @@ Design of Flash proxies 2. Components - Conceptually, each Flash proxy is nothing more than a simple proxy, + Conceptually, each flash proxy is nothing more than a simple proxy, which accepts connections from a client and forwards data to a server. But because of the limited networking facilities available to an in-browser application, several other pieces are needed. 1. Tor client: Is just ordinary Tor with a special configuration to - allow it to connect through a Flash proxy. It advertises its need + allow it to connect through a flash proxy. It advertises its need for a connection the the facilitator, and communicates with the - Flash proxy through the connector. + flash proxy through the connector. 2. Connector: Runs on the same computer as the Tor client. It opens one socket to the Internet and another to localhost. It waits for a connection on both sockets, then starts proxying data between them. @@ -50,13 +50,13 @@ Design of Flash proxies startup, the connector informs the facilitator that it is waiting for a connection. 3. Flash proxy: Runs in someone's browser, in an uncensored region of - the Internet. The Flash proxy first connects to the facilitator to + the Internet. The flash proxy first connects to the facilitator to get a client registration. It then makes two outgoing connections, one to a Tor relay and one to a waiting Tor client, and starts proxying data between them. 4. Facilitator: Keeps track of client registrations and hands them out to clients. It is capable of receiving client registrations in a - variety of ways. It sends registrations to Flash proxies over HTTP. + variety of ways. It sends registrations to flash proxies over HTTP. The facilitator is responsible for matching clients to proxies in a reasonable manner. 5. Tor relay: An ordinary Tor relay with no special configuration @@ -68,15 +68,15 @@ Design of Flash proxies 2. The restricted user starts Tor, which makes a SOCKS connection to the connector. 3. The connector notifies the facilitator that it needs a connection. - 4. An unrestricted user opens the web page containing the Flash proxy. - 5. The Flash proxy connects to the facilitator and asks for a client. + 4. An unrestricted user opens the web page containing the flash proxy. + 5. The flash proxy connects to the facilitator and asks for a client. 6. The facilitator sends one of its client registrations to the proxy. - 7. The Flash proxy connects to a Tor relay and to the waiting client + 7. The flash proxy connects to a Tor relay and to the waiting client connector. - 8. The connector receives the Flash proxy's connection and begins + 8. The connector receives the flash proxy's connection and begins relaying data between it and the Tor relay. - Later, the Flash proxy may go offline. Assuming that another Flash + Later, the flash proxy may go offline. Assuming that another flash proxy is available, it will receive the same client's address from the facilitator, and the local Tor client will reconnect to the client through it. @@ -89,19 +89,19 @@ Design of Flash proxies Bridge 127.0.0.1:9001 Socks4Proxy 127.0.0.1:9001 The address given for the "Bridge" option is actually irrelevant. The - connector will ignore it and connect (through the Flash proxy) to a + connector will ignore it and connect (through the flash proxy) to a Tor relay. The Tor client does not have control of its first hop. 6. Behavior of the connector The connector serves two purposes: It sends a registration message to - the facilitator and it carries data between a Flash proxy and the + the facilitator and it carries data between a flash proxy and the local Tor client. On startup, the connector sends a registration message to the facilitator, informing the facilitator that it is waiting for a connection. The facilitator will later hand this registration to a - Flash proxy. The registration message is an HTTP POST request of the + flash proxy. The registration message is an HTTP POST request of the form: POST / HTTP/1.0 @@ -121,19 +121,19 @@ Design of Flash proxies external address. The connector solves the impedance mismatch between the Tor client and - the Flash proxy, both of which want to make outgoing connections to + the flash proxy, both of which want to make outgoing connections to the other. The connector sits in between, listens for connections from both ends, and matches them together. The remote socket listens on port 9000 and the local on port 9001. The connector can serve a crossdomain policy in response to a - crossdomain request, allowing the Flash proxy to connect. On the local + crossdomain request, allowing the flash proxy to connect. On the local side, it acts as a SOCKS proxy (albeit one that always goes to the same destination). -7. Behavior of the Flash proxy +7. Behavior of the flash proxy - The Flash proxy polls the facilitator for client registrations. When + The flash proxy polls the facilitator for client registrations. When it receives a registration, it opens one connection to the given Tor relay, one to the given client, and begin proxying data between them. @@ -154,7 +154,7 @@ Design of Flash proxies The facilitator keeps the HTTP session alive and does not send a registration until one is available. - The Flash proxy may serve more than one relay–client pair at once. + The flash proxy may serve more than one relay–client pair at once. 8. Behavior of the facilitator @@ -163,11 +163,11 @@ Design of Flash proxies facilitator listens on port 9002. In the current implementation, the facilitator forgets a client - registration after giving it to a Flash proxy. The client must + registration after giving it to a flash proxy. The client must re-register if it wants another connection later. 9. Behavior of the Tor relay. The Tor relay requires no special configuration. It must also be - running a program that serves a crossdomain policy to allow a Flash + running a program that serves a crossdomain policy to allow a flash proxy to connect to it. diff --git a/facilitator.py b/facilitator.py index 86b924c..f7a4ba9 100755 --- a/facilitator.py +++ b/facilitator.py @@ -37,7 +37,7 @@ class options(object): def usage(f = sys.stdout): print >> f, """\ Usage: %(progname)s -r RELAY <OPTIONS> [HOST] [PORT] -Flash bridge facilitator: Register client addresses with HTTP POST requests +Flash proxy facilitator: Register client addresses with HTTP POST requests and serve them out again with HTTP GET. Listen on HOST and PORT, by default %(addr)s %(port)d. -d, --debug don't daemonize, log to stdout.

1 0