tor-dev

tor-dev@lists.torproject.org

3581 discussions

Re: [tor-dev] Stem Descriptor Parsers
by Norman Danner 10 Jul '12

10 Jul '12

OK, bringing back to tor-dev... On 7/5/12 1:44 PM, Damian Johnson wrote: > Hi Norman. > >> (Taking this off tor-dev@ for the moment until we get things straightened out...) > > Actually, this would have been an interesting discussion for the list. > Feel free to add it back in. > >> The TorExport functionality seems pretty straightforward, but the stem-interesting parts (new descriptor parsers) already seem to be on Ravi's punch-list. > > My understanding is that the csv work is to add export (and maybe > import) functionality to the Descriptor class. This would provide > those capabilities to the current ServerDescriptor and > ExtraInfoDescriptor classes in addition to anything we add in the > future like consensus based entities. If it really isn't possible to > do in the Descriptor then it would be an abstract method that's > implemented by Descriptors as we go along. OK, there's the first confusion on my part; I thought the export functionality was to be something like utility scripts rather than built into stem itself. So is export intended to be an instance method of descriptor, one that just dumps a single csv line of the instance attributes (maybe subject to some selection of those attributes)? Or a static method that takes a collection? It seems like it might be awkward to have to hack stem itself to add a new export format (for example). Is this a concern? Actually, this makes me wonder a bit about what exactly stem is. It seems like it is: * stem the Tor Control Protocol interface, and * stem the (relay, network status,...) descriptor utility library. It seems that the former is dependent upon the latter (for stem to provide a list of cached descriptor objects, it needs a descriptor utility library that defines those objects), but not the reverse (the utilities don't much care where the descriptors come from). This isn't completely correct, since the descriptor utilities might provide APIs for parsing some source of descriptor(s) (Tor Control message, cached-consensus, metrics), but making the descriptor utility library one module among many in stem makes it seem like they are more intertwined than they appear. Of course, you've been thinking about this a lot longer than have I. Do all the known use-cases make need both an interface to Tor Control and a descriptor utility library? I guess I'm not quite sure what the design philosophy for stem is. >> Onionoo is always a possibility, though we'd probably need a bit more guidance on which part to work on (front end, back end, both?). But regardless, it still seems like it depends on various parsers that Ravi is working on. > > For an Onionoo project I would be the main mentor for stem based > parts, and Karsten would mentor the work on Onionoo itself since he > wrote the java version (though I'll still do the code reviews). First > step would be to start a thread with both of us (and tor-dev@) to > figure out milestones. > > FYI: at the Tor dev meeting Sathyanarayanan (gsathya.ceg(a)gmail.com) > also expressed interest in taking on this project, though with his > summer internship I'm not sure how much time he'll have to help. Do I understand Onionoo correctly to be basically a small webservice that returns a JSON formatted description of data read from a file based on the HTTP request parameters, along with a program that presumably runs with some frequency to create that file? It seems that at least porting the webservice side to a Django webapp might be a reasonable project for the rest of our summer. However, the little bit of software development that I learned does make me want to ask: Why a Python port or this component? - Norman -- Norman Danner - ndanner(a)wesleyan.edu - http://ndanner.web.wesleyan.edu Department of Mathematics and Computer Science - Wesleyan University

6 9

[GSoC] Stem 'stuff' - Progress report
by Ravi Chandra Padmala 09 Jul '12

09 Jul '12

Hello again I am currently working on implementing the network status (v3) descriptor parsers. I will implement the microdescriptor parsers after I'm done with that. The Python Onionoo implementation requires them, so I have paused working on the controller for now. I will resume working on the controller class once I'm done implementing these descriptor parsers. Damian reviewed and merged the setconf/reset methods into stem/master earlier today[1]. I will also be getting some of the other controller methods reviewed & merged to master this week[2][3][4][5][6]. 1. https://gitweb.torproject.org/stem.git/commit/6a91cda3db2a1ab1c4bf485fad03f… 2. http://repo.or.cz/w/stem/neena.git/shortlog/refs/heads/takeownership-wrapper 3. http://repo.or.cz/w/stem/neena.git/shortlog/refs/heads/signal-wrapper 4. http://repo.or.cz/w/stem/neena.git/shortlog/refs/heads/usefeature-wrapper 5. http://repo.or.cz/w/stem/neena.git/shortlog/refs/heads/saveconf-wrapper 6. http://repo.or.cz/w/stem/neena.git/shortlog/refs/heads/loadconf-wrapper -- neena

1 0

One man left a message for you
by Badoo 08 Jul '12

08 Jul '12

One man left a message for you Only you can see the sender and content of your message, and you can delete it anytime. You can instantly reply using our message exchange system: http://eu1.badoo.com/0246897483/in/EEdZpyZMo6Y/?lang_id=3&m=63&mid=4ff9eb00… Some other people in the area who are on Badoo Segun (Ibadan, Nigeria) Becky Jay (Ibadan, Nigeria) Sarath Cristina (Ibadan, Nigeria) http://eu1.badoo.com/0246897483/in/EEdZpyZMo6Y/?lang_id=3&m=63&mid=4ff9eb00… If the link in this message does not work, try copying and pasting it into your browser. This email is part of our delivery procedure for the message sent by One man. If you have received this email by mistake, please ignore it. The message will be deleted soon. Have fun! The Badoo Team You have received this email from Badoo Trading Limited (postal address below). http://eu1.badoo.com/impersonation.phtml?lang_id=3&mail_code=63&email=tor-d… Badoo Trading Limited is a limited company registered in England and Wales under CRN 7540255 with its registered office at 12 Red Lion Square, London, WC1R 4QD.

1 0

[PATCH] Implement proposal xxx: ignore subdomains in hidden service addresses
by Jérémy Bobbio 08 Jul '12

08 Jul '12

The implementation is pretty straightforward: parse_extended_hostname() is modified to drop any leading components from an address like 'foo.aaaaaaaaaaaaaaaa.onion'. --- Warning! Tests on this patch were limited to 'make check'. src/or/connection_edge.c | 10 +++++++++- src/test/test.c | 4 ++++ 2 files changed, 13 insertions(+), 1 deletions(-) diff --git a/src/or/connection_edge.c b/src/or/connection_edge.c index 3c8b4bc..92a3dbe 100644 --- a/src/or/connection_edge.c +++ b/src/or/connection_edge.c @@ -3490,6 +3490,7 @@ hostname_type_t parse_extended_hostname(char *address) { char *s; + char *q; char query[REND_SERVICE_ID_LEN_BASE32+1]; s = strrchr(address,'.'); @@ -3504,9 +3505,16 @@ parse_extended_hostname(char *address) /* so it is .onion */ *s = 0; /* NUL-terminate it */ - if (strlcpy(query, address, REND_SERVICE_ID_LEN_BASE32+1) >= + /* if there is a 'sub-domain' component, just remove it + * (see proposal XXX) */ + q = strrchr(address, '.'); + q = (NULL == q) ? address : q + 1; + if (strlcpy(query, q, REND_SERVICE_ID_LEN_BASE32+1) >= REND_SERVICE_ID_LEN_BASE32+1) goto failed; + if (q != address) { + memmove(address, q, strlen(q)); + } if (rend_valid_service_id(query)) { return ONION_HOSTNAME; /* success */ } diff --git a/src/test/test.c b/src/test/test.c index 454fc54..3edf02f 100644 --- a/src/test/test.c +++ b/src/test/test.c @@ -1289,11 +1289,15 @@ test_rend_fns(void) char address2[] = "aaaaaaaaaaaaaaaa.onion"; char address3[] = "fooaddress.exit"; char address4[] = "www.torproject.org"; + char address5[] = "foo.aaaaaaaaaaaaaaaa.onion"; + char address6[] = "foo.bar.aaaaaaaaaaaaaaaa.onion"; test_assert(BAD_HOSTNAME == parse_extended_hostname(address1)); test_assert(ONION_HOSTNAME == parse_extended_hostname(address2)); test_assert(EXIT_HOSTNAME == parse_extended_hostname(address3)); test_assert(NORMAL_HOSTNAME == parse_extended_hostname(address4)); + test_assert(ONION_HOSTNAME == parse_extended_hostname(address5)); + test_assert(ONION_HOSTNAME == parse_extended_hostname(address6)); pk1 = pk_generate(0); pk2 = pk_generate(1); -- 1.7.2.5

2 2

unsubscript
by after1990s 07 Jul '12

07 Jul '12

1 0

Proposal: Subdomain support for Hidden Service addresses
by ale＠incal.net 06 Jul '12

06 Jul '12

Hello! As discussed with a few people at the Florence Hackfest, here's a quick proposal for subdomain support on Hidden Service addresses. The implementation seems pretty straightforward (a patch will follow). Please forgive me if the proposal is missing something, or isn't using the proper Tor-specific technical terms, I'm kinda new to this :) -- I hope it is understandable nevertheless. Title: Subdomain support for Hidden Service addresses Author: Alessandro Preite Martinez Created: 06-07-2012 1. Overview This proposal aims to extend the .onion naming scheme for Hidden Service addresses with sub-domain components, which will be ignored by the Tor layer but will appear in HTTP Host headers, allowing subdomain-based virtual hosting. 2. Motivation Sites doing large-scale HTTP virtual hosting on subdomains currently do not have a good option for exposure via Hidden Services, short of creating a separate HS for every subdomain (which in some cases is simply not possible due to the subdomains not being fully known beforehand). 3. Implementation Tor should ignore any subdomain components besides the Hidden Service key, i.e. "foo.aaaaaaaaaaaaaaaa.onion" should be treated simply as "aaaaaaaaaaaaaaaa.onion". -- ale

1 0

Fwd: Stem Descriptor Parsers
by Ravi Chandra Padmala 03 Jul '12

03 Jul '12

Forwarding Megan's email because it looks like it's stuck in the mailing list's moderation queue. ---------- Forwarded message ---------- From: Megan Chang <mchang01(a)wesleyan.edu> Date: Mon, Jul 2, 2012 at 9:24 PM Subject: [tor-dev] Stem Descriptor Parsers To: neenaoffline(a)gmail.com Cc: Erik I Islo <eislo(a)wesleyan.edu>, Norman Danner <ndanner(a)wesleyan.edu>, tor-dev(a)lists.torproject.org Hi Ravi, We're currently working on data export for Stem and were wondering if you could clarify the following paragraph from your recent email: > It's highly unlikely that I'll be able to work on the descriptor parsers before the mid-term evaluation. I do have a large amount of buffer time at the end of the program which should be more than enough to implement them, even after taking Hofstadter's law into account Which descriptor parsers are you referring to, as some are already implemented? A lot of what we're working on in Tor Export overlaps your work regarding descriptor parsers. Seeing that it is unlikely for you to complete your work on them in the near future, do you mind if we take on the minor task of working on descriptor parsers? Also, just for our reference, when is your mid-term evaluation? Thanks! - Erik & Megan -- neena

1 0

Damian's Status Report - June 2012
by Damian Johnson 03 Jul '12

03 Jul '12

Hi all. This June I exchanged my developer hat to be a mentor instead, spending more time reviewing code than writing it myself. Fingers crossed that at least one or two of them stick around after the summer ends! As such, this status report is more about other people than me. Apologies if I miss anything. * Ravi (GSoC Student) This month Ravi discovered a bug with Tor's GETCONF method [1] and wrote numerous features including SAFECOOKIE support [2] and a GETCONF method for the controller [3]. The GETCONF handling is complicated by the accursed HiddenServiceOptions so it has needed several iterations, but I plan to merge it this week. After that Ravi already has two more feature branches lined up for me to review (*sob*)... * Beck (Volunteer) Somehow I've never been able to bring myself to do development on Windows (if you haven't seen Neal Stephenson's Hole Hawg article then I recommend it [4]). Fortunately Beck does, and has done a fantastic job of fixing stem and its tests to work there [5][6]. He also added get_version(), authenticate(), and protocolinfo() methods to the controller. * Erik and Megan (Wesleyan Students) Erik and Megan have been focusing on stem's tests, first submitting a couple fixes for the mocking module [7][8] then writing unit and integration tests for the proc utilities [9]. Next they plan to implement the CSV export functionality suggested by naif [10]. * Sathyanarayanan (Volunteer) Though work has kept him pretty occupied, Sathyanarayanan has been working on an ExitPolicy class [11] and is presently at the dev meeting making plans to implement a python based Onionoo. * Karsten Though he isn't hacking on stem itself, Karsten has been helping by reviewing its descriptor handling and suggesting improvements [12][13]. Besides those, I implemented a few stem improvements too this month... * Sphinx Documentation At the start of June I rewrote stem's documentation into reStructuredText so it could be compiled by Sphinx. The results are very pretty... http://www.atagar.com/transfer/tmp/stem_html_12_06_05/ * Python 2.5 Compatibility Stem aims to support python versions 2.5 and above (in the 2.x series). However, most of our development has been on 2.7, letting backward incompatible changes slip in inadvertently. This ended up being a two week bug fixing odyssey, but now that it's done stem and its tests should now work if users want an interpretor that harks back to 2006... * Test Freezing Issue on Mac OSX Both Sathyanarayanan and Karsten reported that stem's integ tests freeze on Mac OSX. After a dozen hours of hair pulling I've narrowed it down to an issue where control sockets are left in a CLOSE_WAIT state when closed, and eventually we lose the ability to make new control sockets... https://trac.torproject.org/6235 >From what I can tell this is either an issue with Tor, Python, or Mac OSX (my money's on the last). Help welcome if anyone has ideas. Other random things from this month include going to the Fremont Fair, attending a SEAPIG meeting (local python developer group) and making travel arrangements to attend Defcon later in July. Cheers! -Damian [1] https://trac.torproject.org/6172 [2] https://trac.torproject.org/5262 [3] https://trac.torproject.org/6114 [4] http://www.team.net/mjb/hawg.html [5] https://trac.torproject.org/5493 [6] https://trac.torproject.org/6205 [7] https://gitweb.torproject.org/stem.git/commitdiff/66376f5 [8] https://gitweb.torproject.org/stem.git/commitdiff/385b05b [9] https://trac.torproject.org/6082 [10] https://trac.torproject.org/6171 [11] https://trac.torproject.org/5454 [12] https://lists.torproject.org/pipermail/tor-dev/2012-June/003608.html [13] https://trac.torproject.org/6257

1 0

Re: [tor-dev] Stem Descriptor Parsers
by Ravi Chandra Padmala 03 Jul '12

03 Jul '12

On Mon, Jul 2, 2012 at 9:24 PM, Megan Chang <mchang01(a)wesleyan.edu> wrote: > Which descriptor parsers are you referring to, as some are already > implemented? A lot of what we're working on in Tor Export overlaps your work > regarding descriptor parsers. According to my proposal, I was to implement the parsers for V3 network status documents and microdescriptor documents for the mid term evaluation. > Do you mind if we take on the minor task of working on descriptor parsers? Fine by me. What descriptors would you be working on? > Also, just for our reference, when is your mid-term evaluation? July 9 - Mentors and students can begin submitting mid-term evaluations. July 13 - Mid-term evaluations deadline -- neena

2 1

[GSoC] Vidalia - Week 6
by Feroze Naina 02 Jul '12

02 Jul '12

I have created the Hidden Service plugin. Currently, the plugin loads the list of hidden services from the torrc file and displays it in a custom widget consisting of line-edits and spinbox inside a groupbox. This is then displayed in a vertical layout in the container widget's scroll-area. The values of HiddenServiceDir and HiddenServicePort are displayed in line-edits. If the Hidden Service had been activated previously, the hostname string is fetched from the file and displayed inside the plugin. The user can remove a service by selecting the corresponding checkbox and clicking the "-" button. The user can also edit a service by changing the values in line-edit and clicking the Apply button. This would change the values in the torrc file. I'm behind schedule by a few days. By this week, I will implement adding new hidden services to the plugin. The UI needs more work. I had originally alloted Week 7 for code cleanup. I have linked to a screenshot of the existing UI below. The "-" button is grayed out until a checkbox is selected. The Apply button is enabled only if any text has been edited. The stray TextLabel will be removed. I'm just using it for testing. [1] http://i.imgur.com/SG6ea.png [2] https://github.com/feroze/vidalia-plugins/tree/hiddenservice [3] http://feroze.in/gsoc12.html

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev