tor-dev

tor-dev@lists.torproject.org

5 participants
3594 discussions

Next Tor release timeframes?
by Roger Dingledine 08 Aug '12

08 Aug '12

1) Do we have any requirements to release an 0.2.4.1-alpha at any particular date? I haven't been following e.g. the latest SponsorG timelines. 2) Nick was enthusiastic about an 0.2.2.38 with the latest fix. Nick, do you still think that's important? My sense is that it's a totally esoteric theoretical attack where there's no rush to release. 3) For the next 0.2.3 rc, we might want to merge at least: https://trac.torproject.org/projects/tor/ticket/6252 https://trac.torproject.org/projects/tor/ticket/6404 --Roger

3 2

[patch] fix vidalia compilation in gcc 4.7
by Jason A. Donenfeld 08 Aug '12

08 Aug '12

Fixed in a gentoo bug report: https://422645.bugs.gentoo.org/attachment.cgi?id=320722

2 1

http_apache_steg_t is working now
by vmonmoonshine＠gmail.com 08 Aug '12

08 Aug '12

Hey Zack, I have pushed the working version of http_apache_steg_t. On server side it asks apache for the load, on the client side it uses the url dictionary and parameter values. http_apache_steg_t is inherited from http_steg_t. But because of all those macro hackish tricks (which expect you to inherit only from steg_t), it feels bit odd (when c++ natively support polymorphism maybe we don't need these macros). So you can test it writing http_apache instead of http in the command line. (but you need apache installed on server side and you need to run payload_scraper first) Downstream client to server is only curl now and hence probably more robust while passing proxies. It's blocking though. I'll make non-blocking in near future. I'm going to implement the protocol for passing the dictionary from the server to client in following few days and spends next week testing, writing tests and applying your comments on github (including spelling and grammatical mistakes :p ) Cheers, vmon P.S. I'm slowly re-styling stuff in the steg directory to c++ style, meanwhile it might look even uglier and messier, but it'll be pretier at end.

1 0

Re: [tor-dev] #6512 [Stem]: TorExport Module and Unit Testing
by Erik I Islo 07 Aug '12

07 Aug '12

Hi Damian, Looking at coverage the test provides, I was under the impression that the various cases of include_fields and exclude fields (e.g. if they overlap) should also be tested, but if you find that unnecessary, that would help explain why my unit tests were difficult to follow. In the mocking changes that I made, I added functionality for mocking functions that take keyword arguments. Though it is no longer necessary with the new unit tests, I was wondering if there was something I could have done better with that code as it seems such functionality may come in useful in the future. You may have already noticed this (and your documentation is consistent with this), but just to be sure, the new export code won't work with generators, which I bring up as this is what server_descriptor.parse_file() returns. So a user of this module would need to covert that generator into a list or tuple, which could be rather large. >>> def gener(list=[1,2,3,4]): ... for item in list: ... yield item >>> gener()[0] Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'generator' object has no attribute '__getitem__' Working with Professor Danner this summer (and from the CS classes I have taken so far), I am under the impression that run-time type checking can be expensive and generally falls outside of the realm of 'pythonic' code. To help Megan and I understand this design change, could you explain why you went with this style (e.g. line 83 in stem/descriptor/export.py)? Along similar lines, why wouldn't we also check the types of other parameters passed into the function? Thank you in advance for answering these questions -- this summer has been (and still is) a phenomenal learning experience for us, and gaining insight on coding style and the like is crucial to developing our own coding techniques. Looking at the code, I must apologize. I didn't mean to take so much of your time rewriting the code. That said, looking at your implementation gave me some perspective in evaluating the code I submitted so I don't make similar mistakes in the future. Best, Erik On Sat, Aug 4, 2012 at 3:22 PM, Tor Bug Tracker & Wiki < torproject-admin(a)torproject.org> wrote: > #6512: TorExport Module and Unit Testing > > ----------------------------+----------------------------------------------- > Reporter: ErikI | Owner: atagar > Type: enhancement | Status: closed > Priority: normal | Milestone: > Component: Stem | Version: > Resolution: implemented | Keywords: > Parent: | Points: > Actualpoints: | > > ----------------------------+----------------------------------------------- > Changes (by atagar): > > * status: needs_review => closed > * resolution: => implemented > > > Comment: > > Thanks Erik, merged with some revisions [1]. I found the unit tests a bit > hard to follow, especially since it wasn't broken down by the test cases > so I rewrote those. Let me know if I missed any test cases that you think > are important. > > [1] > > https://gitweb.torproject.org/stem.git/commitdiff/7022021c4207a0066cb932616… > > -- > Ticket URL: < > https://trac.torproject.org/projects/tor/ticket/6512#comment:3> > Tor Bug Tracker & Wiki <https://trac.torproject.org/> > The Tor Project: anonymity online >

2 1

[GSoC] Stem descriptor parsing - Status update
by Ravi Chandra Padmala 07 Aug '12

07 Aug '12

Hello I spent the last two weeks implementing the network status document parser and the microdescriptor consensus parser. The network status document parsing code is ready for review here[1]. It's a fairly large amount of code, with ~1.4K new LoC. The microdescriptor consensus parser is much simpler, since it reuses most of the network status document parsing code. I'll be uploading that soon. I should be working on the controller's event handling methods after that. 1. https://trac.torproject.org/projects/tor/ticket/6569 -- neena

1 0

Damian's Status Report - July 2012
by Damian Johnson 05 Aug '12

05 Aug '12

Hi all. My July was mostly spent traveling, both for Defcon [1] and a couple visits with my family on Vashon (for a funeral and Strawberry Festival). August will be much the same. I'll be gone... * 8/8 - 8/12 for Toorcamp [2] * 8/17 - 9/3 for a family trip Besides that and cat wrangling for the GSoC midterms, here's the things I did this month... * Implemented an ExitPolicy class [3]. Sathyanarayanan did the initial port of the class from arm, but that implementation turned out to have several issues (no IPv6 support, masking was incomplete, didn't strictly conform to the spec) so I ended up rewriting it. The result was pretty nice... https://gitweb.torproject.org/stem.git/blob/HEAD:/stem/exit_policy.py https://gitweb.torproject.org/stem.git/blob/HEAD:/test/unit/exit_policy/pol… https://gitweb.torproject.org/stem.git/blob/HEAD:/test/unit/exit_policy/rul… * Not tor related, but submitted five patches to ReviewBoard... * Re-enabling lexer guessing based on content [4] * Supporting dashboard impersonations [5] * Better supporting mixed newline types in diff reconstruction [6] * Crashing issue when authentication fails [7] * Better handle perforce symlinks [8] * Variety of small things... * Skipping tests on OSX that make numerous sockets to unblock development there [9] * Unsuccessful attempt to fix Windows specific date formatting issue [10] * Forgot to account for tor's debugger disabling in stem's proc tests [11] * Supporting the transport line in extrainfo descriptors [12] * Expanding the Version class and tor spec to include git commit ids * Variety of pylint fixes [13] * Discussion about is_alive() handling and quitting the socket [14] * Ravi has also been busy, finishing several controller methods... * GETCONF support [15] * SETCONF and RESETCONF support [16] * LOADCONF and SAVECONF support [17] * SETFEATURE support, though this one's still incomplete [18] Cheers! -Damian [1] http://www.atagar.com/arm/log.php#defcon2012 [2] http://www.toorcamp.org/ [3] https://trac.torproject.org/5454 [4] http://reviews.reviewboard.org/r/3156/ [5] http://reviews.reviewboard.org/r/3207/ [6] http://reviews.reviewboard.org/r/3208/ [7] http://reviews.reviewboard.org/r/3209/ [8] http://reviews.reviewboard.org/r/3221/ [9] https://trac.torproject.org/5917 [10] https://trac.torproject.org/6206 [11] https://trac.torproject.org/6286 [12] https://trac.torproject.org/6257 [13] https://gitweb.torproject.org/stem.git/commitdiff/fd2da10 [14] https://trac.torproject.org/6234 [15] https://trac.torproject.org/6114 [16] https://trac.torproject.org/6239 [17] https://trac.torproject.org/6356 [18] https://trac.torproject.org/6417

1 0

OnionOO protocol questions
by Norman Danner 04 Aug '12

04 Aug '12

Hi Karsten, A few questions on the Onionoo protocol specification: If multiple parameters are specified in the GET request, does that imply a logical and or a logical or (or something else)? E.g., suppose the GET request has type=relay and lookup=FFFF... . To me it seems like that should return the relay with fingerprint FFFF..., if there is such a relay. But it could also mean return all relays as well as the router with fingerprint FFFF... . The search parameter is described as "Return only relays with the parameter value matching the beginning of a nickname, (possibly $-prefixed) fingerprint, or IP address..." Do you mean that the parameter value matches the beginning of a nickname, the beginning of a (possibly $-prefixed) fingerprint, or is one of the relay IP addresses? For ordering, what do you mean by "possible fields for ordering are: consensus_weight." This is really two questions. How is the consensus_weight ordering defined when producing a summary document (which doesn't include a consensus weight field)? Can clients not request that summary documents be ordered by any of the 'n', 'f', 'a', or 'r' fields? Thanks! - Norman -- Norman Danner - ndanner(a)wesleyan.edu - http://ndanner.web.wesleyan.edu Department of Mathematics and Computer Science - Wesleyan University

2 4

[GSoC] Stegotorus
by vmon 04 Aug '12

04 Aug '12

Hi there, The payload strategies can be changed easily now by inheriting different class from PayloadServer. Current strategy is now in TracePayloadServer. For ApachePayloadServer strategy, server side is complete. for the client side, I need a handshake in steg level so the server sends the client, url dictionary. This needs to manipulate the program in level of Chop protocol. I spent few days to add this capability where chop send a reply handshake to the client (based what is in the paper) I haven't find it yet. Time to ask my mentor. Cheers, vmon

3 2

Sathya's status report - July 2012
by Sathyanarayanan Gunasekaran 04 Aug '12

04 Aug '12

July 2012 - Attended Tor dev meeting and hackfest in Florence in the first week of July. - Talked to arma, Karsten and asn about helping out with certain metrics tasks(#6460, #6232) to figure out the safety of the Tor network. Hopefully, I can extend this to something bigger and hack on it for my undergrad thesis. - Hacked on a entropy-over-time script(#6232) with help from Karsten, phw and asn. - Pair programmed with neena, helping him with his GSoC work(the consensus and votes descriptor parser). - Discussed pyonionoo components on the tor-dev mailing list[0]. - Hacked on the web service for pyonionoo for a bit at the hackfest. Megan is currently refactoring it and making it awesome. - Started work on the pyonionoo backend(#6452) - - Completed the network status document parser for summary documents - Taught pyonionoo about stem to parse server descriptors for details documents - Next up - Refactor this and add bandwidth documents. - Finished ExitPolicy parser for stem(#5454), which Damian ended up rewriting mostly. - Discussed the proper way to check if the Tor control socket is closed or not(#6234) which led to "Tor should have a PING command to check"(#6354), but arma and nickm are of the opinion that we shouldn't have any more pre-auth commands since it makes Tor more complex / less safe. Stem now makes a best-effort call (errors ignored) since we just want the socket to shut down and we don't need the QUIT to succeed to do that. - Discussed about setting up a code review tool(#6402). I've set up an ec2 instance with ReviewBoard and will hopefully set up the repos with some help from Damian soon-ish. [0] - https://lists.torproject.org/pipermail/tor-dev/2012-July/003731.html

1 0

Ticket #5749
by SiNA Rabbani 03 Aug '12

03 Aug '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have attached a patch: 0001-Faravahar-added.patch.asc to this ticket. Faravahar is very much ready! The patch is gpg signed, let me know if there are any other actions required on my part. All the best, SiNA - -- "If I had eight hours to chop down a tree, I?d spend the first six of them sharpening my axe." -Abraham Lincoln -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQHDhXAAoJEJPBwXYLR9Vt2Q0P/jRRUvrjB0AcoFagw9rUZzFr 1Os0RYPk1j9HXz30xJy9u+3sLQAaRQovpgvRJJv6GY0Jb+RCI9A4k6ExaHO4nxHq OJPhW6HcWa+w6QcFxIb4GizYVKthxcxcBPfVGPXvzH/U/gkGiuJYGNTXeCUhZNi9 JI5gtfOriwp7pspcXyufLZcAcjGE+8LKlwnEhqNeMhw6bGvqWFuueb5ZYLQwuOn/ ngtLFsD1NnAXgTAJY9wFS9tTmDX3wISKzMq726lKieOBqOH2v4+nkusoq8CUNfjK NPq8MsrtHEtxsEdR5nMy2PDROKHsUNclO9mV8+W/K5nRDjJU9wzgBlX+fttNZ5H6 AH9+1f6Tr4Z1KzLfNfBrwoq4kCgkIIvCkYl4xL+0RboFuITZuqqKwE0tA0MDMh6X uAKSkB7WsXrVbKpYVfppD9Z2blKmJ80gLvOWkuiptoe9mI/EhmfnzlwdGYzcp+80 A3ovAI7JADCQNYQjaVST1nudVy0nUGua957JKgry6P/GM83nj1p7krIKs0FzQtly pG6tyuLySFKFyhfdZ3jkpi/fJwrffDgXVrT2yXh4hljTaHd5ym6WjFrHcnoBdLLx 895jZhaFh65rBpLpq1yYa4yoO0+J0MKTRy5qDEgzZoq6Y5TjagEk3tKCmIF62dW7 18iv/9Dp/+6eZbTOjnN4 =UQ4G -----END PGP SIGNATURE-----

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev