Re: [tor-bugs] #16069 [Tor]: ipv4 + ipv6 exit : v6 policy is displayed twice, v4 isn't displayed

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#16069: ipv4 + ipv6 exit : v6 policy is displayed twice, v4 isn't displayed
--------------------------+-----------------------------------------------
     Reporter:  toralf    |      Owner:
         Type:  defect    |     Status:  needs_review
     Priority:  critical  |  Milestone:  Tor: 0.2.7.x-final
    Component:  Tor       |    Version:  Tor: 0.2.7
   Resolution:            |   Keywords:  026-backport, ipv6, PostFreeze027
Actual Points:            |  Parent ID:
       Points:            |
--------------------------+-----------------------------------------------

Comment (by teor):

 Replying to [comment:39 nickm]:
 > Better and better.
 >
 > Only two questions here:
 >   * Are you completely sure this doesn't affect how we parse descriptors
 at all?

 Descriptors are parsed by `router_add_exit_policy`:
 * The only modifications to this function itself are comments and a log
 message. (The log message was ambiguous, I have pushed a fixup.)
 * `router_add_exit_policy` calls `router_parse_addr_policy(tok, 0)`,
 whereas the torrc parser `router_parse_addr_policy_item_from_string` calls
 `router_parse_addr_policy(tok, TAPMP_EXTENDED_STAR)`.
 * All my changes are conditional on TAPMP_EXTENDED_STAR being set, so they
 don't affect the `router_add_exit_policy` codepath. I have pushed a fixup
 to ensure that we don't even set any extra flags unless
 TAPMP_EXTENDED_STAR is set.

 Routersets are parsed by `routerset_parse`:
 * `routerset_parse` has been modified to use malformed_list. The code used
 to reject the entire list on errors, and that behaviour has been
 preserved.
 * I've added code that ignores the line if malformed_list is 0. It's never
 executed in the current implementation, because `routerset_parse` never
 uses accept6/reject6, and therefore can't get accept6/reject6 IPv4. (But
 it's there in case we decide to ignore other types of policy lines in
 future.)

 >   * How verbose are these logs going to be?

 For serious misconfiguration errors where the operator isn't getting the
 exit policy they expect:
 * One warning-level message per HUP if there are any redundant torrc lines
 after an accept/reject *:* line (or equivalent). The message identifies
 the first redundant line. (We advise operators to finish exit policies
 with accept/reject *:* as the final entry, and no warning is issued in
 this case, as there are no redundant lines.)
 * One warning-level message per HUP per accept6/reject6 line with an IPv4
 address (or *4). We ignore these lines, so we let the operator know
 they're not getting what they expect. (Should we only warn on the first of
 these?)
 * One warning-level message per HUP per accept6/reject6 line with a
 private alias. We include both IPv4 and IPv6 addresses when processing
 these lines, so we let the operator know they're not getting what they
 expect. (Should we only warn on the first of these?)

 For potentislly unexpected policy outcomes:
 * One info-level message per accept/reject *:<port> line per HUP. There
 are typically many of these lines per exit policy. (Should this be at
 debug level? Should we only log on the first of these?)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16069#comment:40>
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