The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-04-09T17:29:30Zhttps://gitlab.torproject.org/tpo/ux/design/-/issues/5[UX] text alignment for the header bar2021-04-09T17:29:30Zriyajawandhiya[UX] text alignment for the header bar**What is the user problem?**
When considering the text alignment for the header bar. Headers are often referred to as «Site Menus» and positioned as a key element of navigation in the website layout. Proper alignment in the designs wi...**What is the user problem?**
When considering the text alignment for the header bar. Headers are often referred to as «Site Menus» and positioned as a key element of navigation in the website layout. Proper alignment in the designs will make them visually more appealing and will also make it easier for users to scan over a page.
![image](/uploads/e66aff1e93f40ce96e4b01d781f086d0/image.png)
**Why is this important?**
Before downloading the application, people tend to visit the website to understand why they should prefer the new application, rather than their existing ones.
**Why does this satisfy?**
1. Looks uniform
2. Clean and self-explanatory
**Why will the community benefit from it?**
1. The user will feel comfortable and creates Connectivity
**How to measure design's effectiveness?**
[A/B testing](https://uxdesign.cc/7-steps-of-a-b-testing-what-how-cf3b209467fd) - A quick A/B with my acquaintances (who cover major sections of people using the internet) with a high-fidelity versionhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40328Man tor - Refactoring - Creation of a new `BANDWIDTH MANAGEMENT OPTIONS` section2023-04-03T16:43:38ZcypherpunksMan tor - Refactoring - Creation of a new `BANDWIDTH MANAGEMENT OPTIONS` sectionA total of 11 options (see the list below) should go in a new section named `BANDWIDTH MANAGEMENT OPTIONS`. This would reduce the amount of time spent scrolling around in the man tor page and make finding options more intuitive instead o...A total of 11 options (see the list below) should go in a new section named `BANDWIDTH MANAGEMENT OPTIONS`. This would reduce the amount of time spent scrolling around in the man tor page and make finding options more intuitive instead of having to remember the spreaded locations were bandwidth options are sometimes located.\\
We could also take this opportunity to change the location of the warning about how bandwidth-limiting options are managed. This warning is located at the end of the description of the option `BandwidthRate`. We could move the warning to the description of the newly created `BANDWIDTH MANAGEMENT OPTIONS` section, or at least, in the `THE CONFIGURATION FILE FORMAT` section.\\
Also, like it is said in description of the option `AccountingMax`:\
>>>
Note that (as also described in the Bandwidth section) Tor uses powers of two [...]
>>>
This "Bandwidth section" does not really exist, but now it will if this issue is approuved. The non-existing "Bandwidth section" seems to refer to the description of the option `BandwidthRate`.\\
I will make the neccessary changes in the man tor page and only show you the final result. You will just need to accept it or tell me what need more tweaking.\\
List of options that will need to move to the newly created one:\
>>>
GENERAL OPTIONS:\
- BandwidthBurst
- BandwidthRate
- CountPrivateBandwidth
- MaxAdvertisedBandwidth
- PerConnBWBurst
- PerConnBWRate
- RelayBandwidthBurst
- RelayBandwidthRate\
SERVER OPTIONS:\
- AccountingMax
- AccountingRule
- AccountingStart
>>>
The newly created section will look something like that:\
>>>
**BANDWIDTH MANAGEMENT OPTIONS**\
Description : The end of the description of the options `BandwidthRate` about size unit format.\\
- AccountingMax
- AccountingRule
- AccountingStart
- BandwidthBurst
- BandwidthRate
- CountPrivateBandwidth
- MaxAdvertisedBandwidth
- PerConnBWBurst
- PerConnBWRate
- RelayBandwidthBurst
- RelayBandwidthRate
>>>\
On an unrelated note to this issue:\
I try to use the functionalities of `GitLab Flavord Markdown` in my previous 2 issues, but that did not really goes has I expected, so sorry for the ugly formating of all my previous issues. I'm learning. I hope this issue look a bit better :)https://gitlab.torproject.org/tpo/core/tor/-/issues/40324tor cli "-f" option is the only one who doesn't have a long format name2021-04-24T18:33:11Zcypherpunkstor cli "-f" option is the only one who doesn't have a long format nameThe tor CLI argument "-f" is the only option which does not have a long format name. Adding a long format name would clear out confusion of the "-f" option generally meaning "--force" and make everything more readable and more intuitive ...The tor CLI argument "-f" is the only option which does not have a long format name. Adding a long format name would clear out confusion of the "-f" option generally meaning "--force" and make everything more readable and more intuitive to learn and remember.
His long format name should at least be "--file" or preverably "--config-file", because the "-f" option is only for configuration file, so it kinda make sense to call it that way.https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/96setup CI caching (and dependency proxy?)2022-03-24T23:28:18Zjugasetup CI caching (and dependency proxy?)I'm used to configure a cache in `gitlab-ci.org`, but maybe tpo isn't configured for [that](https://docs.gitlab.com/ee/ci/caching/#where-the-caches-are-stored)?
The message i get in the pipeline job:
```
Creating cache default...
.cac...I'm used to configure a cache in `gitlab-ci.org`, but maybe tpo isn't configured for [that](https://docs.gitlab.com/ee/ci/caching/#where-the-caches-are-stored)?
The message i get in the pipeline job:
```
Creating cache default...
.cache/pip: found 417 matching files and directories
No URL provided, cache will be not uploaded to shared cache server. Cache will be stored only locally.
```https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40009Use tearDown() in unit tests to clean up all created files2022-10-04T17:30:27ZCecylia BocovichUse tearDown() in unit tests to clean up all created filesRight now we're manually removing the files we create, but we don't manage to find and remove all of them. It would be better to have a more thorough cleanup after tests.
@atagar pointed out the use of the tearDown function in https://g...Right now we're manually removing the files we create, but we don't manage to find and remove all of them. It would be better to have a more thorough cleanup after tests.
@atagar pointed out the use of the tearDown function in https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/merge_requests/13#note_272732155abhilash55abhilashhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40299Compiling src/test/test-test_addr.o consumes lots of memory2021-04-05T12:54:18ZerCompiling src/test/test-test_addr.o consumes lots of memoryRunning my tor relay on raspberry with 512 megs of memory. Os is raspbian stretch. Running tor consumes around 35-50 percent of memory according to the top.
Whenever new tor is announced, I fetch it and compile it on the same machine, w...Running my tor relay on raspberry with 512 megs of memory. Os is raspbian stretch. Running tor consumes around 35-50 percent of memory according to the top.
Whenever new tor is announced, I fetch it and compile it on the same machine, while older tor version runs. Used to be no problem with that. But latest x releases, I end up with build error message and usually dead running-tor also. It always happens in the same point in build process: compiling test-test_addr.o.
If it absolutely positively has to consume lots of memory, ok. But maybe its a mistake that can be fixed.
End of build process below, latest 4.5.6. When it happened, previous tor, running on the same machine, was also trying to allocate some memory and died.
```
...
CC src/test/test-log_test_helpers.o
CC src/test/test-hs_test_helpers.o
CC src/test/test-opts_test_helpers.o
CC src/test/test-rend_test_helpers.o
CC src/test/test-resolve_test_helpers.o
CC src/test/test-rng_test_helpers.o
CC src/test/test-test.o
CC src/test/test-test_accounting.o
CC src/test/test-test_addr.o
cc1: out of memory allocating 6837600 bytes after a total of 42938368 bytes
Makefile:20143: recipe for target 'src/test/test-test_addr.o' failed
make[1]: *** [src/test/test-test_addr.o] Error 1
make[1]: Leaving directory '/home/debian-tor/tor-0.4.5.6'
Makefile:7342: recipe for target 'all' failed
make: *** [all] Error 2
```
At this point, I usually kill running tor, if its not dead already and just finish build process, which now has plenty of free memory and gets its job done.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40007Clean up unused bridgedb mock2021-12-16T11:56:42ZCecylia BocovichClean up unused bridgedb mock`bridgedb mock` was an old utility for generating mock bridgedb descriptors for tests. This functionality has been replaced with the new `./scripts/create_descriptors`. It's also currently broken. Rather than fixing it, it would be bette...`bridgedb mock` was an old utility for generating mock bridgedb descriptors for tests. This functionality has been replaced with the new `./scripts/create_descriptors`. It's also currently broken. Rather than fixing it, it would be better to just remove it all-together.55abhilash55abhilashhttps://gitlab.torproject.org/tpo/web/support/-/issues/162Glossary entry seems incomplete2022-07-01T04:42:25Zc1e0Glossary entry seems incompleteThe definition for [onion services](https://support.torproject.org/glossary/onion-services/) says:
> Onion services (formerly known as “hidden services”) are services (like websites) that are only accessible through the Tor network. Oni...The definition for [onion services](https://support.torproject.org/glossary/onion-services/) says:
> Onion services (formerly known as “hidden services”) are services (like websites) that are only accessible through the Tor network. Onion services offer advantages over ordinary services on the non-private web, including:
I believe there should be more sentences after the "including" word?https://gitlab.torproject.org/tpo/web/support/-/issues/158Move entry "A website I am trying to reach is blocking access over Tor" to ot...2021-06-30T12:23:09ZGusMove entry "A website I am trying to reach is blocking access over Tor" to other sectionAs GK correctly pointed here https://gitlab.torproject.org/tpo/community/support/-/issues/40013#note_2724095 we should move [this entry](https://support.torproject.org/censorship/censorship-2/) to other section. We could move to the Tor ...As GK correctly pointed here https://gitlab.torproject.org/tpo/community/support/-/issues/40013#note_2724095 we should move [this entry](https://support.torproject.org/censorship/censorship-2/) to other section. We could move to the Tor Browser or Misc section.
Related: https://gitlab.torproject.org/tpo/web/support/-/issues/99Anushka JainAnushka Jainhttps://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/90Building Docker images with Gitlab CI may require User Namespace support2023-09-29T01:13:35ZAlexander Færøyahf@torproject.orgBuilding Docker images with Gitlab CI may require User Namespace supportI tried to use `buildah` to build some Docker images for the network team to use for our CI with the Gitlab CI runner.
It looks like the build jobs fails because we don't have User Namespace support. See: https://gitlab.torproject.org/t...I tried to use `buildah` to build some Docker images for the network team to use for our CI with the Gitlab CI runner.
It looks like the build jobs fails because we don't have User Namespace support. See: https://gitlab.torproject.org/tpo/core/tor-ci-support/-/jobs/9686Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/network-health/doctor/-/issues/40018Fix up list() usage after Python 3 port2023-10-04T13:55:22ZGeorg KoppenFix up list() usage after Python 3 port@atagar pointed rightly out that I was lazy in 5360a2131d3189e82e02d73a9c840e96dcd85a4c as not all `list()` changes need to be made. We should clean that up by having a closer look at when it is actually needed and when not.@atagar pointed rightly out that I was lazy in 5360a2131d3189e82e02d73a9c840e96dcd85a4c as not all `list()` changes need to be made. We should clean that up by having a closer look at when it is actually needed and when not.https://gitlab.torproject.org/tpo/network-health/doctor/-/issues/40017Doctor incorrectly reports clock skew2022-09-07T07:01:44ZRoger DingledineDoctor incorrectly reports clock skewOn the consensus-health mails, we're getting lines like this:
```
NOTICE: The system clock of moria1 is 48 seconds off
NOTICE: The system clock of dizum is 70 seconds off
NOTICE: The system clock of Faravahar is 37 seconds off
NOTICE: Th...On the consensus-health mails, we're getting lines like this:
```
NOTICE: The system clock of moria1 is 48 seconds off
NOTICE: The system clock of dizum is 70 seconds off
NOTICE: The system clock of Faravahar is 37 seconds off
NOTICE: The system clock of longclaw is 41 seconds off
```
But I believe the clocks on these systems are fine.
What I assume is happening is that DocTor is launching a directory fetch for an object like the consensus, and it's taking 48 seconds to finish retrieving the answer, and then DocTor looks at the Date header in the resulting http response, notices that it is from 48 seconds ago, and reports a clock problem.
Here is an improved algorithm: remember when we started the request, and when we finished it, and if the Date header is anywhere within that range, there is nothing to report.
We could instead consider making additional tiny requests where we expect the answer to come back quickly, but I think that might be overkill at this stage.https://gitlab.torproject.org/tpo/anti-censorship/emma/-/issues/6Maybe try more than once if a connection timed out?2021-02-07T21:57:09ZPhilipp Winterphw@torproject.orgMaybe try more than once if a connection timed out?I tried to make sense of recent emma runs in Uganda (see tpo/community/outreach#40007) and noticed that it's difficult to tell if a connection failed because of reliability issues or because of censorship. Emma currently tries once to [e...I tried to make sense of recent emma runs in Uganda (see tpo/community/outreach#40007) and noticed that it's difficult to tell if a connection failed because of reliability issues or because of censorship. Emma currently tries once to [establish a TCP connection](https://gitlab.torproject.org/tpo/anti-censorship/emma/-/blob/2ed24be87ec7b6988ebc3c3723e53a2f7f17f89d/tests.go#L36) to a target and if that fails, it labels the target as unreachable. It's up to the operating system to determine the number of TCP retransmissions. Let's teach emma to try more than once to establish a TCP connection to a target. This will increase the test time a little bit but I think the improved clarity is worth the additional wait time.https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/14Listing microseconds in bridgestrap status output is confusing2021-06-10T14:16:52ZRoger DingledineListing microseconds in bridgestrap status output is confusing(This ticket is just a simple UX improvement, but hopefully still a useful one :) I've tagged it as 'First Contribution' since it's a good opportunity for somebody to get some experience making a git commit etc.)
Compare the current out...(This ticket is just a simple UX improvement, but hopefully still a useful one :) I've tagged it as 'First Contribution' since it's a good opportunity for somebody to get some experience making a git commit etc.)
Compare the current output format:
```
* obfs4: dysfunctional
Error: timed out waiting for bridge descriptor
Last tested: 2021-01-17 10:38:22.671859857 +0000 UTC (8h41m42.941665234s ago)
```
to this simpler alternative:
```
* obfs4: dysfunctional
Error: timed out waiting for bridge descriptor
Last tested: 2021-01-17 10:38:22 +0000 UTC (8h41m42s ago)
```
At present, having so much precision in the fraction of the seconds draws the reader's eye to that number, and that number is the least important part of the output.
Thanks!https://gitlab.torproject.org/tpo/web/lego/-/issues/21Add Privchat to footer?2021-08-31T13:25:14ZdonutsAdd Privchat to footer?There doesn't seem to be a way to navigate to the [Privchat landing page](https://www.torproject.org/privchat/) via the site menus. Adding a link to the footer seems like a sensible solution.There doesn't seem to be a way to navigate to the [Privchat landing page](https://www.torproject.org/privchat/) via the site menus. Adding a link to the footer seems like a sensible solution.https://gitlab.torproject.org/tpo/web/support/-/issues/157Missing dot at the end2021-01-07T14:32:28ZGusMissing dot at the end"You can also access the New Circuit option inside the site information menu in the URL bar, and the New Identity option by
clicking the small sparky broom icon at the top-right of the screen"
https://support.torproject.org/tbb/tbb-29/"You can also access the New Circuit option inside the site information menu in the URL bar, and the New Identity option by
clicking the small sparky broom icon at the top-right of the screen"
https://support.torproject.org/tbb/tbb-29/https://gitlab.torproject.org/tpo/web/support/-/issues/156Update how to manage bookmarks2021-04-06T09:55:13ZGusUpdate how to manage bookmarksAfter TB 10, these instructions need to be updated:
https://support.torproject.org/tbb/export-and-import-bookmarks/After TB 10, these instructions need to be updated:
https://support.torproject.org/tbb/export-and-import-bookmarks/https://gitlab.torproject.org/tpo/core/tor/-/issues/40232"Closing no-longer-configured OR listener" does not put brackets around IPv6 ...2021-07-09T17:22:52ZNeel Chauhanneel@neelc.org"Closing no-longer-configured OR listener" does not put brackets around IPv6 addressesWhen I was setting `IPv4Only` on a new Tor relay with broken IPv6, and did `killall -HUP tor`, I got this:
Dec 23 20:08:02.000 [notice] Closing no-longer-configured OR listener on :::143
(I believe) the `:::143` should be `[::]:143`.When I was setting `IPv4Only` on a new Tor relay with broken IPv6, and did `killall -HUP tor`, I got this:
Dec 23 20:08:02.000 [notice] Closing no-longer-configured OR listener on :::143
(I believe) the `:::143` should be `[::]:143`.https://gitlab.torproject.org/tpo/anti-censorship/emma/-/issues/5Incorporate emma into OONI2024-02-29T15:21:09ZPhilipp Winterphw@torproject.orgIncorporate emma into OONIMaria once suggested adding emma to OONI. Both are written in Go, so it may not be a terribly complex endeavour. I'll have a chat with Simone to get a better sense of what this would entail.
The big benefit of having emma in OONI is th...Maria once suggested adding emma to OONI. Both are written in Go, so it may not be a terribly complex endeavour. I'll have a chat with Simone to get a better sense of what this would entail.
The big benefit of having emma in OONI is that we would get significantly more measurements and we no longer need to expect users to be able to compile programs.https://gitlab.torproject.org/tpo/anti-censorship/monit-configuration/-/issues/6Add "end-to-end" test that talks to moat2022-03-01T17:56:58ZPhilipp Winterphw@torproject.orgAdd "end-to-end" test that talks to moatTo catch issues like the one in tpo/anti-censorship/pluggable-transports/meek#40001 early, we could add a new monit test that talks to moat over obfs4proxy. Basically, we would spawn a tor instance and let it bootstrap over meek. We then...To catch issues like the one in tpo/anti-censorship/pluggable-transports/meek#40001 early, we could add a new monit test that talks to moat over obfs4proxy. Basically, we would spawn a tor instance and let it bootstrap over meek. We then try to talk to moat and return with exit code 0 if this succeeded.
The challenge is that we should use the same tor and obfs4proxy version as Tor Browser does. And even then, there is no guarantee that we're catching all possible problems – for example, an issue may be limited to Windows. Still, having a test like this would probably go a long way.
(We discussed this topic in [today's anti-censorship meeting](http://meetbot.debian.net/tor-meeting/2020/tor-meeting.2020-12-17-15.57.html)).