Skip to content
GitLab
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
  • #13483
Closed (moved) (moved)
Open
Issue created Oct 20, 2014 by Roger Dingledine@arma

rend_consider_services_upload() sets initial next_upload_time which is clobbered when first intro point established?

In rend_consider_services_upload(), if (!service->next_upload_time), it sets

      /* The fixed lower bound of 30 seconds ensures that the descriptor
       * is stable before being published. See comment below. */
      service->next_upload_time =
        now + 30 + crypto_rand_int(2*rendpostperiod);

which sure seems to a casual reader like Tor initializes its first upload for the hidden service descriptor to be 30 seconds + a random fraction of twice the RendPostPeriod. So, an hour give or take.

But then right below that we check

        (service->desc_is_dirty &&
         service->desc_is_dirty < now-30)) {

and the service gets dirty whenever an intro point is established, which presumably happens soon after you start up your Tor.

We should verify that this behavior is what I think it is, and then we should at the least fix all the comments to be more accurate, and probably we should get rid of the "up to 2 hours" part of the code since it isn't working anyway.

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