[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #31851 [Core Tor/Tor]: Allow Tor to be compiled without support for relay mode (was: Implement some more optional modules in Tor)
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs