- tor-dev - lists.torproject.org

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

[GSoC] Pluggable Transports in Python Status Update
by Brandon Wiley 02 Jul '12

02 Jul '12

Status Update - Refactoring There was a slight change in the schedule in that I moved refactoring up in front of testing and debugging. The major refactoring effort was in splitting the project into two parts. The library for implementing the pluggable transport specification, with environment variable parsing and printing of pluggable transport protocol lines to stdout is now all that is included in pyptlib. The framework and obfsproxy command line program replacement have been split off into py-obfsproxy. A high-level API has also been added to pyptlib which requires less knowledge of the spec. It automatically parses environment variables and generates protocol lines. The transport implementation just needs to get the list of supported transports and then report success or failure for the launch of each transport as well as the end of the transport launching phase. Examples have been included in pyptlib for how to use the high-level library and py-obfsproxy has been ported to the high-level library as well. All of the code has also been reformatted according to PEP 8 guidelines. Private methods have also been renamed to use the __foo syntax as specified in the python style guidelines. This week the focus is going to be on testing the framework and obfsproxy command line replacement to get the dummy protocol working. One everything is working the focus will shift to documenting the now hopefully stable pyptlib API. pyptlib: http://github.com/blanu/pyptlib py-obfsproxy: http://github.com/blanu/py-obfsproxy More posts on the blog: http://stepthreeprivacy.org/

1 0

[GSoC] Stem Controller Class
by Ravi Chandra Padmala 02 Jul '12

02 Jul '12

Hello. The configuration related control methods get closer to merging each day. I've been working on the control methods for the other control commands. I will begin working on the event handling methods later this week. I also found & fixed(?) a tiny bug in the tests[1]. The deliverables for my mid term evaluation are: * Implementation of a fully documented General controller class with sufficient test coverage. * Implementation of parsers for parsing network status documents and microdescriptor documents with significant test coverage. * Integrate the Safe Cookie authentication client into Stem. (Close #5262). Safe cookie authentication support has been merged into master. I am fairly certain I will be done coding (most, if not all of) the general controller class before the mid-term evaluation, but, it's unlikely that it will be merged into stem/master that soon. 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 :/ 1. https://trac.torproject.org/projects/tor/ticket/6248 -- neena

1 0