I summed up the discussion plus what I had in mind with in 15 tickets that I put on the track.
https://trac.torproject.org/projects/tor/query?status=accepted&status=as...
Zack is going to suppliment it with few more steg module concerns. By that time we should have a fairly complete list.
From: Roger Dingledine arma@mit.edu
We should definitely put a page like that up. Let us know if we can do anything to help! :)
(asn or I or others can do the website commit)
I think we (you? :) should work on a TBB bundle (like the other pluggable transport bundles people are working on) that ships the simplest most efficient steg module(s) we've got, so Stegotorus can get some actual users and start collecting usability/crash/etc bug reports.
I bet Alexandre et al would be happy to bundle in another thing, with their current obfsproxy-and-flashproxy bundle.
Let me deal the ack bug (https://trac.torproject.org/projects/tor/ticket/8086) in the few following weeks. Then I'll approach Alexandre for bundling and you to put the webpage on.
Thanks everybody for your help, Vmon
vmonmoonshine@gmail.com writes:
I summed up the discussion plus what I had in mind with in 15 tickets that I put on the track.
https://trac.torproject.org/projects/tor/query?status=accepted&status=as...
Zack is going to suppliment it with few more steg module concerns. By that time we should have a fairly complete list.
The code monkey inside me doesn't see any code-quality-related tickets in that URL. stegotorus boasts 12k LoC of C++ and some of that code was written in haste. Looking at this from a deployment point of view, I feel much more relaxed and easygoing with deploying programs written in a high-level language (like Flashproxy or pyobfsproxy) than with deploying an unaudited C++ program with many bad code moments.
I think that a trac ticket with a bit of research on how painful would be to write a deployable <high-level language>-port of stegotorus would be a good idea. I know that Zack is also interested in exploring this avenue.