Re: [tor-bugs] #17857 [Core Tor/Tor]: Create a consensus param to disable (netflow) padding if RSOS is enabled

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

#17857: Create a consensus param to disable (netflow) padding if RSOS is enabled
----------------------------------+------------------------------------
 Reporter:  teor                  |          Owner:  mikeperry
     Type:  enhancement           |         Status:  needs_revision
 Priority:  Medium                |      Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor          |        Version:
 Severity:  Normal                |     Resolution:
 Keywords:  tor-hs, single-onion  |  Actual Points:
Parent ID:                        |         Points:  1
 Reviewer:                        |        Sponsor:
----------------------------------+------------------------------------
Changes (by teor):

 * status:  needs_information => needs_revision


Comment:

 Replying to [comment:27 mikeperry]:
 > Ok, I added #defines for the consensus params and defaults in a fixup
 commit, but as for using the functions instead of the options directly,
 there is a problem: I don't see an easy way to use the tor2web function,
 because it depends on a #define for NON_ANONYMOUS_MODE. This makes it
 impossible to unit test the behavior unless I rebuild all of Tor (or
 somehow rebuild only the the Tor files that check the NON_ANONYMOUS_MODE
 #define) just for my test.
 > Do any other tests rebuild various c files with different #define values
 for cases like this? I didn't see any.. Do we need to write custom
 makefile rules now, or is that just crazy? It seems crazy this late in the
 0.3.1 game for sure, and seems a little crazy generally...

 Our unit tests don't work for Tor2web. And it will be deprecated in 0.3.2
 or 0.3.3 when v2 hidden services are deprecated.

 > IMO options validation like this should be done at torrc load time and
 during a control port config update, not at every single use in the
 runtime.

 It's done at torrc load and on use. Please open a separate ticket if you
 want to remove the validation on every use.

 > Given that, I'm inclined to leave it as torrc options only.

 I don't mind what we do with Tor2web, it's going to be removed soon. And
 the current option usage is not consistent in the codebase.

 But it's important that we use accessors for single onion services, so
 it's easier to implement #22694 and similar tickets. And so that access to
 the single onion options is consistent across the codebase. (If you want
 to change that, please open a separate ticket.)

 Also, there's a more fundamental issue with this ticket:

 When a relay that's on 0.3.1 or later activates padding at its end for a
 single onion service or Tor2web client that's on 0.3.0 or earlier, that
 client doesn't know about padding. So it can't turn the padding off when
 this option is set. I known this impacts the largest single onion service,
 which doesn't upgrade versions very often. I also suspect it will impact
 many Tor2web services on old Tor versions.

 What happens if we can't turn off padding on some Tor2web and single onion
 services?
 Do we need an overall padding kill switch for non-padding aware clients?

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