Opened 9 years ago

Closed 9 years ago

Last modified 8 years ago

#5549 closed project (fixed)

Evaluate feasibility of a Python obfsproxy and possibly get it started

Reported by: karsten Owned by:
Priority: Medium Milestone:
Component: Circumvention/Pluggable transport Version:
Severity: Keywords: SponsorF20120701
Cc: nickm, asn, aagbsn, blanu, zwol, xmux Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Item 19 from org/sponsors/SponsorF/Year2 is: "evaluate feasibility of a python equivalent to obfsproxy, to make it easier for people to write transports in python. See also Brandon Wiley's "dust". If we decide it's smart, get it started."

There are a few substeps here: first, we should discuss feasibility of a Python obfsproxy; maybe we need some proof-of-concept implementation to further evaluate things we cannot solve by discussion; then we need to make a decision; and finally, if we decide that having a Python obfsproxy is a good idea, we'll have to get it started.

Creating a child ticket for the discussion part. Further substeps should get their own child tickets.

We need to decide whether this is a July or November deliverable (optimistically assigning to July), and we need somebody to lead the deliverable.

There are quite a few people who I've heard might be interested in this topic and who I'm cc'ing: nickm, asn, aagbsn, blanu, zwol, xmux. If more people are interested, please cc yourself.

Child Tickets

#5550closedDiscuss feasibility of a Python obfsproxyArchived/Obfsproxy

Change History (4)

comment:1 Changed 9 years ago by karsten

Owner: asn deleted
Status: newassigned

Undoing Trac's annoying auto-assignment to the component owner.

comment:2 Changed 9 years ago by karsten

In #5550 we concluded that we're going to develop an experimental Python pluggable transport library for further evaluation and see how people will adapt it. We're going to do that in #5614 which doesn't have to happen in the sponsor F year 2 timeframe.

Can somebody (Roger?, Nick?, George?) summarize the most important pros and cons from the feasibility discussion as a deliverable summary for the year2 page? The summary should give the reason why we decided that writing a Python obfsproxy library is feasible. Once we have that summary we can close this ticket and call deliverable 19 done.

comment:3 Changed 9 years ago by arma

Component: ObfsproxyPluggable transport
Resolution: fixed
Status: assignedclosed


The main goal (#5614) is to develop a python library to make pluggable transport operations easier for the variety of python transports people are working on now (including dust and flashproxy). The secondary goal is to develop a proof-of-concept use of that library that is obfs2-compatible. Brandon will work on this for Google Summer of Code 2012.

comment:4 Changed 8 years ago by karsten

Keywords: SponsorF20120701 added
Milestone: Sponsor F: July 1, 2012

Switching from using milestones to keywords for sponsor deliverables. See #6365 for details.

Note: See TracTickets for help on using tickets.