tor-dev

tor-dev@lists.torproject.org

3581 discussions

Damian's Status Report - April 2013
by Damian Johnson 06 May '13

06 May '13

Hi all. Though April had a bit of stem work the month was mostly gobbled up by the chaos that is GSoC [1]. I never cease to be amazed at how much time orchestrating it takes, but enough of that. Other tasks from last month included... Improved Stem's Site * Added a change log for user facing improvements [2] * Added a FAQ, suggestions for more entries welcome! [3][4] * Improved navigability via a css style navbar menu [5] * Site logo and faveicon * Thanks to Dererk stem is now in Debian [6], and will soon be in Fedora too thanks to Juan * Put stem on tor's front page to improve discoverability [7] General Stem Improvements * Overhaul for a large part of our testing framework, run_tests.py in particular was in need of a rewrite [8] * Fix for broken process renaming (patch from ragwater [9]) * We now have a custom :trac: and :spec: role for Sphinx (patch from ragwater [10]) * ATTACHSTREAM provided an unexpected 555 response (caught thanks to a cypherpunks [11]) * Added support for the ADDRMAP event's new CACHED attribute * Looked into anomalous bridge-ip-transports lines in the consensus, turned out to be from an unmerged tor patch running on George's relay Cheers! -Damian [1] https://blog.torproject.org/blog/tor-google-summer-code-2013 [2] https://stem.torproject.org/change_log.html [3] https://stem.torproject.org/faq.html [4] https://trac.torproject.org/8577 [5] https://trac.torproject.org/8431 [6] http://packages.debian.org/sid/python-stem [7] https://lists.torproject.org/pipermail/tor-commits/2013-April/055091.html [8] https://gitweb.torproject.org/stem.git/commitdiff/ae5193f?hp=314876a [9] https://trac.torproject.org/8631 [10] https://trac.torproject.org/8671 [11] https://trac.torproject.org/8701

1 0

Tor Launcher settings UI feedback request
by Mark Smith 05 May '13

05 May '13

As many of you know, Kathy Brade and I have been working on a Firefox add-on named Tor Launcher, which will function as a Tor process manager and controller for TBB (replacing Vidalia). See: https://trac.torproject.org/projects/tor/ticket/6009 Currently, Tor Launcher provides access to the basic Tor network settings that are needed by TBB users. We would like some feedback on the Network Settings dialog (accessible from within the browser after it starts up) and on a "first run" wizard that we have created based on a suggestion from Greg Norcie. A collection of screenshots is available here: http://trial.pearlcrescent.com/tor/torlauncher/2013-05-03/ If you are in a hurry, just look at these two: http://trial.pearlcrescent.com/tor/torlauncher/2013-05-03/FromBrowser/netwo… (settings dialog as seen from inside the browser) http://trial.pearlcrescent.com/tor/torlauncher/2013-05-03/SetupWizard/wizar… (composite of all of the wizard panels). Thanks to everyone who has provided input so far. -- Mark Smith Pearl Crescent, LLC http://pearlcrescent.com/

11 21

RELAY_COMMAND_END formate
by Frank Young 03 May '13

03 May '13

The payload format for RELAY_COMMAND_END and RELAY_DATA are not details in the tor protocol specifications. where can i get the payload format for these relay cells? Thanks

2 2

GSoC 2013 project idea
by Sreenatha Bhatlapenumarthi 03 May '13

03 May '13

Hi, My name is Sreenatha Bhatlapenumarthi (lucyd). I am a third year computer science undergraduate at IIITH. I am interested in participating in GSoC'13 with Tor. I've begun by submitting patches for stem tickets #7505, #8605 and #7713. I'd like to propose a new idea for a project with a blend of stem, TorBEL and pyobfsproxy. I've split the project into 3 modules. 1. Fix stem bugs and add new features if possible Although I can't think of any new functionality to add to stem(other than what Damian suggested) at this point of time, there are some bugs that need to be fixed. I went through the tracker and picked some stem-related bugs I'd like to fix as a part of the project. Please feel free to suggest new bugs or let me know if you think any these are of low priority and don't need to be included in the project. - #7910 (Port some of arm's connection utilities to stem) - #8255 - #8248 - #8249 2. Migrate TorBEL to Stem [0] This will involve porting TorBEL from TorCtl to Stem and making modifications to the stem API if necessary. Hopefully after fixing the bugs mentioned above, I'd have a better understanding of how stem works and I'd be able to do a better job. 3. Implement HTTP pluggable transport for pyobfsproxy I can think of two ways of doing this - Develop an actual pluggable transport for obfsproxy to impersonate HTTP traffic. I've looked at obfs2's protocol-spec and its python implementation and I think this would involve writing a separate module implementing the transport with a template similar to that of DummyTransport[1]. - Use a browser engine like webkit on client-side and a web server on the server-side as mentioned at ticket #8676[2]. Here are a couple of questions I have regarding the project: - What are the priorities of the modules I've proposed? - Do you think the project has enough scope and material for a SoC project? If not, can you please suggest some more features to add? - If the project seems overloaded, which module(s) do you suggest I drop? I would love to hear your opinions on these matters. If there's something you want me to take a look at or study, please do let me know. Thank you for your time. [0] - https://trac.torproject.org/projects/tor/ticket/8263 [1] - https://github.com/lucyd/obfsproxy/blob/master/obfsproxy/transports/dummy.py [2] - https://trac.torproject.org/projects/tor/ticket/8676 Cheers, Sreenatha

2 2

SQLSupport
by moataz ahmed 03 May '13

03 May '13

is it possible to insert data about routers,circuits and bwhistory in database ? i am using opaddon to measure relays and i can see in torctl folder that there is a file called sqlsupport.py he is using sqlalchemy to deal with database i ran opaddon many times but there is no insertion in the database !!! any help ?

2 1

[possibly OT] Updated giant inventory of headers available on various OSes
by Zack Weinberg 02 May '13

02 May '13

A while ago I posted a call for help (only to autoconf@) taking inventories of which C headers are provided by which OSes. It rapidly became clear that my methodology was far too crude, and I've spent much of the past six weeks coding up something much more sophisticated. The project is now at the point where I feel comfortable sharing it with a wider audience. Please see http://hacks.owlfolio.org/header-survey/ for the results so far, and https://github.com/zackw/header-survey/ for code, raw data, and instructions for contributing inventories for OSes not yet in the big table. (Big table only known to work properly in Firefox, say sorry - patches for the bad stylin' in Webkit most welcome. I've exhausted my ability to sling CSS.) If you sent me an inventory already but your OS is not in the big table, I need you to send it again using the current `scansys.py`. To those of you who told me that it didn't work with your version of Python, take heart - it is now tested to work with 2.0. Yes, 2.0. zw

1 0

Cell digest of relay cells destined for hidden services
by Frank Young 02 May '13

02 May '13

The digest of relay cells are running digests [ SHA_final() is never called ], so the digest of each cell is dependent on the previously computed digest destined for that node particular node. Hashing is seeded with values determine by the OR which responded with CREATED or REALY EXTENDED cell. I have noticed that, the payload of RELAY_COMMAND_RENDEZVOUS unlike CREATED OR RELAY EXTENDED cells made no provisions for the seeding bytes. This can be referenced in section 1.10 of https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=rend-spec.… I'm in a state of confusion concerning how the digest of relay cells destined for hidden services should be computed. [1] should the digests be independent of previously computed digests destined for the hidden services? OR [2] it should be a running digest but not seeded with any seeding value. I will like a little clarification on this. Thanks

2 1

ping
by wac 01 May '13

01 May '13

ignore please

1 0

Re: [tor-dev] Stem Integ tests for Tor
by Ashish Patil 01 May '13

01 May '13

On Mon, Apr 29, 2013 at 17:44 PM, Nick Mathewson <nickm at alum.mit.edu> wrote: > Right now, all chutney > does is configure and launch a small Tor network, but the small > network requires a little babysitting to make it bootstrap. (For > example, you sometimes need to send the clients a SIGHUP once the > authorities have made their first consensus. So, the first bits for improving chutney would be to automate the network generation as much as possible (leaving no loose ends)? > What Chutney doesn't do (but should!) is actually test the network it > launches. Right now, to make sure the network has bootstrapped, you > have to read through its log files. If you want to test the network > with any traffic, you need to use an application of your choice to > send traffic through one of the Tor clients, and verify that the > output as is expected. And if you want to make sure that Tor is > running without weird warnings, you need to manually inspect the > log files again. It would be good if Chutney grew into, or were > replaced by, a tool that could actually do testing right that. Now, we want chutney to be robust enough to encompass all the manual that is mentioned above & automate it as much as possible or atleast print the tasks to be performed by the tester sequentially. We would need a set of static reliable web pages if we want to automate the traffic testing? Also, we would parse the log files for errors or warnings so that we dont have to manually check for them. * Construct a circuit to an exit which allows port 80 and request a site through it. * Do the same for an exit which rejects port 80. * Construct a one-hop circuit through an exit. * Try to use a circuit that runs through a bridge. * Let tor pick the path of a circuit and assert that the first relay's a guard and the last is an exit. * Attempt to request a page from a hidden service. * Host a hidden service and request something from ourselves. * Act as a relay and try to construct a circuit that includes ourselves. * ... etc... As Damian listed down all the tests one needs to carry out for actual network testing (keeping in mind unreliability of the network at times), what all additional tests would we like chutney to have?

3 3

GSoC Deadline Reminder
by Damian Johnson 01 May '13

01 May '13

Hi all. If you're a prospective Google Summer of Code student and haven't yet submitted a proposal then please do so now. The deadline is Friday (May 3rd). You'll be able to edit your proposal up until the deadline so there's no reason not to submit something early. If you don't submit a proposal on time then it doesn't matter how great of an idea you have - we'll be unable to accept it. -Damian

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev