[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #18054 [Tor]: Decide how to proceed with torrc options for proposal 224
#18054: Decide how to proceed with torrc options for proposal 224
-----------------------------+----------------------------
Reporter: dgoulet | Owner:
Type: enhancement | Status: new
Priority: Medium | Milestone: Tor: 0.2.???
Component: Tor | Version:
Severity: Normal | Keywords: tor-hs prop224
Actual Points: | Parent ID: #12424
Points: | Sponsor: SponsorR
-----------------------------+----------------------------
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.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18054>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs