[tor-bugs] #32363 [Core Tor/Tor]: tor_inet_aton parsing of IPv4 literals is too lax

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Feb 5 18:06:12 UTC 2020


#32363: tor_inet_aton parsing of IPv4 literals is too lax
----------------------------------------+----------------------------------
 Reporter:  liberat                     |          Owner:  neel
     Type:  enhancement                 |         Status:  needs_review
 Priority:  Medium                      |      Milestone:  Tor:
                                        |  0.4.4.x-final
Component:  Core Tor/Tor                |        Version:
 Severity:  Normal                      |     Resolution:
 Keywords:  BugSmashFund, extra-review  |  Actual Points:
Parent ID:                              |         Points:  0.2
 Reviewer:  nickm                       |        Sponsor:
----------------------------------------+----------------------------------

Comment (by nickm):

 > Now with the last changes, we do use the heap quite a bit with the
 smartlist_t so why would we prefer not using the heap in the first place?
 Does it still matter now?

 It doesn't matter except to the extent that it slows us down... we should
 keep an eye on profiles after we merge this.

 > Can we add a smartlist_core dependency to lib/net ?

 Yes: to see why, run `./scripts/maint/practracker/includes.py --toposort`
 for a topological sort of our current modules from lowest to highest
 level.  It appears that `net` is already much higher than smartlist_core.

 One thing I want to think about, though: do we care about the
 fingerprinting issue?  That is, this patch will create a class of
 addresses that some clients will parse and some clients will reject.  Is
 that a security issue to worry about, or are we cool here?

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


More information about the tor-bugs mailing list