tor-dev July 2012

tor-dev@lists.torproject.org

54 participants
68 discussions

Tomas' June 2012 status report
by Tomás Touceda 10 Jul '12

10 Jul '12

Hi everyone, Here's what I did for Vidalia in June: - Reviewed a series of patches from other people: TorrcPrototype implementation and some Torrc parsing fixes by feroze, the testing framework by sebb, up to date country code/flags handling by sirop, a Network Map stream traffic patch by an anonymous contributor. - Improved Network Map by adding Entry/ExitNode handling, better display of relays in the router list, better handling of microdescriptors, improved performance in loading the whole router list, solved a couple of crashes with certain edge cases. - Fixed a couple of bugs regarding default values with DataDirectory. - Improved bridge handling usability a little bit. - I spent a couple of days trying to understand better qtscriptgenerator so we can improve the plugin engine. - I did a lot of testing in general and helped Erinn with the new configurations for TBB. Most of my work on June and on will be on the alpha branch, since it'll be tagged as stable in not too long. Regarding Vidalia Plugins: - I did a lot of testing of the TorControl interface, now that Vidalia uses the automatically generated extension by qtscriptgenerator. The idea is to use this tool to create interfaces for everything we need. I also helped Feroze with his GSoC goals. As he has said in his reports in here, he's been working in the HiddenService configuration plugin. Vidalia alpha doesn't have that tab in its configuration because it was pretty problematic, so we decided to move it to a plugin. Regards, Tomas

1 0

Mike's June 2012 Status Report
by Mike Perry 10 Jul '12

10 Jul '12

I fixed the following bugs in June: https://trac.torproject.org/projects/tor/query?keywords=~MikePerry201206 Exec Summary of Trac Tickets: I reviewed WebGL for fingerprinting issues as well as reviewed a rendering-based fingerprinting vector and produced plans for next steps/defenses on both fronts. I rebased our Firefox patches to both 10.x-ESR and 13.0, and wrote a script to immediately alert us of new releases via email. I spent some time shepherding a Windows TBB patch by Shondoit. I also commented a whole bunch of Torbutton code with priority levels so that it may be ported over to Proxy Mobile or eliminated. The future will run on a Proxy Mobile derivative. Nick and I also worked on a Tor patch to help Tor clients defend against "path bias"/"route capture" attacks, but we still need to tune the parameters more. Non-trac tasks: I made some progress on determining how to set optimal parameters for the "path bias"/"route capture" defense (ticket #6138). I wrote a python simulation and determined next steps (12 points, development). I finished up the Tor core interview process by sending out "rejection" letters suggesting specific areas where the applicants could apply their skills in potential future positions at Tor, and at least volunteer in those areas in the meantime (5 points). I spent an unsettling amount of time on email, coordination, and general conspiracy. It seems to have gone up from last month to about 8 points/week this month. (32 points). I spent a day and some change with the EFF and working on HTTPS-Everywhere issues (6 pts, development). I did some postmortem on our first volunteer QA run, replying to results and filing tickets about potential future tests. More postmortem is needed. Hopefully I can get to it before the next TBB release. (1 point). Time Keeping Notes: I did 31 points of trac-recorded development activity this month, in addition to 18 more points of development on tickets not yet closed, for a total of 49 points of development activity. I did 38 points of non-development work this month. A bit more sane ratio than last month, but man is email a time sink. Trac Workload Stats: I only closed 7 tickets of priority major and above in June. Sad. At the beginning of June, 50 major+ tickets were opened against me. As of this report, 54 major+ tickets are now opened against me. This means I've lost roughly 4 months of forward progress against major issues (I had previously been closing about 1 major+ ticket more per month than were opened against me). https://trac.torproject.org/projects/tor/query?status=accepted&status=assig… aka https://bit.ly/KZcmA9 Next month: https://trac.torproject.org/projects/tor/query?keywords=~MikePerry201207 Exec Summary: I'm going to throw much less on the queue ahead of time this month, due to a week being lost to fascistly shitty Internet access (yes, fascistly. Adverbing is the new new hotness now. Verbing is so OVER) during the dev meeting in Italy, as well as last month seeing way less closed tickets than expected. There's also a lot more conspiring to be done, as it turns out. -- Mike Perry

1 0

Mike's May 2012 Status Report
by Mike Perry 10 Jul '12

10 Jul '12

For comparison with June and to follow Roger's example, here's my May status report. ----- Forwarded message from Mike Perry <mikeperry(a)torproject.org> ----- I fixed the following bugs in May: https://trac.torproject.org/projects/tor/query?keywords=~MikePerry201205 Exec Summary of Trac Tickets: I designed a volunteer TBB testing program. We're still working out the bumps, but I'm pretty confident that we'll be able to keep the overhead at the level of "one email + an scp" for Erinn. I fixed several very serious Tor Browser bugs, including a DNS leak, a disk leak, an evercookie leak, and I released a Torbutton 1.4.6 using an offline update signing key (no more remote code exec through arbitrary CA compromise!). I also bumped the Torbutton useragent, clear search+find boxes on New Identity, perform the TBB versioncheck regularly in the background, updated the captcha redirect to startpage, fixed a window sizing issue, synced some important Torbutton and TBB prefs with eachother, and did some review + made some suggestions for Torbirdy. Most notably from a support perspective, Torbutton 1.4.6 informs users about TBB, and is no longer togglable (though you can re-enable toggle if you uncheck a checkbox in the prefs). Non-Trac Tasks: I helped with the tor core interview process, determining stages, reviewing resumes and phone screening candidates, and helping Nick with the third round coding question. (20 points). I reviewed a handful of trac tickets and did some triage. (3 points). I made a first pass at a patch to detect path bias (2 points). I reviewed another silly website fingerprinting attack paper. (2 points). I spent a fair amount of time on email. It seems like it comes down to about 6 points per week on average, with the exception of this last week, where I spent an additional 16 points arguing about volunteer processes and the benefits of involving the community in our work. (6*4 + 16 = 40 points). Time keeping notes: I did 40 points of trac-recorded development activity this month. I did 67 points of non-trac work this month. That's a total of 107 points, which is roughly 214 hours, give or take about 20 hours for rounding error. I really failed at timeboxing work in the last week, which is I think why this number is so high compared to last month. Trac workload stats: I closed 14 tickets of major priority or above, yet there are still currently 50 tickets of major priority or above opened against me. This is one less than the number of tickets last month! I'm still making steady progress at a rate of 1 major+ ticket per month (same rate as last month)! I'll be done with them all in just a scant 50 more months! :) https://trac.torproject.org/projects/tor/query?status=accepted&status=assig… https://bit.ly/KZcmA9 Next Month: https://trac.torproject.org/projects/tor/query?keywords=~MikePerry201206 Exec Summary: Fix TBB fingerprinting and linkability issues, updating the TBB design doc, rebase Tor Browser to Firefox 10.x ESR, publish the relay best practices doc + scripts, write a build security proposal outline, work on the path bias issue. Probably also help smooth out tor-qa process a bit more. -- Mike Perry ----- End forwarded message ----- -- Mike Perry

1 0

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev July 2012