Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
T
Tor
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,065
    • Issues 1,065
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 17
    • Merge Requests 17
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • The Tor Project
  • Core
  • Tor
  • Issues
  • #18346

Closed
Open
Opened Feb 19, 2016 by Nick Mathewson@nickm🐭Owner

Separate the various roles that directory authorities play, from a configuration POV

It would be handy if the following roles were split up:

  1. The list of IP:Orport:Identity to which every relay should upload every descriptor.
  2. The list of IP:Orport:Identity from which caches should expect to find canonical consensuses and descriptors.
  3. The list of IP:Orport:Identity from which non-caches should expect to bootstrap consensuses and descriptors. (See 'fallbackdir')
  4. The list of keys that must sign a vote or a consensus.
  5. The list of IP:Orport:Identity that authorities use when sending and receiving votes.

Splitting roles up in this way would better prepare us for an implementation of prop#257 down the road.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: tpo/core/tor#18346