Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Trac Trac
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Legacy
  • TracTrac
  • Issues
  • #21597
Closed (moved) (moved)
Open
Created Mar 02, 2017 by cypherpunks@cypherpunks

ExitRelay configuration option is confusingly named

I imagine this is already well known, and that the option is very unlikely to change names, but I wish to identify the issue regardless. Perhaps the consideration of phasing in a new option with a more descriptive name is valid.

As I understand, the ExitRelay config option applies to non-exit relays in addition to exit relays. It is not considered for bridge relays (which are by definition non-exit and in a separate classification entirely).

This is confusing when configuring a non-exit, non-bridge relay. The confusion can be avoided by renaming the option to e.g. "AllowTraffic" or "AllowExitingTraffic" (or "AllowOutbound"/"Traffic" ... "...Outgoing...").

It seems the ExitRelay option is intended to be more of a safety switch to accommodate a transition in Tor concepts (the addition of bridge relays, I believe) without introducing breaking changes, rather than actually having anything to do with establishing a configured relay as an "exit" relay, as one might easily misunderstand.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking