Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Tor Tor
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 833
    • Issues 833
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 34
    • Merge requests 34
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Core
  • TorTor
  • Issues
  • #9290

Closed
Open
Created Jul 18, 2013 by Nick Mathewson@nickm🏃Owner

Use something other than "known relay" to decide on rate in connection_or_update_token_buckets_helper() on authorities

On #tor-dev , Beeps says:

13:18 < Beeps> connection_or_update_token_buckets_helper() will not limit speed
               if relay knows desc. You can upldoad desc to any auth. Before
               limit speed you need protect all auths or limit speed for them.
               5 of them are victims for cheaters for now.

In other words, anybody can get the higher limit from an authority by uploading a descriptor with their ID, whether they're really a relay or not. That's annoying.

One fix would be to change the behavior of connection_or_digest_is_known_relay to require that the relay be present in the consensus. (Would this hurt bandwidth measurement?)

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