[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

Send tor-dev mailing list submissions to
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
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of tor-dev digest..."
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
Subject: Re: [tor-dev] Auto-senescence and/or CW penalty for a less
outdated tor network?
Content-Type: text/plain; charset="windows-1252"

1) Auto-senescence
-------------------

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.

https://trac.torproject.org/projects/tor/ticket/15940
But there's no equivalent ticket for relay versions.

--
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
<http://lists.torproject.org/pipermail/tor-dev/attachments/20170918/62770e33/attachment-0001.sig>
------------------------------
Subject: Digest Footer
_______________________________________________
tor-dev mailing list
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
------------------------------
End of tor-dev Digest, Vol 80, Issue 10
***************************************