Hi, all!
This is a draft for a tor long-term support policy for the program "tor". Please let me know what you think. It's based on earlier work and surveys, but it isn't final till we say it is, and it needs more commentary.
Please keep in mind that dropping support for any old release is an inconvenience to some nice busy people, and that supporting any old release is an inconvenience to other nice busy people. Therefore, "don't inconvenience anybody" is not a viable goal here: instead we are stuck with a balancing act.
Also please remember the bikeshed. ;) http://bikeshed.com/
== Background ==
In the past, Tor has had no actual policy for how long we support older releases of the core "tor" network program. We've aimed for informal rules like "support old releases as long as it isn't too much trouble," or "support old releases as long as a lot of people really need it," but these aren't working so well with our new release schedule.
The good thing about our new release schedule is that we try to put out two stable release series per year, when previously we were finishing release series once every ~18 months. But this means that, to support the last N years of releases, we need to support three times as many older release series as we did before. This won't scale, and probably isn't a good use of our time.
Therefore, we're adopting a practice from several other free software projects with a rapid release schedule: we are going to support some Tor releases for different amounts of time than others.
== Levels of support ==
Here's the plan.
* Every new release series will be supported for at least nine months after it becomes stable, and for at least three months after another release series becomes stable.
Example: * The first 0.2.8.x stable release was released in August 2016. So it will be supported until at least 9 months later, in May 2017. But if the first 0.2.9.x stable release had not been released until April 2017, we'd keep supporting 0.2.8.x for another 3 months past that point, to July 2017.
* Occasionally, we will designate some Tor release series as "long-term support" releases. These will be supported for an amount of time to be announced in advance -- typically, for 3 years.
* For the release series that exist today, we will support them according to the schedule at the end of this document.
== What does support entail? ==
For all supported releases, we intend:
* Information needed to connect to the Tor network (directory authorities, fallback directories, geoip tables) will be kept up-to-date.
* Important security issues will get fixed.
* Major stability issues will get fixed.
* Portability regressions will get fixed.
* Portability bugs to major supported platforms will get fixed.
For the most recent supported stable release only:
* Misleading documentation will get fixed.
* Smaller bugs that significantly impact user experience will get fixed.
We do NOT expect:
* That directory authorities will be able to run any but the two most recent stable releases.
* That unsupported releases will all work on the Tor network.
* That unsupported releases will all fail to work on the Tor network.
* That older supported releases will provide the same privacy as the newer ones.
== The obligatory disclaimer ==
This document is about plans, not promises. We'll try hard to follow through on these plans, but it's always possible that something unexpected will happen and we'll need to choose between following this policy to the letter and maintaining our users' security. If that happens, we'll aim for protecting our users.
== Plan for current releases ==
0.2.4.x, 0.2.6.x, and 0.2.7.x, will all receive at least one more stable release. Support for them will end on 1 August 2017.
0.2.8.x will be supported until 1 January 2018.
0.2.5.x is retroactively declared an LTS release, and will be supported until 1 May 2018.
0.2.9.x is an LTS release, and will be supported until at least 1 January 2020.
On Fri, Jan 13, 2017 at 09:29:25AM -0500, Nick Mathewson wrote:
Hi, all!
This is a draft for a tor long-term support policy for the program "tor". Please let me know what you think. It's based on earlier work and surveys, but it isn't final till we say it is, and it needs more commentary.
Please keep in mind that dropping support for any old release is an inconvenience to some nice busy people, and that supporting any old release is an inconvenience to other nice busy people. Therefore, "don't inconvenience anybody" is not a viable goal here: instead we are stuck with a balancing act.
I like this plan. Is there a reason 0.2.5.x in particular was chosen as the retroactive LTS?
On Fri, Jan 13, 2017 at 1:54 PM, Ian Goldberg iang@cs.uwaterloo.ca wrote:
On Fri, Jan 13, 2017 at 09:29:25AM -0500, Nick Mathewson wrote:
Hi, all!
This is a draft for a tor long-term support policy for the program "tor". Please let me know what you think. It's based on earlier work and surveys, but it isn't final till we say it is, and it needs more commentary.
Please keep in mind that dropping support for any old release is an inconvenience to some nice busy people, and that supporting any old release is an inconvenience to other nice busy people. Therefore, "don't inconvenience anybody" is not a viable goal here: instead we are stuck with a balancing act.
I like this plan. Is there a reason 0.2.5.x in particular was chosen as the retroactive LTS?
I think it's because of the volume of relays running Debian Jessie, and because it's easier to tell really-old-version users to upgrade than to tell them to downgrade.
Our earlier draft stuff is all here: https://pad.riseup.net/p/tor-lts , including an attempt to figure out what versions exist where.
cheers,
You may encounter special justification to extend support for last branch that still supports pre-prop224 onions. There is a *lot* of code / community built on those. Darknet fora have mentioned possible maintenance forks as such if need be.
On Mon, Jan 16, 2017 at 4:12 AM, grarpamp grarpamp@gmail.com wrote:
You may encounter special justification to extend support for last branch that still supports pre-prop224 onions. There is a *lot* of code / community built on those. Darknet fora have mentioned possible maintenance forks as such if need be.
There's no current plan to drop support for the old .onion addresses any time soon, though I sure would hope that people start migrating not too long after the new ones are available.
== Plan for current releases ==
0.2.4.x, 0.2.6.x, and 0.2.7.x, will all receive at least one more stable release. Support for them will end on 1 August 2017.
0.2.8.x will be supported until 1 January 2018.
0.2.5.x is retroactively declared an LTS release, and will be supported until 1 May 2018.
0.2.9.x is an LTS release, and will be supported until at least 1 January 2020.
I'm glad to see such a policy.
Maybe be more verbose on when tor dir auths plan to remove EOL tor relays from consensus?
+---------------------+ | relays_published | +---------------------+ | 2017-01-17 07:00:00 | +---------------------+ +-------------+-------------+-----------+------------+--------+ | tor version | cw-fraction | exit_prob | guard_prob | relays | +-------------+-------------+-----------+------------+--------+ | 0.2.9 | 33.3 | 37.76 | 32.53 | 1917 | | 0.2.8 | 27.6 | 27.87 | 28.05 | 1582 | | 0.2.7 | 10.2 | 10.47 | 9.12 | 1008 | | 0.2.5 | 9.5 | 7.15 | 9.77 | 1219 | | 0.2.6 | 8.6 | 3.02 | 10.91 | 492 | | 0.3.0 | 5.8 | 8.99 | 5.06 | 174 | | 0.2.4 | 4.7 | 4.70 | 4.54 | 787 | +-------------+-------------+-----------+------------+--------+
On 18 Jan 2017, at 09:22, nusenu nusenu@openmailbox.org wrote:
== Plan for current releases ==
0.2.4.x, 0.2.6.x, and 0.2.7.x, will all receive at least one more stable release. Support for them will end on 1 August 2017.
0.2.8.x will be supported until 1 January 2018.
0.2.5.x is retroactively declared an LTS release, and will be supported until 1 May 2018.
0.2.9.x is an LTS release, and will be supported until at least 1 January 2020.
I'm glad to see such a policy.
Maybe be more verbose on when tor dir auths plan to remove EOL tor relays from consensus?
If we do this, we should mention client versions as well.
Typically, this is a decision made by the directory authority operators in consultation with the tor (network daemon) team.
Sometimes, as was the case with early point releases of 0.2.4 and 0.2.5, we stop recommending tor versions because they no longer believe a sufficient number of current directory authority keys.
At other times (as is the case with all but the most recent 0.2.4 to 0.2.9 releases), we stop recommending tor versions because they are not secure - that is, there is a known high-severity issue in those versions. (Or, perhaps, an important security improvement only present in newer versions.)
If neither of these conditions apply, then we have to make a judgement call on when relays or clients are "too old". In practice, we've just tended to keep relays around until they fail one of the above checks.
I suggest that we stop recommending versions after we stop supporting them. I'm not sure if we should delay this a few months after EOL.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------