[tor-bugs] #26227 [Core Tor/Stem]: Review existing stem.client code
    Tor Bug Tracker & Wiki 
    blackhole at torproject.org
       
    Tue Jun 26 18:42:54 UTC 2018
    
    
  
#26227: Review existing stem.client code
---------------------------+------------------------------
 Reporter:  dmr            |          Owner:  dmr
     Type:  task           |         Status:  needs_review
 Priority:  Medium         |      Milestone:
Component:  Core Tor/Stem  |        Version:
 Severity:  Normal         |     Resolution:
 Keywords:  client         |  Actual Points:
Parent ID:                 |         Points:
 Reviewer:  atagar         |        Sponsor:
---------------------------+------------------------------
Comment (by atagar):
 > I just noticed that several other places relied on the Size pop() for
 the exception behavior; these few seemed inconsistent.
 Ok, you persuaded me. Consistency is important - pushed.
 > Suggestion: use a library for this (see architecture ticket, #26227)
 I'm confused. Is this ticket citing itself?
 This conversation has grown way too long for me to keep track of. Please
 file a separate ticket to discuss the HTTP edge cases you pointed out. The
 approach Stem takes with libraries is...
 * Use builtins if at all possible.
 * If a library is vital then we can take a **soft** dependency on it. An
 example of this is cryptography - if unavailable Stem still works, but
 lacks certain features like descriptor signature validation.
 On first glance maybe we can use builtins to avoid the gotchas you
 mentioned?
 https://stackoverflow.com/questions/4685217/parse-raw-http-
 headers/5955949#5955949
 > comment 4
 What in particular from comment #4 would you like for me to reply to? As
 you mention, it's veeeeeery long.
 > circ_id allocation
 Yup, we subtly changed how circ_ids are allocated but unless I'm missing
 something it still conforms with the spec.
 We are not attempting to be indistinguishable from the C tor codebase on
 the wire. That is a different and much, much harder project that would
 involve wireshark, a moving target, and tears. Rather, our goal is to make
 a **compatible** tor implementation that conforms with the spec.
 Did I miss anything?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/26227#comment:14>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
    
    
More information about the tor-bugs
mailing list