- tor-dev - lists.torproject.org

[release] [protocol] Onionoo 4.1-1.4.1
by iwakeh 31 Aug '17

31 Aug '17

Hi there! Onionoo's protocol was extended and has a minor version jump to 4.1, therefore a new release is available: https://dist.torproject.org/onionoo/4.1-1.4.1/ Protocol changes (also summarized in [0]): * removal of (unused) beta fields in bridge client objects * addition of a new search filter parameter by Tor version, see [1] and [2] for example calls. There were also some internal improvements, which can be found in the changelog [3a]. You might have noticed an increment in the middle and minor application version. This is due to a fix for the new filter, which was discovered after creating the 4.1-1.4.0 release, but could be applied before announcing 4.1-1.4.0 (cf.[3b]). Please direct comments and questions to the metrics-team mailing list [4]. Cheers, iwakeh [0] https://metrics.torproject.org/onionoo.html#versions [1] https://onionoo.torproject.org/details?search=version:0.2.4&limit=10 [2] https://onionoo.torproject.org/details?search=version:0.3&limit=10 [3a] https://gitweb.torproject.org/onionoo.git/tree/CHANGELOG.md?h=onionoo-4.1-1… [3b] https://gitweb.torproject.org/onionoo.git/tree/CHANGELOG.md?h=onionoo-4.1-1… [4] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0

Meeting on IRC to discuss prop280 privcount stuff (Sep 12, 8pm EDT)
by Nick Mathewson 28 Aug '17

28 Aug '17

Hello! On #tor-dev at 8pm EDT on Tuesday Sep 12 (== 00:00 Sep 13 in UTC, I think), we'll have an IRC meeting to talk about proposal 280, and integrating privcount into Tor. If you're interested, please feel free to drop by! The current draft of the proposal is at https://gitweb.torproject.org/torspec.git/tree/proposals/280-privcount-in-t… best wisehes, -- Nick

1 0

Proposal 281: downloading microdescriptors in bulk
by Nick Mathewson 28 Aug '17

28 Aug '17

Filename: 281-bulk-md-download.txt Title: Downloading microdescriptors in bulk Author: Nick Mathewson Created: 11-Aug-2017 Status: Draft 1. Introduction This proposal describes a ways to download more microdescriptors at a time, using fewer bytes. Right now, to download N microdescriptors, the client must send about 44*N bytes in its HTTP request. Because clients can request microdescriptors in any combination, the directory caches cannot pre-compress responses to these requests, and need to use less space-efficient on-the-fly compression algorithms. Under this proposal, clients simply say "Send me the microdescriptors I need", given what I know. 2. Combined microdescriptor downloads 2.1. By diff If a client has a consensus with base64 sha3-256 digest X, and it previously had a consensus with base64 sha3-256 digests Y then it may request all the microdescriptors listed in X but not Y, by asking for the resource: /tor/micro/diff/X/Y Clients SHOULD only ask for this resource compressed. Caches MUST NOT answer this request unless they recognize the consensus with digest X, and digest Y. digest Y. If answering, caches MUST reply with all of the microdescriptors that the cache holds that were listed by consensus X, and MUST omit all the microdescriptors that were omitted listed in consensus Y. 2.2. By consensus: If a client has fewer than NMNM% of the microdescriptors listed in a consensus X, it should fetch the resource /tor/micro/full/X Clients SHOULD only ask for this resource compressed. Caches MUST NOT answer this request unless they recognize the consensus with digest X. They should send all the microdescriptors they have that are listed in that consensus. 2.3. When to make these requests Clients should decide to use this format in preference to the old download-by-digest format if the consensus X lists their preferred directory cache as using a new DirCache subprotocol version. (See 5 below.) 3. Performance analysis This is a back-of-the-envelope analysis using a month's worth of consensus documents, and a randomly chosen sample of microdescriptors. On average, about 0.5% of the microdescriptors change between any two consensuses. Call it 50. That means 50*43 bytes == 2150 bytes to request the microdescriptors. It means ~24530 bytes of microdescriptors downloaded, compressed to ~13687 bytes by zstd. With this proposal, we're down to 86 bytes for the request, and we can precompute the compressed output, making it save to use lzma2, getting a compressed result more like 13362. It appears that this change would save about 15% for incremental microdescriptor downloads, most of that coming from the reduction in request size. For complete downloads, a complete set of microdescriptors is about 7700 microdesciptors long. That makes the total number of bytes for the requests 7700*43 == 331100 bytes. The response, if compressed with lzma instead of zstd, would fall from 1659682 to 1587804 bytes, for a total savings of 20%. 5. Compatibility Caches supporting this download protocol need to advertise support of a new DirCache subprotocol version.

3 2

Some Tor Devs could get higher pay as PR than as programmers
by Ryan Carboni 24 Aug '17

24 Aug '17

Whenever I read something, with an open mind, but say, in a sandboxed environment (don't run your memes on root), I get impressed by arguments which convince me of things which are not true. Take for instance the following article: https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-… It is a self-contradictory argument, we detected these bad relays when they arrived, allowed them for 6 months. Now, what was the available prophylactic measures at the time? Alleged family greylisting wasn't available at the time, but certainly an attempt could be made to contact (presumably) a few owners of the tor relays. Although it turned out to be only one owner. I mean, people depend their lives on Tor. Can all discretionary decisions of this type be made public? Now there's also the Tor's unlike racists we value free speech. I cannot explain it, but if one replaced racists with Islamists, somehow the argument is weaker. I can't fully explain it, even though I've heard more about beheadings and defenestrations as opposed to... whatever racists do nowadays (shitpost?). It truly is a clever argument that strengthens and preserves Tor's brand identity among target demographic groups. How did Freud invent psychoanalysis? What are you doing during the idle cycles of your brain? One does not need a fancy degree to be an amateur at anything, or do you folks not call yourselves hackers?

2 1

Draft patchset for PT2.0 support (ticket #21816)
by Robin Tarsiger 24 Aug '17

24 Aug '17

Good day, tor-dev; As some of you know, I've been working on a patchset for Tor to allow it to participate in Pluggable Transports 2.0 configuration, primarily the new JSON Parameter Block SOCKS method (at least that's what I've been calling it in the absence of a more official name), almost but not quite as described in section 3.3.4 of PT2 draft 2 [1]---i.e., basically #21816 [2]. [1] https://www.pluggabletransports.info/assets/PTSpecV2Draft2.pdf [2] https://trac.torproject.org/projects/tor/ticket/21816 I'm attaching a draft patchset which adds this functionality, with the intent of getting feedback and making remaining cleanups or other modifications necessary to get it merged into Tor. I have successfully completed circuits through an obfs4 bridge using both obfs4proxy (PT1) and a version of shapeshifter-dispatcher (PT2) using a patched Tor. I've tried to follow the local style, but the preferred implementation strategies aren't always clear, and of course I'd appreciate any reports of other problems. A forked Git repository is also available on Bitbucket [5][6], which will be updated as I make remaining changes. [5] https://bitbucket.org/DasyatidPrime/tor-rtt2017-21816.git (Git) [6] https://bitbucket.org/DasyatidPrime/tor-rtt2017-21816/src (Web) More implementation details are below if you're interested in this; thanks for your attention. I'll try to be around on IRC more during the week, so feel free to ping me there as well. -RTT ... Details: Not visible above, related to the target functionality: - I'm assuming the SOCKS method includes a response with an analogous structure to RFC 1929; PT2 draft 2 doesn't specify one. I've cleared this with blanu, and that's intended for the next draft of the PT2 specification. - Similarly, the length prefix is in fact big-endian; the example in PT2 draft 2 is wrong, though the text is correct. - We're looking into getting an IANA assignment for the method number. Technically this probably meets the requirements for the private use block, but I feel like interop might be easier later on, and it could simplify code paths in places to have a registered number (mainly if it's possible to decouple the method negotiation from the configuration-version plumbing). I believe this is still in limbo. - For the PT2 side, I've been testing against my branch of shapeshifter-dispatcher [3] compiled with my branch of shapeshifter-ipc [4] since there were some breaking changes to Shapeshifter upstream which were otherwise preventing it from interoperating with Tor. I'm planning to help merge fixes into Shapeshifter upstream as I can; it's my current understanding that there aren't any other PT2 managed transport implementations to test against. [3] https://github.com/OperatorFoundation/shapeshifter-dispatcher/tree/rtt2017 [4] https://github.com/OperatorFoundation/shapeshifter-ipc/tree/rtt2017 Issues on my radar currently (comments appreciated): - We probably want unit tests for the (limited) JSON encoding functions, and for the factored-out RFC 1929 encoding functions. Anything else that looks feasibly testable here? - It's not clear to me whether negotiating a PT2 configuration version still allows PT1-style RFC 1929 parameter encoding so that managed transports can support the new configuration version and the new SOCKS method separately. I've assumed it might be possible, so far, but that's not being tested against anything. - I currently restrict parameters to ASCII to avoid either writing a JSON encoder that can spit out invalid JSON or writing a JSON encoder that has to validate incoming UTF-8. The impression I've gotten is that this is probably okay, but if there are counter- examples, I can put in UTF-8 passthrough. - The commit sequence isn't the cleanest. How high a priority is it to reorder/combine patch hunks to make a cleaner one? - We still need a 'changes' file. (What would be an appropriate heading for this? Is this a minor feature, for instance?) A few other questions: - Is there an effective way of doing automated testing of the SOCKS state machine currently in Tor? I didn't see anything obvious in the test directory. This seems like the most fragile part, especially since both the original and modified versions are not very explicit in their state machine nature and are split between multiple files. - Can there ever be more than one managed_proxy_t to a transport name? More generally, is there a relational diagram of the main Tor data structures somewhere? A lot of the way the plumbing for state and configuration information is set up feels kind of fragile.

3 3

Tor and IP2Location LITE
by KL Liew 24 Aug '17

24 Aug '17

All, My name is Kim, the founder of IP2Location, a geolocation service provider since 2002. It looks like Tor is looking to review other providers for GeoIP service while I was reading one of a meeting minute for a meeting back in March 2017. https://trac.torproject.org/projects/tor/wiki/org/meetings/2017Amsterdam/No… We are very interested in contributing to Tor and work on this matter. Tor can host and integrate IP2Location LITE (http://lite.ip2location.com) into their application. IP2Location has programming libraries in most languages. We can also work with developers if there is any technical issues. In term of accuracy, you can find the latest research paper published by TUM. IP2Location has good accuracy as reported in Table V. Title : HLOC: Hints-Based Geolocation Leveraging Multiple Measurement Frameworks Authors : Quirin Scheitle, Oliver Gasser, Patrick Sattler, Georg Carle from Technical University of Munich (TUM) PDF Access : https://arxiv.org/pdf/1706.09331.pdf Let me know if there is any questions. - Kim

6 9

Re: [tor-dev] tor-dev Digest, Vol 79, Issue 4
by John kongtcheu 21 Aug '17

21 Aug '17

Hello Tor developers, I am interested in becoming an open source contributor for Tor, but I don't know where to start some guidance would be appreciated. Thank you, On Sat, Aug 12, 2017 at 8:00 AM, <tor-dev-request(a)lists.torproject.org> wrote: > Send tor-dev mailing list submissions to > tor-dev(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > or, via email, send a message with subject or body 'help' to > tor-dev-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-dev-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-dev digest..." > > > Today's Topics: > > 1. Proposal 281: downloading microdescriptors in bulk > (Nick Mathewson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 11 Aug 2017 13:36:00 -0400 > From: Nick Mathewson <nickm(a)torproject.org> > To: tor-dev(a)lists.torproject.org > Subject: [tor-dev] Proposal 281: downloading microdescriptors in bulk > Message-ID: > <CAKDKvux=eJBh_JsEeiqnhbEbcgRVeMRrbm2G7itZ8kX > y4+M26A(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Filename: 281-bulk-md-download.txt > Title: Downloading microdescriptors in bulk > Author: Nick Mathewson > Created: 11-Aug-2017 > Status: Draft > > 1. Introduction > > This proposal describes a ways to download more microdescriptors > at a time, using fewer bytes. > > Right now, to download N microdescriptors, the client must send > about 44*N bytes in its HTTP request. Because clients can request > microdescriptors in any combination, the directory caches cannot > pre-compress responses to these requests, and need to use less > space-efficient on-the-fly compression algorithms. > > Under this proposal, clients simply say "Send me the > microdescriptors I need", given what I know. > > 2. Combined microdescriptor downloads > > 2.1. By diff > > If a client has a consensus with base64 sha3-256 digest X, and it > previously had a consensus with base64 sha3-256 digests Y then > it may request all the microdescriptors listed in X but not Y, > by asking for the resource: > /tor/micro/diff/X/Y > > Clients SHOULD only ask for this resource compressed. > > Caches MUST NOT answer this request unless they recognize the > consensus with digest X, and digest Y. > digest Y. If answering, caches MUST reply with all of the > microdescriptors that the cache holds that were listed by > consensus X, and MUST omit all the microdescriptors that were > omitted listed in consensus Y. > > 2.2. By consensus: > > If a client has fewer than NMNM% of the microdescriptors listed in a > consensus X, it should fetch the resource > /tor/micro/full/X > > Clients SHOULD only ask for this resource compressed. > > Caches MUST NOT answer this request unless they recognize the > consensus with digest X. They should send all the microdescriptors > they have that are listed in that consensus. > > 2.3. When to make these requests > > Clients should decide to use this format in preference to the > old download-by-digest format if the consensus X lists their > preferred directory cache as using a new DirCache subprotocol > version. (See 5 below.) > > 3. Performance analysis > > This is a back-of-the-envelope analysis using a month's worth of > consensus documents, and a randomly chosen sample of > microdescriptors. > > > On average, about 0.5% of the microdescriptors change between any > two consensuses. Call it 50. That means 50*43 bytes == 2150 > bytes to request the microdescriptors. It means ~24530 bytes of > microdescriptors downloaded, compressed to ~13687 bytes by zstd. > > With this proposal, we're down to 86 bytes for the request, and we > can precompute the compressed output, making it save to use lzma2, > getting a compressed result more like 13362. > > It appears that this change would save about 15% for incremental > microdescriptor downloads, most of that coming from the reduction > in request size. > > For complete downloads, a complete set of microdescriptors is about > 7700 microdesciptors long. That makes the total number of bytes > for the requests 7700*43 == 331100 bytes. The response, if > compressed with lzma instead of zstd, would fall from 1659682 to > 1587804 bytes, for a total savings of 20%. > > > 5. Compatibility > > Caches supporting this download protocol need to advertise > support of a new DirCache subprotocol version. > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > tor-dev mailing list > tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > > ------------------------------ > > End of tor-dev Digest, Vol 79, Issue 4 > ************************************** >

2 1

Re: [tor-dev] Feature Request: please consider ship default, Tor bridges
by iry 19 Aug '17

19 Aug '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Roger: > On Thu, Aug 17, 2017 at 07:57:53PM +0000, iry wrote: >> Btw, Collateral Freedom seems to be one of the most effective >> ways to circumvent Internet censorship in China. Circumvention >> tools that depend on Collateral Freedom usually works fine, >> including meek, lantern, psiphon3 etc. Therefore, I see a lot of >> potential work which may benefit the Internet freedom in China. >> For example: 1. package meek into Debian 2. host (part of the) >> BridgeDB mirror on Github or AWS 3. #22402: >> https://trac.torproject.org/projects/tor/ticket/22402 > Some hopefully useful thoughts along these lines: > Hi Roger! Thank you for sharing your insights! > A) Most places around the world that need bridges these days need > pluggable transport bridges, not just vanilla bridges. So if we > want to bundle bridge addresses, we should bundle PT bridge > addresses. > I agree! This also makes me think about a small potential improvement on the design of BridgeDB web. When users click the big "Just give me some bridge" on https://bridges.torproject.org/options , they will be provided with vanilla bridges instead of obfs4 bridges. However, those users who choose not to use "Advanced Options" are most likely to be inexperienced and have no idea on what obfd4, PT etc are. Therefore, is it a good idea to provide obfs4 bridges, rather than vanilla ones, in "Just give me some bridge" for better usability and higher success rate? > B) ...and that means we need to make sure that those PTs are well > packaged in Debian too, since the Tor deb by itself would not be > able to use them. > Agreed. I can help to report a bug against obfs4proxy on Debian BTS when the idea is mature. > C) I wonder if we could use the new %include torrc directive in > this situation: https://bugs.torproject.org/1922 I don't have a say on the final decision, but this is also what I am thinking about:> 3. "Bridge" + plain text which is ready to be appended to a torrc file > or to be one of the torrc files in /etc/torrc.d/ (or whatever > torrc.d path Debain decides to use) > That is, when you apt-get install obfs4proxy, is that the right > time to populate /etc/torrc.d/obfs4-bridges with some (probably > commented out to start) lines that let you use those bridges if > you want? How about not commenting out the bridge info as the switch? Instead, user who would like to use bridge can comment out or add the following two lines in /etc/tor/torrc: #UseBridges 1 #ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy I have being considering /etc/torrc.d/ as a place to store all the available settings and considering /etc/tor/torrc as a panel that let user decide what they would like to enable and disable. But I am not sure if this is a good way to think about the relationship between /etc/tor/torrc and /etc/torrc.d/ One thing I am concerned about is, when applying the method above, how can user choose different PTs in the future? For example, when meek in packaged into Debian, the meek package will probably also have a /etc/torrc.d/meek-bridges file. Can we just choose to use obfs4 or meek in /etc/tor/torrc by switching between the following two lines? #ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy #ClientTransportPlugin meek exec /usr/bin/meek-client (I can test with that, but people who is familiar with the mechanism behind it can probably answer that.) Best, iry -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZmHZUAAoJEKFLTbxtzdU8Y2gP+wfDoSOTprVqe4rByzHVhUup LXvy4WnfHeUq03t+H8W5QwJCPdsFssFZae/EsfUU5Q490GqhAFryi8rHmOHluSGl FmX9SIxQXT3RV7iEFN7w4qKqYHLEKrRTklWOLrDauHZe3eJEUyn49VCROtBat88Y bdnrav4D443fFD/ugk8C3K5u4oNEWgtaq9natsLkPFbXpNcB06gd/S23Vj4VsOP0 +FUmIHmtzzMk0iTAVjGrW8X/z6/lyqk6Nj/lvwfNhdIJ5gbk5F848sl71VBeK3of Q7rdCjglZ3/tPRfrE+d40cfQWmOpw7doozC7LKdDbxCtx/LJ0WFq2PvwmO+uUFOG 3QMAV0w58JWsUsLW80ifcx7T+0O7QeAMASqWqKva7d1Y2PgqNCJfDJDHOX/KuEy3 TUi8o5WkIUUtyPaMwnYXW9VkaEKIHBXxfjYBwg0llfGU9HKJmTj+yCrMMHB2t0m0 OlZUFx9E7U11mhWzGM64sICHuob8VjwsLgLPMJc1+ocDobo0HrJr1ZtWmMZScp60 SpK35EwU8jKZJTSXtI/SKtDdHGhGmxm4NvLy26TWSqHbEzlcelK+yqkifnLHr3tb we61NdV2ZA7XCrp+o3Q7NprMjRGtaP1aze2bQTjJfkLDdrShkZFw3/hYk75cRpvk tkf7Tl4oLtoa5lnNhB/S =sP5G -----END PGP SIGNATURE-----

1 0

Feature Request: please consider ship default Tor bridges
by iry 19 Aug '17

19 Aug '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello Tor people! A set of Tor bridges are shipped with Tor browser bundle[0], helping users in Tor-censored area to connection to the Tor network. Since system Tor users may also face the censorship problem, shall we ship some Tor bridges along with the tor package? The request is firstly reported[0] to Debian BTS and I got the following reply by Peter: > If upstream starts shipping bridges with their Tor releases, that > would naturally result in the Tor package shipping bridges as > well. > > I do not know whether that's a good idea or not, but I don't think > deviating from upstream would be particularly worthwhile. The following is some related information which may help the future discussion: The possible formats to hold those bridges can be: 1. JSON which is also the way tor-connection-wizard used so far[1]; 2. plain text which is the same formatt given by the BridgeDB[2] by Tor Project; 3. "Bridge" + plain text which is ready to be appended to a torrc file or to be one of the torrc files in /etc/torrc.d/ (or whatever torrc.d path Debain decides to use) The default bridge shipped with tor package should be exactly the same bridges contained in bridge_prefs.js[0] shipped with the latest stable TBB. This is because: 1. The servers hosting default bridges are set up for huge amount of traffic; 2. The servers hosting default bridges are probably audited by TPO for better security; 3. Using a different set of bridges will distinguish the anon-connection-wizard bridge users from the TBB bridge users, which compromises their anonymity. What do you think? Looking forward to hearing your insights! Best, iry [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872456 [1]: https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundl e-Data/PTConfigs/bridge_prefs.js?h=7.5a3-linux [2]: https://github.com/irykoon/anon-connection-wizard/blob/master/usr/share/ anon-connection-wizard/bridges_default [3]: https://bridges.torproject.org/options Best, iry -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZldAaAAoJEKFLTbxtzdU8QHEP/0DyAtD95JOKEkDulsyuuVfx uYT+5WGaRSFntqRq91RcNkHLHDy61JtLXhr5VIcz/tYIIe3TVZhI9idqbPgJMZc+ xxS/4r5qhkkcJ5X99xo7Jerz/0Y/4CKboREAkSstz15RL3FNLF6mwFZgWsiZ4rMa SkruE8qchz1KIUuWKZyx3HioloZgIHQkvqQ6fE4asGIs8gnaKeofpSwRGq85/Vcq T8D0WTqCFweLFaYzCWMtO7bVKXrfqC8rGLesLPJhxZbl0MJ3H/5TdvbPHn6VwRH0 AZCT5q7A+0fC/+HHwsn9SFhMo0TaIOtZBonOH58X3OEamKrmJOwqESvCPqILtMC3 pU2PtoOSDQEd684b2hxoR+0uRMOew+CJ+U7lzyh7yYU9x3jv//9CsFGcKcD+FoFG zrkDPJ75uzYGJjHZUFpnk8opwVy49TghYiVvjwm9/PXXQVvEiCGNEt7W1wTHX3Ja DygMsGN8GXg6AqWRESg4NcI8N/4U2EUEt+Li45u0qsTJ/uYmfamsC/WoacfjznaD JQVKjJQlhuk7F3qUPuxtxaGCLopLJd/uAUyYaI/HPrFeR3uIawSzCW9prTkk/E7n wAop3mErdp6JYnTacUb4pcYINIQf1c7FymbngrAmJzljxH4apZpBPugitAYvtJ2X 2OBJpUV0CtEJH3poicdq =oct9 -----END PGP SIGNATURE-----

3 3

[release] CollecTor 1.2.1
by iwakeh 18 Aug '17

18 Aug '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi there! A bugfix release for CollecTor is available: https://dist.torproject.org/collector/1.2.1/ The bug fixed by this release affects CollecTors sanitizing bridge descriptors and was discovered due to the recent bridge authority outage. Please direct comments and questions to the metrics-team mailing list [2]. And, of course, bug reports [3] or feature requests [4] can be filed in trac. Cheers, iwakeh [1] https://gitweb.torproject.org/collector.git/plain/CHANGELOG.md?id=collector… [2] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team [3] https://trac.torproject.org/projects/tor/newticket?component=Metrics/Collec… [4] https://trac.torproject.org/projects/tor/newticket?component=Metrics/Collec… -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJZlvIvAAoJEPeEx9Sa/gviAEUP/iSAAW5uaQNpMKtNze9x87M/ jluCBRzvIN61xyxjib7Caswz5uBdUew2qYM1+fswBr7odng5sFlUuP6/oJZJBqr5 /C/68WYeYncXUj1vKi5mNjktJ7CJQE29anqG8EYtbVAKIqiQJmot/Hb8JI/V+RFU 1HueB78zPXbJBb8A0NBDvvhO5tFcTeQKEMKqZngkv4eojuhQu8pgT9Y5YGxMsSU9 al/kzpJIG78MnuKHZBjkSc8vn9YivZnxIyLgl8zaxKT5SOx11U3T8PN2rV5gJs3o qzstD75S71g7K9w4RZqg2bljp2xM4z0ui9lgfWWAKkodhm0aGZZFs9CIZeVhtN/s FiOVm+ZTJfpiudEqF9amv1uZxW9d5KQzpKKEjGKGOa9kk2idWZieLFbj2NLjDtv1 GJxYgW+pxliJYH/sQqSjJ4icxcQD75k4+Z725ENd8vVBVGDS7jqmjDr9tUKbctad ftD4Fjeg0CE8CTOneY2tTJ6w8dpbiPxXP1otzGltDGpOX0D1cMCSXtNX10/n4GRv ndnat57JBTLwKnRQ3SL/eDTXCwRpXzT66bUbWAhNeY6tl5aGni7/vItn4Hd9qf8v zp8T2X0tp2+02FYnidITPIxLmLfCcDh3b87qIFC+3DStD/GOuUVz0P/i/sfuCN6A onSYAUgAIqx7Uced2auo =9wXW -----END PGP SIGNATURE-----

1 0