Opened 8 years ago

Closed 8 years ago

#5550 closed task (fixed)

Discuss feasibility of a Python obfsproxy

Reported by: karsten Owned by:
Priority: Medium Milestone:
Component: Archived/Obfsproxy Version:
Severity: Keywords:
Cc: nickm, asn, aagbsn, blanu, zwol, xmux, hellais Actual Points:
Parent ID: #5549 Points:
Reviewer: Sponsor:

Description

The first step in evaluating feasibility of a Python obfsproxy could be to discuss possible issues and advantages as compared to the C obfsproxy. Here is a random collection of arguments that I heard from talking to people and which might help kick off the discussion:

  • Maintaining two versions ob obfsproxy is madness.
  • Once we have a working Python obfsproxy we can drop the C obfsproxy.
  • Python will make it easier to keep a sane software architecture than C, in particular when adding lots of transports.
  • Implementing the same transport in C and Python in a compatible way might be difficult.
  • Packaging a Python obfsproxy would be much harder than packaging the C obfsproxy.
  • A Python obfsproxy might not be able to handle potentially large numbers of connections, as opposed to a C obfsproxy.
  • A Python obfsproxy can start as a by-product of working on transports.

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.

How about we keep this discussion in this ticket to collect more arguments and figure out which issues and advantages are most relevant?

Should we define a date when we hope to have discussion results? How about April 30?

Who can moderate this discussion and summarize results at the end?

Child Tickets

Change History (5)

comment:1 Changed 8 years ago by karsten

Owner: asn deleted
Status: newassigned

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

comment:2 Changed 8 years ago by asn

Cc: hellais added

After discussing this issue in the dev meeting, we decided that the performance questions can be answered by creating a dummy pluggable transport proxy and doing stress tests on it.

This means that the current unanswered problem, is deployment in Windows. My understanding is that Nick is afraid that solutions like py2exe result in 30MB .exe files.

I think we should find out what is our threshold for the size of a python binary (is 5MB okay?), and how big would a "pyobfsproxy" windows binary actually be in practice.

This is a related thread in tor-dev by Arturo:
https://lists.torproject.org/pipermail/tor-dev/2012-March/003328.html

comment:3 in reply to:  2 Changed 8 years ago by karsten

Replying to asn:

After discussing this issue in the dev meeting, we decided that the performance questions can be answered by creating a dummy pluggable transport proxy and doing stress tests on it.

Oh great, sounds like a good portion of the suggested discussion has already taken place.

So, regarding performance evaluation, what do we expect to be the performance bottleneck? Is it handling hundreds of connections, doing crypto, or something else? Is the plan to implement obfs2 in Python and comparing performance to the C obfsproxy, or something different?

Is there already a ticket for this performance evaluation, or should I create one? What's a reasonable deadline for this task (April 30?) and who would do the work?

This means that the current unanswered problem, is deployment in Windows. My understanding is that Nick is afraid that solutions like py2exe result in 30MB .exe files.

I think we should find out what is our threshold for the size of a python binary (is 5MB okay?), and how big would a "pyobfsproxy" windows binary actually be in practice.

Is there already a ticket for evaluating installer size? If not, who would I assign a newly created ticket to and what would be a reasonable deadline (April 30?)?

This is a related thread in tor-dev by Arturo:
https://lists.torproject.org/pipermail/tor-dev/2012-March/003328.html

Without reading that thread in detail, are there any other aspects that need discussion and/or evaluation with respect to "pyfsprxy?"

comment:4 Changed 8 years ago by arma

I want to make sure nickm, wearing his chief architect hat, has input here.

comment:5 Changed 8 years ago by karsten

Resolution: fixed
Status: assignedclosed

George, Roger, and Nick discussed pros and cons of developing a Python obfsproxy in #tor-dev yesterday. The conclusion was that we should come up with a little framework, and maintain it if it gets used. We're going to do that in #5614. As part of that we're also going to look into the evaluations as discussed in the comments above. That means we're done with the feasibility discussion. Closing this ticket.

Note: See TracTickets for help on using tickets.