Include relay version listed in consensus in addition to platform line from server descriptor

changed milestone to %Onionoo 2.0.0

added component::metrics/onionoo metrics-2018 milestone::Onionoo 2.0.0 owner::metrics-team priority::high resolution::fixed severity::normal status::closed type::enhancement labels

This relay was last included in a consensus on 2017-05-31 at 22:00:00 UTC. It was listed there with version 0.3.0.6 which was not a recommended server version at the time. That's why recommended_version is false.

The relay may have uploaded a server descriptor with "Tor 0.3.0.7 on FreeBSD" as platform string after that (I haven't checked when that was), but that descriptor never made it into a consensus.

We only look at the consensus for determining recommended versions, which is also what Tor clients do.

This is not a bug in Onionoo, just a rare edge case of which there are probably a dozen more. Closing as not-a-bug. Thanks for the report anyway!

Trac:
Status: new to closed
Resolution: N/A to not a bug

From the metrics-team@ mailing list:

thanks for your prompt reply, since the ticket has been closed I'm answering here.

We display whatever version was last uploaded by the relay but we only care about what made it into the consensus.

What do you think about also just displaying whatever made it into the consensus so there is no mismatch between what atlas displays and what is actually in the consensus?

Sounds plausible to me. I'm currently focusing on metrics-lib, so I'm reopening this ticket for now.

Trac:
Resolution: not a bug to N/A
Summary: recommended_version is false but it should be true to Include relay version listed in consensus in addition to platform line from server descriptor
Type: defect to enhancement
Status: closed to reopened

Trac:
Keywords: N/A deleted, metrics-2018 added

Trac:
Keywords: metrics-2018 deleted, metrics-2017 added

(I worked on all currently open (recommended) version related Onionoo tickets including this one: #22488 (moved), #23962 (moved), #21827 (moved), and #23544 (moved).)

I suggest we add a new "version" field in addition to the existing "platform" field. For relays we include the version listed in the consensus in that field. Then we have both versions: "platform" with the version from the server descriptor and "version" with the version from the consensus.

And for bridges we include the version substring from the "platform" line. That's somewhat redundant. But in some cases it might be easier for clients to process that version string without the rest of the rest of the "platform" line around it. No harm in adding that new field to both relay and bridge details documents.

Please review the first commit bd5b45a in my tasks-22488-23962-21827-23544 branch together with specification changes in commit 75c7626 in my corresponding metrics-web branch.

Trac:
Status: reopened to needs_review

Patch looks fine and it is a good idea to provide the 'version' field. Tests and checks pass, spec changes describe the changes. => ready for merge.

Trac:
Status: needs_review to merge_ready

Great, thanks for checking! Merged. Closing.

Trac:
Status: merge_ready to closed
Resolution: N/A to fixed

This will be part of the next release.

Trac:
Milestone: N/A to Onionoo-1.8.0

Is this fix already deployed? A few relays that have recommended_version set to False even though they are running a recommended version:

+----------------+-------------+------------------------------------------+---------------------+---------+
| nickname       | tor_version | fingerprint                              | last_restarted      | running |
+----------------+-------------+------------------------------------------+---------------------+---------+
| TOris          | 0.3.1.9     | A2888CB01CEAD3BBD84F63707F45318A7A71D141 | 2018-01-08 07:39:07 |       0 |
| NoSpyOrg       | 0.2.9.14    | 1AFD68DF6403140E32E73F1DB72415CE4229832F | 2018-01-09 10:17:15 |       0 |
| DeltaIV        | 0.3.1.9     | 75CCC14FB38F2E473AC2C31F255355110FCE8D38 | 2018-01-06 21:01:47 |       0 |
| cosmicsurfin   | 0.3.1.9     | 4A0242BED06138AD6BB1FE103A1D5D3AA9E97C05 | 2018-01-08 21:32:15 |       0 |
| wintermute     | 0.3.1.9     | 276EAD6119C327930C0B8D3E370BF163EFB0244B | 2018-01-09 15:40:38 |       1 |
| heteigenwijsje | 0.3.1.9     | 1283EBDEEC2B9D745F1E7FBE83407655B984FD66 | 2018-01-09 16:38:02 |       1 |
| monoculus      | 0.3.1.9     | A1A01D1B3353F3CFB065E9CBA113AEEB948DF8E1 | 2018-01-09 20:47:16 |       1 |
| Unnamed        | 0.2.9.14    | 7C8F045FC6710FBA57B2C84D008F91BCEABD6A36 | 2018-01-03 15:32:15 |       0 |
| propub01       | 0.3.2.8-rc  | 4290EEF4276FEACAD3A4694770B3B905FED51302 | 2018-01-03 22:27:11 |       0 |
+----------------+-------------+------------------------------------------+---------------------+---------+

Trac:
Resolution: fixed to N/A
Status: closed to reopened

This causing confusion for tor relay operators example: http://lists.nycbug.org/pipermail/tor-bsd/2018-January/000620.html

Trac:
task-22488-relay-versions.csv.gz

Hmm, you might have found something here, but I'm not certain yet. (And I have too many other things going on to take a closer look.)

For the record, recommended server versions as of your comment were: 0.2.5.16, 0.2.5.17, 0.2.9.14, 0.2.9.15, 0.3.0.13, 0.3.0.14, 0.3.1.9, 0.3.1.10, 0.3.2.8-rc, 0.3.2.9.

Please find the attached compressed CSV file which contains:

fingerprint: the relay fingerprint, limited to the relays you listed
timestamp: the timestamp when a descriptor was published or after which a status was declared valid
descriptor: "server" for server descriptors published by the relay, "vote" for network status votes, "consensus" for network status consensuses
authority: authority nickname in case of a vote and blank otherwise
version: tor software version

Again, I'm not certain yet, but it looks like there's a delay of a few hours between relays publishing a server descriptor with a new tor software version number and authorities including that version in their votes. This delay is different between authorities, with some authorities picking up the change earlier than others.

If this is true, and somebody would have to look through the attached file in detail, that's a bug in the authorities. Totally wild guess: authorities might consider platform changes "cosmetic" and continue using an older descriptor of the relay until that gets too old.

However, from Onionoo's perspective I think we don't have a bug here. Onionoo uses whatever version it sees in the consensus to say whether a relay runs a recommended version or not. If the authorities don't update that version number properly, that's not something that Onionoo can fix.

Want to analyze this more and possibly open a ticket in Core Tor/Tor if you can confirm that this is a bug in tor? (But please don't move this ticket to that component, because 90% of what's discussed above is irrelevant for the issue you may have found.)

Trac:
Status: reopened to needs_information

Hi Karsten, thanks for that CSV file. I can confirm what you suggested: https://lists.torproject.org/pipermail/tor-dev/2018-January/012786.html

I did some analysis of the examples in the Core Tor ticket, Tor appears to be working fine: https://trac.torproject.org/projects/tor/ticket/24864#comment:6

Perhaps this is just a bug in Onionoo?

I am waiting for some more examples in the Core Tor ticket.

Replying to teor:

I did some analysis of the examples in the Core Tor ticket, Tor appears to be working fine: https://trac.torproject.org/projects/tor/ticket/24864#comment:6

Perhaps this is just a bug in Onionoo?

Hmm, I don't see how Onionoo would be the issue here. The preliminary analysis that I did in comment 11 above is not based on Onionoo, but on a new analysis made using metrics-lib.

I am waiting for some more examples in the Core Tor ticket.

Did you check the CSV file that is attached to this ticket? That just contains the relays above. I'm going to upload the full file with all relay fingerprints now and will post the link here in 10-20 minutes.

Replying to karsten:

[...] I'm going to upload the full file with all relay fingerprints now and will post the link here in 10-20 minutes.

https://people.torproject.org/~karsten/volatile/task-22488-relay-versions-full.csv.xz

Adapting to new year and next version.

Trac:
Keywords: metrics-2017 deleted, metrics-2018 added
Milestone: Onionoo-1.8.0 to Onionoo-2.0.0

So, from the discussion in #24864 (moved) it sounds like this is either a bug in the tor daemon or somewhat non-intuitive behavior of the tor daemon. But I don't see where Onionoo would be doing something wrong here. If there's no bug, we should close this ticket again.

Not a bug in Onionoo

Trac:
Resolution: N/A to not a bug
Status: needs_information to closed

I believe there is still something that is related to onionoo regardless of the other related tickets.

If onionoo says tor_version:some good tor version and it displays recommended_version:false than there seems to be a mismatch.

Onionoo should display the tor version it uses to compare against the list of recommended_versions and not any other version. If it does, this mismatch will disappear, right?

Trac:
Resolution: not a bug to N/A
Status: closed to reopened

Onionoo displays the platform from the descriptor. But it uses the relay version and recommended versions list from the consensus to calculate the relay recommended version field. This is a correct behaviour.

There are three ways to resolve this issue:

clarify that the recommended version uses the consensus version at https://metrics.torproject.org/onionoo.html#details_relay_recommended_version
make Onionoo parse the platform field in the descriptor and compare it to the consensus version
fix the underlying bug in Tor and wait 6 months for the directory authorities to deploy the fix (see #24864 (moved))
- since this isn't causing any network issues, it's low priority right now. I'm not sure when we will get time to fix it.

Replying to teor:

clarify that the recommended version uses the consensus version at https://metrics.torproject.org/onionoo.html#details_relay_recommended_version

make Onionoo parse the platform field in the descriptor and compare it to the consensus version Yes, it would be great if onionoo includes both and atlas could then display a clear info when they are not the same (and display only one if they are the same, so to not confuse operators).

Replying to cypherpunks:

Replying to teor:

clarify that the recommended version uses the consensus version at https://metrics.torproject.org/onionoo.html#details_relay_recommended_version

Please see my branch bug22488 at https://github.com/teor2345/metrics-web.git

It updates the Onionoo documentation for recommended_version. The versions used in recommended_version come from the consensus or bridge networkstatus. I checked the code for relays and bridges.

make Onionoo parse the platform field in the descriptor and compare it to the consensus version Yes, it would be great if onionoo includes both and atlas could then display a clear info when they are not the same (and display only one if they are the same, so to not confuse operators).

I am not sure if this fix is a good idea. We don't trust descriptors when they are not in a consensus. (Their details can be wrong.) So why are any of our tools using them? And what should Onionoo do if a relay has multiple descriptors?

And I don't have time to write this fix. It looks like new feature that involves at least one new field. Or a rethink of how we parse descriptors and which ones we should parse.

For an alternative fix where Onionoo stops parsing untrusted descriptors, see #24932 (moved).

Edit: remove duplicate quotes

Trac:
Status: reopened to needs_review

Replying to teor:

Replying to cypherpunks:

Replying to teor:

clarify that the recommended version uses the consensus version at https://metrics.torproject.org/onionoo.html#details_relay_recommended_version

Please see my branch bug22488 at https://github.com/teor2345/metrics-web.git

It updates the Onionoo documentation for recommended_version. The versions used in recommended_version come from the consensus or bridge networkstatus. I checked the code for relays and bridges.

Thanks for providing that patch! Merged with trivial tweaks, and deployed.

make Onionoo parse the platform field in the descriptor and compare it to the consensus version Yes, it would be great if onionoo includes both and atlas could then display a clear info when they are not the same (and display only one if they are the same, so to not confuse operators).

I am not sure if this fix is a good idea. We don't trust descriptors when they are not in a consensus. (Their details can be wrong.) So why are any of our tools using them? And what should Onionoo do if a relay has multiple descriptors?

And I don't have time to write this fix. It looks like new feature that involves at least one new field. Or a rethink of how we parse descriptors and which ones we should parse.

In theory, this should be as simple as checking whether the "platform" string starts with "Tor " + version_field_content + " ". This could already be done in Relay Search and doesn't require a new Onionoo field. At least it could be a start, if we really care.

For an alternative fix where Onionoo stops parsing untrusted descriptors, see #24932 (moved).

Indeed, this is worth thinking about. I'll comment on the ticket why this might be tricky to implement, though. But it seems like something we should do.

Okay, I think with the documentation patch merged and #24864 (moved) and #24932 (moved) still open, it's safe to close this ticket now. Doing so. Thanks, everyone!

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

I just realized that onionoo provides already both data points (platform and version as seen in consensus):

https://onionoo.torproject.org/details?fields=version,platform,recommended_version,fingerprint&search=fastor&type=relay

{"version":"5.0",
"build_revision":"0bce98a",
"relays_published":"2018-01-23 08:00:00",
"relays":[
{"fingerprint":"0EE3D3F6988B868F9018FFEC7567289E791D4785","platform":"Tor 0.3.2.9 on Linux","version":"0.2.9.11","recommended_version":false}
],
"bridges_published":"2018-01-23 08:04:05",
"bridges":[
]}

Filed a low prio ticket: https://trac.torproject.org/projects/tor/ticket/24974

Milestone renamed

Trac:
Milestone: Onionoo-2.0.0 to Onionoo 2.0.0

closed

mentioned in issue #23544 (moved)

mentioned in issue #23962 (moved)

mentioned in issue #24864 (moved)

mentioned in issue #24932 (moved)

Include relay version listed in consensus in addition to platform line from server descriptor

Child items 0

Activity