- tor-dev - lists.torproject.org

Re: [tor-dev] Moving ownership to TheTorProject
by Zack Weinberg 04 Apr '14

04 Apr '14

On 02/20/2014 10:48 AM, vmonmoonshine(a)gmail.com wrote: > Hey Zack, > > I want to put up Stegotorus up for GSoC this summer. I was wondering if > you mind transfering the ownership of your Stegotorus repo: > > https://github.com/zackw/stegotorus > > To "TheTorProject" on github: > > https://github.com/TheTorProject > > ? (https://github.com/zackw/stegotorus/settings then Transfer) > > If you don't feel comfortable, we can fork it as well. [ Background for tor-dev: I am no longer involved in Stegotorus development. vmon and at least one other person are continuing to work on it; this is currently happening in non-default branches of the copy on my github account. There is also a copy of the repo on gitweb.torproject.org but it has not been updated in quite some time. ] I discussed this with Roger on IRC yesterday and we came to the conclusion that instead of transferring my Stegotorus repo to the "TheTorProject" organizational account, gitweb.torproject.org/stegotorus.git should be promoted to the master copy. I think right now I am the only person with write access to that copy, and I am not sure what the right procedure is for granting you access. I'm also not good enough at Git to know how to copy all branches of remote A into remote B (short of tedious manual actions and/or shell loops). I think this would also entail using Tor's Trac for issues instead of Github's issue tracker. zw

5 5

Prototype of a next-generation Tor control interface
by ra 04 Apr '14

04 Apr '14

Hi, all! Originally, I wrote the proposal for this year's GSoC, but nobody seems willing to mentor it and the idea most probably needs more time to shape. Hence, I post it on this list to get some feedback and let the idea evolve. (: Best, Robert Problem statement Tor's control protocol[0] facilitated the communication from other programs with a locally running Tor process, regardless of their programming language. It is used by various projects like GUI controllers, such as Vidalia or arm, research projects, or services for monitoring the Tor network, such as bandwidth scanners. The Tor control protocol is a message-based protocol which requires lots of message/string parsing when using it. Hence, to ease the use of that interface, libraries such as JTorCtl, TorCtl, Txtorcon, and Stem were developed. Today, some of those libraries can be considered outdated, such as JTorCtl and TorCtl - even though TorCtl is still in use. Stem and Txtorcon are state-of-the-art and heavily being used, provide thread safety, caching and a better interface, rendering string parsing unnecessary. However, both are Python libraries, restricting the use of the Tor control protocol to Python scripts only. While Python is a fine and very popular scripting language, actual restriction to use a specific programming language, prevents wider use of the Tor control interface. Proposal Therefore, I would like to propose a prototype of a next-generation Tor control interface, aiming to combine the strengths of both the present control protocol and the state-of-the-art libraries. It should provide (network) connectivity from other programs to a locally running Tor process, regardless of the programming language, while preserving thread safety, caching and a better interface. Before implementing in Tor itself, coding a prototype is substantially less work. The prototype should consist of a daemon running on the same machine as the Tor instance. The daemon implements a backend interface to the Tor instance through the Tor control protocol (via Stem) and a frontend interface providing JSON encoded data over HTTP (REST). Therefore, semi-structured data (JSON) can be accessed by any (HTTP-capable) programming/scripting language. HTTP compression and/or encryption can be implemented, too. Not having looked into Python REST frameworks yet in detail, Flask looks promising for this task. Until the new interface is implemented in Tor itself, it will require continual upkeep and maintenance. Therefore, as a long term goal, the new interface should be implemented in Tor itself, if the prototype proofs to be successful. [0] https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=control- spec.txt

1 1

Feedback on recent Globe improvements
by Karsten Loesing 03 Apr '14

03 Apr '14

Hi Christian, moving our private discussion to the public mailing list. You were asking about making graphs from Onionoo's new clients documents. Here's an example: "1_week":{"first":"2014-03-23 12:00:00","last":"2014-03-30 12:00:00","interval":86400,"factor":0.002802803,"count":8,"values":[251,933,471,955,999,999,735,713],"countries":{"cn":0.1882,"dz":0.0728,"es":0.0146,"fr":0.1006,"gb":0.0174,"hk":0.0233,"ir":0.1119,"jp":0.1882,"kz":0.0117,"my":0.1532,"us":0.1123},"versions":{"v4":1.0000}}, For this bridge, you'd draw the first data point at x = 2014-03-23 12:00:00 UTC with y = 251 * 0.002802803 = 0,703503553 concurrent users. You were also asking about feedback on new uptime graphs: http://rndm.de/globe/canary/index-11349.html Looks pretty good! The uptime graphs for the relays I checked were not as exciting as the bandwidth graphs, but it's actually good if uptime is always at 100%. And finally, you asked about showing numeric averages next to graphs, like on: https://status.github.com/graphs/past_week I like the idea. I think we shouldn't split up graphs to have only 1 line per graph, because that makes it hard to compare incoming and outgoing traffic or the various weights to each other. But it could help to have numeric averages in the same color as graph lines next to the graphs. Thanks! All the best, Karsten

4 15

Re: [tor-dev] Java-version Tor router?
by str4d 03 Apr '14

03 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/03/2014 02:17 PM, Lei Yang wrote: > I'm wondering are there any Tor routers which are implemented in > Java? Orchid[0] is the Java implementation of Tor. In general it is working well; we have packaged it as an I2P plugin[1] to provide easy outproxy support inside I2P. Unfortunately, the developer appears to not have time to maintain it, as there are several outstanding pull requests with bug fixes, including a fix for a deadlock we discovered during use. We maintain our own repository with fixes[]; Bitcoinj may also be forking the Orchid codebase as part of their plan to bundle it by default[3]. str4d [0]: https://github.com/subgraph/Orchid [1]: http://plugins.i2p.me/plugins/orchid/ (via I2P inproxy) [2]: https://github.com/str4d/Orchid [3]: https://github.com/bitcoinj/bitcoinj/pull/28 -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJTPMjhAAoJENXeOJaUpGWywNkH/2bBNMb01uNxNHTnOXdThMnQ pnSflUEDTkvtfXWveY4soIVaFVo4XZaJXz6ibvABn5OFLizzwJEjW7CKw0gc3Lg1 4t3R9JhqEQSJyQpFuh3sJEQO+oBl92NBGRHIjiPWkeitJjxcw8mJtSkLYXbtNMyJ 1VgQjSP5AlQ+1KILpuORtuYl2kV5+yUrFqFxvJN6oWt4d5FwuDjdpphzebTERuw5 hJ2Jz4iHh1jvZx1UPKH7gkt+1Mcl+wTFz9fJvfXM8Lc6VUO5P/Sd/m9NXUN5n6N/ bdRp32Y9AzLdxaPXPmjr5A2OQIQGfCoYhOSJwAXSMrPvr6/CZxs4JoWF9pvqnZ8= =zvoZ -----END PGP SIGNATURE-----

1 0

Java-version Tor router?
by Lei Yang 03 Apr '14

03 Apr '14

Hi, I'm wondering are there any Tor routers which are implemented in Java? Thanks, Lei

1 0

Reminder: Tor weekly dev meetings all April, Wednesday at 19:00 UTC
by Nick Mathewson 31 Mar '14

31 Mar '14

Hi, all. This is another developer's meeting for working on the program "tor". (This won't cover all the other programs developed under the Tor umbrella.) We're going to try doing the weekly meeting on Wednesday. The meeting time will be: Wednesday April 2, 19:00 UTC. (That's 3pm EDT and 12:00 noon PDT) As before, we'll do it on the #tor-dev IRC channel, unless the meeting turns out to be too disruptive for the rest of the channel or vice versa. Starting in April, I'm sending these reminders out monthly rather than weekly, unless that causes a huge drop in attendance. So, no more of these emails for a month or so. I'm sending this out now so that nobody thinks it's an April Fools thing if I do it tomorrow. cheers, -- Nick

1 0

Damian's Status Report - March 2014
by Damian Johnson 31 Mar '14

31 Mar '14

Hi all. GSoC coordination and a couple particularly tenacious illnesses pretty well knocked me out of commission this March. The neatest changes I managed to slip in concerned Stem's site... * FAQ entry for how to interact with Tor's controller interface directly. This comes up reasonably frequently on Stack Overflow. In the answer we discuss each connection and authentication scenario with examples... https://stem.torproject.org/faq.html#can-i-interact-with-tors-controller-in… * A few weeks ago Coderman made the great suggestion for a Stem Cookbook. I've put together a few scripts that demonstrate neat things. If you have any suggestions for other things to exemplify then please let me know! https://stem.torproject.org/tutorials/double_double_toil_and_trouble.html#s… * Code reviewed Martin's munin-tor and Lunar's exit-funding scripts. Both are now listed on our examples page, and I also made Exit Map more prominent (thanks Philipp for mentioning Stem in Spoiled Onions!). https://lists.torproject.org/pipermail/tor-relays/2014-March/004173.html https://lists.torproject.org/pipermail/tor-dev/2014-March/006598.html * Handful of other minor improvements such as making FAQ entries more concise, syntax highlighting torrc snippets, and better module docs. Stem now supports HS_DESC events, and fixed an issue with ExitPolicy pickle-ability thanks to Nick Hopper. Final note for March is that as anybody who knows me can attest I make a lot of typos. I spend enough time on irc that I finally invested some effort into getting an Irssi spellchecker working... https://www.atagar.com/transfer/tmp/irssi_spellchecker.png I love Irssi to death but user friendly it is not. If you would like a similar setup then here's my notes... http://paste.debian.net/plain/90855 Cheers! -Damian

1 0

Patch: Hidden service: use inbound bind-address based on circuit ID (effectively giving each circuit a temporarily-unique IP address)
by Harry SeventyOne 31 Mar '14

31 Mar '14

Hi, I've written this (ugly, unconfigurable) patch for Tor which is designed to allow hidden services more information about their users, by giving each inbound circuit its own temporary "IP address" in the 127.x range. This technique works on Linux (I've not tried it on anything else) and allows the application server to do some useful things which were previously difficult: * Identify TCP connections coming from the same client, in a short space of time, for example, for diagnostic log analysis, identifying traffic trends * Rate-limit operations coming from the same client, to defend against some types of DoS attacks * Temporarily block abusive clients (at least, until they make a new Tor circuit) More importantly, it can do this with an unmodified application-server (e.g. web servers typically have these features built-in) because it effectively "spoofs" the client ID as an ip-address, in the 127.x range. The patch is currently not configurable (the feature can't be turned off). It only works with hidden services which are routed to "localhost". Request for comments. What do you think? -- Harry SeventyOne

2 2

Announcing OnionPy, a Python wrapper for OnionOO
by Lukas Erlacher 31 Mar '14

31 Mar '14

Hello, this will most likely only be interesting to the people working on the tor-weather rewrite. I have started work on a Python wrapper for OnionOO with support for transparently caching OnionOO replies in memcached. It is hosted on github for now: https://github.com/duk3luk3/onion-py Please let me know if you have any thoughts on it! Best regards, Luke

3 4

Mr. Hyde, or The guy who runs a Jekyll blog over a Tor Hidden Service
by Karsten Loesing 30 Mar '14

30 Mar '14

Hello everyone, I wrote a first draft of a manual that explains how to run a Jekyll blog over a hidden service. *Disclaimer: The following manual is a draft and may contain severe problems harming your privacy! Do not rely on anything in the manual yet!* http://csxeeumg5ynu2rk7.onion/ https://github.com/kloesing/hyde/blob/master/publisher-manual/index.md The intended audience are bloggers who can handle a terminal window but who don't know the typical pitfalls of securely setting up a web server over a hidden service. The approach taken in the manual is to describe how to assemble existing software for a simple hidden blog in as few steps as possible. Are there any obvious security problems with the described setup? Is it possible to simplify parts of the manual even more? Does anyone want to work on a Jekyll layout to make the manual prettier? Feedback much appreciated! Thanks! All the best, Karsten

1 0