[tor-dev] Deprecating Tor Protocol Versions

teor teor at riseup.net
Fri May 15 03:58:06 UTC 2020


Hi all,

Nick and I were talking about how we remove legacy features in tor,
and their corresponding subprotocol versions.

Here is a list of the current subprotocol versions:
https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n2049

Here's a recent protocol version proposal, which deals with
recommending and requiring new features:
https://gitweb.torproject.org/torspec.git/tree/proposals/303-protover-removal-policy.txt

But we don't have a similar proposal for removing support for older
protocol versions from the tor codebase.

For an example of what that proposal could look like, see our proposal
for deprecating consensus methods:
https://gitweb.torproject.org/torspec.git/tree/proposals/290-deprecate-consensus-methods.txt

Here's the original conversation Nick and I had:
https://github.com/torproject/tor/pull/1874#discussion_r423713579

But after reading our consensus methods deprecation proposal, I've
changed my mind. I think that we should check for "protocol N, and
any later version" by default.

That's what we do for consensus methods, and it seems to work well.
We can drop the earliest consensus methods, and recent tor versions
just keep working.

If we need an incompatible change, we can make it another protocol
version, and recommend then require support for it.

So here's an edited version of my notes on that ticket:

There are a few instances of ">=" and "=" confusion in protocol
versions. We should try to fix them all.

It only matters when we remove protocol versions. We haven't
really specified, tested, or exercised this functionality in
practice. And so our reviewers lack experience. (And when we did
discover a need for it with NSS and LinkAuth, it was more complicated
than we expected.)

I'd like to see a proposal that tells us how to check future protocol
versions as they are added. Along with a migration plan for disabling
protocol versions.

So let's also open a ticket to check for "any future version".
We should replace all "=" checks with ">=". Let's make sure we check
all the places where we use protocol versions, even if they don't
have a summary flag.

Overall, I think it would be helpful if future protocol versions were
orthogonal. Or if they depend on earlier features, that dependency
should be clearly documented. (For example, Relay=3 IPv6 extends
depends on Relay=2 EXTEND2 cells. So if we were checking EXTEND2 cell
support, it would be Relay=2 or Relay=3.)

T

--
teor
----------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20200515/573daf23/attachment-0001.sig>


More information about the tor-dev mailing list