The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-03-01T18:42:07Zhttps://gitlab.torproject.org/tpo/web/newsletter/-/issues/15Links in the RSS feed need to have absolute paths2022-03-01T18:42:07Zchampionquizzerchampionquizzer@torproject.orgLinks in the RSS feed need to have absolute pathsA user on `#tor-www` IRC channel reported:
"https://newsletter.torproject.org/rss/ contains relative URLs (they start with ./), but RSS requires absolute/full URLs (e.g. https://newsletter.torproject.org/etc.). It causes feed readers t...A user on `#tor-www` IRC channel reported:
"https://newsletter.torproject.org/rss/ contains relative URLs (they start with ./), but RSS requires absolute/full URLs (e.g. https://newsletter.torproject.org/etc.). It causes feed readers to fail to open the links in the feed. See: https://validator.w3.org/feed/check.cgi?url=https%3A%2F%2Fnewsletter.torproject.org%2Frss%2F"
Thanks for reporting!https://gitlab.torproject.org/tpo/web/support/-/issues/170Update screenshots to remove (i) Site information icon from the URL bar2021-04-07T14:26:33Zchampionquizzerchampionquizzer@torproject.orgUpdate screenshots to remove (i) Site information icon from the URL barWith Tor Browser 10 (the current series of Tor Browser releases), the (i) Site information icon was removed from the URL bar. We need to update the screenshots in the [Support](https://support.torproject.org/) portal accordingly. I found...With Tor Browser 10 (the current series of Tor Browser releases), the (i) Site information icon was removed from the URL bar. We need to update the screenshots in the [Support](https://support.torproject.org/) portal accordingly. I found two instances of outdated screengrabs:
1) https://support.torproject.org/tbb/tbb-29/
2) https://support.torproject.org/onionservices/onionservices-2/Sehrish AslamSehrish Aslamhttps://gitlab.torproject.org/tpo/web/community/-/issues/193Past GSOC projects don't appear, but there is an empty section for them.2023-04-22T07:32:26ZemmapeelPast GSOC projects don't appear, but there is an empty section for them.at the bottom of https://community.torproject.org/gsoc/ there is a section only consisting of:
Past Projects
Here are some successful projects which have been implemented in the past by Google Summer of Code and Outreachy participants
...at the bottom of https://community.torproject.org/gsoc/ there is a section only consisting of:
Past Projects
Here are some successful projects which have been implemented in the past by Google Summer of Code and Outreachy participants
But the past projects are not there anymore.https://gitlab.torproject.org/tpo/web/community/-/issues/192Create a link anchor to "Featured .onion sites" section2021-03-30T13:47:44ZGusCreate a link anchor to "Featured .onion sites" sectionWe have some featured onion sites on the onion services page, and we want to have a link anchor to that section:
https://community.torproject.org/onion-services/We have some featured onion sites on the onion services page, and we want to have a link anchor to that section:
https://community.torproject.org/onion-services/himandrisharma27himandrisharma27https://gitlab.torproject.org/tpo/web/community/-/issues/191Good Bad ISP - Remove Contabo2021-03-30T14:11:00ZGusGood Bad ISP - Remove ContaboHello,
Please remove Contabo from the list of good ISPs that support the operation of a TOR Exit node, their ToS have been altered:
https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs
https://contabo.com/agb.html:
(5) The Pr...Hello,
Please remove Contabo from the list of good ISPs that support the operation of a TOR Exit node, their ToS have been altered:
https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs
https://contabo.com/agb.html:
(5) The Provider reserves the right to immediately suspend of any server or webspace package on which any kind of proxy service, such as VPN or TOR, is operated, for which the Provider has knowledge of abuse or fraudulent or unlawful use.
Thank you!https://gitlab.torproject.org/tpo/web/community/-/issues/188[content][types of relays] Mentions to unexisting section are confusing2022-01-20T19:12:23Zemmapeel[content][types of relays] Mentions to unexisting section are confusingIn the page https://community.torproject.org/relay/types-of-relays/ , in the Exit relay section, we mention the 'legal considerations section' twice.
One is linked to https://community.torproject.org/relay/community-resources , but the ...In the page https://community.torproject.org/relay/types-of-relays/ , in the Exit relay section, we mention the 'legal considerations section' twice.
One is linked to https://community.torproject.org/relay/community-resources , but the other is unlinked, and there are no sections called 'legal considerations'.
> Exit relays have the greatest legal exposure and liability of all the relays. For example, if a user downloads copyrighted material while using your exit relay, you, the operator may receive a DMCA notice. Any abuse complaints about the exit will go directly to you (via your hoster, depending on the WHOIS records). Generally, most complaints can be handled pretty easily through template letters, which we'll discuss further in the **legal considerations section**.
> Because of the legal exposure that comes with running an exit relay, you should not run a Tor exit relay from your home. Ideal exit relay operators are affiliated with some institution, like a university, a library, a hackerspace or a privacy related organization. An institution can not only provide greater bandwidth for the exit, but is better positioned to handle abuse complaints or the rare law enforcement inquiry.
> If you are considering running an exit relay, please read the **section on legal considerations** for exit relay operators.
We should rephrase, mention the current name of the section, and also add a link where there is none.https://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/40333`ServerTransportPlugin` option exit cleanly with exit code `-1`, but with no ...2024-03-05T15:39:31Zcypherpunks`ServerTransportPlugin` option exit cleanly with exit code `-1`, but with no user-friendly log warning when the argument `path-to-binary` is invalidIf we add in `/etc/tor/torrc` the line `ServerTransportPlugin obfs4 exec /path/that/does/not/exist`, have log minimum severity to `info` and execute the command `sudo systemctl reload tor`, we can clearly see in the following log extract...If we add in `/etc/tor/torrc` the line `ServerTransportPlugin obfs4 exec /path/that/does/not/exist`, have log minimum severity to `info` and execute the command `sudo systemctl reload tor`, we can clearly see in the following log extract, that the `path-to-binary` argument is improperly or not at all validated before executing it :
~~~
`XXX 00 00:00:00.001 [notice] Tor 0.4.5.6 opening new log file.` \
`[...]` \
`XXX 00 00:00:00.002 [info] process_exec(): Starting new process: /path/that/does/not/exist` \
`XXX 00 00:00:00.020 [info] launch_managed_proxy(): Managed proxy at \'/path/that/does/not/exist\' has spawned with PID \'XXXXX\'. ` \
`[...]` \
`XXX 00 00:00:00.300 [info] notify_waitpid_callback_by_pid(): Child process XXXXX has exited; running callback.` \
`XXX 00 00:00:00.300 [warn] Pluggable Transport process terminated with status code 256` \
`[...]` \
~~~
A relay operator who do no pay enough attentions while reading logs and have log minimum severity of `notice` will only see :
> `XXX 00 00:00:00.300 [warn] Pluggable Transport process terminated with status code 256`
We should definitely have a user-friendly log message to notify the operator that there is a problem with is configuration file.
The file `tor-0.4.5.6/app/config/config.c`, at the fonction `pt_parse_transport_line()`, in the `else` statement between line 5377 and 5421 look a promising place to validate the `path-to-binary`.
There is already a test for this case of non-existent executable, at `tor-0.4.5.6/src/test/test_process_slow.c`, `test_nonexistent_executable()`, starting at line 331.Tor: 0.4.9.x-freezeAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://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/applications/tor-browser/-/issues/40316Patch GeckoView's ConnectivityManager usage2022-11-30T15:19:48ZMatthew FinkelPatch GeckoView's ConnectivityManager usageGeckoView uses the connectivity manager for detecting the currently used [type of network connection](https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/tor-browser-86.0b1-10.5-1/mobile/android/geckoview/src/main/java/org/...GeckoView uses the connectivity manager for detecting the currently used [type of network connection](https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/tor-browser-86.0b1-10.5-1/mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoAppShell.java#L1170) (WIFI, 2G, 3G, 4G, etc). I didn't dig into the code, but it looks like some gecko behavior changes depending on the link type. Along with removing the `WIFI_STATE` Android permission, we should make sure this isn't [leaking any info into content](https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/tor-browser-86.0b1-10.5-1/dom/html/HTMLMediaElement.cpp#L2914), and we should probably just always return `LINK_TYPE_UNKNOWN`.Tor Browser: 11.0 Issues with previous releasehttps://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.