- tor-dev - lists.torproject.org

Pluggable transports meeting tomorrow (16:00UTC Wednesday 13th of August 2014)
by George Kadianakis 12 Aug '14

12 Aug '14

Hola brothers and sisters, just wanted to remind you that the regular biweekly pluggable transports meeting is going to occur tomorrow at 16:00 UTC. Place is the #tor-dev IRC channel in the OFTC network. As you see, the meeting day was recently changed from Fridays to Wednesdays: https://lists.torproject.org/pipermail/tor-dev/2014-August/007317.html Thanks for your attention!

1 0

Tor API doc?
by CJ 11 Aug '14

11 Aug '14

Hello, I've searched, but didn't find anything regarding how we can interact with Tor API (through the Administration Port). Would be nice if you could provide some link :). Thanks in advance. Cheers, C.

3 4

little-t tor "projects" in need of another keyboard
by tibicen＠riseup.net 11 Aug '14

11 Aug '14

Hi everyone, Is there any project in little-t tor that needs another hacker? I have (under another name) been writing tor unit tests, which I've "finished". What should I work on next? Happy to work on either new code or more unit tests. I'm also reasonably skilled with python, if any pythonic project needs a hand, particularly OONI, which I love the idea of (I won't CC the ooni dev list, as I assume you're all on here). tibicen

2 1

Torflow error
by spriver 11 Aug '14

11 Aug '14

Hi, I am trying to setup Torflow, but when I am about to start metatroller I'm getting following error: sudo ./metatroller.py Traceback (most recent call last): File "./metatroller.py", line 330, in <module> main(sys.argv) File "./metatroller.py", line 327, in main listenloop(*startup()) File "./metatroller.py", line 310, in startup h = PathSupport.PathBuilder(c, __selmgr) # StatsHandler(c, __selmgr) File "/home/dodo/flowtor/TorCtl/PathSupport.py", line 1447, in __init__ TorCtl.ConsensusTracker.__init__(self, c, RouterClass) File "/home/dodo/flowtor/TorCtl/TorCtl.py", line 1582, in __init__ self.update_consensus() File "/home/dodo/flowtor/TorCtl/TorCtl.py", line 1674, in update_consensus self._update_consensus(self.c.get_consensus()) File "/home/dodo/flowtor/TorCtl/TorCtl.py", line 1011, in get_consensus nsData = self.sendAndRecv("GETINFO dir/status-vote/current/consensus\r\n")[0][2] File "/home/dodo/flowtor/TorCtl/TorCtl.py", line 877, in sendAndRecv raise ErrorReply("%s %s"%(tp, msg), status = code, message = msg) TorCtl.TorCtl.ErrorReply: 552 Unrecognized key "dir/status-vote/current/consensus" Does anybody has an idea what's going wrong? Tor is running properly configured (with opened ControlPort). Cheers spriver

1 0

[GSoC] BridgeDB Twitter Distributor report
by Kostas Jakeliunas 11 Aug '14

11 Aug '14

Hi all, preferring existing code over shiny code and being mad late, I * (re)wrote a simple but working churn control mechanism[1], which uses * a general persistable storage system: * in particular, the bot now has a central storage controller which takes care of storage handlers which, in turn, may be of different varieties. Each variety knows how to handle its own kind of storage containers (simple objects with data as attributes). Some of them may be persistable, others necessarily ephemeral (wipe data on close); * right now we only make use of simple pickle-dump-to-file-and-gzip persistable storage; we use it for churn control and for challenge responses; everything is self-contained so to speak; * we hash the user twitter handles (unique usernames / screen names) and round up bridges-last-given-at timestamps; * we handle bot shutdown by catching the appropriate signal (then properly closing down the twitter stream listener and asking the storage controller to close down the handlers); * we use the storage system in the core bot via a general "bot state" object (which is itself oblivious to how storage is actually implemented); * wrote a simple and generic challenge-response system[2] (which makes use of the persistent storage); * instead of doing something very smart, we use a general CR system which takes care of particular challenge-responses; the general CR is usable as-is; the particular CR objects can be easily subclassed (and that's what we do now); * the current mock/bogus CR system that is in place (for testing etc.) is a naive text-based question-answer CR, which asks the users to add the number of characters in their twitter username to a given verbal/English-word number; * I should now finish up with ``BridgeRequest``s, which are the proper way to handle bridge requests in the bot while doing challenge-responses (the current interaction between the core bot and the CR system will lead / has been leading nowhere); * also, there's a question to be had whether the cached (and hashed) answers to CRs should be persisted to storage (if bot gets shutdown while some challenges are pending) in the first place. I've been unable to find[3] or to come up with a concept of a user-friendly *text-based* CR that would stand against any kind of thief who is able to create lots of Twitter users and to write twenty-line scripts solving any text-based challenges/questions presented. Either it will to be a difficult problem that will be easier solved by a computer than by a human (hence unfeasible general-UX-wise), or it will be so "symmetrical" in the sense that one only has to view the source (if even that) to come up with a script trivially solving the challenge presented. Hence I've been slowly moving on with the captcha-over-twitter-direct-messages idea, which is not pretty, but which would at least ensure that we don't give up bridges more easily than in, say, the current IPDistributor. [1]: https://github.com/wfn/twidibot/compare/master...churn_rewrite [2]: https://github.com/wfn/twidibot/compare/churn_rewrite...simple_cr2 [3] it's quite hard to find anything of use in the "chatroom problem" / "text-based challenge response" area. Basically, it would be great to have a "reverse Turing test"[4] that is not about captcha/OCR. I realize this is in itself a very ambitious topic. [4]: some context on early CAPTCHAs / precursors (have been trying to familiarize myself with the general area), http://www2.parc.com/istl/projects/captcha/docs/pessimalprint.pdf -- Kostas. 0x0e5dce45 @ pgp.mit.edu

2 1

A change in the schedule of Pluggable Transport meetings
by George Kadianakis 09 Aug '14

09 Aug '14

tl;dr: From now on, Tor PT meetings happen on Wednesdays. Same time. Next PT meeting: Wednesday 13th of August, at 16:00 UTC. Hello friends, I want to inform you of a schedule change that affects Pluggable Transport meetings. Because of the diverse set of timezones participating in the biweekly PT meetings, we have decided to move the meeting to Wednesdays (instead of Fridays) since for some people the PT meeting occurs during Friday night, which is considered precious social time in some cultures. So the plan is to start having PT meetings on Wednesdays. The time will remain the same for now (16:00 UTC), but it might also change in the future (I will inform you) to make it more convenient for some people. BTW, the changes are effective immediately, which means that our next meeting is on Wednesday, 13th of August 2014, at 16:00. Thanks :)

1 0

New tor relay configuration
by Richard Dennis 08 Aug '14

08 Aug '14

Hi guys, I have recently created a python library that creates a circuit through tor and then can send streams through etc, for the next phase of this project however i require access to a tor relay node to monitor. i have set one up using a raspberry pi, following this tutorial : http://www.instructables.com/id/Raspberry-Pi-Tor-relay/?ALLSTEPS i have three flags already : Running, V2Dir and Valid however when i try to connect to the node i get a destroy cell back after a lengthy wait. the node is Goblin500 and is listed on the consensus, but i am not sure why i am unable to connect to it, Would it be possible for some one to try and create a circuit using this node to see if it works if this does not work does any one know where i have likely gone wrong ? Thanks Rich

1 0

New time for Tor dev meetings: 1330 UTC on Wednesdays
by Nick Mathewson 08 Aug '14

08 Aug '14

Hi, all! Due to time zone changes for a bunch of developers, we're going to have a new time for the weekly core Tor development meetings. Going forward, they will be each Wednesday at 1330 UTC. This is the weekly IRC meeting for people working on the program "tor". (It won't cover all the other programs developed under the Tor umbrella.) As usual, we'll do it on the #tor-dev IRC channel. best wishes, -- Nick Mathewson

1 0

Sybil attack detection (was: Karsten's July 2014)
by Philipp Winter 07 Aug '14

07 Aug '14

On Tue, Aug 05, 2014 at 11:37:45AM +0200, Karsten Loesing wrote: > Started looking into better algorithms to detect Sybil attacks on the > Tor network. Current thinking is that we should define relay similarity > metrics like common IP address prefix length or time between first seen > in a consensus, go throw the consensus archives, and see which relays > look similar but are not defined to be in the same family. Do you already have some code or more details on that? I'm quite interested in this topic and I'm wondering if it wouldn't be best to start with something simple like cosine similarity [0]. We would have to transform a relay descriptor into a numerical vector and then calculate the cosine similarity to other relay vectors. However, this might scale poorly as we would need (n^2)/2 comparisons. We might also want to weigh the vector's elements differently as some of them are easy to control for an attacker (advertised bandwidth, uptime, flags, exit policy) and others require more effort (IP address, ASN, observed bandwidth). Like you mentioned, the key thing to look at might be time, i.e., uptime and derived features such as "total online time in last month" etc. [0] https://en.wikipedia.org/wiki/Cosine_similarity Cheers, Philipp

5 5

Damian's Status Report - July 2014
by Damian Johnson 06 Aug '14

06 Aug '14

For one brief, glorious moment in time I touched code. Really, it happened! House plants can vouch as my witness. Or that is to say, I've coded a lot less than I'd like. Barring a long overdue vacation to Sol Duc this month went toward a lot of random distractions... * Worked with Philipp on overhauling our procedure for flagging bad relays... https://trac.torproject.org/projects/tor/wiki/doc/ReportingBadRelays Philipp's taken the lead here and is doing a great job! While I find this space interesting I'm already spread too thin, so going forward I won't be a co-maintainer for it after all. :( * Looked over Nick Hopper's consensus validation change, adding crypto blob type validation to simplify his work. I now owe him a more thorough code review. (#11045) * Handful of DocTor issues including OOM troubles (#12457), unpleasant amount of noise from consensus parameters (#12708), and a several minor revisions. * Discussed adding a new X- extrainfo descriptor field with Virgil, suggesting revisions and helping him make it conformant with the spec. * System I do development on died a puzzling death. Even after twenty hours investigating I'm still not quite sure what happened. Cleaning out dust, removing the RAID controller, and starting over seems to have done the trick. * GSoC administrative work. We're now less than two weeks from the final evaluations! * Continued overhauling arm but as already mentioned focused on this a lot less on this than I'd like. So little coding makes me grumpy, so like many of you I'm taking a hard look at where my time's evaporating to. Maybe there's something I can change or extricate myself from to better focus. Cheers! -Damian

1 0