>> 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. [1] https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases >> 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. -- https://mastodon.social/@nusenu https://twitter.com/nusenu_
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev