- tor-dev - lists.torproject.org

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

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