- tor-dev - lists.torproject.org

Documenting the translation process
by Runa A. Sandvik 07 Feb '13

07 Feb '13

Hi everyone, I started documenting how the translation process works for translators, developers, and those who manage it all: https://trac.torproject.org/projects/tor/wiki/doc/translation/Introduction. Any feedback will be greatly appreciated. Thanks, -- Runa A. Sandvik

1 0

Re: [tor-dev] [tor-talk] Exit Node Scanning Status
by Damian Johnson 03 Feb '13

03 Feb '13

> Actually, I might be a good fit. Feel free to ping me off-list to discuss. Unless there's a reason that you'd like to make this private it's better to have development discussions in the open (though tor-dev@ is probably more appropriate). Imho writing a SoaT counterpart based on either stem [1] or txtorcon [2] would be a great project if you're interested in improving our bad-exit detection infrastructure. Cheers! -Damian [1] https://stem.torproject.org/ [2] https://txtorcon.readthedocs.org/

4 5

Damian's Status Report - January 2013
by Damian Johnson 02 Feb '13

02 Feb '13

Hi all. This January I've been integrating feedback from first time stem users and implementing their feature requests. Projects included... * Python 3.x Support Stem now works under both the python 2.x and 3.x series. To use stem with python 3 simply use it when you install... python3 setup.py install This turned out to be a larger project than I had anticipated, taking almost half the month. But it was well worth the effort. https://gitweb.torproject.org/stem.git/commit/3930f1f https://trac.torproject.org/7843 * PEP8 Compliance Ditched most of my odd coding preferences in favor of the standard python style guide. I've integrated both pep8 and pyflakes with our tests to prevent regression. Hopefully this'll make it easier for others to contribute to stem. https://gitweb.torproject.org/stem.git/commit/d29ec4d https://trac.torproject.org/7631 * Arm Codebase Refactoring Prior to being shanghaied into the projects above I sunk quite a bit of time into overhauling arm. Thus far I've dropped around a third of the codebase in favor of similar (but tested!) capabilities in stem. * Descriptor Improvements Got lots of input concerning stem's descriptor module (thanks Karsten!), leading to quite a few improvements... * used feedback from Aaron Johnson to make the descriptor API less confusing * we now support bridge network status documents (https://trac.torproject.org/7938) * added support for '-legacy' authorities (https://trac.torproject.org/7866) * parsing error if network status documents lacked a 'directory-footer' line (https://trac.torproject.org/7932) * empty 'bridge-ip-versions' lines caused problems (https://trac.torproject.org/7967) * we didn't recognize the @type annotation for key certificates (https://trac.torproject.org/7987) * we weren't parsing the new ntor-onion-key lines (caught by sonu, https://trac.torproject.org/7868) * error when ran with pypy (caught by peer) Sean helped quite a bit at the start of the month, but has since been busy with other things. * added a Controller.get_streams() method (https://trac.torproject.org/7859) * tests for the close_stream() method (https://trac.torproject.org/7687) * expanded the Controller's unit tests (https://trac.torproject.org/7874) * fixed type checks (https://trac.torproject.org/7873) * fixed test_reattaching_listeners (https://trac.torproject.org/7872) Cheers! -Damian

1 0

extension works in FF, fails in TBB
by Greg Norcie 01 Feb '13

01 Feb '13

Dear Tor Devs, Hello. My name is Greg Norcie, I'm a PhD student at Indiana University, working on a project focusing on improving Tor usability. This is a follow up to a paper looking at usability issues with the Tor Browser Bundle. (http://petsymposium.org/2012/papers/hotpets12-1-usability.pdf) The research group I'm leading is currently working on tweaking the Tor Browser Bundle to test solutions to the issues we noted in a formal lab study. (Our previous paper simply suggested changes, but did not scientifically validate our suggestions) One issue we noted was people feeling Tor was slow. Now, this is a function of how Tor works - traffic passed through a series of nodes will always have more latency than a direct connection. So we are experimenting with a custom extension that pops up a message to TBB users when a delay is detected, to see if reframing the delay makes users tolerate the latency better. However, we have hit a snag. While in a normal, run of the mill Firefox install w/ the same extensions as the TBB, our extension functions - delays are detected and a pop up box appears. However, when we install our custom extension in the Tor Browser Bundle, it fails to work. We initially thought this might be because our extension was utilizing Javascript, but disabling NoScript doesn't fix thes issue. We're at a bit of a loss as to how to solve this issue, and are reaching out to the Tor developer community to see if anyone might be able to offer some insight as to what could be causing this failure. Our lead developer recently left the project, so we're struggling to get things on track in time for PETS) The extension in question is available at the following URL (password is "cryptoparty" - our uni's MegaUpload clone requires a password for all files): https://www.slashtmp.iu.edu/files/download?FILE=gnorcie%2F1700EHKJOv Any help anyone can provide would be greatly appreciated. (And of course, it goes without saying we will be making our code available to the Tor community) Thanks for reading, have a great day. Sincerely, Greg Norcie PhD Student - Security Informatics Indiana University

1 0

torsocks release pending: towards a release candidate
by Oscar Koeroo 31 Jan '13

31 Jan '13

Hi, I've created trac ticket[1] #8063. The torsocks script has an option "on" which did't work and in the current state I'm curious on which shell it did work :-) The patch is included and only affects the src/torsocks.in file with a oneliner. More details are included on the ticket. Oscar [1]: https://trac.torproject.org/projects/tor/ticket/8063

6 8

a new project: "visionion"
by thomas lörtsch 31 Jan '13

31 Jan '13

Hi everybody, my name is Thomas and a month ago I started working on a project called "visionion" with the goal to visualize Tor network metrics interactively in the browser. I just uploaded a readme describing the thingy and a draft of the database scheme to Github: https://github.com/tomlurge/visionion There's still nothing to look at or play with in the repository and it may well take another week or two until the first prototypes surface, but the dust has settled already a little and concepts and ideas begin to shape. Karsten has been tremendously helpful in the early stages (and I'm sure he'll continue to be). He now suggested to involve more people into the discussion - which hereby I do. I'd be very glad to get your feedback, input, ideas, remarks, scrutiny and I'd like to invite everybody to take a look at the project and comment on any aspect of it - breakdown of the status quo, concept, realisation, or whatsoever! Thanks, Thomas

1 0

User-agent in TBB alpha bundles
by Jamie Nguyen 31 Jan '13

31 Jan '13

I noticed in alpha Linux bundle (2.4.9-alpha-1) that the prefs.js still sets the user-agent as Firefox 10 instead of Firefox 17. I'm not sure which is likely to provide more anonymity, but I just wanted to check whether this was intentional or a slight oversight. Thanks. -- Jamie Nguyen

2 1

Comments on librarifying an Extended ORPort client?
by George Kadianakis 30 Jan '13

30 Jan '13

Hi Nick, I have a question for you. It's not high priority, so feel free to postpone your answer till after the workshop is over. Are you aware of pyptlib? It is a small Python library that does the managed proxy environment-variable/stdout configuration dance, so that people who write pluggable transports don't have to care how the pluggable transport protocol actually works. Another thing I would like transport authors to never learn about is the Extended ORPort. It would be truly great if pyptlib could do the Extended ORPort dance (authentication, send client's IP address, etc.), and after it's completed, let the transport send whatever ORPort data it wants. Unfortunately, I don't know how to do such a thing without influencing a certain networking programming style to the transport author. For example, if I coded the Extended ORPort client in Twisted, the transport author would probably have to use Twisted for the rest of her communication with the Extended ORPort. Similarly, if I coded the Extended ORPort client using the low-level 'socket' module, a transport author who wanted to use Twisted would be in trouble. As a matter of fact, I'm not sure how to do this task without coding separate different Extended ORPort clients for each networking library (one for Twisted, one for 'socket', etc.). But this sounds like too much work. Do you think there is a way to do what I want, or is it a lost cause? #7903 is the relevant ticket. Thanks!

2 1

Re: [tor-dev] All the problems about Stegotorous
by vmonmoonshine＠gmail.com 30 Jan '13

30 Jan '13

I summed up the discussion plus what I had in mind with in 15 tickets that I put on the track. https://trac.torproject.org/projects/tor/query?status=accepted&status=assig… Zack is going to suppliment it with few more steg module concerns. By that time we should have a fairly complete list. > From: Roger Dingledine <arma(a)mit.edu> > We should definitely put a page like that up. Let us know if we can do > anything to help! :) > > (asn or I or others can do the website commit) > > I think we (you? :) should work on a TBB bundle (like the other pluggable > transport bundles people are working on) that ships the simplest most > efficient steg module(s) we've got, so Stegotorus can get some actual > users and start collecting usability/crash/etc bug reports. > > I bet Alexandre et al would be happy to bundle in another thing, with > their current obfsproxy-and-flashproxy bundle. Let me deal the ack bug (https://trac.torproject.org/projects/tor/ticket/8086) in the few following weeks. Then I'll approach Alexandre for bundling and you to put the webpage on. Thanks everybody for your help, Vmon

2 1

Tor QA stress-testing advise
by Lee Fisher 27 Jan '13

27 Jan '13

Hi, Is there any info from current Tor QA use? I am trying to reproduce a Tor bug that causes a Windows-based Tor node to crash (BSOD). The bug needs lots of Tor traffic going through the node for it to crash. I am looking for information on the safest way to diagnose a crashing Tor node, without harming user data or the live Tor overlay. I would prefer to test offline, not using the live Tor overlay, since it may destroy user's data, perhaps harm nearby nodes, and I'd rather not have to deal with cleartext PII issues when studying the dump file. Is there any existing private Tor overlay, perhaps used by some academic research purposes, that I could briefly use for this test? I don't have lab resources available to setup a private Tor network. Is Tor-Lab, or that other similar virtual Tor network tool (Karsten-based?, JTorCtl-based?) up-to-date and usable for current Tor builds? Is there a way to use the live Tor overlay to get some script-generated traffic through a specific node, without letting any real user traffic? Wouldn't that traffic harm adjacent nodes and overlay as well? Any related advice appreciated. Thanks, Lee PS: Thanks to those involved with recent checkins to get MSVC compiler support working again; this will give me working Windows-style symbols in the dump. That is really useful.

1 0