[tor-dev] Auto-senescence and/or CW penalty for a less outdated tor network?

teor teor2345 at gmail.com
Mon Sep 18 02:25:11 UTC 2017


Hi nusenu,

This looks like it needs a proposal: I think we might have some
similar proposals already.

> On 17 Sep 2017, at 20:48, nusenu <nusenu-lists at riseup.net> wrote:
> 
> 1) Auto-senescence
> -------------------

I think automatic timed shutdown can be unhelpful or dangerous:
* what if we need it earlier due to a severe bug or mandatory feature?
* what if it isn't needed, and the relay version is fine?

> 2) consensus weight penalty for outdated relays
> -----------------------------------------------

I can't see much point in this: if the relays are insecure, they
should be eliminated. If not, they should be used.

> 3) update tor dir auth code to reject old tor releases (not include them
> in consensus)
> -------------------------------------------------------------------------
> 
> As soon as a tor directory operator updates to a new release the dirauth
> would no longer vote for specific tor versions (I guess this is the
> current mostly manual approach).
> 
> Another important aspect is the practical reality in current package
> repositories, but I simply assume they will follow LTS releases and are
> fine with the 4 years (3+grace period) lifespan.

In the past, we've excluded relay versions when they don't have a
required feature. For example:

0.2.4.8-alpha is the first version that supports ntor onion keys, so
earlier versions and relays without ntor onion keys are excluded

0.2.4.18-rc doesn't believe enough current directory authorities, so
it is excluded (we may have to re-do the minimum version when we get a
9th directory authority, or if authorities change)

0.2.9.0-alpha to 0.2.9.5-alpha deliver expired consensuses to clients,
so they are excluded

In the future, when we require network-wide features, we will exclude
versions that don't support this feature. And similarly with a number
of newer protocol features.

I can't think of any other bugs or features that have this significant
an impact. But if they are, we can use this manual process.

We have a ticket to make a plan to kill off old client versions:
https://trac.torproject.org/projects/tor/ticket/15940
But there's no equivalent ticket for relay versions.

T
--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
------------------------------------------------------------------------

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


More information about the tor-dev mailing list