I emailed someone that runned an out of date version of tor yesterday and maybe it's more efficient to have an auto mailer to remind ppl to update
On September 19, 2017 2:00:09 PM GMT+02:00, tor-dev-request@lists.torproject.org wrote:
Send tor-dev mailing list submissions to tor-dev@lists.torproject.org
To subscribe or unsubscribe via the World Wide Web, visit https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev or, via email, send a message with subject or body 'help' to tor-dev-request@lists.torproject.org
You can reach the person managing the list at tor-dev-owner@lists.torproject.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of tor-dev digest..."
Today's Topics:
- Re: Auto-senescence and/or CW penalty for a less outdated tor network? (nusenu)
Message: 1 Date: Mon, 18 Sep 2017 17:30:00 +0000 From: nusenu nusenu-lists@riseup.net To: tor-dev@lists.torproject.org Subject: Re: [tor-dev] Auto-senescence and/or CW penalty for a less outdated tor network? Message-ID: 6aaa7727-7013-2ff8-3eb1-ac9b752b5981@riseup.net Content-Type: text/plain; charset="windows-1252"
- 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/CoreTorR...
- 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.
- 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_
-
flipchan