- tor-dev - lists.torproject.org

Proposal idea: Stop assigning (and eventually supporting) the Named flag
by Sebastian Hahn 13 Aug '14

13 Aug '14

Filename: xxx-kill-named-flag.txt Title: Stop assigning (and eventually supporting) the Named flag Authors: Sebastian Hahnn Created: 10 April 2014 Target: 0.2.5 Status: Draft 1. Intro and motivation Currently, Tor supports the concept of linking a Tor relay's nickname to its identity key. This happens automatically as a new relay joins the network with a unique nickname, and keeps it for a while. To indicate that a nickname is linked to the presented identity, the directory authorities vote on a Named flag for all relays where they have such a link. Not all directory authorities are currently doing this - in fact, there are only two, gabelmoo and tor26. For a long time, we've been telling everyone to not rely on relay nicknames, even if the Named flag is assigned. This has two reasons: First off, it adds another trust requirement on the directory authorities, and secondly naming may change over time as relays go offline for substantial amounts of time. Now that a significant portion of the network is required to rotate their identity keys, few relays will keep their Named flag. We should use this chance to stop assigning Named flags. 2. Design None. Tor clients already support consensuses without Named flags, and testing in private Tor networks has never revealed any issues in this regard. 3. Implementation The gabelmoo and tor26 directory authorities can simply remove the NamingAuthoritativeDirectory configuration option to stop giving out Named flags. This will mean the consensus won't include Named and Unnamed flags any longer. The code collecting naming statistics is independent of Tor, so it can run a while longer to ensure Naming can be switched on if unforeseen issues arise. Once this has been shown to not cause any issues, support for the Named flag can be removed from the Tor client implementation, and support for the NamingAuthoritativeDirectory can be removed from the Tor directory authority implementation. 4. Open questions None.

3 6

Rescheduling of next OONI development meeting
by Arturo Filastò 13 Aug '14

13 Aug '14

The next weekly OONI development meeting is supposed to happen on the 15th of August. Since the this day is holiday in a lot of countries I am going to propose we skip next weeks meeting and move it to the week after: the 22nd of August. The time will be the same 5 PM CET (3 PM UTC). The upcoming weeks the meeting should happen every Friday as usual. Happy holidays, ~ Art.

1 0

Globe Dev
by Mike 13 Aug '14

13 Aug '14

I'd like to help and last I read on this list wpapper was taking on Globe dev https://github.com/wpapper/globe. Their fork is looking a bit quite of late so I'm not sure where I should start. I'm happy to start from where makepanic left off, or continue with wpapper's fork??? Mike.

2 1

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