Re: [tor-dev] Stem GSoC 2013

[Damian Johnson <atagar@xxxxxxxxxxxxxx>]

> As far as tutorials go, I was thinking about dealing with manual stream
> attachment (as a follow up to #8728),
> exploring more operations on circuits i.e. tearing down, forcing hops
> through specified
> countries or address ranges (maybe a more robust example as an excuse to
> come up with good
>  use cases for REDIRECTSTREAM and TRUNCATE).

Great! Actually I was just thinking about this yesterday too. Indeed,
a couple things that would be great to have are...

* A truncate_circuit() method. From what I can tell TRUNCATE isn't an
operation (just a REMOTE_REASON for CIRC events), so this might
require expanding the tor controller interface.

* The ability for new_circuit() and extend_circuit() to handle paths
where tor picks some of the hops. For instance...

circ_id = controller.new_circuit([None, None, 'amunet1'])

... to construct a circuit where tor picks the first two hops normally
but we exit through amunet1. There are a couple ways of doing this.
The right way is to add this capability to tor, and the hacky way is
to construct a normal circuit, truncate the exit, then replace it.

If you're willing to get your hands dirty with tor code as well as
stem then two other things that have been high on my wish list are...

https://trac.torproject.org/7953
https://trac.torproject.org/8323

Though that said while these would certainly make for a meaty proposal
a lot of this work would be C rather than Python. I'd understand if
that makes this less than appealing - there's plenty of other options
too.

Some stem specific ideas are...

* Navigation of our API documentation presently sucks a bit. Two ideas
for things that could help it are...

  https://trac.torproject.org/7632
  https://trac.torproject.org/8780

* Controllers often iterate over descriptors but it's presently
horribly inefficient. The trouble is that we read the full controller
response into memory which can be hundreds of kilobytes and parse it
before providing the first reply. Unfortunately fixing this will be
tricky, requiring some additional capabilities in the stem.socket
module.

  https://trac.torproject.org/8248

* As you've found the process for attaching a stream to a circuit is
presently pretty clunky. Maybe the controller should have a method
that takes two arguments: a circuit id and a functor which will
generate a stream. It then makes the stream, attaches it to the
circuit, and returns to the caller when its done?

Besides that I'm really having trouble coming up with meaty ideas that
solely involve working on stem. Most ideas that I'm coming up with are
either limited by tor's control protocol (so would require work in C)
or would involve a new project.

One that Karsten warned me away from suggesting for GSoC but I'd love
to see happen is Pyonionoo, a python rewrite of our Onionoo service.
That project would involve a fair bit of stem expansion...

https://trac.torproject.org/8252

All that said maybe a fresh pair of eyes are best here. Do you have
any ideas, maybe some expansion to stems site, capabilities, or tests
that you think would make a good project?

Cheers! -Damian
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev