[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