<html><head></head><body>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<br><br><div class="gmail_quote">On September 19, 2017 2:00:09 PM GMT+02:00, tor-dev-request@lists.torproject.org wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Send tor-dev mailing list submissions to<br /> tor-dev@lists.torproject.org<br /><br />To subscribe or unsubscribe via the World Wide Web, visit<br /> <a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br />or, via email, send a message with subject or body 'help' to<br /> tor-dev-request@lists.torproject.org<br /><br />You can reach the person managing the list at<br /> tor-dev-owner@lists.torproject.org<br /><br />When replying, please edit your Subject line so it is more specific<br />than "Re: Contents of tor-dev digest..."<br /><br /><br />Today's Topics:<br /><br /> 1. Re: Auto-senescence and/or CW penalty for a less outdated tor<br /> network? (nusenu)<br /><br /><br /><hr /><br /><br />Message: 1<br />Date: Mon, 18 Sep 2017 17:30:00 +0000<br />From: nusenu <nusenu-lists@riseup.net><br />To: tor-dev@lists.torproject.org<br />Subject: Re: [tor-dev] Auto-senescence and/or CW penalty for a less<br /> outdated tor network?<br />Message-ID: <6aaa7727-7013-2ff8-3eb1-ac9b752b5981@riseup.net><br />Content-Type: text/plain; charset="windows-1252"<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> 1) Auto-senescence<br /> -------------------<br /></blockquote> <br /> I think automatic timed shutdown can be unhelpful or dangerous:<br /></blockquote><br />Yes it reduces the number of options once such a feature would be<br />implemented and deployed.<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> * what if we need it earlier due to a severe bug or mandatory feature?<br /></blockquote><br />This should not be an issue since that auto-shutdown only mandates an<br />upper limit but does not stop you from removing a relay before that<br />limit has been reached.<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> * what if it isn't needed, and the relay version is fine?<br /></blockquote><br />Yes this can be an issue, but if you say "every relay that runs versions<br />past its eol date" [1] is "not fine" then the auto-shutdown date can be<br />specified with a very high likelihood to a date that is past the eol<br />date because you have an estimate of how long you plan to support it (3y<br />for LTS).<br /><br />I'm less concerned about auto-shutdown for tor clients since most tor<br />users might be using TBB with auto updates and it would help you having<br />to do things like prop266.<br /><br />[1]<br /><a href="https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases">https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases</a><br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> 2) consensus weight penalty for outdated relays<br /><hr /><br /></blockquote> <br /> I can't see much point in this: if the relays are insecure, they<br /> should be eliminated. If not, they should be used.<br /></blockquote><br />I'm happy with "insecure -> should be removed".<br />With "outdated" I meant "not running a recommended version" I'm not sure<br />if that is the same as 'insecure'.<br /><br />A CW penalty would be a strong incentive for relay operators to keep<br />their relays up to date (to a recommended version).<br />This would likely reduce the number of relays running not-recommended<br />versions because currently the incentive is inverted (never<br />restart/update your tor instance - uptime!).<br />..but it would also affect testers running master.<br /><br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> 3) update tor dir auth code to reject old tor releases (not include them<br /> in consensus)<br /><hr /><br /></blockquote></blockquote><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> In the past, we've excluded relay versions when they don't have a<br /> required feature. <br /></blockquote><br />Does this step (excluding specific versions) require a code change or a<br />dir auth configuration change? (like it does for changing recommended<br />versions list)<br />If it does: Maybe it could be turned into a configurable option for dir<br />auths like recommended version.<br /><br />(3) will not stop old relays from contacting dir auths.<br /><br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> We have a ticket to make a plan to kill off old client versions:<br /> <a href="https://trac.torproject.org/projects/tor/ticket/15940">https://trac.torproject.org/projects/tor/ticket/15940</a><br /> But there's no equivalent ticket for relay versions.<br /></blockquote><br /><br /></pre></blockquote></div><br>
-- <br>
Take Care Sincerely flipchan layerprox dev</body></html>