[tor-dev] Sponsor F: update; next meeting [in *two weeks*]

[David Fifield]

On Mon, Oct 14, 2013 at 09:14:25PM +0100, Ximin Luo wrote:
> On 01/10/13 03:13, Tom Lowenthal wrote:
> > Combine obfuscation (obfsproxy) with address-diversity (flashproxy) [#11]
> > -------------------------------------------------------------------
> > 
> > **[On Track: Minimal]** The work of integrating obfsproxy with
> > flashproxy is done. George will include this in the next released
> > version of the pluggable transports browser bundle. George will also
> > write a report on this work. Ximin and David will help. By Halloween,
> > the report will be complete and the bundles will either be released or
> > well on their way through testing. This likely represents some
> > combination of minimal or intended outcomes for this deliverable.
> 
> We have deployed and tested working instances of the combined
> obfs3/flashproxy transport. This includes all components - the client,
> server, facilitator and browser proxy - and they are all backwards
> compatible with the old components that only support the plain
> (non-obfs3) websocket protocol. Soon (this week) the code will be
> merged. There are a few other issues to iron out before a
> production-quality release. We may be able to do it by Halloween, but
> I'd prefer not to rush through them just to make that date (if that is
> fine for the sponsor). I'm more certain it will be production-quality
> sometime mid-November.
> 
> I haven't considered PTBB packaging and I'm not sure about the work
> needed, but if George does this in parallel with me making the code
> production-quality, the timings should line up as expected.
> 
> Specific remaining tasks:
> 
> - merge #9349, #6810, #9974
> - push #7167 to an official tpo repo
> - do #9976, and #7167#comment:42 might require an obfsproxy fix

I agree with this, except that I don't think #9974 (facilitator
packaging) and #9976 (general argument passing to registration helpers)
are necessary for this deliverable. They are nice and I want them, but
in terms of this deliverable I would prioritize #9349 (facilitator
transport support) and #7167 (obfs–flash composition) first.

Would you hate me if I suggest not merging #6810 (client code
reorganization) until after we build at least one bundle? It's lower
risk to go with the organization we know works, especially given that we
are changing other things within the bundle.

> Other less-vital things which improve robustness/quality:
> 
> - connection reliability under churn: #9964, #5426, #8285
> - flexibility of ecosystem: #9942, #9949, #9965
> - various other code-quality issues, all on trac, see [1]

Just one note here, #8285 (expiration of email registrations) is already
closed.

David Fifield