Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T18:09:38Zhttps://gitlab.torproject.org/legacy/trac/-/issues/34070Add parsing support for OnionPerf analysis files2020-06-13T18:09:38ZKarsten LoesingAdd parsing support for OnionPerf analysis filesBack in the days, Torperf wrote its results to .tpf files using one line per measurement with space-separated key=value pairs. OnionPerf continued using this format in addition to writing a more sophisticated JSON format. It's time to te...Back in the days, Torperf wrote its results to .tpf files using one line per measurement with space-separated key=value pairs. OnionPerf continued using this format in addition to writing a more sophisticated JSON format. It's time to teach metrics-lib how to read that JSON format, so that we can abandon the .tpf format. That is going to simplify upcoming changes to OnionPerf where we then only have to write a single output format.
The first step is to add parsing support for OnionPerf analysis files to metrics-lib. I worked on a patch over the past weeks that parses JSON files and internally converts them to Torperf results. The idea here is to keep changes to applications like metrics-web as small as possible. They can simply read different descriptor files and obtain the same output as before. We can later extract more parts from OnionPerf analysis files and provide them in a new interface, but we don't have to do that right now.Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/33650Verify that intro2 cell extensions actually work2020-06-13T15:52:23ZRoger DingledineVerify that intro2 cell extensions actually workIn the future we're going to want to transport end-to-end tokens, proofs of work, or other blobs from client to onion service. We should make sure that we can actually add these into the cells without anything going wrong, like surprisin...In the future we're going to want to transport end-to-end tokens, proofs of work, or other blobs from client to onion service. We should make sure that we can actually add these into the cells without anything going wrong, like surprising asserts or surprising length enforcement.
(Now is the time to notice if things will go wrong, so we can fix them and deploy that fix, and then people will have upgraded by the time we're ready to actually use them.)
So: let's make a branch that adds "hi mom" on the client side, and reads it out again on the service side.
In spelunking through the code and the spec, I found that modern intro2 cells have an "extensions" field inside their encrypted component, which seems perfectly suited for transporting arbitrary blobs from client to service. Here's how we set it currently on the client side:
```
/* Set extension data. None are used. */
ext = trn_cell_extension_new();
tor_assert(ext);
trn_cell_extension_set_num(ext, 0);
trn_cell_introduce_encrypted_set_extensions(enc_cell, ext);
```
So that 0 needs to become a 1, and then we need something new that makes and sets a new extension in ext (modeled maybe on `build_establish_intro_dos_extension()`, and something on the receiving end that invokes trn_cell_extension_parse() and reads it out to us.
I am optimistic, because this thing is encrypted, so the intro point in the middle can't be looking at it very carefully. But if we have bugs on the client side or the service side, or surprise length enforcement in the middle, now is a great time to notice and fix them.Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/33379Make chutney wait for all relays in the consensus before verifying2020-06-13T13:31:35ZteorMake chutney wait for all relays in the consensus before verifyingAs part of #33232, we want chutney to check that all relays are in the consensus, then verify.As part of #33232, we want chutney to check that all relays are in the consensus, then verify.teorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/33009sbws bandwidth scans should require a minimum exit bandwidth2020-06-13T16:16:20Zteorsbws bandwidth scans should require a minimum exit bandwidthWhen sbws is constructing a two-hop measurement circuit to run a test, it tries to pick an exit that has at least twice the consensus weight of the current relay-under-test:
https://github.com/torproject/sbws/blob/master/sbws/core/scanne...When sbws is constructing a two-hop measurement circuit to run a test, it tries to pick an exit that has at least twice the consensus weight of the current relay-under-test:
https://github.com/torproject/sbws/blob/master/sbws/core/scanner.py#L216
So this means that in this case, sbws would have picked any exit that was not a BadExit, has an acceptable ExitPolicy, and has a consensus weight of at least, well, 2. That's not a lot.
As it turns out, something like 10% of exits have under a 600Kbyte/sec advertised bandwidth. So it seems pretty easy from this weight=1 bootstrap scenario to get paired with an exit that will give poor test results.
Perhaps bwauth path selection should also choose a testing pair from exits/relays with a certain absolute minimum of weight or advertised bandwidth?
Reported by Jimmy on tor-relays:
https://lists.torproject.org/pipermail/tor-relays/2020-January/018027.htmlsbws: 1.1.x-finalGeorg KoppenGeorg Koppenhttps://gitlab.torproject.org/legacy/trac/-/issues/32427Refactor options_act_reversible into manageable chunks2020-06-13T15:48:03ZNick MathewsonRefactor options_act_reversible into manageable chunksTor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/31384localize snowflake website2020-06-13T18:20:50Zemmapeellocalize snowflake websitehttps://snowflake.torproject.org/ should appear at least on our priority 12 languages.https://snowflake.torproject.org/ should appear at least on our priority 12 languages.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/legacy/trac/-/issues/31369HSv3 descriptor support in stem [decoding]2020-06-13T10:52:54ZGeorge KadianakisHSv3 descriptor support in stem [decoding]Hello,
it would be great if stem could support v3 onion service descriptors: both to parse them and to generate them.
This would be particularly useful as part of onionbalance v3 (#26768). The old onionbalance actually generates the de...Hello,
it would be great if stem could support v3 onion service descriptors: both to parse them and to generate them.
This would be particularly useful as part of onionbalance v3 (#26768). The old onionbalance actually generates the descriptors itself in an ad-hoc way, but it would be great if we could have stem make them in the new one.
Damian asked me for an HSFETCH command that will fetch a stable v3 onion desc. I used Donncha's script from here (https://gist.github.com/DonnchaC/13b744a1e30b7d34bc26) like this:
`python tmp/hsfetch.py vww6ybal4bd7szmgncyruucpgfkqahzddi37ktceo3ah7ngmcopnpyyd.onion` and that gives me the riseup onion descriptor (there is no DDG v3 onion right now).
Also, v3 descriptors are more complicated than v2 descriptors because of their double-layer encryption. You can see more info here: https://github.com/torproject/torspec/blob/master/rend-spec-v3.txt#L1046
https://github.com/torproject/tor/blob/0acfd7dcee2a4473eba05a53d6df2d6d4fe2050b/src/feature/hs/hs_descriptor.c#L2639
Damian, let me know how that looks like to you and how we can help. We plan to start working on Onionbalance v3 at mid-to-late August, but if this is something we can have at a reasonaable timeframe we can potentially delay the descriptor parts of it for some time until stem support exists.Damian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/31192TBA - Support x86_64 target2020-06-16T01:05:50ZcypherpunksTBA - Support x86_64 targethttps://bugzilla.mozilla.org/show_bug.cgi?id=1480834#c0https://bugzilla.mozilla.org/show_bug.cgi?id=1480834#c0https://gitlab.torproject.org/legacy/trac/-/issues/28849Handle dormant mode in process library and for PT's2020-06-13T18:35:41ZAlexander Færøyahf@torproject.orgHandle dormant mode in process library and for PT'sBug #28179 makes us able to handle PT processes better and read output from stdout/stderr, but with the recent dormant mode we should figure out this interaction works for PT's.
Especially on Windows this becomes a problem because we wi...Bug #28179 makes us able to handle PT processes better and read output from stdout/stderr, but with the recent dormant mode we should figure out this interaction works for PT's.
Especially on Windows this becomes a problem because we will probably stop reading from stdout/stderr when Tor enters its dormant mode to disable the timer that ticks once a second.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23854Add an RSS feed for https://metrics.torproject.org/news.html2020-06-13T18:14:19ZcypherpunksAdd an RSS feed for https://metrics.torproject.org/news.htmlThis is an item on the roadmap and has also been requested on twitter:
https://twitter.com/33b5e5/status/918598903066386432This is an item on the roadmap and has also been requested on twitter:
https://twitter.com/33b5e5/status/918598903066386432irlirlhttps://gitlab.torproject.org/legacy/trac/-/issues/23169Explain why metrics are important and what we do to make sure they're safe2020-06-13T18:14:06ZRoger DingledineExplain why metrics are important and what we do to make sure they're safeIn trying to answer the comments on https://blog.torproject.org/blog/we-enhanced-security-and-integrity-tor-metrics-supported-moss, I realized that our metrics site is just a bunch of graphs and stuff, with no easy-to-find explanation of...In trying to answer the comments on https://blog.torproject.org/blog/we-enhanced-security-and-integrity-tor-metrics-supported-moss, I realized that our metrics site is just a bunch of graphs and stuff, with no easy-to-find explanation of *why* we collect stuff, what our goals are and why collecting these things will get us there, what our constraints are (e.g. which things we won't ever do even if they would also help us achieve our goals), etc.
I see a little sentence under 'Philosophy' on the about page. That's a nice start.
But explaining why metrics are worthwhile, when we're a privacy project, seems like something we should address directly rather than leave implicit.
It might be that some of the safety board principles could be useful to articulate here: https://research.torproject.org/safetyboard.html#guidelinesirlirl