[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