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

Re: [tor-bugs] #24864 [Core Tor/Tor]: directory authorities take a while to update relays' Tor versions



#24864: directory authorities take a while to update  relays' Tor versions
------------------------------------+------------------------------------
 Reporter:  cypherpunks             |          Owner:  (none)
     Type:  defect                  |         Status:  needs_information
 Priority:  Medium                  |      Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor            |        Version:
 Severity:  Normal                  |     Resolution:
 Keywords:  tor-relay, tor-dirauth  |  Actual Points:
Parent ID:                          |         Points:  1
 Reviewer:                          |        Sponsor:
------------------------------------+------------------------------------
Changes (by teor):

 * status:  new => needs_information
 * keywords:   => tor-relay, tor-dirauth
 * points:   => 1
 * milestone:   => Tor: 0.3.3.x-final


Old description:

> copy from
> ​https://lists.torproject.org/pipermail/tor-dev/2018-January/012786.html
>
> Hi,
>
> the goal of this email is to avoid a false positive warning for relay
> operators
> on atlas but the root cause might be in core tor.
>
> background:
> I really liked when irl added the big red warning to atlas when a tor
> relay
> runs an outdated (aka not running a "recommended") tor version
> because it actually triggered operators to upgrade, an important step
> toward a more healthy network.
> The problem is: This big red banner on atlas has false-positives which
> confuses operators [0].
>
> Originally this has been an onionoo bug which
> has been fixed in v1.8.0, but it happens again and Karsten had the
> feeling
> that tor dir auths do not update  the version information of a relay
> after it
> upgraded (and uploaded a new descriptor). I looked into one example and
> can confirm what Karsten suggested [1].
>
> Let me show you that example of FP
> 1283EBDEEC2B9D745F1E7FBE83407655B984FD66.
> Data has been provided by Karsten and is available here: [2].
>
> That relay was running 0.3.0.10 and upgraded to 0.3.0.13 and uploaded his
> first
> descriptor with 0.3.0.13 on:
>
> 2018-01-09 10:14:00,server,,0.3.0.13
>
> except for bastet dir auths did not care and still said this relay runs
> 0.3.0.10:
>
> 2018-01-09 11:00:00,consensus,,0.3.0.10
> 2018-01-09 11:00:00,vote,bastet,0.3.0.13  <<<< note
> 2018-01-09 11:00:00,vote,dannenberg,0.3.0.10
> 2018-01-09 11:00:00,vote,dizum,0.3.0.10
> 2018-01-09 11:00:00,vote,Faravahar,0.3.0.10
> 2018-01-09 11:00:00,vote,gabelmoo,0.3.0.10
> 2018-01-09 11:00:00,vote,longclaw,0.3.0.10
> 2018-01-09 11:00:00,vote,maatuska,0.3.0.10
> 2018-01-09 11:00:00,vote,moria1,0.3.0.10
> 2018-01-09 11:00:00,vote,tor26,0.3.0.10
> 2018-01-09 12:00:00,consensus,,0.3.0.10
> 2018-01-09 12:00:00,vote,bastet,0.3.0.13 <<<<<<
> 2018-01-09 12:00:00,vote,dannenberg,0.3.0.10
> 2018-01-09 12:00:00,vote,dizum,0.3.0.10
> 2018-01-09 12:00:00,vote,Faravahar,0.3.0.10
> 2018-01-09 12:00:00,vote,gabelmoo,0.3.0.10
> 2018-01-09 12:00:00,vote,longclaw,0.3.0.10
> 2018-01-09 12:00:00,vote,maatuska,0.3.0.10
> 2018-01-09 12:00:00,vote,moria1,0.3.0.10
> 2018-01-09 12:00:00,vote,tor26,0.3.0.10
>
> even 6 hours later this is unchanged.
>
> Then the operator upgraded from 0.3.0.13 to 0.3.1.9
> and uploaded his first descriptor:
>
> 2018-01-09 16:39:01,server,,0.3.1.9
>
> this remained "unnoticed" by all dir auths until
> longclaw voted for the new version:
>
> 2018-01-09 23:00:00,consensus,,0.3.0.10
> 2018-01-09 23:00:00,vote,bastet,0.3.0.10
> 2018-01-09 23:00:00,vote,dannenberg,0.3.0.10
> 2018-01-09 23:00:00,vote,dizum,0.3.0.10
> 2018-01-09 23:00:00,vote,Faravahar,0.3.0.10
> 2018-01-09 23:00:00,vote,gabelmoo,0.3.0.10
> 2018-01-09 23:00:00,vote,longclaw,0.3.1.9 <<<<<
> 2018-01-09 23:00:00,vote,maatuska,0.3.0.10
> 2018-01-09 23:00:00,vote,moria1,0.3.0.10
> 2018-01-09 23:00:00,vote,tor26,0.3.0.10
>
> On 2018-01-10 02:38:07 the relay uploaded a second descriptor with
> v0.3.1.9 and almost all dir auths agreed immediately:
>
> 2018-01-10 02:38:07,server,,0.3.1.9
> 2018-01-10 03:00:00,consensus,,0.3.1.9
> 2018-01-10 03:00:00,vote,bastet,0.3.0.10
> 2018-01-10 03:00:00,vote,dannenberg,0.3.1.9
> 2018-01-10 03:00:00,vote,dizum,0.3.1.9
> 2018-01-10 03:00:00,vote,Faravahar,0.3.1.9
> 2018-01-10 03:00:00,vote,gabelmoo,0.3.1.9
> 2018-01-10 03:00:00,vote,longclaw,0.3.1.9
> 2018-01-10 03:00:00,vote,maatuska,0.3.1.9
> 2018-01-10 03:00:00,vote,moria1,0.3.1.9
> 2018-01-10 03:00:00,vote,tor26,0.3.1.9
>

> So it took the operator 17 hours to convince enough
> dir auths that he upgraded.
> I can see multiple reasons why this can make sense (as the tor version
> is actually not that relevant consensus data) but maybe it was
> not clear what the side effects of not updating that field are.
>
> While I believe there is still another onionoo issue,
> this should also be improved.
>
> Thoughts?
>

>
> [0] http://lists.nycbug.org/pipermail/tor-bsd/2018-January/000620.html
> [1] https://trac.torproject.org/projects/tor/ticket/22488#comment:11
> [2]
> https://trac.torproject.org/projects/tor/attachment/ticket/22488/task-22488
> -relay-versions.csv.gz
>

> #24862 aims to help track and debug this.

New description:

 copy from
 ​https://lists.torproject.org/pipermail/tor-dev/2018-January/012786.html

 Hi,

 the goal of this email is to avoid a false positive warning for relay
 operators
 on atlas but the root cause might be in core tor.

 background:
 I really liked when irl added the big red warning to atlas when a tor
 relay
 runs an outdated (aka not running a "recommended") tor version
 because it actually triggered operators to upgrade, an important step
 toward a more healthy network.
 The problem is: This big red banner on atlas has false-positives which
 confuses operators [0].

 Originally this has been an onionoo bug which
 has been fixed in v1.8.0, but it happens again and Karsten had the feeling
 that tor dir auths do not update  the version information of a relay after
 it
 upgraded (and uploaded a new descriptor). I looked into one example and
 can confirm what Karsten suggested [1].

 Let me show you that example of FP
 1283EBDEEC2B9D745F1E7FBE83407655B984FD66.
 Data has been provided by Karsten and is available here: [2].

 That relay was running 0.3.0.10 and upgraded to 0.3.0.13 and uploaded his
 first
 descriptor with 0.3.0.13 on:

 {{{
 2018-01-09 10:14:00,server,,0.3.0.13
 }}}

 except for bastet dir auths did not care and still said this relay runs
 0.3.0.10:

 {{{
 2018-01-09 11:00:00,consensus,,0.3.0.10
 2018-01-09 11:00:00,vote,bastet,0.3.0.13  <<<< note
 2018-01-09 11:00:00,vote,dannenberg,0.3.0.10
 2018-01-09 11:00:00,vote,dizum,0.3.0.10
 2018-01-09 11:00:00,vote,Faravahar,0.3.0.10
 2018-01-09 11:00:00,vote,gabelmoo,0.3.0.10
 2018-01-09 11:00:00,vote,longclaw,0.3.0.10
 2018-01-09 11:00:00,vote,maatuska,0.3.0.10
 2018-01-09 11:00:00,vote,moria1,0.3.0.10
 2018-01-09 11:00:00,vote,tor26,0.3.0.10
 2018-01-09 12:00:00,consensus,,0.3.0.10
 2018-01-09 12:00:00,vote,bastet,0.3.0.13 <<<<<<
 2018-01-09 12:00:00,vote,dannenberg,0.3.0.10
 2018-01-09 12:00:00,vote,dizum,0.3.0.10
 2018-01-09 12:00:00,vote,Faravahar,0.3.0.10
 2018-01-09 12:00:00,vote,gabelmoo,0.3.0.10
 2018-01-09 12:00:00,vote,longclaw,0.3.0.10
 2018-01-09 12:00:00,vote,maatuska,0.3.0.10
 2018-01-09 12:00:00,vote,moria1,0.3.0.10
 2018-01-09 12:00:00,vote,tor26,0.3.0.10
 }}}

 even 6 hours later this is unchanged.

 Then the operator upgraded from 0.3.0.13 to 0.3.1.9
 and uploaded his first descriptor:

 {{{
 2018-01-09 16:39:01,server,,0.3.1.9
 }}}

 this remained "unnoticed" by all dir auths until
 longclaw voted for the new version:

 {{{
 2018-01-09 23:00:00,consensus,,0.3.0.10
 2018-01-09 23:00:00,vote,bastet,0.3.0.10
 2018-01-09 23:00:00,vote,dannenberg,0.3.0.10
 2018-01-09 23:00:00,vote,dizum,0.3.0.10
 2018-01-09 23:00:00,vote,Faravahar,0.3.0.10
 2018-01-09 23:00:00,vote,gabelmoo,0.3.0.10
 2018-01-09 23:00:00,vote,longclaw,0.3.1.9 <<<<<
 2018-01-09 23:00:00,vote,maatuska,0.3.0.10
 2018-01-09 23:00:00,vote,moria1,0.3.0.10
 2018-01-09 23:00:00,vote,tor26,0.3.0.10
 }}}

 On 2018-01-10 02:38:07 the relay uploaded a second descriptor with
 v0.3.1.9 and almost all dir auths agreed immediately:

 {{{
 2018-01-10 02:38:07,server,,0.3.1.9
 2018-01-10 03:00:00,consensus,,0.3.1.9
 2018-01-10 03:00:00,vote,bastet,0.3.0.10
 2018-01-10 03:00:00,vote,dannenberg,0.3.1.9
 2018-01-10 03:00:00,vote,dizum,0.3.1.9
 2018-01-10 03:00:00,vote,Faravahar,0.3.1.9
 2018-01-10 03:00:00,vote,gabelmoo,0.3.1.9
 2018-01-10 03:00:00,vote,longclaw,0.3.1.9
 2018-01-10 03:00:00,vote,maatuska,0.3.1.9
 2018-01-10 03:00:00,vote,moria1,0.3.1.9
 2018-01-10 03:00:00,vote,tor26,0.3.1.9
 }}}

 So it took the operator 17 hours to convince enough
 dir auths that he upgraded.
 I can see multiple reasons why this can make sense (as the tor version
 is actually not that relevant consensus data) but maybe it was
 not clear what the side effects of not updating that field are.

 While I believe there is still another onionoo issue,
 this should also be improved.

 Thoughts?



 [0] http://lists.nycbug.org/pipermail/tor-bsd/2018-January/000620.html
 [1] https://trac.torproject.org/projects/tor/ticket/22488#comment:11
 [2]
 https://trac.torproject.org/projects/tor/attachment/ticket/22488/task-22488
 -relay-versions.csv.gz


 #24862 aims to help track and debug this.

--

Comment:

 Edit description: quote lists to avoid subscript formatting

 CalyxInstitute01 is not affected, its descriptor claims version 0.3.2.8-rc
 See http://162.247.72.7/tor/server/authority

 Same for k21hermes and pix2, the other running relays with DirPorts:
 http://95.183.51.126:9030/tor/server/authority
 http://5.147.112.201:9030/tor/server/authority

 Can you please provide a list of relays that are running, have a DirPort,
 and exhibit a version mismatch between their self-served descriptors, and
 the descriptors or consensus provided by the authorities. It would help to
 know the versions from each.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24864#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs