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