[tor-dev] On status of Stegotorus on github vs SRI

[vmonmoonshine at gmail.com]

Hi Jeoren,

Thanks for your comments or tor-dev IRC channel. I thought I may as well
take my time and reply to them here so I can also include Zack, Vinod
and others into the discussion. 

>I think the large chunks of commits without specific
>goals/descriptions what the commit fixes will be timecostly to
> integrate, 

I started working on Stegotorus as a GSoC student last summer and I have
been more or less continuously working on it since then. I always kept
the tor-dev list informed on my progress. So a quick search on
[Stegotorus] should gives anybody a good idea on stuff I was working
on. But I can summarize all my works in four categories:

- Debug.
- Writing more unit and behavior tests, including tester-proxy,
  webpage-tester and bad-dropper-proxy.
- Integrating Stegotorus with a web server (e.g Apache Httpd) so the covers
  can be served by the web server.
- Debugging the ack/transmit protocol and the packet transmission
- reliability in general.

In general, along the way, I tried to reconstruct the code into being
more C++ and more object oriented (I'm continuously doing so). Obviously
Stegotorus was designed to be as modular as possible. That is the main
motivation behind "pluggable transport": the DPI got more intelligent?
Plug the compromised module out, plug something else in with minimum
effort.  

All of Stegotorus different modules are begging for OOP and
inheritance. However, forcing the code into C had just made the steg
folder unmanageable and un-expandable. The different steg modules (pdf,
swf and js) have something like 70%-90% code in common but instead of
being inherited from a common parent the code has been copied multiple
times. It seems like an artificially generated example by OOP
evangelists to convert people into OOP by showing how terrifying
functional programming can be.  

>especially as the hidden upstream has diverged quite a
>bit in some places (which one can nicely attribute to the wrong of
>that 'model', but unfortunately not an easy way around that);

Until recently that Roger sent an email to Vinod, I did not know that the
upstream in SRI is making any progress (I'm not sure if even Roger (or
anybody else on the Tor side for that matter) was fully aware of the
amount of progress on the other side) . Last winter, Zack told me that
I'll be the maintainer of the code (at least from Zack's prospective) in
the sense I'd decide what patch to keep and what to discard. 

> nevertheless, I think the best plan to get those in there would be to
> see when that code is out, and have a list of important
> ... fixes/commits available and then at one point go over everything 
> and try to get them merged into that code base, will be big
> job though to get that done, and would 'require'
> that upstream takes them, which mostly depends on
> available time I would say....

As Roger and other have mentioned multiple time, it is hard to fully
reconcile the SRI model of development with the open source model. In
that sense, we'll probably always have an open source version of
Stegotorus and a SRI version of it (At least till SRI development is
active).

Nevertheless, my goal is to reconstruct the best piece of software
possible out of all available code and I'll do my best to integrate all
improvement into the open source version.

> I think for that matter, trying to really have upstream have a
> github version and accept patches would be a good way to avoid such
> scenarios; hence also why we'll be pushing the acs code there into
> the safdef repo, just the easiest way to make that happen if one 
> wants it; but first to finish that code and stop restructuring it
> and adding new features etc.... then it will be pushed there,
> otherwise not much use for people looking at it anyway.

I do agree that the best thing is to wait for updated code to be
published before going ahead to avoid re-invention of the wheel and
waste of time. But I have a contract to add some features
to Stegotorus with deadlines and I think Roger has asked Vinod for the code
release on March 25 and it is not clear how longer it is going to
take. Nonetheless, I'm going to ask Vinod if he can have a quick look at
those features and decide which one are more likely to be affected by
the recent development. For example when you told me about the ACK, I
moved to the other parts.

Thanks for your advice and updating me about the other side. Please
keep me updated of any detail that you think will help with Stegotorus development.

Cheers,
Vmon