[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #32363 [Core Tor/Tor]: tor_inet_aton parsing of IPv4 literals is too lax
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs