tor-dev

tor-dev@lists.torproject.org

3581 discussions

Italy - third highest number users
by SiNA Rabbani 19 Sep '12

19 Sep '12

Somehow in August, Italy got a few thousand additional Tor users and became third as far as usage of Tor: > https://metrics.torproject.org/users.html?graph=direct-users&country=it#dir… > Country Mean daily users > United States 60769 (14.30 %) > Iran 43709 (10.28 %) > Italy 37306 (8.78 %) > Germany 36672 (8.63 %) Any insight? --SiNA

1 0

Reminder: Big/tricky/interesting features for 0.2.4 need proposals by 10 October
by Nick Mathewson 17 Sep '12

17 Sep '12

Hi, all! >From https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/024 : "October 10, 2012: Big feature proposal checkpoint. Any large complicated feature which requires a design proposal must have its first design proposal draft by this date." There are only 23 days till October 10. If there's something you want in 0.2.4.x, and it is the kind of thing that needs a design proposal, and there is no proposal yet, it could be time to start writing! What needs a design proposal? Generally: anything that involves a change to the Tor protocol; anything whose security implications are nontrivial and need discussion; and anything that will change any Tor specification. Err on the side of "it needs a proposal." What is a "large complicated feature"? Please assume I'm going to be extremely grumpy here, and err on the side of "it is big". If the writeup of the proposal that explains how it works, or why to do it this way is going to take more than a few paragraphs, it is probably 'big' or 'complex'. (Note to would-be system-gamers: Please don't send a sketchy incomplete draft as a placeholder to get your foot in the door. That's not cool. If you don't have a draft ready, the feature can wait till 0.2.5.) (Note also: a feature proposal by this deadline is a necessary condition for getting your big/tricky/complicated feature into 0.2.4, but not a sufficient condition. It also needs to have a working implementation on schedule.) (Note finally: This is not a promise to not merge stuff that violates this deadline, but I sure will be trying not to merge such stuff.) yrs, -- Nick

1 0

DNS(SEC) draft update
by Ondrej Mikle 16 Sep '12

16 Sep '12

Hi Nick, I've revised the DNS draft, attaching it. In section 4 there are some options for integration with libunbound, but each of them requires some work with the stock libunbound code. Ondrej

3 3

Re: [tor-dev] Tor Volunteer
by Damian Johnson 15 Sep '12

15 Sep '12

> Damian, > > I saw on the tor-dev mailing list you would be happy to have help with > Python related Tor work. I'm game. I'd love to help the Tor Project. Hi Scott. Glad you want to help! These are great questions so I'm looping in Ravi (another developer who's actively hacking on stem) and tor-dev in case other people are interested. > I looked through the Easy bugs for Arm but it seems that Stem is where the > effort is going now. Yup. Arm was experiencing really bad feature creep so I swapped my focus to stem around a year back. Here's the relevant links for stem... * Development Wiki https://trac.torproject.org/projects/tor/wiki/doc/stem * Gitweb https://gitweb.torproject.org/stem.git * Bug Tracker http://tinyurl.com/stem-bugs > Should I focus on Stem? > Do you have a list of easier tasks to get my feet wet with? Sure! We're currently working to make it feature complete and prepare for its initial release. Development tasks tend to fall into a few general categories... =================== Controller Functionality =================== Stem is primarily a replacement for TorCtl, a controller library used by several of our other projects (arm, SoaT, TorBEL, etc). Ravi's been focusing on making the Controller class feature complete. This is mostly located in... https://gitweb.torproject.org/stem.git/blob/HEAD:/stem/control.py Some nice introductory tasks here would be... * Add methods for querying relay descriptors The first bits of this is very easy, while the later parts get a bit more interesting... - Add a get_relay() method that calls get_info("desc/id/[fingerprint]") then return a ServerDescriptor for it. - Write unit and integ tests for the addition. - [tricky part] Add a get_all_relays() method that provides an iterator for all of the descriptors. The tricky bit is that the BaseController provides discrete controller messages, but in this case the "GETINFO desc/all" output is so large that we want to process it while it comes in. This means changing stem's underlying message processing system. * Split low and high level controller methods The Controller class is growing to be pretty bulky, and its methods can generally be split into two categories... - Low level methods that simply mirror what the control-spec provides. - Higher level methods (like the get_relay() and get_all_relays() above) which are more user friendly and build on what the control spec provides. Ravi: Do you have any thoughts on this? Do you think this would be a good way to break up the controller, or would this just make it more confusing? Alternatively we could wait until we try using stem in arm to see if this makes sense or not... =============== Descriptor Parsing =============== This is where my focus has been for the last couple weeks. A controller needs to be able to parse Tor's descriptor content (GETINFO's desc, ns, and md responses). This has expanded to include file descriptors and other descriptor content, so stem can be used as a python replacement for MetricsLib. This is useful for projects like Onionoo's python counterpart. This is a somewhat dry part of stem to work on, so unless you like reading specs and writing a parser for them this might not be a great section to work on. That said, if detail oriented parsing and validation sounds interesting then there's lots 'o tasks here. ====== Clients ====== Stem doesn't yet have any clients, and will certainly need some before we make a release in order to work out the kinks. Our plan for this is... * Port arm's interpretor Arm's control interpretor is actually a standalone script that can, with a little work, be used independently from the rest of arm. It would be interesting to see what an stem based control interpretor would look like... * Port arm's torTools module Arm makes very heavy use of the controller, and abstracts all of its TorCtl usage behind a wrapper module... https://gitweb.torproject.org/arm.git/blob/HEAD:/src/util/torTools.py This abstraction should make arm reasonably easy to move to stem. Also, stem's getting many of that wrapper's features so arm's codebase could be greatly simplified after we move. * Port TorBEL TorBEL would be a great candidate after we work out most of stem's rough edges by moving arm. It'll likely provide some interesting use cases, though this is still a ways out. ======= Usability ======= Stem doesn't yet have a site, nor have I posted its sphinx documentation anywhere. A few things that we should do here is... * Make a pretty site Ideally I'd like to write the site itself with sphinx so we have a consistent look between the front page and the documentation. * Site with auto-updating documentation This would involve setting up a site with a cron process that fetches stem and, if changed, serves up the new documentation. * Tidy up sphinx docs Stem has a lot of documentation, but we haven't really looked much at the sphinx output with an eye for making it developer friendly. It would be nice to have people try to use stem, and improve the documentation for the confusing bits. * Examples We should ask tor-dev@ for a list of bite sized Tor tasks that people commonly want (like "print my relay's bandwidth" or "list all of the relays with the BadExit flag"). Then write example scripts that do this, and provide them on stem's site to give example usage. > If so, how hard is it to set up a dev environment? Very, very easy. Assuming that you have python, git, and tor installed simply do the following. * Get a copy of stem git clone git://git.torproject.org/stem.git * To run its unit tests cd stem ./run_tests.py --unit * To run its integ tests ./run_tests.py --integ > Does the Tor Project have a formal mentorship program? How does that work? I'm not sure what you mean by a 'formal mentorship program'. I've mentored students through GSoC and Wesleyan's open source program if that answers your question. Cheers! -Damian

2 1

torrouter development
by ficus＠robocracy.org 12 Sep '12

12 Sep '12

Hello tor-dev! I would like to contribute to the torouter (aka TorRouter, aka OnionBox?) project, with the intention of getting a "functional" development image for the DreamPlug hardware released in the next few weeks. The goals of the torouter project seem a bit vague (especially w/r/t a transparent torified WiFi access point), perhaps this is why development slowed down previously. I will attempt a design document and specification, but mostly focus on making the core components (debian, tor, web interface) functional and configurable, such that they could be leveraged by others as solutions to specific use cases. Will this be useful to others? It seems like the preferred collaboration tool is the trac wiki and tickets. Many of the torouter tickets seem stale and incomplete, and the roadmap on the trac wiki is very out of date. Unless there is advice i'll ignore those but continue discussion on tickets like #3854 (Summary of outstanding things with Torouter) and #3453 (Torouter desires and features). cheers!

4 9

Format-Transforming Encryption for Censorship Circumvention
by Kevin P Dyer 11 Sep '12

11 Sep '12

Following my email to this list, dated 29/07/2012, I direct your attention to the IACR eprint document http://eprint.iacr.org/2012/494, "Format-Transforming Encryption: More than Meets the DPI". In it, we present our framework for steganographic encoding of messages using regular languages, along with initial findings for a Python/C++ based implementation. To briefly highlight some of the main things we deliver: * A record-layer, powered by format-transforming encryption, that can tunnel arbitrary SOCKS streams. * Algorithms that allow efficient and invertible mapping between bit strings and elements of a regular language L. These allow us to encode traditional encryptions of plaintexts into strings from L in a way that maximizes the number of bits that are encoded. * A framework for the creation of good regular languages, "good" with respect to performance and security. In particular, our language-learning framework produces sets of regular expressions (compact representations of the languages) that are learned from real traffic. Our system also allows you to use off-the-shelf regular expressions, like those from appid [1] and l7-filter [2] that are designed to detect HTTP traffic. We consider this preliminary technical report on a work-in-progress. In fact, we can already do more than what is reported (e.g. greater variety of languages, better system performance), but we will save these advances for a future release. Cheers, Kevin P Dyer (and his co-authors) [1] http://code.google.com/p/appid/ [2] http://l7-filter.sourceforge.net/

2 3

Integration of Tor, Tor Browser, Tor IM, Tor Birdy, Vidalia, Tor Router, Tails, etc.
by adrelanos 10 Sep '12

10 Sep '12

Hello, the current integration has a lot open issues and feature requests. [2] Because there might come a proposal [1] to solve this cleanly, I created an overview of all related open issues. [2] There are just so many issues I though it makes sense to create an overview so nothing gets forgotten. Feel free to edit/correct/expand the wiki site. Add your wishes. I cc'ed all effected people, if someone has been forgotten, feel free to forward this mail. Can we have this discussion on tor-dev? Cheers, adrelanos [1] https://trac.torproject.org/projects/tor/ticket/5611#comment:43 [2] https://trac.torproject.org/projects/tor/wiki/doc/TB

2 1

[GSoC] [Stegotorus] Code submission and more curl
by vmon 10 Sep '12

10 Sep '12

Hello Zack, 1) I would like to ask your permission to submit the whole code for code submission. First because my task in the summer wasn't only to write the parts that I wrote but also to read the code and debug it as well. Secondly because the git log shows who wrote what. Thirdly, It's easier. 2) I had more discussion on libcurl-dev with the libcurl main developer. He thinks despite the fact my approach is working right now, it isn't stable and can break down in a different environment. To solve this, I'm going to let curl also read from the socket instead of libevent, this isn't very hard (I'll disable both EV_READ and EV_WRITE as soon as I'm handing the socket to curl). I confirmed with Nick that (unlike libcurl) libevent support this. 3) Thank you for telling me about fts. I'm going to replace boost code with fts soon. 4) >I still don't see the problem. If you do exactly that, and don't use >he DECLARE macros for http_apache_steg, what breaks? If I don't use the DECLARE then I can't specify http_apache as the steg protocol in the command line . Best, vmon

4 4

Tenative schedule for Tor 0.2.4 [Or, why I might reject your patches in November->March]
by Nick Mathewson 07 Sep '12

07 Sep '12

Hi, all! Last year, I announced a tenative schedule for 0.2.3.x. We didn't stick to it, and things have gone a little pear-shaped with getting 0.2.3.x stabilized, but I think with a few tweaks we can use something similar to get a good schedule out for 0.2.4.x. My goals remain about what they were before: get release out faster by getting better at saying "no" to features after a release window. My target is March or April 2013. To that end: October 10, 2012: Big feature proposal checkpoint. Any large complicated feature which requires a design proposal must have its first design proposal draft by this date. November 10, 2012: Big feature checkpoint. If I don't know about a large feature by this date, it might have to wait. November 10, 2012: Big feature proposal freeze. Any small feature which requires a design proposal must have its design proposal finished by this date. December 10, 2012: Big feature merge freeze. No big features will be merged after this date. December 10, 2012: Small feature proposal freeze. Any small feature which requires a design proposal must have its design proposal finished by this date. January 10, 2013: Feature merge freeze. No features after this date. I mean it. Feb 20, 2013: Buggy feature backout date. Any feature which seems intractably buggy by this date may be disabled, deprecated, or removed until the next release. On the meaning of "feature": I'm probably going to argue that some things that you think are bugfixes are features. I'm probably going to argue that your security bugfix is actually a security feature. I'm probably even going to argue that most non-regression bugfixes are features. Let's try to get a release out *early* in 2013 this time, come heck or high water. (This is all subject to change, but let's not push it.) [0] https://lists.torproject.org/pipermail/tor-dev/2011-July/002851.html happy hacking, -- Nick

4 4

Parallel release series for directory authorities?
by Nick Mathewson 06 Sep '12

06 Sep '12

Hi, all! Here's an idea I had for directory authorities and the 0.2.3 release series. "As you know Bob," Tor 0.2.3 will be stable very soon, and I'm hoping not to take any more patches for it except for important security issues. I want 0.2.4 to come out very early next year. But in the meantime, to support 0.2.4, and to deploy security/reliability features to the network early, there are some directory consensus features that we'd want to deploy before the rest of 0.2.4 is done and stable. In particular, I'd like directories to be able to reach consensus on IPv6 addresses (6363), and I'd like to try out the code that Mike wrote to make the bandwidth voting system more robust against dishonest during its startup phase (2286). So here's my plan: Make a "maint-0.2.3-da" branch based on 0.2.3, plus feature patches for directory authorities. It gets patches from the stable series (0.2.3), plus directory-authority features under development. It would get merged-forward into 0.2.4, to make sure that 0.2.3-da and 0.2.4 behavior stay in sync. This way we can get new authority features working in time to support 0.2.4 clients, but without forcing too many authorities to run 0.2.4 before it's ready, and without forcing us to make feature changes in 0.2.3 proper. Thoughts? yrs, -- Nick

7 8

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev