tor-dev May 2013

tor-dev@lists.torproject.org

64 participants
50 discussions

txtorcon 0.8.0
by meejah 14 May '13

14 May '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 txtorcon 0.8.0 is now tagged and released. [1] txtorcon is a Python+Twisted-based asynchronous implementation of the Tor control protocol. It includes a state-tracking abstraction, configuration abstraction, Twisted endpoint support for hidden services, 96%+ unit-test coverage and many examples. New in this release: . issue #18: slight *API change* ICircuitListener.circuit_failed, circuit_closed, IStreamListener.stream_failed, stream_closed and stream_detach all now include any keywords in the notification method (these either lacked flags, or only included some) . launch_tor() can take a timeout (starting with a patch from hellais); . cleanup from aagbsn; . more test coverage; . run tests cleanly without graphviz (from lukaslueg); . issue #26: fix from lukaslueg; . pep8 and whitespace targets plus massive cleanup (now pep8 clean, from lukaslueg); . issue #30: fix reported by webmeister making ipaddr actually-optional; . example using synchronous web server (built-in SimpleHTTPServer) with txtorcon (from lukaslueg); . TorState can now create circuits without an explicit path; . passwords for non-cookie authenticated sessions now use a password callback (that may return a Deferred); . fixes for AddrMap in case Tor ticket #8596 is implemented; Code and built documentation may be obtained: git clone git://github.com/meejah/txtorcon.git https://github.com/meejah/txtorcon https://txtorcon.readthedocs.org/en/latest/index.html You may easily install it: pip install txtorcon easy_install txtorcon The sha256sum output is: 87fcb3bce3ac3b48583f637bf69445bd50071411dc3fded89df7600d870a3094 txtorcon-0.8.0.tar.gz thanks, meejah [1] -- (Note the tagging took place last month, and I've only now updated PyPI, ReadTheDocs, freecode, emailed this, ...) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJRjy+yAAoJEJ0UOBRRgEVQXrMH/0Kl3DmVLyqo3aTBNv1d50RL yi8u5LTZLNtuYiyJsxqTFyq8zNhfEwIPoXbsqHyNuv0hv8s6Qn4OkXh47/crhukO GpnNNTldvSQIpOfNw+ftCYF/NC0X5pOjJo/Rz1XUkFyms50cqq17i+MWvcAvaFnW Ols6+7ulh8u61ElafVxnwn1zgitkpUOOsnF8a27iXryFJ/iZFFROnCigJv2eM8pj SqcwKbVp9h1VtztoYhtEcjEPBm1NnrYGoRIjh9D3RQfEVnXgM2fU4HoGhFAqYj7M wFZv0DZBvL2s/XwV8PEi4Y4+fTJZTXE7bbHctMWjUWjhlMfMniq2oud4hZJ5ugY= =MDAq -----END PGP SIGNATURE-----

1 1

Tor Launcher UI feedback follow up
by Mark Smith 13 May '13

13 May '13

Thank you to everyone who provided feedback on the Tor Launcher UI. It has been very helpful to us and we made a lot of changes based on it. The most significant change was the addition of an initial question to the "first run" settings wizard, which allows people to skip all of the detailed questions and quickly connect. Take a look here: http://trial.pearlcrescent.com/tor/torlauncher/2013-05-08/SetupWizard/scree… As Mike pointed out, we are trying to get to alpha ASAP so we can deliver much smaller TBB packages – without Vidalia. For that reason, some of the improvements that people suggested will be left out for now (e.g., automated probing for proxy or firewall settings). -- Mark Smith Pearl Crescent, LLC http://pearlcrescent.com/

9 12

Local onionoo cache
by David Fifield 13 May '13

13 May '13

Karsten, could I ask you to take a quick look at this code? https://trac.torproject.org/projects/tor/ticket/7549#comment:14 https://trac.torproject.org/projects/tor/attachment/ticket/7549/onionoo-que… It's a daemon that keeps a local cache of potential exit relays, sourced from onionoo. It listens on a local port and sends "EXIT" when asked about an IP address that is possibly an exit. The idea behind this code was to have a fast local database that we can rapidly query from the flash proxy facilitator, in order to prevent Tor users from being flash proxies themselves. Is this code the most straightforward way you can think to achieve the goal? Do you have any suggestions on the use of onionoo? I wonder if something like the daemon exists already. The code looks reasonable, though I would make some changes before merging it. I want to gauge whether detection of exits is worth the additional code. David Fifield

4 6

Tor Censorship Detector: Can I help?
by Sam Burnett 13 May '13

13 May '13

Hi, I'd like to help improve the Tor Censorship Detector. I've read some background material and think I understand the basics of George Danezis' detection algorithm [1, 2]. Is anyone still working on this? Two tickets from a year ago talk about experimenting with various detection algorithms and turning one of them into a standalone utility [3, 4]. Has anything happened since then? My background: I'm a graduate student at Georgia Tech studying network censorship circumvention and measurement. Although I've met Tor developers on various occasions, I haven't directly contributed to the project; I'd like to change that. Thanks! Sam [1] https://lists.torproject.org/pipermail/tor-dev/2011-September/002923.html [2] https://metrics.torproject.org/papers/detector-2011-08-11.pdf [3] https://trac.torproject.org/projects/tor/ticket/3718 [4] https://trac.torproject.org/projects/tor/ticket/4180

3 3

Re: [tor-dev] Iran
by monet＠tormail.org 10 May '13

10 May '13

Is any IP6 in Iran? IP6 is blocked too?

1 0

Channel incoming queue
by MF Nowlan 09 May '13

09 May '13

Hi all, I am working on integrating uTCP and uTLS ( http://arxiv.org/abs/1103.0463) into Tor to see if we can lower the latency due to head of line blocking across circuits. This is Tracker Item #7679 ( https://trac.torproject.org/projects/tor/ticket/7679). I want to first test the Tor code's ability to process cells from different circuits out of order with respect to how TCP delivered them. To test this, I made some changes to the file named src/or/channel.c. 1. I forced queueing of cells into the channel's incoming_queue with: channel_queue_cell(...) { ... need_to_queue = 1; // Force all cells into the queue, so they do NOT go directly to the handler. ... 2. Now, look for case when two cells from different circuits are present in the incoming_queue and process the second cell before the first cell. channel_process_cells(...) { ... while (NULL != (q = TOR_SIMPLEQ_FIRST(&chan->incoming_queue))) { // Remove q from the incoming_queue. // if the queue is still not empty, get the next one, // if the circuit ids do not match, Swap the cells. } ... } My problem is that number 2. above never occurs. I have not observed a case where the incoming_queue ever has two cells from different circuits. In fact, I don't think I've ever had a time when the incoming_queue has more than 1 cell in it. I am hammering a small tor test network with 30+ curl requests at once. I have two proxies, each of them uses the same entry node, and the same exit node, and there is only one other node in the network, so the circuit that is set up should be the same for every single request. Am I missing something? Will this function (channel_process_cells) ever process more than one cell at a time? I've checked the logs to verify that different circuits are actually set up for the different requests (rather than the Proxies just reusing the existing circuit and giving each new request a new stream id). Thanks for the help! Fitz

3 4

Iran
by Nima 09 May '13

09 May '13

Iran is actively dropping connections to *any* unknown port right after *60secs*. Pluggable Transport successfully connects to Tor network, Although it can not make a circuit in many ISPs including "Mobin". -- Nima 0x1C92A77B "I disapprove of what you say, but I will defend to the death your right to say it" --Evelyn Beatrice Hall

9 14

Re: [tor-dev] LibOnionRoute released
by wac 06 May '13

06 May '13

On Mon, May 6, 2013 13:59 EDT Jeroen Massar wrote: >On 2013-05-06 19:45 , wac wrote: >> >> Hi folks: >> >> For all those interested I made an Initial release of the >> modification that transforms Tor into a library. The former libTor >> renamed to libOnionRoute. Windows only so far. >> >> You can download at: >> >> http://www.onionroute.org/downloads/ > >As your code is based on Tor and that evolves, continuously especially >regarding security fixes, other updates and newer features, is there a >git-branch somewhere so that the changes you are making are visible? The changes compared to Tor are still not that big with all due intention. I made them that way in order to ease migration to a new Tor release and/or include changes coming from Tor easily. Be able to keep up. As matters of fact you can still get a Tor binary out of the sources (or almost, this wasn't tested) if you undefine the LIBRARY macro. Also so people can study them easily. The changes are more source code study than actual modification. I do however understand that commits are more descriptive. If you do not understand one of the modifications just ask me, I can tell you what does the change to alleviate the lack. As for Git, we are planning to move the repository to GitHub as we are looking to make this a community process. Review and include pull requests. Don't worry, I released that way because is faster not because being the best. Many people was requesting the source code, to the point that some guessed the sources archive name out of the binary archive. And downloaded it before being published at the website. This way they can be studying the sources in parallel while I work in other areas other than coding. I will not be fixing bugs in Tor ATM but I expect that by the time sources to be in a Git repository. As matters of fact I plan to move the changes to the next Tor release and if is not stable, work on it to make it that way. Maybe coordinated with Tor developers. Regards Waldo > >Greets, > Jeroen

1 0

LibOnionRoute released
by wac 06 May '13

06 May '13

Hi folks: For all those interested I made an Initial release of the modification that transforms Tor into a library. The former libTor renamed to libOnionRoute. Windows only so far. You can download at: http://www.onionroute.org/downloads/ Regards Waldo

2 1

Damian's Status Report - April 2013
by Damian Johnson 06 May '13

06 May '13

Hi all. Though April had a bit of stem work the month was mostly gobbled up by the chaos that is GSoC [1]. I never cease to be amazed at how much time orchestrating it takes, but enough of that. Other tasks from last month included... Improved Stem's Site * Added a change log for user facing improvements [2] * Added a FAQ, suggestions for more entries welcome! [3][4] * Improved navigability via a css style navbar menu [5] * Site logo and faveicon * Thanks to Dererk stem is now in Debian [6], and will soon be in Fedora too thanks to Juan * Put stem on tor's front page to improve discoverability [7] General Stem Improvements * Overhaul for a large part of our testing framework, run_tests.py in particular was in need of a rewrite [8] * Fix for broken process renaming (patch from ragwater [9]) * We now have a custom :trac: and :spec: role for Sphinx (patch from ragwater [10]) * ATTACHSTREAM provided an unexpected 555 response (caught thanks to a cypherpunks [11]) * Added support for the ADDRMAP event's new CACHED attribute * Looked into anomalous bridge-ip-transports lines in the consensus, turned out to be from an unmerged tor patch running on George's relay Cheers! -Damian [1] https://blog.torproject.org/blog/tor-google-summer-code-2013 [2] https://stem.torproject.org/change_log.html [3] https://stem.torproject.org/faq.html [4] https://trac.torproject.org/8577 [5] https://trac.torproject.org/8431 [6] http://packages.debian.org/sid/python-stem [7] https://lists.torproject.org/pipermail/tor-commits/2013-April/055091.html [8] https://gitweb.torproject.org/stem.git/commitdiff/ae5193f?hp=314876a [9] https://trac.torproject.org/8631 [10] https://trac.torproject.org/8671 [11] https://trac.torproject.org/8701

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev May 2013