[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #30196 [Core Tor/sbws]: Add the tor version to the sbws bandwidth file header
#30196: Add the tor version to the sbws bandwidth file header
---------------------------+-----------------------------------
Reporter: teor | Owner: (none)
Type: enhancement | Status: new
Priority: Medium | Milestone: sbws: 1.2.x-final
Component: Core Tor/sbws | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points: 1
Reviewer: | Sponsor:
---------------------------+-----------------------------------
Comment (by teor):
Replying to [comment:1 irl]:
> I can see how in practice this is really useful, but this may not be the
best field to add to the headers. Are we going to add fields for all of
the versions of libraries on the system (e.g. OpenSSL), operating system
kernel, etc. All of these fields could be places with important
information that helps us to interpret the results we see
You're right: we need to define scope.
Here's the scope of the sbws data file:
* questions we have asked bandwidth authority operators (or they have
asked us)
* data we wanted Torflow to provide, but it couldn't (or didn't)
* questions that relay operators ask
* factors that have a large impact on measurements
The scope you're suggesting is much larger, and potentially unlimited.
I suggest that we restrict ourselves to data that we need to know to run
the network.
In this context:
* we wanted to know the tor version to recommend tor upgrades to bandwidth
authority operators (#30184)
* we might be interested in OpenSSL and NSS versions in future, because
they have both had different bugs that stop relays connecting to each
other
* we have asked authority operators about operating systems before
* but I have never wanted to know kernel versions
* I have never even wondered about the versions of any other libraries
Here's another possible rule:
* if it's in Tor relay descriptors, then it's useful for administering
the network
* tor version
* operating system
> but every change to the headers means also a change to parsers.
Parsers which follow the spec MUST allow unknown headers:
https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-
spec.txt#n481
A well-written parser will present unknown headers (or all headers) in a
flexible, dictionary-like structure.
> There is also an implicit assumption here that the bandwidth scanner
uses tor at all. A future bandwidth scanner implementation may use
`stem.client` or an alternative implementation.
Most headers are optional. We can specify that if there's no tor, then the
tor version header SHOULD NOT be present.
> For exit lists we are considering using a free-form text field with some
suggested formats, e.g. something like "ExitScanner 55.5 using Tor 1.0.0
on Windows 10". If there is later something that affects the specific
implementation we can adjust that string without a spec change to report
library details.
Unstructured text is a nightmare to parse. Just look at the browser user-
agent. Or the Tor ContactInfo field.
If we need something, let's specify it as a separate header.
If we're not sure, then let's leave it out.
> For quick diagnosis of problems, it would be great if the bandwidth
scanners added some contact information to the output. We are planning to
add contact strings to exit scanners.
Let's not specify another unstructured contact string, please.
Instead, if we need to email someone, let's specify an operator email
address.
> Whatever we do here, we should come up with good reasons why we are
doing it and then apply the decisions to both exit lists and bandwidth
files if the good reasons are working for both.
I agree.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30196#comment:4>
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