December 2012 - tor-dev - lists.torproject.org

Re: [tor-dev] RFC on obfs3 pluggable transport
by Ian Goldberg 05 Jan '13

05 Jan '13

On Wed, Dec 12, 2012 at 03:13:59AM +0200, George Kadianakis wrote: > Ian Goldberg <iang(a)cs.uwaterloo.ca> writes: > > > [Should we not be copying tor-dev on this thread?] > > > > We definitely should. > > Is it OK if I forward the whole thread to tor-dev (including this mail > and your reply)? Feel free to do it yourself too if you want. I'll copy tor-dev on this email, and not snip things in order that context is mostly preserved. If you think some past snippage should be restored, feel free to forward that as well. > BTW, in my first email, I had tor-assistants CCed, but you stripped it > off when you replied, so I didn't add it again :) Oops; that was unintentional. My bad. But tor-dev is better, anyway. > > On Fri, Dec 07, 2012 at 02:09:21AM +0200, George Kadianakis wrote: > > <snip> > > > >> > You'll also need to be careful about the exact protocol to select > >> > whether to use the curve or the twist; I remember we discussed this at > >> > PETS, sitting outside the wine tasting. > >> > > >> > >> Ugh. I admit that even though I remember our discussion at PETS, I > >> don't recall that part of our discussion. What do you mean by "the > >> exact protocol to select whether to use the curve or the twist"? > >> > >> My plan would be to choose randomly between the base point of the > >> curve and the base point of its twist, make a public key using the > >> randomly chosen base point, and finally send the public key to the > >> other party. Looking at the Telex paper, this is similar to the > >> creation of a_0/a_1 in the 'Setup' phase of appendix 'Tagging Details'. > >> > >> IIUC the other party shouldn't care whether the public key was created > >> using the curve or its twist, and can just do another point > >> multiplication to derive the shared secret. > >> > >> Is this the protocol you are talking about, or am I getting my stuff > >> wrong? > > > > That works if clients know a pair of public keys for the bridge in > > advance. It was unclear to me whether this would be the case. Is it? > > Can we put public keys in with the bridge descriptors? In this case, > > you'd need 42 octets for the public key. The spec I see in gitweb > > doesn't assume that. Rather, it has all operations being performed on a > > common curve. > > > > Correct. Let's assume that clients _don't_ have any shared-secrets > beforehand. It makes our transport more deployable and usable, and it > doesn't rely on non-implemented pluggable transport features. > > (FWIW, adding public keys (or other info) to bridge descriptors is > supported by the pluggable transport spec (DECLARE option), but it's > not implemented. Support for passing public keys (or other info) to > pluggable transport proxies is implemented in ticket #3594 but it's > not ready for merge yet.) > > > The trick is that both sides need to use the *same* curve: either the > > main curve or the twist. So if I watch a host I suspect is an > > obfs3proxy responder and find that the first 21 bytes it outputs is > > always on the same curve as the first 21 bytes it received, that's good > > evidence for my suspicion. > > > > I see. > > Let me formalize the protocol I tried to describe in my previous mail. > > Alice randomly selects a bit 'b' \in {0,1}. Similar to Telex, the bit > 'b' selects whether Alice will use the normal curve E or its twist E'). > Depending on the bit 'b', Alice generates a public key on E or E'. > > Now, Alice sends to Bob her public key along with padding, as > described in the obfs3 spec. > > Bob receives Alice's message and parses the first 21 bytes, which he > considers her public key. Bob checks whether the public key fits E or > E'. Depending on the curve, Bob loads up the correct domain > parameters, does a point multiplication with Alice's public key and > his private key, and derives the shared secret. > > Now, Bob does the same dance with Alice, so that Alice can also derive > the shared secret. > > What's the problem with this protocol? When Bob "does a point multiplication with Alice's public key", you mean "Bob picks a private key y, and multiplies Alice's public key by y to yield the shared secret". Note that the resulting shared secret (y times Alice's public key) will be in the same group (E or E') that Alice's public key is in. Now what does Bob send to Alice? Bob should be sending y times the generator of the group. Which group? If Bob and Alice are to agree on the shared secret, it has to be the same group Alice used. Otherwise, Alice's computation will necessarily end up different from Bob's (since they'd be in different groups) and the two secrets won't match. So in order for this protocol to work, Bob has to always choose the same group he received as a public key from Alice. But that's now a distinguisher for the protocol: if I'm watching someone I think is running an obfsproxy3 bridge, and I notice that the first 21 bytes he receives on any TCP connection always lies in the same group as the first 21 bytes he sends in response, then I can be pretty confident in my suspicion. > I think it's similar to how Telex generates and inspects tags: Looking > at the algorithm of the "Telex tag inspection" section of the Telex > paper, it seems to me that the Telex station doesn't know whether the > tag is on the curve or its twist either. The big difference is that Telex uses *static* DH (and gains forward secrecy by rotating keys): the client comes pre-loaded with (rP, rP') where P and P' are generators of E and E'. The Telex client then randomly picks Q to be either P or P', and randomly picks s, and sends sQ. The Telex station then can tell which group sQ is in, and multiply sQ by r. Conversely, the client uses whichever of rP and rP' corresponds to its choice of Q, and multiplies that by s. Then the secrets match. The important distinction is that in Telex, the client *already knows one public key in each group*. In the above obfsproxy3 proposal, it does not. > I tried to find how the Telex station code does it, but I didn't > manage to find the telex-relay code on the Internet :( Indeed, I don't believe the UMich people have (yet?) published it. > > Are we married to using elliptic curves? Is performance a serious > > concern at the moment? If not, it may be easier to use Z_p, while still > > using a trick similar to the "twist": > > > > No, we are not married to elliptic curves. It was just that the only > trick I knew on hiding DH public keys was the Telex trick, which uses > ECC. > > > Let p = 3 mod 4 be prime, with q=(p-1)/2 also prime, and p is at least > > 1536 bits. (2048 if there's room.) [Use group 5 or group 14 from RFC > > 3526.] Let g be a generator of the order-q subgroup of Z_p^* (g=2 for > > the two above groups from the RFC.) > > > > To pick a private key, pick a random 1536-bit (or 2048-bit) number, and > > force the low bit to 0. So there are 1535 (2047) bits of randomness, > > which is the size of q. Let x be that private key. Let X = g^x mod p. > > > > Here's the trick: When you send the public key, randomly decide to send > > either X or p-X. That will make the public key part a uniform 1536-bit > > (2048-bit) string (well, negligibly different from uniform). > > > > The other side constructs y and Y=g^y mod p in the same way, and sends > > either Y or p-Y. > > > > Note that both (p-Y)^x = Y^x mod p since x is even, and similarly > > (p-X)^y = X^y mod p, so key derivation goes through unchanged. > > > > The downside of the larger public keys is that it puts a lower bound on > > the size of the data sent by the initiator before the responder answers. > > > > Ha. The Z_p stunt you describe is nifty! I will seriously consider it, > if the telex-curve protocol doesn't work out without a pre-shared > public key. Note that the above protocol assumes that p is very close to a power of 256, but that's true of the RFC 3526 groups 5 and 14 I pointed to. > > On a side note, in Philipp Winter's "put the hash there" trick, I think > > it would be better to use HMAC(SHARED_SECRET, "obfsproxy3 delimiter > > string") rather than h(SHARED_SECRET). > > > > True. > > As a matter of fact, we should probably have two HMACs, one for the > initiator and another for the responder. Otherwise, hashing the > SHARED_SECRET with a common key, will result in HASH_LEN bytes that > appear both in the initiator's and in the responder's traffic stream. Yes indeed. - Ian

2 4

want to contribute to tor
by Debamitro Chakraborti 04 Jan '13

04 Jan '13

Hi, I am a C/C++ programmer wanting to dabble in the world of open source. I got to know of Tor and I felt the product is an important one for humanity. I have downloaded, built and run tor and also torsocks. Are there any coding tasks needed in tor at present? Do let me know. Regards, Debamitro Chakraborti -- http://about.me/debamitro

5 5

TorCtl Deprecation and Stem Plans
by Damian Johnson 01 Jan '13

01 Jan '13

Hi all. Just a friendly heads up concerning a couple things going on in our python controller space. The first is that Mike and I have decided to deprecate TorCtl [1] and make it a part of TorFlow (the framework used to support the Bandwidth Authorities and SoaT). The TorCtl codebase has largely been frozen for years out of concern for the stability of the Bandwidth Authorities (which lack any tests). If you're writing scripts or controller applications for Tor then you're encouraged to move to either... * Stem (https://stem.torproject.org/) Library with a similar design to TorCtl, but friendlier APIs and documentation. This has reached feature parity with TorCtl and is still being actively developed, so if there's something it can do to better suit your needs then please let me know! * Txtorcon (https://txtorcon.readthedocs.org/) Twisted controller library written by Meejah, and used in projects like Ooni Probe. Both of these libraries have extensive test suites and are being very actively maintained. ======================================== The second part are my plans regarding Stem. As of early December we've reached feature completion, covering just about everything in the control-spec and dir-spec. Next up is migrating our controllers. So far we've moved arm [2] (the largest python controller we have) and the consensus-tracker [3]. Other controllers we have queued up to move are TorBEL, Tor Weather, and the control interpretor. I've avoided making an initial release announcement for stem because until we have actual users of the library we won't be sure that we nailed a nice, intuitive API (and hence, can't promise that it'll be frozen). On reflection this is letting the perfect be the enemy of the good. Stem's API is unlikely to change substantially, and holding off on an initial release poses a chicken-and-egg situation. Users want a frozen API before using stem, but we need users before feeling confident enough to lock down the API. So here's what I propose. For the next couple months stem will have an open beta. If you'd like to have input on the future of our python controller space then please give Stem a try and tell me the following... * What pain points did you encounter? Is there anything that you'd like to see changed or that we're missing? * If your project is public then please tell me where I can find your code. I'll review it, both to suggest improvements and see how we can tweak stem to better suit your needs. In the unlikely event we make a backward incompatible change I'll check with the beta participants to be sure we don't break anyone (and submit fixes if we do). Thoughts? -Damian PS. Many thanks to Ravi, Sean, Eoin, Beck, Erik, Megan, Sathyanarayanan, and everyone else who has helped stem get to this point. Happy New Year! [1] https://gitweb.torproject.org/pytorctl.git [2] http://www.atagar.com/arm/ [3] https://gitweb.torproject.org/atagar/tor-utils.git/blob/HEAD:/consensusTrac…

3 3

Fwd: [Wikitech-l] Can we help Tor users make legitimate edits?
by Zack Weinberg 31 Dec '12

31 Dec '12

The author asked me to forward this message to tor-dev. I can vouch for their personal interest in making something happen here and their being in a position of ability to do so from Wikimedia's end. Replies should go to wikitech-l and/or the author as well as here. It looks like there was quite a bit of a thread there already: http://lists.wikimedia.org/pipermail/wikitech-l/2012-December/065345.html (note in particular that their primary concern seems to be "sockpuppets" rather than spammers). ---- Begin forwarded message: From: Sumana Harihareswara <sumanah(a)wikimedia.org> To: wikitech-l(a)lists.wikimedia.org Subject: [Wikitech-l] Can we help Tor users make legitimate edits? TL;DR: A few ideas follow on how we could possibly help legit editors contribute from behind Tor proxies. I am just conversant enough with the security problems to make unworkable suggestions ;-), so please correct me, critique & suggest solutions, and perhaps volunteer to help. The current situation: https://en.wikipedia.org/wiki/Wikipedia:Advice_to_users_using_Tor_to_bypass… We generally don't let anyone edit or upload from behind Tor; the TorBlock extension stops them. One exception: a person can create an account, accumulate lots of good edits, and then ask for an IP block exemption, and then use that account to edit from behind Tor. This is unappealing because then there's still a bunch of in-the-clear editing that has to happen first, and because then site functionaries know that the account is going to be making controversial edits (and could possibly connect it to IPs in the future, right?). And right now there's no way to truly *anonymously* contribute from behind Tor proxies; you have to log in. However, since JavaScript delivery is hard for Tor users, I'm not sure how much editing from Tor -- vandalism or legit -- is actually happening. (I hope for analytics on this and thus added it to https://www.mediawiki.org/wiki/Analytics/Dreams .) We know at least that there are legitimate editors who would prefer to use Tor and can't. People have been talking about how to improve the situation for some time -- see http://cryptome.info/wiki-no-tor.htm and https://lists.torproject.org/pipermail/tor-dev/2012-October/004116.html . It'd be nice if it could actually move forward. I've floated this problem past Tor and privacy people, and here are a few ideas: 1) Just use the existing mechanisms more leniently. Encourage the communities (Wikimedia & Tor) to use https://en.wikipedia.org/wiki/Wikipedia:Request_an_account (to get an account from behind Tor) and to let more people get IP block exemptions even before they've made any edits (< 30 people have gotten exemptions on en.wp in 2012). Add encouraging "get an exempt account" language to the "you're blocked because you're using Tor" messaging. Then if there's an uptick in vandalism from Tor then they can just tighten up again. 2) Encourage people with closed proxies to re-vitalize https://en.wikipedia.org/wiki/Wikipedia:WOCP . Problem: using closed proxies is okay for people with some threat models but not others. 3) Look at Nymble - http://freehaven.net/anonbib/#oakland11-formalizing and http://cgi.soic.indiana.edu/~kapadia/nymble/overview.php . It would allow Wikimedia to distance itself from knowing people's identities, but still allow admins to revoke permissions if people acted up. The user shows a real identity, gets a token, and exchanges that token over tor for an account. If the user abuses the site, Wikimedia site admins can blacklist the user without ever being able to learn who they were or what other edits they did. More: https://cs.uwaterloo.ca/~iang/ Ian Golberg's, Nick Hopper's, and Apu Kapadia's groups are all working on Nymble or its derivatives. It's not ready for production yet, I bet, but if someone wanted a Big Project.... 3a) A token authorization system (perhaps a MediaWiki extension) where the server blindly signs a token, and then the user can use that token to bypass the Tor blocks. (Tyler mentioned he saw this somewhere in a Bugzilla suggestion; I haven't found it.) 4) Allow more users the IP block exemption, possibly even automatically after a certain number of unreverted edits, but with some kind of FlaggedRevs integration; Tor users can edit but their changes have to be reviewed before going live. We could combine this with (3); Nymble administrators or token-issuers could pledge to review edits coming from Tor. But that latter idea sounds like a lot of social infrastructure to set up and maintain. Thoughts? Are any of you interested in working on this problem? #tor on the OFTC IRC server is full of people who'd be interested in talking about this. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation

2 1

Xeronet's torrc
by Nathan Freitas 31 Dec '12

31 Dec '12

I was just made aware of this "advanced" torrc configuration below. Any comments on it, from a client-only/mobile device perspective? I can understand how it might deanonymize you, but it might be a trade-off that users seeking fast circumvention only may want to make. http://xeronet.primeoptic.net/tor/torrc.php *** Advanced Torrc Settings - Did You Edit The Config ? This is a working example of an advanced configuration for use with the Tor Browser Bundle. N.B. Vidalia will show the following 'warning' message if you use this Torrc file and specifically StrictNodes 1 : "You have asked to exclude certain relays from all positions in your circuits. Expect hidden services and other Tor features to be broken in unpredictable ways." If something is broken or you cannot connect, your should set StrictNodes to 0 again. If you don't want to see warning messages the you can always switch them off in Vidalia > Messages > Options. xeronet Torrc - v1.4 - 12/12/2012 - Download ... 'Save As'. This file can be used to replace the existing Torrc file in your Tor Browser Bundle > Data > Tor The idea is to make Tor faster and safer for regular internet browsing and it does work ! How does it work ? Well, Tor works just great 'out-of-the-box', however, by tweaking settings and controlling how Tor connects to its own network we can improve on privacy and security. (1) Block 'Bad' Exit Nodes using: ExcludeNodes 'Bad' Exit Nodes are flagged in red here: http://torstatus.blutmagie.de N.B. torstatus.blutmagie.de will probably load very slowly in your web browser and might even appear to 'freeze' ! It contains a lot of 'live' data. Be patient and it will load up OK. (2) Block 'problematic' internet countries using: ExcludeNodes 'problematic' internet countries can be found here: http://map.opennet.net and here: https://wikipedia.org/wiki/Internet_censorship_by_country N.B. The 'default' list of blocked Countries has been selected by including those Countries using Pervasive and Substantial blocking of Internet Tools and Political, Social, Conflict and/or Security website filtering... You have lots of Tor servers to choose from... Why should you use a Tor server in a country that heavily filters its own citizens or perhaps even worse... (Don't worry - In doing this you will not be preventing access to the Tor network from users in these Countries.) Recommended: 'problem' internet countries Block List: Afghanistan, Algeria, Armenia, Argentina, Azerbaijan, Bangladesh, Belarus, Burma, China, Colombia, Cuba, Egypt, Eritrea, Ethiopia, Gambia, Georgia, Ghana, Guatemala, India, Indonesia, Iraq, Iran, Israel, Jordan, Kazakhstan, Kuwait, Kyrgyzstan, Laos, Lebanon, Libya, Macau, Malawi, Mali, Malaysia, Mauritania, Mexico, Moldova, Mongolia, Morocco, Nepal, Nigeria, North Korea, Oman, Pakistan, Palestinian Territories, Paraguay, Peru, Philippines, Qatar, Russia, Rwanda, Saudi Arabia, Somalia, South Africa, South Korea, Sudan, Sri Lanka, Syria, Taiwan, Tajikistan, Thailand, Tunisia, Turkey, Turkmenistan, UAE, Uganda, Uzbekistan, Venezuela, Vietnam, Yemen, Zimbabwe. See: https://wikipedia.org/wiki/List_of_Internet_top-level_domains for Country Codes. N.B. You might also consider adding / blocking your own country or location, if it is not already included in the list. This will have obvious benefits in increasing both your privacy and anonymity. Additional: 'slow' internet countries (below 1000 kbps avg.) Avoid List: Angola, Benin, Bolivia, Botswana, Burkina Faso, Burundi, Cameroon, Central African Republic, Chad, Comoros, Republic of the Congo, Democratic Republic of the Congo, Côte d'Ivoire, Djibouti, Equatorial Guinea, Gabon, Guinea, Guinea-Bissau, Guyana, Liberia, Mozambique, Namibia, Niger, Rwanda, Sao Tome and Príncipe, Senegal, Sierra Leone, Swaziland, Tanzania, Uganda, Zambia. See: http://www.akamai.com/stateoftheinternet/ for avg. internet speeds. (3) Block potentially mis-configured servers using: ExcludeNodes Mis-configured nodes might include: default or Unnamed servers etc. (4) Select fast (high bandwidth) Entry servers using: EntryNodes (5) Select fast (high bandwidth) Exit servers using: ExitNodes Fast (high bandwidth) servers can be found here: http://torstatus.blutmagie.de N.B. Servers selected for this example Torrc have been chosen because they are run by individuals or non-profit organizations with an interest or involvement in supporting internet privacy and security, freedom of speech and / or the free software movements i.e. torservers.net, globenet.org, riseup.net, privacyfoundation.ch, privacyfoundation.de, tor.noisebridge.net, fsf.org, team-cymru.org, eff.org and others. (6) Use StrictNodes 1 to enforce the server selection. N.B. "If StrictNodes is set to 1, Tor will treat the ExcludeNodes option as a requirement to follow for all the circuits you generate, even if doing so will break functionality for you. If StrictNodes is set to 0, Tor will still try to avoid nodes in the ExcludeNodes list, but it will err on the side of avoiding unexpected errors. Specifically, StrictNodes 0 tells Tor that it is okay to use an excluded node when it is necessary to perform relay reachability self-tests, connect to a hidden service, provide a hidden service to a client, fulfill a .exit request, upload directory information, or download directory information. (Default: 0)" (7) Use FascistFirewall 1 to force port 80 (http) and port 443 (https) access. N.B. "If 1, Tor will only create outgoing connections to ORs running on ports that your firewall allows (defaults to 80 and 443; see FirewallPorts). This will allow you to run Tor as a client behind a firewall with restrictive policies, but will not allow you to run as a server behind such a firewall. If you prefer more fine-grained control, use ReachableAddresses instead." If you choose to do this then make sure that your selected Nodes use port 80 and/or port 443 (8) Use UseEntryGuards 1 for increased security. N.B. "If this option is set to 1, we pick a few long-term entry servers, and try to stick with them. This is desirable because constantly changing servers increases the odds that an adversary who owns some servers will observe a fraction of your paths. (Defaults to 1.)" (9) Use ClientOnly 1 for the Tor Browser Bundle. N.B. "If set to 1, Tor will under no circumstances run as a server or serve directory requests. The default is to run as a client unless ORPort is configured. (Usually, you don’t need to set this; Tor is pretty smart at figuring out whether you are reliable and high-bandwidth enough to be a useful server.) (Default: 0)" (10) Tips: Do add Authority servers to your EntryNodes list. Do add ExitNodes as EntryNodes. Don't add EntryNodes as ExitNodes ! Do block new 'bad' Nodes in ExcludeNodes. Do check the status of the nodes that you have selected on a regular basis. Do find and add new bridge nodes as EnrtyNodes if you require them for access. If you have problems connecting to Tor then changing FascistFirewall to 0 and/or StrictNodes to 0 will probably fix the issue. Do read the Tor Manual: https://www.torproject.org/docs/tor-manual.html > CLIENT OPTIONS Remember: You can view or edit your Torrc file using Notepad.exe or another text editor. This example Torrc file will be updated when necessary, So do check back here occasionally for a new version. Thank you and safe browsing.

2 1

Opt-in model for flash proxy
by David Fifield 28 Dec '12

28 Dec '12

Alexandre recently finished up work adding an opt-in option for flash proxies. Now, clicking on the badge will bring up this page with yes/no buttons: http://crypto.stanford.edu/flashproxy/options.html The default model is still opt-out, though this may change in the future. If you want to make the badge on your site opt-in-only, add the cookierequired query parameter to your iframe, and encourage your visitors to visit the options page. The options work by setting a cookie. <iframe src="//crypto.stanford.edu/flashproxy/embed.html?cookierequired" width="80" height="15" frameborder="0" scrolling="no"></iframe> To summarize, here is what happens if you use cookierequired or not. The only difference is when the user hasn't set a cookie at all. Without cookierequired: no cookie cookie=no cookie=yes Will I be a proxy? yes no yes With cookierequired: no cookie cookie=no cookie=yes Will I be a proxy? no no yes If we switch to opt-in by default in the future, we'll ignore the cookierequired parameter and always use the no/no/yes part of the table. It will also help us switch to opt-in-only if we can get lots of people to opt in in advance. David Fifield

1 0

Brainstorming a Tor censorship analysis tool
by Philipp Winter 26 Dec '12

26 Dec '12

Hi there, Deliverable 6 for sponsor Z says: > 6. Start a tool that a censored developer can run to discover why their Tor is > failing to connect: brainstorm a list of "things to check", and sort them by > how useful they'd be to check / how hard they'd be to build. (#7137) The deliverable is due on Feb. 28, 2013 so we should get started. Some background about the deliverable: The reason for this project is that debugging possible censorship events is tedious right now. We often have no access to machines in censoring countries and we are dependent on users creating packet dumps for us. This tool should speed up and automate this process to some extent. Censored users should run it and the tool should then collect data which should then somehow reach us. I created the following wiki page which should contain all the necessary information: https://censorshipwiki.torproject.org/TorCensorshipAnalyzer Please add/modify stuff and share your opinion. Since there is quite some overlap with OONI, it would be great if the OONI people could give feedback. Cheers, Philipp

5 5

Testing in Tor [was Re: Brainstorming a Tor censorship analysis tool]
by Nick Mathewson 23 Dec '12

23 Dec '12

On Wed, Dec 19, 2012 at 2:29 PM, Simon <simonhf(a)gmail.com> wrote: [...] > Maybe there is no automated testing for any Tor projects? At least a > quick search on the wiki only found [1] which lists possible ways to > test (but was created 7 months ago and apparently not updated since > and collecting dust) and [2] discussing a manual test procedure for > TBB. However, tor-0.2.3.25.tar.gz does reveal some test files but the > source code ratio of production code to test code is not inspiring at > first glance: [...] Be aware that we've also been using 'chutney' and 'experimentor' for integration testing. They supplement coverage a bit, though they need more tests, and each tends to hide certain classes of error. > Tor seems to have good planning compared to most open source projects. > So I would be interested in hearing why testing is apparently 'falling > between the cracks'. Why isn't there just 10 times more test LOC? Not because of any hatred or disapproval of tests--just because nobody's written that 100 kloc of testing code yet. I think that's for two main reasons: * We were in a hurry when we wrote lots of the stuff we wrote. * Large parts of the codebase have been written in a tightly coupled style that needs refactoring before it can be tested without a live Tor network at hand. * Until Tor 0.2.2, our testing framework didn't let us have tests that touched global state, which made our tests in general pretty fragile. > What > about implementing a new policy immediately: Any new production LOC > committed must be covered by tests, or peer reviewed and > democratically excluded? Goodness knows we need more review and testing. It doesn't seem fair to reject patches for lacking test coverage when they are patches to code that itself lacks coverage, though. If you write a 5-line patch to connection_ap_rewrite_and_attach, for instance, you probably shouldn't be on the hook for refactoring the whole function to make it testable, though you will be hard-pressed to write any tests for that monster without a complete refactor. It might be a reasonable goal to try to set a plan for increasing test coverage by a certain percentage with each release. If you like and you have time, it would be cool to stop by the tickets on trac.torproject.org for milestone "Tor: 0.2.4.x-final" in state "needs_review" and look to see whether you think any of them have code that would be amenable to new tests, or to look through currently untested functions and try to figure out how to make more of them tested and testable. yrs, -- Nick

5 20

Stem code review 2012-12-21
by Sean Robinson 22 Dec '12

22 Dec '12

Stem devs, This is a review of Stem commits from 2012-12-11 through 2012-12-21. Damian, you are very good at documentation, concise and informative. I tend to hit one or the other, but not both. I recognize when someone gets the right mix. Good work. I, too, have found logging.basicConfig[0] hides too much about how it works and, now, I roll my own logging handler early. Would GETINFO/GETCONF cache hit logging[1] benefit from log_once? Or even something between log and log_once (e.g. rate_limited_log)? Is there any particular reason for moving away from readthedocs.org? I'm curious if there was more than a desire to self-host as much as possible. Good work on the Controller.get_conf() clean-up[2]. This is easier to code against with the predictable return types. I have already written a new method with this and always getting a list (event empty) reduces the amount of error checking I had to do. The heartbeat time tracking is a good idea[3]. But, I wonder, should this bother with an accessor method? Could this work as just well as an (non-callable) attribute? [0]: https://gitweb.torproject.org/stem.git/commit/a7b275a3d64301da4d23137dbadd4… [1]: https://gitweb.torproject.org/stem.git/commit/9b5ff19be35ebbf8c75772a63406b… [2]: https://gitweb.torproject.org/stem.git/commit/5b45d3125c811067d7c3ba0a11e32… [3]: https://gitweb.torproject.org/stem.git/commit/6bc92816dc4356a204fdde0f160ee… -- Sean Robinson

2 1

Idle connections in netstat
by Angus Gardner 20 Dec '12

20 Dec '12

Hi, I am fairly new to Tor and have been running a relay for a couple of weeks. I have configured a RelayBandwithRate of only 100 KB and so only see a few active connections at any one time. Recently I have been noticing, in netstat output, a high level of established but idle TCP connections to other tor-hosts. (Out of 96 ESTABLISHED connections there are 90 with Recv-Q & Send-Q of 0.) Is this part of the rolling connection set of this host or something else? Eg: #netstat -e Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State User Inode ... tcp 0 0 my.ip:55528 digi00299.digicube:9001 ESTABLISHED tor 449100 tcp 0 0 my.ip:56308 tor01.spacedump.ne:9001 ESTABLISHED tor 440912 tcp 0 0 my.ip:57934 torsrvo.snydernet:https ESTABLISHED tor 443309 tcp 0 0 my.ip:9001 tor18.anonymizer.:57588 TIME_WAIT root 0 tcp 0 0 my.ip:46943 tor.parad0x.org:https ESTABLISHED tor 449313 tcp 0 0 my.ip:9001 vodka.projekt16.b:51520 ESTABLISHED tor 449337 tcp 0 0 my.ip:9001 gamma.rueckgr.at:39215 ESTABLISHED tor 449218 tcp 0 0 my.ip:44622 dannenberg.ccc.de:https ESTABLISHED tor 431598 tcp 0 0 my.ip:39656 torsrvn.snydernet:https ESTABLISHED tor 446435 tcp 0 0 my.ip:9001 76.72.169.90:40606 TIME_WAIT root 0 tcp 0 93 my.ip:9001 torproxy10.teamcy:58154 ESTABLISHED tor 449452 tcp 0 0 my.ip:60081 v-603-kalfa-23-10:https ESTABLISHED tor 448047 tcp 0 1846 my.ip:35776 tor5.anonymizer.c:https ESTABLISHED tor 440943 . Cheers, Gus

3 4