[prev in list] [next in list] [prev in thread] [next in thread]
List: tor-dev
Subject: Re: [tor-dev] tor-dev Digest, Vol 80, Issue 10
From: flipchan <flipchan () riseup ! net>
Date: 2017-09-19 19:51:09
Message-ID: 98E89D6D-B902-4638-B76B-027FEB9B0551 () riseup ! net
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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:
>
> 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@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"
>
> > > 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@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
[Attachment #5 (text/html)]
<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/CoreTorRelea \
ses">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>
[Attachment #6 (text/plain)]
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic