[tor-bugs] #31851 [Core Tor/Tor]: Allow Tor to be compiled without support for relay mode (was: Implement some more optional modules in Tor)

[Tor Bug Tracker & Wiki]

#31851: Allow Tor to be compiled without support for relay mode
--------------------------+------------------------------------
 Reporter:  teor          |          Owner:  teor
     Type:  task          |         Status:  new
 Priority:  Medium        |      Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:  tor-design    |  Actual Points:  0.2
Parent ID:                |         Points:  5
 Reviewer:  nickm         |        Sponsor:  Sponsor31-can
--------------------------+------------------------------------

Comment (by teor):

 Replying to [comment:2 nickm]:
 > I think that this proposal is reasonable.  Let's make a new ticket or
 set of tickets for disabling relay/cache stuff specifically, or change
 this ticket to be about relay/cache stuff specifically.

 I've made this ticket the parent ticket for the work.

 > I think that it is reasonable to have the ability to disable dircache
 and relay code inside the codebase, but I do wonder whether it makes sense
 to expose them separately in the configuration. Right now, there's not
 really any way to be a useful dircache without being a relay, and we
 assume that nearly any relay is potentially a dircache.  Maybe having a
 --disable-relay-mode makes sense here.

 I think it's helpful to expose one new option. Adding only one new option
 also simplifies our CI and our testing matrix. And I'd like to make the
 name consistent with the existing dirauth module.

 Here are the new descriptions:
 * --disable-dirauth-mode
   * hidden alias --disable-module-dirauth
   * Build tor with authority mode disabled: tor can not run as a directory
 authority or bridge authority.
 * --disable-relay-mode
   * Build tor with relay mode disabled: tor can not run as a relay,
 bridge, or authority. Implies --disable-dirauth-mode.

 I'm not sure if it's worth keeping the relay/dircache distinction when we
 name the split modules. In any case, we shouldn't distinguish between them
 when compiling (for example, with separate relay and dircache macros).
 Because we are not going to test that distinction.

 > These modules are intended to be relay-only:
 >   * feature/relay
 >
 > These modules are intended to be dircache-only:
 >   * feature/dircache
 >
 > These modules are _mostly_ relay-only:
 >   * feature/hibernate

 What happens if you try to use AccountingMax on a client or onion service?
 If it works, maybe we should keep it enabled on clients for now.

 >   * feature/stats

 The relay stats can go in stats_relay.
 DirReqStatistics is dircache-only, we could put it in stats_dircache.

 > These modules have significant parts that are relay-only:
 >   * feature/hs
 >   * feature/hs_common
 >   * feature/rend

 I think we'll end up extracting hs_relay and rend_relay. Maybe also
 hs_dircache and rend_dircache.

 >   * lib/compress

 I think we'll end up extracting compress_dircache.

 >   * core/crypto
 >   * core/mainloop
 >   * core/or

 I think we'll end up extracting crypto_relay, mainloop_relay, and
 or_relay. Maybe also the corresponding dircache modules.

 > (In general, if a module is _mostly_ relay only, we should split it into
 two modules, one of which is completely disabled and one of which is not.)
 >
 > I also expect will also find parts of src/core and src/app that are
 relay-specific.

 Yes, we'll need to go through all the code :-)

 > In general, as we are disabling code, we should remember that it is
 better to only stub out code that is called from higher-level modules.
 When code is called from lower-level modules, we should look for a way to
 remove the inverted dependency entirely.

 Is there a quick guide or picture of our higher-level and lower-level
 modules?

 How should we prioritise the modules?
 1. Quick wins
 2. Easy stubs for lower-level modules
 3. Stubs and remove low-high dependencies for higher-level modules

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