[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



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@xxxxxxxxxxxxxxxxxxxx wrote:
Send tor-dev mailing list submissions to
tor-dev@xxxxxxxxxxxxxxxxxxxx

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@xxxxxxxxxxxxxxxxxxxx

You can reach the person managing the list at
tor-dev-owner@xxxxxxxxxxxxxxxxxxxx

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@xxxxxxxxxx>
To: tor-dev@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [tor-dev] Auto-senescence and/or CW penalty for a less
outdated tor network?
Message-ID: <6aaa7727-7013-2ff8-3eb1-ac9b752b5981@xxxxxxxxxx>
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.



--
Take Care Sincerely flipchan layerprox dev
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev