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

nusenu nusenu-lists at riseup.net
Mon Sep 18 17:30:00 UTC 2017

>> 1) Auto-senescence
>> -------------------
> I think automatic timed shutdown can be unhelpful or dangerous:

Yes it reduces the number of options once such a feature would be
implemented and deployed.

> * what if we need it earlier due to a severe bug or mandatory feature?

This should not be an issue since that auto-shutdown only mandates an
upper limit but does not stop you from removing a relay before that
limit has been reached.

> * what if it isn't needed, and the relay version is fine?

Yes this can be an issue, but if you say "every relay that runs versions
past its eol date" [1] is "not fine" then the auto-shutdown date can be
specified with a very high likelihood to a date that is past the eol
date because you have an estimate of how long you plan to support it (3y
for LTS).

I'm less concerned about auto-shutdown for tor clients since most tor
users might be using TBB with auto updates and it would help you having
to do things like prop266.


>> 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.

I'm happy with "insecure -> should be removed".
With "outdated" I meant "not running a recommended version" I'm not sure
if that is the same as 'insecure'.

A CW penalty would be a strong incentive for relay operators to keep
their relays up to date (to a recommended version).
This would likely reduce the number of relays running not-recommended
versions because currently the incentive is inverted (never
restart/update your tor instance - uptime!).
..but it would also affect testers running master.

>> 3) update tor dir auth code to reject old tor releases (not include them
>> in consensus)
>> -------------------------------------------------------------------------

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

Does this step (excluding specific versions) require a code change or a
dir auth configuration change? (like it does for changing recommended
versions list)
If it does: Maybe it could be turned into a configurable option for dir
auths like recommended version.

(3) will not stop old relays from contacting dir auths.

> 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.


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

More information about the tor-dev mailing list