The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-02-22T17:09:33Zhttps://gitlab.torproject.org/tpo/core/arti/-/issues/223Run strip --strip-debug in reproducible_build.sh2022-02-22T17:09:33ZNick MathewsonRun strip --strip-debug in reproducible_build.shWe don't need our release builds to have debugging information from std or from the libraries they include: we should run `strip --strip-debug` on them as part of the reproducible build process.
(Not plain `strip`; that would break RUST...We don't need our release builds to have debugging information from std or from the libraries they include: we should run `strip --strip-debug` on them as part of the reproducible build process.
(Not plain `strip`; that would break RUST_BACKTRACE.)Arti 1.0.0: Ready for production usehttps://gitlab.torproject.org/tpo/core/arti/-/issues/210tor-circmgr test "request_retried" is not reliable2023-01-04T13:24:11ZNick Mathewsontor-circmgr test "request_retried" is not reliableAt https://gitlab.torproject.org/nickm/arti/-/jobs/45855 I see:
```
...
thread 'mgr::test::request_retried' panicked at 'called `Result::unwrap()` on an `Err` value: RequestFailed(RetryError { doing: "find or build a circuit", errors: []...At https://gitlab.torproject.org/nickm/arti/-/jobs/45855 I see:
```
...
thread 'mgr::test::request_retried' panicked at 'called `Result::unwrap()` on an `Err` value: RequestFailed(RetryError { doing: "find or build a circuit", errors: [], n_errors: 0 })', crates/tor-circmgr/src/mgr.rs:1575:25
advancing released: circuit builder task 6132487541863617059
failures:
mgr::test::request_retried
```
I couldn't reproduce this just by running this test on its own, but I managed to get it to reoccur by running all of the tor-circmgr tests in a loop:
```
; while cargo test -p tor-circmgr ; do : ; done
...
sleeper made for 59.97s, 64/65
sleeper dropped, incrementing count
sleeper polled, 65/65
setting advance flag
waitfor done!
thread 'mgr::test::request_retried' panicked at 'called `Result::unwrap()` on an `Err` value: RequestFailed(RetryError { doing: "find or build a circuit", errors: [], n_errors: 0 })', crates/tor-circmgr/src/mgr.rs:1575:25
```Arti 1.0.0: Ready for production usehttps://gitlab.torproject.org/tpo/core/arti/-/issues/158Improve continually_expire_circuits() to wake up only as needed.2021-12-16T12:20:11ZNick MathewsonImprove continually_expire_circuits() to wake up only as needed.Right now, the `continually_expire_circuits()` function in `tor_circmgr` wakes up every few seconds to check for expired circuits. That's similar to C Tor's behavior, but that isn't good enough. Instead, we would like it to behave more...Right now, the `continually_expire_circuits()` function in `tor_circmgr` wakes up every few seconds to check for expired circuits. That's similar to C Tor's behavior, but that isn't good enough. Instead, we would like it to behave more like this:
```
loop {
wait until (notification received) or (timeout);
expire_circuits()
set timeout = (time until next currently scheduled expiration)
}
```
We'd need to have any code that decreases the _next expected_ timeout send a notification to the task.
This isn't necessary in the near term, but we'll want it before we're done.Arti 1.0.0: Ready for production usehttps://gitlab.torproject.org/tpo/core/arti/-/issues/150Improve and refactor circuit isolation code2022-03-28T13:50:31ZNick MathewsonImprove and refactor circuit isolation codeWith !38, we now have working circuit isolation code. Here are some follow-up items for %"Arti 0.0.1 release: basic anonymity". We should probably talk about these before going ahead and doing them, however: most of these involve some ...With !38, we now have working circuit isolation code. Here are some follow-up items for %"Arti 0.0.1 release: basic anonymity". We should probably talk about these before going ahead and doing them, however: most of these involve some design thinking.
* [ ] Possibly: Split the Usage types and the Isolation types into separate types, such that they can be used and tested independently. Maybe the concrete `TargetCircUsage` and `SupportedCircUsage` types ought to be .
* [x] Possibly: Instead of IsolationToken, support isolation profiles with multiple fields, like we do in Tor. This would let us get rid of `IsolationMap` in tor-client. Perhaps "isolation" should be represented with a a trait and CircMgr should be parameterized with it?
* [ ] Test coverage on IsolationMap, assuming we keep it.
* [x] A function on TorClient to return a clone of the TorClient whose streams are always isolated from the original TorClient.
* [ ] Configurable isolation for different types of field in tor-client, like tor has today.
* [ ] Integration tests that make sure that streams that are supposed to be isolated are in fact assigned to different circuits.Arti 1.0.0: Ready for production useNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/arti/-/issues/137Measure fuzzing-based coverage2022-02-25T14:15:25ZNick MathewsonMeasure fuzzing-based coverageWe have fuzzers: we should see what their coverage looks like, so we can try to improve it over time.We have fuzzers: we should see what their coverage looks like, so we can try to improve it over time.Arti 1.0.0: Ready for production usehttps://gitlab.torproject.org/tpo/core/arti/-/issues/95Have more experienced Rust programmers read our code2022-02-24T21:07:53ZNick MathewsonHave more experienced Rust programmers read our codeArti is my first production project in Rust; none of us at Tor currently have done a Rust project of this size before. Before we can say that Arti is production ready, we should seek some experienced Rust programmers and ask them to loo...Arti is my first production project in Rust; none of us at Tor currently have done a Rust project of this size before. Before we can say that Arti is production ready, we should seek some experienced Rust programmers and ask them to look through our code for general quality issues.
If you're reading this because you're new to Arti and you don't know so much about Tor: no need to worry! Just poke around in the codebase, find a random file, and start asking yourself: does this look like good rust? What about the other things that use it? Is there a way to make it better?Arti 1.0.0: Ready for production usehttps://gitlab.torproject.org/tpo/core/arti/-/issues/89Suspend circuit creation if netdir is far far too old2021-12-13T14:24:08ZNick MathewsonSuspend circuit creation if netdir is far far too oldOnce an arti `DirMgr` is bootstrapped, it currently _stays_ bootstrapped forever, even if it never succeeds at another download. Tor, on the other hand, will consider itself "unbootstrapped" if its consensus becomes expired by more than...Once an arti `DirMgr` is bootstrapped, it currently _stays_ bootstrapped forever, even if it never succeeds at another download. Tor, on the other hand, will consider itself "unbootstrapped" if its consensus becomes expired by more than 72 (ish) hours.
We should add an (optional?) feature for Arti to consider itself to have become unbootstrapped.Arti 1.0.0: Ready for production usehttps://gitlab.torproject.org/tpo/network-health/team/-/issues/175Investigate non-exit general overload2022-03-04T13:25:37ZGeorg KoppenInvestigate non-exit general overloadWe have [some](https://gitlab.torproject.org/tpo/network-health/team/-/issues/66#note_2770466) [indicators](https://lists.torproject.org/pipermail/tor-relays/2022-January/020184.html) about serious non-exit relay general overload going o...We have [some](https://gitlab.torproject.org/tpo/network-health/team/-/issues/66#note_2770466) [indicators](https://lists.torproject.org/pipermail/tor-relays/2022-January/020184.html) about serious non-exit relay general overload going on. We "solved" the *exit* relay issues by just not using the DNS failure metric anymore (see: #139 for some analysis of the problem). We might need to tune our metrics that get triggered by non-exits as well.
We should probably use our network-health relays in testing and figuring out what is going on.
/cc @dgouletNetwork Health OKRs 2022 Q1-Q2 (Metrics excluded)Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/issues/40021Document current model for tor nodes history and status and define future imp...2022-03-28T14:59:06ZHiroDocument current model for tor nodes history and status and define future implementation for the metrics pipelineWe want to be able to track tor nodes behavior beyond their current status to understand some patterns of their life on the Tor network.We want to be able to track tor nodes behavior beyond their current status to understand some patterns of their life on the Tor network.Metrics OKR Q1 - Q2 2022https://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/issues/40020Document current data models for onionoo data2022-02-11T18:23:01ZHiroDocument current data models for onionoo dataCurrently we have some issues related to our underlying data model in onionoo (Ex: https://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/issues/40018) we should document the dependencies between the raw descriptors data, our...Currently we have some issues related to our underlying data model in onionoo (Ex: https://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/issues/40018) we should document the dependencies between the raw descriptors data, our processing pipeline, and our current data models as expressed in onionoo APIs.Metrics OKR Q1 - Q2 2022https://gitlab.torproject.org/tpo/network-health/metrics/monitoring-and-alerting/-/issues/5Evaluate a thrends spotter component for Tor network data.2022-03-21T17:05:36ZHiroEvaluate a thrends spotter component for Tor network data.We should have a component to monitor data from metrics.torproject.org to spot trends and spikes. It doesn't have something super sophisticated to start with, it should just allow people to receive an alert when some indicators are growi...We should have a component to monitor data from metrics.torproject.org to spot trends and spikes. It doesn't have something super sophisticated to start with, it should just allow people to receive an alert when some indicators are growing in certain graph or countries.Metrics OKR Q1 - Q2 2022https://gitlab.torproject.org/tpo/web/community/-/issues/245Work on community.torproject.org usabilty issues based on user feedback2022-06-23T00:58:42ZGabagaba@torproject.orgWork on community.torproject.org usabilty issues based on user feedbackBased on feedback from Sponsor 9's trainings, this ticket will link to usability issues from the community portal.Based on feedback from Sponsor 9's trainings, this ticket will link to usability issues from the community portal.Sponsor 9 - Phase 5 - Usability and Community Intervention on Support for Democracy and Human Rightshttps://gitlab.torproject.org/tpo/web/tpo/-/issues/245Work on torproject.org usabilty issues based on user feedback2022-06-23T00:57:52ZGabagaba@torproject.orgWork on torproject.org usabilty issues based on user feedbackAs part of sponsor 9 we have estimated time to work on the torproject.org based on feedback from users.As part of sponsor 9 we have estimated time to work on the torproject.org based on feedback from users.Sponsor 9 - Phase 5 - Usability and Community Intervention on Support for Democracy and Human Rightsnicobnicob2022-06-30https://gitlab.torproject.org/tpo/community/support/-/issues/40014Update Tor Browser Manual and support.torproject.org content based on Tor Bro...2022-01-17T16:39:55ZGabagaba@torproject.orgUpdate Tor Browser Manual and support.torproject.org content based on Tor Browser 10.5 release10.5 new features:
- Snowflake stable
- "Connecting to Tor" new experience (Remove "Tor is censored in my country")
- v2 onion services warning10.5 new features:
- Snowflake stable
- "Connecting to Tor" new experience (Remove "Tor is censored in my country")
- v2 onion services warningSponsor 9 - Phase 5 - Usability and Community Intervention on Support for Democracy and Human RightsGusGus2021-07-31https://gitlab.torproject.org/tpo/web/support/-/issues/160Research on discussion forum platforms for support.torproject.org2021-06-16T21:32:41ZGabagaba@torproject.orgResearch on discussion forum platforms for support.torproject.org@hiro this discussion is for this project in June. I'm assigning this issue to you mostly because you are working on a test of discourse but we will really work on this ticket in Q3.@hiro this discussion is for this project in June. I'm assigning this issue to you mostly because you are working on a test of discourse but we will really work on this ticket in Q3.Sponsor 9 - Phase 5 - Usability and Community Intervention on Support for Democracy and Human Rights2021-06-30https://gitlab.torproject.org/tpo/web/community/-/issues/183Release training new material focused on new use cases based on COVID-19 cont...2022-06-23T01:15:50ZGabagaba@torproject.orgRelease training new material focused on new use cases based on COVID-19 context in the community portal.Sponsor 9 - Phase 5 - Usability and Community Intervention on Support for Democracy and Human Rightshttps://gitlab.torproject.org/tpo/web/tpo/-/issues/149lektor portals: Titles should not be capitalized in the CSS2022-07-09T04:26:24Zemmapeellektor portals: Titles should not be capitalized in the CSSDifferent languages have different rules for capitalization. So we should not hardcode capitalize, lowercase or uppercase in the CSS.
We should propose the string in all caps to translate and let translators decide on how to write it on...Different languages have different rules for capitalization. So we should not hardcode capitalize, lowercase or uppercase in the CSS.
We should propose the string in all caps to translate and let translators decide on how to write it on their different languages.
For example, https://tb-manual.torproject.org/el/ should not capitalize the titles, as in Greek the accentuation rules are different if you write all in caps.
Also in French it does look weird, as for example the title `Comment les services oignon fonctionnent-ils ?' at https://lektor-staging.torproject.org/community/translations/fr/onion-services/overview/
thanks papassadrian for the report!Sponsor 9 - Phase 5 - Usability and Community Intervention on Support for Democracy and Human Rightshttps://gitlab.torproject.org/tpo/ux/research/-/issues/20Work on selected improvements to user experience on Tor Browser (desktop and ...2022-06-23T14:51:18ZGabagaba@torproject.orgWork on selected improvements to user experience on Tor Browser (desktop and mobile).Let's keep track here of improvements on UX for the Tor Browser that are part of the Sponsor 9 , Phase 5 project.Let's keep track here of improvements on UX for the Tor Browser that are part of the Sponsor 9 , Phase 5 project.Sponsor 9 - Phase 5 - Usability and Community Intervention on Support for Democracy and Human Rightsdonutsdonuts2022-06-30https://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40022Sbws should pin exits (or Single Onions) that have larger windows/congestion ...2022-07-06T08:29:04ZMike PerrySbws should pin exits (or Single Onions) that have larger windows/congestion controlSbws is not assigning stream ratios above ~2.2 to any relays right now. This means that it is not measuring any relays as faster than 2.2 times than the network average stream capacity. This is impacting spare capacity load balancing of ...Sbws is not assigning stream ratios above ~2.2 to any relays right now. This means that it is not measuring any relays as faster than 2.2 times than the network average stream capacity. This is impacting spare capacity load balancing of fast relays.
The reason for this is because of tor's current 1000 cell circuit window and 500 cell stream window. These windows impose a speed limit on sbws stream tests that is dependent on latency. It both means that we will currently measure relays with less latency to the sbws exit(s) as faster, as well as be unable to measure their full spare capacity.
If we run a custom exit with a larger congestion window and stream window, then we will be able to measure relays with more spare capacity than current. We could then pin sbws to use only that exit.
Longer term, we should pin sbws to only use exits that have upgraded to support https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/324-rtt-congestion-control.txtsbws: 1.5.x-finaljugajugahttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/29728Deprecate torflow2022-03-11T12:38:23ZjugaDeprecate torflowWhen we are happy with `sbws` as the bandwidth scanner implementation, we should add a line to Torflow README saying something like "Deprecated by sbws (url)".
We should also add that line to https://github.com/TheTorProject/bwscanner (t...When we are happy with `sbws` as the bandwidth scanner implementation, we should add a line to Torflow README saying something like "Deprecated by sbws (url)".
We should also add that line to https://github.com/TheTorProject/bwscanner (this repo might still be useful if/when `sbws` get refactored to use concurrency instead of multi-threading.
Maybe the git.tpo repository should be moved to `attic`.
Assigning to sbws component since we're not tracking torflowsbws: 1.4.x-finaljugajuga