Re: [tor-dev] Stem ORPort protocol support
> On 8 Feb 2018, at 07:23, Damian Johnsonwrote: > > Hi all. Over the last few months Tim and I have been collaborating on > Python support for the ORPort protocol. With it you can download > descriptors without a DirPort, and possibly fancier things in the > future like full circuit construction. Stem's ORPort support is great news! We have been looking at alternate Tor implementations that are easier to hack for testing: https://trac.torproject.org/projects/tor/ticket/17270 > Tim put together a wonderful proof of concept called Endosome... > > https://github.com/teor2345/endosome > > ... and I just finished integrating it into Stem... > > https://gitweb.torproject.org/stem.git/tree/stem/client/__init__.py I have added both Endosome and Stem to the Tor implementations wiki: https://trac.torproject.org/projects/tor/wiki/doc/ListOfTorImplementations Looking forward to trying out the ORPort features when the descriptor download API is stable. It will be great to be able to check Fallback Directory Mirror ORPorts: https://trac.torproject.org/projects/tor/ticket/19129 T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n signature.asc Description: Message signed with OpenPGP ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Stem ORPort protocol support
Damian Johnsonwrites: > Thanks meejah! Took a peek but they both look pretty old and it's > unclear to me how complete either got. If there's something in > particular you think is worthwhile integrating I'm all ears. I haven't looked closely enough to know the answer to that ;) but as I understand it had (2 years ago) enough to bootstrap and make circuits. >> For any of these efforts, writing a "Tor protocol library" that >> *doesn't* do any I/O would be the most useful; then other Python tools >> can benefit from the protocol support without being tied to "threads" or >> to a particular async framework. > Actually, this uses a similar pattern as the rest of Stem in that cell > packing/unpacking is independent of the threaded socket. Just as you > could use stem.response for controller message parsing in txtorcon, > you can use stem.client.cell for cell packing/unpacking with a twisted > application too. Interesting, okay! Last time I looked, I had to re-assemble the whole "response" to feed it into stem.response -- so I ended up needing to keep most of the protocol state-machine anyway (i.e. to figure out which bytes constituted "a response"). I should probably look again if this has changed :) The way Hyper/h2 works is it just gets fed bytes and "interesting events" come out (essentially), as I understand it. So, the corresponding thing here would be: set up some Stem 'protocol' object with an "interesting event happend" callback. Then, feed bytes into some single API on this object and it calls the "event happened" callback every time enough bytes have been fed in for a complete parsed response object to be generated. (This is just the one side of the protocol; the other side would be similar) -- meejah ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Stem ORPort protocol support
> So, there is this already -- not sure how "complete" it is though (and > looks like hasn't seen commits for 2+ years) but might have useful code: Thanks meejah! Took a peek but they both look pretty old and it's unclear to me how complete either got. If there's something in particular you think is worthwhile integrating I'm all ears. > For any of these efforts, writing a "Tor protocol library" that > *doesn't* do any I/O would be the most useful; then other Python tools > can benefit from the protocol support without being tied to "threads" or > to a particular async framework. Actually, this uses a similar pattern as the rest of Stem in that cell packing/unpacking is independent of the threaded socket. Just as you could use stem.response for controller message parsing in txtorcon, you can use stem.client.cell for cell packing/unpacking with a twisted application too. That said, thanks for the reminder to keep this in mind as we go. Cheers! -Damian ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Stem ORPort protocol support
Damian Johnsonwrites: > they'd care to go (potentially all the way up to a Python Tor client, > similar to Orchid). So, there is this already -- not sure how "complete" it is though (and looks like hasn't seen commits for 2+ years) but might have useful code: https://github.com/pycepa/pycepa There is also this one, that I've barely looked at (and is older than the above) based around Scapy: https://github.com/cea-sec/TorPylle For any of these efforts, writing a "Tor protocol library" that *doesn't* do any I/O would be the most useful; then other Python tools can benefit from the protocol support without being tied to "threads" or to a particular async framework. One of the best examples of this style of library is the hyper/h2 implementation of HTTP2 (which powers Twisted's HTTP2 support and also supports threaded HTTP2 servers and clients) by separating the "protocol" implementation into its own library (that does no I/O and doesn't start any threads "for" you). This style is usually referred to as "sans-io" (at least in the Python community). You can read more about these libraries: https://python-hyper.org It would be really cool to have a Python implementation of the Tor protocol -- and double-extra-useful if it's a "pure" protocol library without any messy I/O constructs involved :) Cheers, meejah ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev