- tor-dev - lists.torproject.org

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

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

01 Jul '14

It's already established that, for clients, onion-pi's are discouraged---onion-pi wifi doesn't protect enough (I.e., at all) from browser-based attacks. Given that, The question is now, "Are onion-pi's are good enough to be useful relays?" Roger said no. Is there a more informed opinion on this matter---particularly from someone who has actually tried this? Are there any relays that are known to run on onion-pi? If an onion-pi is insufficient for a useful Tor relay, what is the limiting reagent? What more does it need to be useful? -V

2 1

Disk full under .tor
by grarpamp 30 Jun '14

30 Jun '14

Tor seems to have kept running ok through at least one disk full instance here. Posting in case such rare edge conditions haven't yet been fully 'do the right thinged' in design. cached-consensus": No space left on device cached-descriptors.new": No space left on device Unable to store router descriptor

1 0

I have a group at internet archive that are interested in buying a lot of OnionPi's
by Virgil Griffith 29 Jun '14

29 Jun '14

What is the current state of the art on this, and if it is ready for larger deployment want to buy about 50-100 of them. -V

5 4

Re: [tor-dev] I have a group at internet archive that are, interested in buying a lot of OnionPi's
by Rémi 29 Jun '14

29 Jun '14

Roger wrote: > And the onionpi boxes don't have enough cpu to be a useful relay. I'm not sure what the definition of 'useful relay' is, but I am running an exit relay with 900KB/s and between 1000-1500 consensus weight. This is the limit for the pi, but definitively above the 100KB/s I read somewhere else. Also, although I know it is nowhere near decent security, I do get a warm feeling from the fact that all my non-tor home traffic gets mixed/emitted along with tor exit traffic. I'm not running an onionpi because I prefer TorBrowser for all the good reasons, but the pi makes a nice little relay I think. R.

1 0

Proposal for improving social incentives for relay operators
by Virgil Griffith 29 Jun '14

29 Jun '14

For a while I've been seeking to grow the Tor network in both size and goodput. Towards this end, I've explored various avenues such as increasing user-awareness via tor2web. More recently, I've been exploring financial incentives like TorCoin. Not wanting to strictly limit ourselves to financial incentives, I began reading the literature on incentivizing volunteers. The most relevant papers I found are: * http://www-2.rotman.utoronto.ca/facbios/file/LMS2_ManSci-Paper-Final.pdf * http://pareto.uab.es/~prey/gneezy_254.pdf * https://dl.dropboxusercontent.com/u/3308162/Slonim%202013.pdf The most relevant of these papers (Lacetera 2013) cites the major motivations for volunteer labor are: "pure altruism, warm glow, self-image, and reputation". Upon reading this I realized TorCoin's technical interestingness had blinded me to much easier to leverage motivations of "warm glow" and "reputation". I propose the following system for harnessing "warm glow" and "reputation" for Tor relay operators. I am willing to fund this in its entirety. I propose establishing a subdomain on torproject.org giving each Tor relay operator (hereafter affectionately called "Torati") his/her own page using the information her machines provide to the Tor Directory Consensus. The fields to show on her "Torati profile page" would be things like: ContactInfo, PGP fingerprint, list of server nicknames, date the Directory Authorities first saw her contact info, etc. You can also imagine a receiving special "special recognition stars" for operating an exit or bridge node. Moreover, some bandwidth measurement like EigenSpeed or TorCoin gain traction, the Torati page could recognize contributors with by listing the sum total she has relayed to the Tor network. Naturally a node can opt-out of Torati recognition by setting a parameter in the torrc file. I argue this would be a cheap and easy way to motivate operators to volunteer more bandwidth for the Tor network. As mentioned before, I am willing to fund this in its entirety. -Virgil

8 10

[PATCH] remove test for remote SOCKS Port at config validation
by Martin Kepplinger 28 Jun '14

28 Jun '14

remove the check for a non-local SOCKS Port in the config by removing the flag when calling parse_port_config() for it. this should only prevent parse_port_config() from writing a warning that is written when the listener is opened anyways, according to https://trac.torproject.org/projects/tor/ticket/4019 --- this is UNTESTED and more of a question if that may suffice for closing ticket 4019 for now. src/or/config.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/or/config.c b/src/or/config.c index 10df839..7c22171 100644 --- a/src/or/config.c +++ b/src/or/config.c @@ -6002,8 +6002,7 @@ parse_ports(or_options_t *options, int validate_only, options->SocksPort_lines, options->SocksListenAddress, "Socks", CONN_TYPE_AP_LISTENER, "127.0.0.1", 9050, - CL_PORT_WARN_NONLOCAL|CL_PORT_ALLOW_EXTRA_LISTENADDR| - CL_PORT_TAKES_HOSTNAMES) < 0) { + CL_PORT_ALLOW_EXTRA_LISTENADDR|CL_PORT_TAKES_HOSTNAMES) < 0) { *msg = tor_strdup("Invalid SocksPort/SocksListenAddress configuration"); goto err; } -- 1.7.10.4

1 0