The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-07-07T00:47:11Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40520module thinko in src/lib/crypt_ops/crypto_rand.c2022-07-07T00:47:11Ztoralfmodule thinko in src/lib/crypt_ops/crypto_rand.c### Summary
I do wonder if
- "modulo 5" should be "modulo 8"
- the bits -> bytes calculation have to made afterwards
- the goal is to calculate the amount of bytes needed for N base32 characters then even the "+7" is wrong
```patch
ind...### Summary
I do wonder if
- "modulo 5" should be "modulo 8"
- the bits -> bytes calculation have to made afterwards
- the goal is to calculate the amount of bytes needed for N base32 characters then even the "+7" is wrong
```patch
index 5bf3a65b3b..90a755537c 100644
--- a/src/lib/crypt_ops/crypto_rand.c
+++ b/src/lib/crypt_ops/crypto_rand.c
@@ -568,9 +568,10 @@ crypto_random_hostname(int min_rand_len, int max_rand_len, const char *prefix,
prefixlen = strlen(prefix);
resultlen = prefixlen + strlen(suffix) + randlen + 16;
- rand_bytes_len = ((randlen*5)+7)/8;
- if (rand_bytes_len % 5)
- rand_bytes_len += 5 - (rand_bytes_len%5);
+ rand_bytes_len = randlen*5;
+ if (rand_bytes_len % 8)
+ rand_bytes_len += 8 - (rand_bytes_len%8);
+ rand_bytes_len /= 8;
rand_bytes = tor_malloc(rand_bytes_len);
crypto_rand(rand_bytes, rand_bytes_len);
```
Or?Tor: 0.4.7.x-stablehttps://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-finaljugajugahttps://gitlab.torproject.org/tpo/web/community/-/issues/127Please include licensing information in outreach materials2022-07-01T04:05:23ZAntonelaantonela@torproject.orgPlease include licensing information in outreach materialsOutreach materials (found at either the tor_outreach_md or tor_outreach_md_completed branches of the "translation" git repo) lack licensing information, either as part of the Markdown files or as a standalone file in the directory.
This ...Outreach materials (found at either the tor_outreach_md or tor_outreach_md_completed branches of the "translation" git repo) lack licensing information, either as part of the Markdown files or as a standalone file in the directory.
This makes redistributing or modifying them not legally sound!
So, please specify the licensing information for the outreach materials, so they can be shared and derived!
https://trac.torproject.org/projects/tor/ticket/30690Sponsor 9 - Phase 5 - Usability and Community Intervention on Support for Democracy and Human Rightshttps://gitlab.torproject.org/tpo/core/arti/-/issues/541In our docs, annotate more items with which features they depend on?2022-08-24T18:50:44ZNick MathewsonIn our docs, annotate more items with which features they depend on?Have a look at https://tpo.pages.torproject.net/core/doc/rust/arti/index.html : the documentation we build there lists all of our members, including those that depend on `experimental-api`. There is no documentation saying what function...Have a look at https://tpo.pages.torproject.net/core/doc/rust/arti/index.html : the documentation we build there lists all of our members, including those that depend on `experimental-api`. There is no documentation saying what functions they are!
Possible actions are:
* Change our script at https://gitlab.torproject.org/tpo/core/doc/-/blob/main/scripts/gen-api-doc.bash to run with different flags. Maybe `--features=full` instead of `--all-features`?
* Do some magic to make relevant items get documented with "Depends on an `experimental-api` feature" whenever they are generated?Arti 1.0.0: Ready for production usehttps://gitlab.torproject.org/tpo/core/arti/-/issues/538Decide whether to increment MSRV for Arti 1.0.02022-11-05T13:19:42ZNick MathewsonDecide whether to increment MSRV for Arti 1.0.0When we release, we will have an opportunity to increase our MSRV as high as 1.59, if we want.
Is there a reason to do so? The only other tickets we have that say "do such-and-such once we require Rust X" are labeled with ~"MSRV:1.60"....When we release, we will have an opportunity to increase our MSRV as high as 1.59, if we want.
Is there a reason to do so? The only other tickets we have that say "do such-and-such once we require Rust X" are labeled with ~"MSRV:1.60". So the only reason to do this would be for access to recent language and stdlib features.
The most relevant such features are, FWICT:
* Support for "Captured identifiers in format strings", as in `println!("Hello, {person}!")`. We run into this a lot by accident, and it seems to be a leading breaker of our minimal-version CI.
* "Custom cargo profiles", as in "Production" is based on "release", but with lto turned on.
IMO these features are not enough to justify an MSRV bump right now, but I thought I should ask.
@eta, @diziet, does either of you think we should bump MSRV? If not, I'll close this.Arti 1.0.0: Ready for production useNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/arti/-/issues/489config "download_*" should probably become download.*2022-08-03T14:28:57ZIan Jacksoniwj@torproject.orgconfig "download_*" should probably become download.*We now have `download_schedule` and `download_tolerance`. I think these should be a sub-structure `DownloadConfig`, or perhaps something with the word "directory" in somehow.
This is part of #458. Noticed while pursuing "test that ex...We now have `download_schedule` and `download_tolerance`. I think these should be a sub-structure `DownloadConfig`, or perhaps something with the word "directory" in somehow.
This is part of #458. Noticed while pursuing "test that example config is exhaustive", part of #457.Arti 1.0.0: Ready for production useIan Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/331Be "at least as secure" as Tor (as a client)2022-08-23T17:11:36ZNick MathewsonBe "at least as secure" as Tor (as a client)This is a fairly open-ended ticket; it is a requirement for %"Arti 1.0.0: Ready for production use", but we need to decide what exactly it comprises.
Some likely candidates to include are:
* SafeLogging (#189)
* Zeroizing keys (#...This is a fairly open-ended ticket; it is a requirement for %"Arti 1.0.0: Ready for production use", but we need to decide what exactly it comprises.
Some likely candidates to include are:
* SafeLogging (#189)
* Zeroizing keys (#254)
* Circuit isolation code (#150)
* File permission checking (#315)
* Setting per-process flags and dropping permissions as in C tor's `winprocess_sys.c`, `restrict.c`, `setuid.h` (#364)
* Netflow padding (#62)
Some things not necessarily to include (now) are:
* seccomp2 sandboxing (huge kludge, less necessary in Rust)
* memory-DoS resistance (waits for %"Arti 1.2.0: Onion service support" )
* hardened PRNG (current prng is "good enough")Arti 1.0.0: Ready for production usehttps://gitlab.torproject.org/tpo/core/arti/-/issues/330Make sure high-level APIs are stable and sensible.2022-08-03T14:45:38ZNick MathewsonMake sure high-level APIs are stable and sensible.We've done a lot of this in %"Arti 0.1.0 release: Okay for experimental embedding" , but for 1.0.0, we should see if there are any _missing_ APIs that embedders need badly, and provide them.
We could try to find out what APIs these ar...We've done a lot of this in %"Arti 0.1.0 release: Okay for experimental embedding" , but for 1.0.0, we should see if there are any _missing_ APIs that embedders need badly, and provide them.
We could try to find out what APIs these are by surveying existing and prospective embedders. We should collect feedback, and act upon it. The ~"User Feedback" ticket can be used for that.
This ticket comes from a Roadmap item, "Sensible stable API". It is more or less a placeholder for whatever work we do underneath it.Arti 1.0.0: Ready for production use