Re: [tor-dev] TorPylle: a Python/Scapy TOR protocol implementation

[Damian Johnson <atagar@xxxxxxxxxxxxxx>]

> More seriously, it's not a software intended to be run by Tor users or even
> Tor relay operators, it's a framework intended to be used by Tor developers
> / hackers to play with implementations of the Tor protocol.

Gotcha. It might be worthwhile to clear this with
tor-assistants@xxxxxxxxxxxxxxxxxxxx to ensure that this won't be a
problem down the road if TorPylle grows. I can speak from experience
when I say that renaming a project is a pain in the ass. Especially
once its been established for a while. I'd loooove to rename arm
(years back when I picked the name the processor didn't have much
prominence) but doing so is now just too daunting.


On a side note the appearance of your project has kinda funny timing.
Just last week I was thinking "Gah! Why does tor's reference
implementation need to be C?". In my not-so-humble opinion that's
dragging the application down in terms of maintainability and
continued development...

* Tor has only three people (mostly just Nick) routinely touching the
core codebase. This means effectively no code reviews and little
collaboration. This is not likely to get better with time -
universities have been shifting toward higher level languages for
years as have industry.

* Mocking is a pain with C. Nick had some ideas six months back to get
around this, but I'm not sure if they ever really took off or itself
is maintainable.

* C is simply difficult to get right. Besides the risk of stack
overflows and memory leaks, there's countless pitfalls that
necessitate years of C development experience before touching a line
of code.

* Tor really doesn't *need* to be in C. Descriptors, controller,
consensus voting, and much of its other functionality would do better
with a higher level language, with small C modules for networking and
crypto parts that truly need Libevent and such. This would be fine
with Java's JNI, Python, Ruby, or any of a handful of languages.

All this said Nick no doubt could list a dozen reasons why this is a
terrible idea, not the least being the monumental amount of work and
wanting a tor executable without the need for an interpretor. Oh well,
I can still dream.

> I just had a look at this project, and if I understand well, it speaks to a
> Tor's control port
> and gets its data from the Tor client. With TorPylle, I want to be able to
> fetch data from any Directory Server directly, and act more or less "as if"
> I was a Tor client.

As I said previously, "It's not just a client of tor's control port,
but also a python implementation of its directory specification."

Take another look at the remote descriptor module I pointed out. It's
exactly what you want - it pulls descriptor content from the tor
directory authorities and mirrors.

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