- tor-dev - lists.torproject.org

Re: [tor-dev] Response on adding extra torrc fields
by Damian Johnson 05 Jul '14

05 Jul '14

> Hi Damian! I'm trying to make this work under your suggestions, but I'm not > entirely clear how. Can you help me get this in shape to pass your muster? Hi Virgil, I'd be glad to! Adding tor-dev@ back in case others have thoughts on the details. I like your idea, what I was trying to hint by asking about the motivation was that the proposal should clearly explain why we're doing this (with example use cases). As for detail, I mean the proposal should have text we can copy and paste into the dir-spec. Maybe something like... ============================================================ The following would be added to section 2.1.2 of the dir-spec (Extra-info document format): "X-" CustomKey SP CustomValue NL CustomKeyChar = ALPHA / DIGIT / "_" / "-" CustomKey = 1*20 CustomKeyChar CustomValueChar = atext / SP CustomValue = 1*200 CustomValueChar Custom field that can appear multiple times, for example... X-bitcoin 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8 X-gravatar https://s.gravatar.com/avatar/d27fce46c9ac41a41bb52455ae75701d X-favoritequote Be excellent to each other. Party on dudes! X-foo bar A CustomKey cannot appear more than once, and there cannot be more than ten of these entries. ============================================================ As a controller library author what I want from proposals is enough detail so I know *exactly* how to parse new additions. There's lot of potential edge cases. Can values be an empty string? How about keys? What should we do if a key appears multiple times? Is that valid? You mentioned a 5 KB limit, is that per option or for all custom fields? Rather than a size threshold, in the above I'm proposing a limit of ten entries each of which can be at most 220 characters. That would only be 2 KB so feel free to tweak these limitations. I'm not entirely sure 'atext' is what we want here. This would exclude tabs, but maybe that's not such a bad thing. You can look it up on... http://www.ietf.org/rfc/rfc2822.txt Cheers! -Damian

1 0

GSoC : Rewrite Tor Weather (Status Update 3)
by Sreenatha Bhatlapenumarthi 04 Jul '14

04 Jul '14

Hi all, I've written most of the new weather's backend a.k.a the notification scripts that run hourly(LowBandwidth, Nodedown) and daily(Welcome, Tshirt) as cron jobs and this is how they essentially operate: 1. Fetch and parse required documents from Onionoo. 2. Filter out required relays(e.g 'running', 'stable' flagged for welcome email). 3. For each filtered relay: 3.a. For each notification type: 3.a.a. Query the corresponding subscription model to get subscribers' info. 3.a.b. Collect the email(to, from, subject, content) to be sent. 4. Send out the collected mass email. 5. Delete old entries and/or update the django models. I happened to make some changes the onionoo-wrapper module in this process by modifying the response objects, utilities etc. The current version with all the changes is available at https://github.com/lucyd/tor-weather/tree/backend. After fixing a couple of issues, I setup the vagrant+puppet environment that was previously configured(#11417). I tested out the notification scripts and although the daily script is working fine, the hourly script is giving a couple of errors for now. I plan on fixing these pretty soon and testing the overall weather to make sure everything's working fine. Cheers, Sreenatha

1 0

[GSoC] Consensus diffs - Third report
by Daniel Martí 04 Jul '14

04 Jul '14

Hello everyone, This is the thid status report of my Google Summer of Code project, which is to implement consensus diffs for Tor. We hold weekly meetings every Wednesday at 14h UTC with the project mentors Nick and Sebastian. Two weeks ago I sent the second report, which explained how I had working versions of both the ed diff generation and application code, and that I would move on to writing tests, fixing bugs and starting the integration into Tor. And that's what I've done these past two weeks. I have restrured my codebase to make it fit into the main repository (I came up with the 'consdiff' name, so consdiff.c and consdiff.h - criticism or better names welcome). I have also started writing tests in test_consdiff.c, which are extensive but still have room for improvement. Most importantly, while writing the tests and adding assertions I found a handful of issues which are now solved. I'll try to come up with as many edge cases as I can to get rid of any remaining bugs. All the code is up on github: https://github.com/mvdan/tor_sample Our schedules this week have been difficult in part due to the tor-dev summer meeting, so not much else has happened other than my coding. Hopefully we'll be back at full speed soon! -- Daniel Martí - mvdan(a)mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C

1 0

Gsoc tor daemon status report
by Белоус Михаил 04 Jul '14

04 Jul '14

As I said before applying for Gsoc,until 19 July I'm in military camp. After my return I'm going to rewrite code.

1 0

XKeyscore rules probably are from Snowden, after all
by Maxim Kammerer 04 Jul '14

04 Jul '14

There has been some speculation that the recent XKeyscore rule leaks [1] do not come from Snowden — particularly, by Schneier [2]. I believe that there is a good case that the leaks do come from Snowden, since it is possible to pinpoint the date range when the rule sources [3] have been last updated. The earliest possible date is 2011-08-08, when the Linux Journal writeup about Tails [4], referenced by the glob pattern "linuxjournal.com/content/linux*" has been published. The pattern is not a generic Linux Journal filter, as implied in [1]. The likely latest possible date is 2012-02-28, when "maatuska" directory authority has changed its IP [5]. A less likely upper bound is 2012-09-21, when "Faravahar" directory authority has been added [6]. NSA either took the 8 authorities from the actual consensus, or picked them from Tor's sources [7]. However, Tor sources list more than 8 authorities, and are not properly maintained (e.g., see entry for "moria1" wrt. its last .34/.39 octet tweaks), so I doubt NSA would use that. Moreover, it is hard to miss the port number in the sources, whereas NSA did miss that some authorities do not (and did not) use ports 80/443. E.g., "moria1" (the MIT campus server mentioned in [1]) would not be matched as a Tor authority by the rules. Snowden most likely tried to contact Greenwald at the end of 2012 [8], which is entirely consistent with the above. Another NSA employee leaking XKeyscore rules after being inspired by Snowden's leaks, would have probably downloaded a more up-to-date rules file. Cross-posting to tor-dev, in case I got any historical directory authority changes wrong. [1] http://daserste.ndr.de/panorama/aktuell/nsa230_page-1.html [2] https://www.schneier.com/blog/archives/2014/07/nsa_targets_pri.html [3] http://daserste.ndr.de/panorama/xkeyscorerules100.txt [4] http://www.linuxjournal.com/content/linux-distro-tales-you-can-never-be-too… [5] https://lists.torproject.org/pipermail/tor-dev/2012-February/003312.html [6] https://trac.torproject.org/projects/tor/ticket/5749 [7] https://gitweb.torproject.org/tor.git/blob/HEAD:/src/or/config.c [8] http://www.nytimes.com/2013/08/18/magazine/laura-poitras-snowden.html -- Maxim Kammerer Liberté Linux: http://dee.su/liberte

1 0

Orbot & Orfox - GSoC bi-weekly report 3
by Amogh Pradeep 04 Jul '14

04 Jul '14

Status Report 3 July 4th, 2014. Things I have done: 1)Building Fennec: Finally built Fennec and applied the patches to provide anonymity to some extent. The apk can be found at https://guardianproject.info/releases/FennecForTor_GSoC_prototype.apk . This is just a prototype and requires the original browser code to be a fully anonymous browser. 2)Building tor-browser: I downloaded the source for tor-browser which is based on firefox 24esr. Built it, and it runs, makes an apk which works to some extent but I was informed that the browser won't function unless certain plugins are added to it. This means that I'm going to have to port the plugins to work on Fennec or find a usable alternative.

1 0

Torspec proposal for adding new X- fields to relay descriptor
by Virgil Griffith 03 Jul '14

03 Jul '14

URL: https://dl.dropboxusercontent.com/u/3308162/ExtraRelayDescriptorFields.txt Fulltext below. Comments appreciated. -V ======================= Filename: ExtraRelayDescriptorFields.txt Title: Adding new X- fields to relay descriptor Author: Virgil Griffith, Nick Mathewson Created: 2014-06-03 Status: Open 1. Motivation We wish to allow developers to build new applications atop relays. Towards this end, we wish to add the ability for users to specify arbitrary new key-value entries under the "X-" namespace. 2. Proposal Allow optional key-value lines in the relay's torrc file. These lines will be mirrored in the relay's descriptor which is then published in the directory consensus. The format is: X-key value For example: X-bitcoin 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8 X-gravatar https://s.gravatar.com/avatar/d27fce46c9ac41a41bb52455ae75701d X-nameid virgil.gr X-favoritequote Be excellent to each other. Party on dudes! The value field must be printable ASCII (characters 32-126). The value must not under any condition contain a newline. The key may contain lowercase ASCII letters (a-z), digits, underscore, or dash. In regex, [-_0-9a-z]. There may need to be a maximum sum length of the X- entries. This is left to the developers. I propose a maximum sum length of 5 kilobytes.

4 4

Re: [tor-dev] I have a group at internet archive that are interested in buying a lot of OnionPi's
by Virgil Griffith 02 Jul '14

02 Jul '14

Roger et al, I'm interested in something like onion-pi to be a Tor relay. Is there something with enough COU to be viable? I know nothing about this embedded scene. -V

2 1

[GSoC 2014] Revamp GetTor status report #3
by Israel Leiva 02 Jul '14

02 Jul '14

Hi all! This is my third report for the Revamp GetTor GSoC project. It's not much, since I'm finishing my semester and I haven't had much time to do complex stuff. Achievements: [*] Fixed minor issues pointed out by my mentor on the Core module (still one remaining). The biggest thing was to eliminate unnecessary inspection of the stack to know which service was calling. I implemented a rather simple solution: the service should be specified when calling the Core module. This will help for statistics. [*] Create the basis of the SMTP module. For now, it has the main classes and methods to be used, with basic documentation and logging. There are some methods with working code, but nothing definitive yet. [*] Created a dummy script to test the SMTP module. For now, it just reads emails from stdin (eml files). Goals until next bi-weekly report: [+] Fix the one remaining issue on the Core module. [+] Have a functional SMTP module, hopefully tested on a real server. As always, you can check what's been done on [0]. As I mentioned earlier, I'm finishing my semester and I'll be free by mid of the next week. After that, I'll considerably increase my productivity in order to achieve the timeline proposed. [0]: https://github.com/ileiva/gettor/tree/master/src Best, -- israel

1 0

(no subject)
by Gareth Owen 01 Jul '14

01 Jul '14

Dear all I'm working on a tor research project and am having difficulty understanding the SENDME cells. The tor spec acknowledges that it isn't particularly clear so I would welcome some clarification please. The spec says that *all* nodes in a circuit maintain a send and receive window, and that this window is decremented on each RELAY_DATA and incremented on each SENDME. Cells that are neither of these do not affect the window size. The problem I have understanding is, that only edge nodes will know whether a cell is a RELAY_DATA, the intermediate nodes only know that its a RELAY but not what type. So, if only RELAY_DATA decrements the window size, and intermediate nodes cannot spot these, what point is there in intermediate nodes having a window? Any help greatly appreciated. Gareth --- Dr Gareth Owen Senior Lecturer School of Computing, University of Portsmouth W: ghowen.me

1 0