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
  • #18054
Closed (moved) (moved)
Open
Issue created Jan 13, 2016 by David Goulet@dgoulet🐼

prop224: Decide how to proceed with torrc options

With next-gen HS, we'll have both new and legacy system running in parallel. However, we should encourage as much as possible the adoption of the new system when setting up a new hidden service.

From a torrc perspective, we should probably use the same options as we have now but making tor code a bit more smarter when parsing them. One idea would be to add an option that indicates if the user wants the legacy protocol or not:

Something that could look like:

    HiddenServiceLegacy 1
    HiddenServiceDir <PATH>
    HiddenServicePort ...

And HiddenServiceLegacy by default would be 0. This option should be deprecated over time.

Another possibility is NOT having this config option and only if "private_key" file exists in the HiddenServiceDir and it's RSA1024, we switch to legacy. Without it, we go next-gen. So in other words, we DO NOT let a user setup a legacy HS unless she has a key for it placed in the HS directory. This will allow current HS setup to still work after upgrade and not make operators add an extra option.

Basically, the key type would be our heuristic to switch from legacy to next-gen.

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