[tor-dev] Tor Bandwidth List Format specification
Hi, after nick, irl and teor reviewed the last version i sent [1], i paste below a new version of the specification versions 1.1.0 and 1.0.0. It's the same version as commit https://github.com/juga0/torspec/commit/c7cdfd4fcb4b5623e1407e2bec38e9fdf7b70e6b. The main question that came up was whether we should create a backwards incompatible specification version 2.0.0. Since right now it's faster to implement the version 1.1.0 of this specification, and assuming that we can add the specification and the code later, i'd propose to continue with 1.1.0. I've asked dirauths about their opinion about this. Thanks, juga [1] https://lists.torproject.org/pipermail/tor-dev/2018-May/013141.html [2] https://lists.torproject.org/pipermail/tor-dev/2018-May/013154.html --- Tor Bandwidth List Format juga teor 1. Scope and preliminaries This document describes the format of Tor's Bandwidth List, version 1.0.0, 1.1.0 and later. It is new specification for the existing format 1.0.0. Describes a new format 1.1.0, which is backwards compatible with 1.0.0 parsers. Since Tor version 0.2.4.12-alpha the directory authorities use the Bandwidth List file called "V3BandwidthsFile" generated by Torflow [1]. The format is described in Torflow's README.spec.txt and is considered to be version 1.0.0. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 1.2. Acknowledgements The original bandwidth generator (Torflow) and format was created by mike. Teor suggested to write this specification while contributing on pastly's new bandwidth generator implementation. This specification was revised after feedback from: Nick Mathewson (nickm) Iain Learmonth (irl) 1.3 Outline The Tor directory protocol (dir-spec.txt [3]) sections 3.4.1 and 3.4.2, use the term bandwidth measurements, to refer to what here is called Bandwidth List. A Bandwidth List file contains information on relays' bandwidth capacities and is produced by bandwidth generators, previously known as bandwidth scanners. 1.4. Format Versions 1.0.0 - The legacy fallback Bandwidth List format 1.1.0 - Adds KeyValue Lines to the Header List section, add KeyValues to RelayLines and format versions. All Tor versions can consume format version 1.0.0. All Tor versions can consume format version 1.1.0, but they warn on additional header Lines. [TODO: this might be fixed, and if it is fixed should be said which version of Tor] 2. Format details The Bandwidth List MUST contain the following sections: - Header List (exactly once) - Relays' Bandwidth List (zero or more times) If it does not contain these sections, parsers SHOULD ignore the file. 2.1. Definitions The following nonterminals are defined in Tor directory protocol sections 1.2., 2.1.1., 2.1.3.: Int SP (space) NL (newline) Keyword ArgumentChar nickname hexdigest (a '$', followed by 40 hexadecimal characters ([A-Fa-f0-9])) Nonterminal defined section 2 of version-spec.txt [4]: version_number We define the following nonterminals: Line ::= ArgumentChar* NL RelayLine ::= KeyValue (SP KeyValue)* NL KeyValue ::= Keyword "=" Value Value ::= ArgumentCharValue+ ArgumentCharValue ::= any printing ASCII character except NL and SP. Terminator ::= "=" Timestamp ::= Int Bandwidth ::= Int MasterKey ::= a base64-encoded Ed25519 public key, with padding characters omitted. DateTime ::= "-MM-DDTHH:MM:SS", as in ISO 8601 Note that key_value and value are defined in Tor directory protocol with different formats to KeyValue and Value here. All Lines in the file MUST be 510 characters or less, to allow for the trailing newline and NULL characters. The previous limit was 254 characters in Tor 0.2.6.2-alpha and earlier. The parser MAY ignore longer Lines. [TODO: Change this restriction in 1.1.0 or later] 2.2. Header List format Some header Lines MUST appear in specific positions, as documented below. All other Lines can appear in any order. If a parser does not recognize any extra material in a header Line, the Line MUST be ignored. If a header Line does not conform to this format, the Line SHOULD be ignored by parsers. It consists of: Timestamp NL [At start, exactly once.] The Unix Epoch time in seconds when the file was created. It does not follow the KeyValue format for backwards compatibility with version 1.0.0. "version=" version_number NL [In second position,
Re: [tor-dev] Tor Bandwidth List Format specification
Iain Learmonth: > >> The main question that came up was whether we should create a backwards >> incompatible specification version 2.0.0. > > I do think it may be easier to finish this specification first before > moving on to a 2.0.0 version. We discussed this specification at the > last Tor Metrics meeting: Currently Tor Metrics' descriptor parsing > library (metrics-lib) does not have a parser for the current (1.0.0) > bandwidth lists. We should implement this, and hopefully it would not be > too much extra work to make this also work for 1.1.0 lists. It shouldn't be much extra work, if metrics-lib ignore the extra header lines and extra bandwidth KeyValue (as Tor currently does). > > If there were to be a 2.0.0 version, I would hope this brings the syntax > closer to other Tor descriptors to enable us to reuse existing code in > our parser (and also for tor to reuse existing code too) rather than > being something entirely new. That was the idea :) Thanks! juga. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor Bandwidth List Format specification
Hi, as commented by nickm [0], the specification has been merged into torspec git repository. If you find any issues with it, as usual, we can open a ticket and patch the specification. Thanks, juga. [0] https://trac.torproject.org/projects/tor/ticket/25869#comment:10 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal: Tor bandwidth measurements document format
Hi Iain, Iain Learmonth: > Hi, > >> Tor Bandwidth Measurements Document Format > > "Measurement" could mean a method for performing a measurement, a single > measurement task, a schedule for a repeating measurement task, a > measurement result or a few other things. I also wondered whether that was the correct word and considered "capacity", but didn't convince me. Teor also suggested me to remove "Document", but i thought i'd keep it, trying to mean that the spec is only about the "file" and not the process or how they are formatted somewhere else. Do you have a suggestion on what other word to use instead of measurements?. > When Large MeAsurement Platforms (LMAP) wrote documents in the IETF, > they only ever used measurement as an adjective to avoid any ambiguity. > > https://www.ietf.org/archive/id/draft-eardley-lmap-terminology-02.txt > > The architecture for LMAP may not fit well with the bandwidth scanner > architecture, and so I'm not suggesting we adopt the terminology in that > document throughout. > >>> 2. Format details >>> >>> Bandwidth measurements MUST contain the following > sections: >>> - Header (exactly once) >>> - Relays measurements (zero or more times) >> >> Grammar suggestion: "Relay measurements". > > In this case, this would become "Relay measurement result". More accurate, though starts becoming a bit too long. The title should probably become then: "Tor Bandwidth Measurements Results Document Format" Any shorter suggestion?. > If desirable, I'd be happy to check through the document for any other > places ambiguities pop up, but I'll let others finish having their > comments integrated first. It's fine to continue to make comments on the thread where others commented, no need to wait until those comments are integrated. But either way works. Thanks for your comments!, juga. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal: Tor bandwidth measurements document format
juga: >>> Each relay_line MUST include the following key_value in arbitrary order: >> >> Do existing implementations accept arbitrary order here? > > Good question, it seems like bw must be behind node_id, but they can > have things in front and behind. I probably should create a ticket to > add more test lines in [1] or include them in #25960. Checked: in the current implementation, the only order required is that bw must appear before node_id. It probably does not make sense, but to be compatible with it, it is what this spec should say. [1] https://gitweb.torproject.org/torspec.git/tree/dir-list-spec.txt#n131 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal: Tor bandwidth measurements document format
Karsten Loesing: > Hi Juga, > > On 2018-05-01 14:36, Nick Mathewson wrote: >> This is a review of the document from >> https://raw.githubusercontent.com/juga0/torspec/c7f06023dd1d5d47adad128de541f8eba2a13bfb/bandwidth-file-spec.txt >> , which I *think* is the same as the document you have below. > > I'd like to review this document format, too, in particular with regard > to archiving these documents with CollecTor in the future. (Unless there > are no plans to archive them, ever.) > > Should I wait for you to revise the document and join in the next review > round, or should I review the document now? From my side, you can review this now. In the latter case, where > would I find the most recent version? I don't if i interpret you correctly, but while working on it and not in the torspec canonical repo, last version should be in https://github.com/juga0/torspec/tree/bandwidth-file-spec. Thanks!, juga. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal: Tor bandwidth measurements document format
Hi, Thanks Nick for the comments, i'm replaying only to the parts where i give an answer or i've more questions. I'd accept the rest of your suggestions unless there will be further comments. Nick Mathewson: > Hi, Juga! > > This is a review of the document from > https://raw.githubusercontent.com/juga0/torspec/c7f06023dd1d5d47adad128de541f8eba2a13bfb/bandwidth-file-spec.txt > , which I *think* is the same as the document you have below. Yes, it is. > > I'm reviewing this as though it were a fully new format, since I'm not sure > how much we already have locked-in based on existing code, and how much is > new. We might decide that backward compatibility is more important than > consistency, and if so, we won't want to take all of my recommendations > here. > > >> Tor Bandwidth Measurements Document Format >> juga >> teor >> >> 1. Scope and preliminaries >> >> This document describes the format of Tor's bandwidth measurements >> document, version 1.0.0 and later. > > Suggestion: Maybe explicitly say "1.0.0, 1.1.0, and later"? > >> Since Tor version 0.2.4.12-alpha the directory >> authorities use the bandwidth measurements document called >> "V3BandwidthsFile" and produced by Torflow [1] >> (format described in README.spec.txt [2]). > > Recommendation: "Format described in Torflow's README.spec.txt". > > Explanation needed: Is this a new format, or a new specification of the > existing format? Let's say so here. New version of existing format. Though old version (Torflow's), didn't have an specification in the sense this specification is being made). > Question: If this is a different format, and we're calling it version > 1.0.0, what should we call the old one? But later it seems that we're > introducing 1.1.0, and we're calling the old one 1.0.0. yeah, this would be 1.1.0, the old one (Torflow's) would be 1.0.0 > Suggestion: let's be explicit that we're only describing the format > here, and *not* describing how bwauths generate their data. > > >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >> NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and >> "OPTIONAL" in this document are to be interpreted as described in >> RFC 2119. >> >> 1.2. Acknowledgements >> >> The original bandwidth measurement scanner (Torflow) and format was >> created by mike. Teor suggested to write this specification while >> contributing on pastly's new bandwidth scanner implementation. >> >> This specification was revised after feedback from: >> >> XXX >> >> 1.3 Outline >> >> The bandwidth measurements mentioned in sections 3.4.1 and 3.4.2 >> of "Tor directory protocol" (dir-spec.txt) [3] are obtained >> by bandwidth authorities, which generate a file storing information >> on relays' measured bandwidth capacities. >> >> 1.4. Format Versions >> >>1.0.0 - The legacy fallback bandwidth measurements document format >> >>1.1.0 - Adds key_value lines to the header, format version, >>optional ones and section separator. > > Information: Let's repeat in this section which versions of Tor can > consume these versions. > >> 2. Format details >> >> Bandwidth measurements MUST contain the following sections: >> - Header (exactly once) >> - Relays measurements (zero or more times) > > Grammar suggestion: "Relay measurements". > > > >> 2.1. Definitions >> >> The following nonterminals are defined in dir-spec.txt, sections >> 1.2., 2.1.1., 2.1.3.: >> >> Int >> SP (space) >> NL (newline) >> Keyword >> ArgumentChar >> fingerprint (hexdigest) > > Does this have to start with a "$" ? I think it does. Maybe we should be > explicit about that. Yes >> nickname >> >> Nonterminals defined in "Tor Directory List Format" (dir-list-spec.txt), >> section 2.2.1.: >> >> version_number >> >> We define the following nonterminals: >> >> value ::= ArgumentChar+ >> key_value ::= Keyword "=" value >> line ::= ArgumentChar* NL >> timestamp ::= Int >> bandwidth ::= Int >> relay_line ::= key_value (SP key_value)* NL >> >> 2.2. Header format One more thing that teor pointed at me: any
Re: [tor-dev] Proposal: Tor bandwidth measurements document format
Hi, after teor's revision, second version pasted below. Changes can be seen: in https://github.com/juga0/torspec/commits/bandwidth-file-spec Best, juga = Tor Bandwidth Measurements Document Format juga teor 1. Scope and preliminaries This document describes the format of Tor's bandwidth measurements document, version 1.0.0 and later. Since Tor version 0.2.4.12-alpha the directory authorities use the bandwidth measurements document called "V3BandwidthsFile" and produced by Torflow [1] (format described in README.spec.txt [2]). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 1.2. Acknowledgements The original bandwidth measurement scanner (Torflow) and format was created by mike. Teor suggested to write this specification while contributing on pastly's new bandwidth scanner implementation. This specification was revised after feedback from: XXX 1.3 Outline The bandwidth measurements mentioned in sections 3.4.1 and 3.4.2 of "Tor directory protocol" (dir-spec.txt) [3] are obtained by bandwidth authorities, which generate a file storing information on relays' measured bandwidth capacities. 1.4. Format Versions 1.0.0 - The legacy fallback bandwidth measurements document format 1.1.0 - Adds key_value lines to the header, format version, optional ones and section separator. 2. Format details Bandwidth measurements MUST contain the following sections: - Header (exactly once) - Relays measurements (zero or more times) 2.1. Definitions The following nonterminals are defined in dir-spec.txt, sections 1.2., 2.1.1., 2.1.3.: Int SP (space) NL (newline) Keyword ArgumentChar fingerprint (hexdigest) nickname Nonterminals defined in "Tor Directory List Format" (dir-list-spec.txt), section 2.2.1.: version_number We define the following nonterminals: value ::= ArgumentChar+ key_value ::= Keyword "=" value line ::= ArgumentChar* NL timestamp ::= Int bandwidth ::= Int relay_line ::= key_value (SP key_value)* NL 2.2. Header format Some header lines MUST appear in specific positions, as documented below. All other lines can appear in any order. There MUST NOT be multiple key_value header lines with the same key. It consists of: timestamp NL [At start, exactly once.] The Unix Epoch time in seconds when the file was created. "version=" version_number NL [In second position, zero or one time.] The specification document format version. It uses semantic versioning [5]. This line has been added in version 1.1.0 of this specification. Version 1.0.0 documents do not contain this line, and the version_number is considered to be "1.0.0". "software=" value NL [Zero or one time.] The name of the software that created the document. This line has been added in version 1.1.0 of this specification. Version 1.0.0 documents do not contain this line, and the software is considered to be "torflow". "software_version=" value NL [Zero or one time.] The version of the software that created the document. The version may be a version_number, a git commit, or some other version scheme. This line has been added in version 1.1.0 of this specification. "scanner_started=" timestamp NL [Zero or one time.] The Unix Epoch time in seconds when the scanner that generates the measurements document started. This line has been added in version 1.1.0 of this specification. "earliest_measurement=" timestamp NL [Zero or one time.] The Unix Epoch time in seconds when the first relay measurement was obtained. This line has been added in version 1.1.0 of this specification. key_value NL [Zero or more times.] Future format versions may include additional key_value header lines. Additional header lines will be accompanied by a minor version increment. Implementations MAY add additional header lines as needed. This specification SHOULD be updated to avoid conflicting meanings for the same header keys. Parsers MUST NOT rely on the order of these additional lines. Additional header lines MUST NOT use any keywords specified in the relay measurements format. If a header line does not conform to this format, the line SHOULD be ignored by parsers. NL [Zero or one time.] The header ends. This line has been added in version 1.1.
[tor-dev] Tor Bandwidth Measurements Document Format
Hi,
as commented with teor and pastly, i send in-line a draft specification
for the document format that the bandwidth scanner implementations
should produce.
I've left my own questions/notes in square brackets.
Thanks,
juga.
===
Tor Bandwidth Measurements Document Format
[juga: which name should we give to this document?]
1. Scope and preliminaries
This document describes the format of Tor's bandwidth measurements
document, version X.X.X [juga: which version should be this?]
and later.
Since Tor version X.X.X [juga: which tor version?] the directory
authorities use the bandwidth measurements document called
"V3BandwidthsFile" and produced by Torflow [1]
(format described in README.spec.txt [2]).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
1.2. Acknowledgements
The original bandwidth measurement scanner (Torflow) and format was
created by mike. Teor suggested to write this specification while
contributing on pastly's new bandwidth scanner implementation.
This specification was revised after feedback from:
XXX
1.3 Outline
The bandwidth measurements mentioned in sections 3.4.1 and 3.4.2
of dir-spec.txt [3] are obtained by bandwidth authorities, which are
either directory authorities or other servers running bandwidth
measurement scanners and sending the results to the former.
[juga: it seems that bandwidth authorities have not been formally
before]
2. Format details
Bandwidth measurements MUST contain the following sections:
- Header (exactly once)
- Relays measurements (zero or more times)
Each section (or entry) ends with a separator.
2.1. Nonterminals
The following nonterminals are defined in the Onionoo details
document specification [4]:
fingerprint
nickname
In the bandwidth measurement documents nickname is optional.
The following nonterminals are defined in the in dir-spec.txt:
NL (newline)
SP (space)
"bw" = INT, the aggregated measured bandwidth of this relay, in
kilobytes per second.
We introduce the following nonterminals:
[juga: this should probably be defined more formally and should
probably link to other documents, which ones?]
"version" = The name and the version of the bandwidth scannner
software, such as "sbws 0.1.0".
The name of the software, if absent, is assumed to be "torflow".
[juga: which should be the version if absent?]
"timestamp" = INT, the Unix Epoch time when the file was created.
2.2. Header format
It MUST consists of:
"timestamp" timestamp NL
"version" version NL
2.3. Relay measurements format
Relays measurements MUST consist of the following items.
"node_id" fingerprint SP
"bw" bandwidth SP
When there are no more items, the "bw" item ends with NL instead of
SP.
2.4. Optional extra items
Different implementations of the bandwidth measurements scanners MAY
include other items per relay.
For instance, sbws includes:
"rtt" = INT, Round Trip Time (to obtain 1B)
Every relay measurement in sbws consists of:
"node_id" fingerprint SP
"bw" bandwidth SP
"nick=" nickname SP
"rtt=" rtt SP
"time=" timestamp NL
Every relay measurement in Torflow consists of:
"node_id" fingerprint SP
"bw" bandwidth SP
"nick=" nickname SP
"measured_at=" slice timestamp NL
The "measured_at" does not correspond to the "time" in sbws.
[juga: actually, if bwauths use "measured_at", then the code on them
or sbws should be changed].
Torflow includes other items that are out of the scope of this
document.
References:
1. https://gitweb.torproject.org/torflow.git
2.
https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/README.spec.txt#n332
3. https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt
4. https://metrics.torproject.org/onionoo.html#details
A. Sample data
A.1. Torflow
1523911758
node_id=$68A483E05A2ABDCA6DA5A3EF8DB5177638A27F80 bw=392760 nick=Test
measured_at=1523911725 updated_at=1523911725 pid_error=4.11374090719
pid_error_sum=4.11374090719 pid_bw=57136645 pid_delta=2.12168374577
circ_fail=0.2 scanner=/filepath
A.2. sbws
1523911758
version=0.1.0
node_id=$68A483E05A2ABDCA6DA5A3EF8DB5177638A27F80 bw=392760 nick=Test
rtt=380 time=1523911725
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Bandwidth scanner - Summer of Privacy
Hi, I will be working on the bandwidth scanner project during the Tor Summer of Privacy. This would include implementing features to the scanner code, writing tests and documentation, deployment in a test network, comparing results, modify little-tor code. The goal is to have bandwidth scanner code that is easier to maintain, understand, run and gives better measurements. There will be more details online and with reports. I've being already contributing on this project, for instance, writing a draft specification for the bandwidth measurements format [0] or reporting/fixing bugs on bwscanner code [1]. I'm MS in computer engineering, senior developer and have worked as sysadmin and researcher. Best regards, juga. GnuPG key fp: 2DA81D01455C3A0032198850F305447AF806D46B [0] https://lists.torproject.org/pipermail/tor-dev/2018-April/013071.html [1] https://github.com/TheTorProject/bwscanner ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Dealing with critical sbws tickets
teor: > Hi juga, > > I read your meeting notes from this week's network team meeting: > > juga(offline): >Week of 05/20 (planned) > - Add Tor version to the bandwidth file (#30196) >Week of 05/20 (actual) >Week of 06/03 (plan) > - Continue with #30406: Refactor header constants in sbws to > use Stem's one > > For the next few weeks, can you focus on fixing critical sbws bugs, > and helping with authority deployments? Yes, i'll do my best with the little time i've to continue with sbws. > > Here's what I think we could do: > > I would like us to deploy sbws to 3/6 bandwidth authorities some time > in June. We can do this deployment as soon as another directory > authority operator is ready. There's another authority operator ready. If you think we don't need to fix any bug before a 3rd directory authority runs sbws, i can tell them to start running sbws. > > To deploy more than 3 sbws instances, we need to fix these critical sbws > bugs: > > We need sbws to generate bandwidth lines for all relays with results, > even if they are not Running in the sbws tor client's current consensus. > https://trac.torproject.org/projects/tor/ticket/29710#comment:13 > > We need sbws to use MaxAdvertisedBandwidth from the latest descriptors: > https://trac.torproject.org/projects/tor/ticket/30733 > > We also need to look for any more critical bugs in sbws. Here are some > ways we can check for bugs: > > We need to check if all sbws instances exclude some relays, to help us find > any more bugs in sbws: > https://trac.torproject.org/projects/tor/ticket/30735 > > 90% of sbws measurement attempts fail. But these are internal errors, not > network errors. So it looks like sbws has a relay selection bug: > https://trac.torproject.org/projects/tor/ticket/30719#comment:2 > > After we do these tasks, we can deploy sbws to 4 bandwidth authorities. > > What do you think? > I'll look at all these bugs more in detail. How many directory authorities would we like to be running sbws (after those bugs are fixed) by which date?. BTW, longclaw's sbws did not have network for ~1 days (which for sure has affected to some metrics), i should have documented that somewhere, not sure there's a better place for that than trac. Thanks, juga. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Release new version of stem
Hi hefee, On 9/17/22 11:06, Hefee wrote: There are no further releases planned and talking to atagar last time he said the master branch was not ready for release. We could think about minor point releases for the 1.8 series but those would just contain small bug fixes (like Python 3.10 compatibility) but no new features. Having a way to work with Python 3.10+ is still great but will not help for our use case as onionshare using the feature of client auth v3. we've released stem 1.8.1 [1] including v3 onion services patches [2]. There'd be a pypi package soon (in aprox. 1 day) and stem's website update. Please, let us know whether that works for you, Cheers, juga. [1] https://github.com/torproject/stem/releases/tag/1.8.1 [2] https://github.com/torproject/stem/commits/maint ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
