[tor-bugs] #5127 [Obfsproxy]: Fix IPv6 support in obfsproxy

[Tor Bug Tracker & Wiki]

#5127: Fix IPv6 support in obfsproxy
-----------------------+----------------------------------------------------
 Reporter:  karsten    |          Owner:  asn           
     Type:  defect     |         Status:  needs_revision
 Priority:  normal     |      Milestone:                
Component:  Obfsproxy  |        Version:                
 Keywords:             |         Parent:                
   Points:             |   Actualpoints:                
-----------------------+----------------------------------------------------
Changes (by nickm):

  * status:  needs_review => needs_revision


Comment:

 Reviewing....

 Actual code issues:

 * It looks like the code will accept a bunch of addresses that aren't
 actually any good, like "[1.2.3.4]:80" and "[::1] random junk :80".  For
 the first one, we probably want to insist that anything between brackets
 needs to be an IPv6 address.  For the second, we probably want to make
 sure that the : appears immediately after the ], not 'eventually' after.

 Minor stuff unrelated to actual code:

 * Next time, use a repository cloned with "git clone" rather than by just
 re-important all the files into a new repository.  Using "git clone" makes
 your history match the upstream history, so that your branch can be merged
 with "Git merge" and show up in the history properly.  As it stands, we'll
 have to cherry-pick the commits.  Not a big deal since there are just 3,
 though.
 * What editor are you using?  It seems to be giving you weird brace
 alignments.  Like, sometimes your indent is 4 space, and some times it's 1
 space.

 TODO at merge time, or whenever. No need to do all this yourself; asn or I
 can do it instead:

 * Replace the printfs in test_util.c with TT_BLATHER so the unit tests
 aren't loud unless we want them to be.
 * The array of tests in test_util.c should probably be const.
 * Reconsider "fuckeverybody" as a generic nonexistent servicename. (We're
 not anti-fuck  in the Tor source code, but we generally use it for
 describing stuff like APIs we don't like, the state of cross-platform
 programming, the complexity of openssl, censorship, censorware, data
 retention proposals, ugly code, insecure security tools, breaking backward
 compatibility, and so on.)
 * Should the tests check that the value produced is indeed as expected?
 * Add license boilerplace to new test_util.c.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5127#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online