[tor-dev] tor-dev Digest, Vol 80, Issue 10

[flipchan]

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 at lists.torproject.org wrote:
>Send tor-dev mailing list submissions to
>	tor-dev at 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 at lists.torproject.org
>
>You can reach the person managing the list at
>	tor-dev-owner at 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:
>
>   1. 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 at riseup.net>
>To: tor-dev at 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 at riseup.net>
>Content-Type: text/plain; charset="windows-1252"
>
>>> 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_
>
>-------------- 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-0001.sig>
>
>------------------------------
>
>Subject: Digest Footer
>
>_______________________________________________
>tor-dev mailing list
>tor-dev at lists.torproject.org
>https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
>------------------------------
>
>End of tor-dev Digest, Vol 80, Issue 10
>***************************************

-- 
Take Care Sincerely flipchan layerprox dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170919/0bdbea26/attachment.html>