The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:09:48Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1101getinfo config-file doesn't handle relative paths well2020-06-27T14:09:48ZRoger Dingledinegetinfo config-file doesn't handle relative paths wellHere's how getinfo config-file is supposed to go:
getinfo config-file
250-config-file=/usr/local/etc/tor/torrc
250 OK
But I started my tor like "path/to/tor -f moria2-orrc", so getinfo
config-file simply returns "moria2-orrc" with no h...Here's how getinfo config-file is supposed to go:
getinfo config-file
250-config-file=/usr/local/etc/tor/torrc
250 OK
But I started my tor like "path/to/tor -f moria2-orrc", so getinfo
config-file simply returns "moria2-orrc" with no hint about where
it is. That means controllers like arm don't know where to look.
Should we change Tor so it prepends an absolute path when answering
the controller?
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1042rate-limit MaxOnionsPending warns2020-06-27T14:09:51ZRoger Dingledinerate-limit MaxOnionsPending warnsIf your cpu can't keep up with the number of create cells you get, you'll
fill your logs with warnings:
if (ol_length >= get_options()->MaxOnionsPending) {
log_warn(LD_GENERAL,
"Your computer is too slow to handle thi...If your cpu can't keep up with the number of create cells you get, you'll
fill your logs with warnings:
if (ol_length >= get_options()->MaxOnionsPending) {
log_warn(LD_GENERAL,
"Your computer is too slow to handle this many circuit "
"creation requests! Please consider using the "
"MaxAdvertisedBandwidth config option or choosing a more "
"restricted exit policy.");
We should make the warning only happen once a minute or something.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/968Directory authority in private Tor network doesn't publish consensus2020-06-27T14:09:57ZKarsten LoesingDirectory authority in private Tor network doesn't publish consensusUnder certain circumstances a single directory authority in a private Tor
network does not manage to publish a consensus. For some reason the
directory adds itself to the list of trusted directory authorities *twice*.
The result is that ...Under certain circumstances a single directory authority in a private Tor
network does not manage to publish a consensus. For some reason the
directory adds itself to the list of trusted directory authorities *twice*.
The result is that it thinks there are 2 directories and that a single
vote is not enough to publish a consensus.
The directory triggers the following warning:
Index: src/or/routerlist.c
===================================================================
--- src/or/routerlist.c (revision 19258)
+++ src/or/routerlist.c (working copy)
@@ -3706,6 +3706,18 @@
hostname = tor_strdup(address);
}
+ SMARTLIST_FOREACH(trusted_dir_servers, trusted_dir_server_t *, ent, {
+ if (ent->v3_identity_digest &&
+ !memcmp(v3_auth_digest, ent->v3_identity_digest, DIGEST_LEN))
+ log_warn(LD_CONFIG, "We already have a directory with the same "
+ "v3 identity digest %s, address %s, OR port %d, and Dir port %d. "
+ "Now we try to add one with address %s, OR port %d, and Dir port %d. "
+ "Something is wrong here!",
+ hex_str(ent->v3_identity_digest, DIGEST_LEN),
+ ent->address, ent->or_port, ent->dir_port,
+ hostname, or_port, dir_port);
+ });
+
ent = tor_malloc_zero(sizeof(trusted_dir_server_t));
ent->nickname = nickname ? tor_strdup(nickname) : NULL;
ent->address = hostname;
A workaround is to add a return statement to that loop. But it would be
better to find out why the directory adds itself to the list twice.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.3.x-finalSebastian HahnSebastian Hahnhttps://gitlab.torproject.org/tpo/core/tor/-/issues/965Redo DNS tests when exit policy changes from reject *; avoid when policy chan...2020-06-27T14:09:58ZSebastian HahnRedo DNS tests when exit policy changes from reject *; avoid when policy changes to reject *> hm. I published my descriptor before doing DNS tests. Also, I'm rejecting all exit
traffic, and still do DNS tests. Isn't that supposed to be different?
<armadev> i've had a todo item for nick to not do dns tests if reject *:*. he didn...> hm. I published my descriptor before doing DNS tests. Also, I'm rejecting all exit
traffic, and still do DNS tests. Isn't that supposed to be different?
<armadev> i've had a todo item for nick to not do dns tests if reject *:*. he didn't
want to put it in, though.
<armadev> i think that you would need to remember whether you did them, and if
not launch them, if exit policy changes from reject * to something else
> Can't we just redo them every time exit policy changes from reject to something?
<armadev> fine by me. open a flyspray, due 0.2.2.x?
> (in theory, we should probably redo them when the IP changes. This could mean
Laptop user in a new environment)
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/961TotalTraffic option (upload+download)2020-06-27T14:09:58ZTracTotalTraffic option (upload+download)Could a TotalTraffic option similar to AccountingMax be added?
I know, it isn't to hard to divide by two, but you usually need
to limit the sum of upload and download to not exceed your
traffic limit.
Maybe the description of Accounting...Could a TotalTraffic option similar to AccountingMax be added?
I know, it isn't to hard to divide by two, but you usually need
to limit the sum of upload and download to not exceed your
traffic limit.
Maybe the description of AccountingMax should also be changed to
make it clear, if one, either upstream traffic or downstream
traffic exceeds the limit Tor will hibernate.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: AthabaTor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/928With BridgeRelay 1 and ORPort 0, things go bad2020-06-27T14:10:00ZRoger DingledineWith BridgeRelay 1 and ORPort 0, things go badA while ago Vidalia set my BridgeRelay to 1 but left my ORPort off. This
caused my Tor to make all sorts of weird decisions about what it would
contact, what it would fetch, etc. After a while my Tor became useless
because it didn't have...A while ago Vidalia set my BridgeRelay to 1 but left my ORPort off. This
caused my Tor to make all sorts of weird decisions about what it would
contact, what it would fetch, etc. After a while my Tor became useless
because it didn't have enough descriptors to make a circuit, and it didn't
care to get any more.
We fixed the Vidalia bug (I think), but if a user sets their config this
way they will end up sad. We should explore why this is, and tighten up
the checks inside Tor.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/919If you hup tor while it's hibernating, it rebinds its ports2020-06-27T14:10:01ZRoger DingledineIf you hup tor while it's hibernating, it rebinds its portsIt looks like retry_listeners() and retry_all_listeners() do not care
whether we're hibernating. In main.c, retry-all-listeners is only called if
if (!we_are_hibernating() && time_to_check_listeners < now) {
whereas in config.c it do...It looks like retry_listeners() and retry_all_listeners() do not care
whether we're hibernating. In main.c, retry-all-listeners is only called if
if (!we_are_hibernating() && time_to_check_listeners < now) {
whereas in config.c it does not check if we_are_hibernating. Sounds like that's
the place to fix it.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/584Clients process descriptor fetches as they arrive?2020-07-24T12:17:47ZRoger DingledineClients process descriptor fetches as they arrive?While we're fetching descriptors in a directory request, wouldn't it
be nice if we could parse and make use of the ones that are sitting
on the buffer?
This would let us bootstrap quicker, and be especially relevant once
we use the fall...While we're fetching descriptors in a directory request, wouldn't it
be nice if we could parse and make use of the ones that are sitting
on the buffer?
This would let us bootstrap quicker, and be especially relevant once
we use the fallback consensus and start using slow dir caches to
bootstrap.
It will also avoid the 250K blobs sitting in ram.
This might be destabilizing enough that it should wait til 0.2.1.x. Not sure.
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/tpo/web/community/-/issues/341[Featured Onions] Add Amnesty International onionsite2024-03-06T17:41:16ZGus[Featured Onions] Add Amnesty International onionsiteLet's add Amnesty International onionsite to our curated list: https://community.torproject.org/onion-services/#featured-onions
"Amnesty International has today launched its global website as an .onion site on the Tor network, giving us...Let's add Amnesty International onionsite to our curated list: https://community.torproject.org/onion-services/#featured-onions
"Amnesty International has today launched its global website as an .onion site on the Tor network, giving users greater access to its ground-breaking work exposing and documenting human rights violations in areas where government censorship and digital surveillance are rife.
In recent years, a number of countries including Algeria, China, Iran, Russia and Viet Nam have blocked Amnesty International websites, according to the Open Observatory of Network Interference (OONI), in a deliberate attempt to suppress freedom of information and efforts to hold the powerful to account.
The new Amnesty onion site can be accessed using the Tor Browser through our secure onion address at: https://www.amnestyl337aduwuvpf57irfl54ggtnuera45ygcxzuftwxjvvmpuzqd.onion."
https://www.amnesty.org/en/latest/news/2023/12/global-amnesty-international-website-launches-on-tor-network-to-help-universal-access/GusGushttps://gitlab.torproject.org/tpo/onion-services/onionmine/-/issues/26Setup Onion MkDocs for Onionmine2024-02-22T22:06:52ZSilvio RhattoSetup Onion MkDocs for OnionmineConvert Onionmine documentation to [Onion MkDocs][].
[Onion Mkdocs]: https://gitlab.torproject.org/tpo/web/onion-mkdocs/Convert Onionmine documentation to [Onion MkDocs][].
[Onion Mkdocs]: https://gitlab.torproject.org/tpo/web/onion-mkdocs/Silvio RhattoSilvio Rhattohttps://gitlab.torproject.org/tpo/network-health/doctor/-/issues/40035"NOTICE: gabelmoo had 17 MiddleOnly flags in its vote but the consensus had 9...2024-03-21T14:27:02ZRoger Dingledine"NOTICE: gabelmoo had 17 MiddleOnly flags in its vote but the consensus had 9" isn't noteworthyI grabbed the consensus and gabelmoo's vote during the time period that we got the doctor warning, and sure enough:
```
$ grep MiddleOnly cached-consensus |grep ^s|wc -l
9
$ grep MiddleOnly gabelmoo-vote |grep ^s|wc -l
17
```
And in mo...I grabbed the consensus and gabelmoo's vote during the time period that we got the doctor warning, and sure enough:
```
$ grep MiddleOnly cached-consensus |grep ^s|wc -l
9
$ grep MiddleOnly gabelmoo-vote |grep ^s|wc -l
17
```
And in more detail,
```
$ grep MiddleOnly gabelmoo-vote |grep ^s
s BadExit MiddleOnly Running Stable Valid
s BadExit Fast MiddleOnly Stable Valid
s BadExit Fast MiddleOnly Running Stable Valid
s BadExit Fast MiddleOnly Running Stable Valid
s BadExit Fast MiddleOnly Stable Valid
s BadExit Fast MiddleOnly Running Valid
s BadExit Fast MiddleOnly Running Stable Valid
s BadExit Fast MiddleOnly Running Valid
s BadExit Fast MiddleOnly Stable Valid
s BadExit Fast MiddleOnly Stable Valid
s BadExit Fast MiddleOnly Stable Valid
s BadExit Fast MiddleOnly Stable Valid
s BadExit Fast MiddleOnly Stable Valid
s BadExit Fast MiddleOnly Running Stable Valid
s BadExit Fast MiddleOnly Running Stable Valid
s BadExit Fast MiddleOnly Stable Valid
s BadExit Fast MiddleOnly Running Stable Valid
```
So even gabelmoo only thought 9 of the 17 should be Running, so it's not surprising that only 9 of them made it into the consensus.
But even if gabelmoo had different opinions about which ones are Running, the fact that gabelmoo voted MiddleOnly about a relay which didn't make it into the consensus is not noteworthy. There are a variety of cases where it could happen during normal operation.
I think a more precise check would be: for each relay listed in the consensus as MiddleOnly, did gabelmoo list it as MiddleOnly too?
If that's too much coding, a simpler approximation (which avoids reporting the false positives but also omits some of the true positives) might be: don't log anything if the number in the vote is bigger than the number in the consensus.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/anti-censorship/bridge-port-scan/-/issues/7Build process needs updating2024-02-07T13:11:37ZKezBuild process needs updatingThe web team's lektor site build process has changed a bit since this repo was last updated, and the repo no longer builds with the instructions provided (the build instructions seem a bit incomplete even without these build changes). So...The web team's lektor site build process has changed a bit since this repo was last updated, and the repo no longer builds with the instructions provided (the build instructions seem a bit incomplete even without these build changes). So the build process needs to be updated, and more thoroughly documented.https://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/40106Details API returning undocumented `contact` for bridges2023-11-29T20:48:03ZSarthik Guptasarthikg@icloud.comDetails API returning undocumented `contact` for bridgesContrary to the key-value pairs listed at https://metrics.torproject.org/onionoo.html#details_bridge,
Details API Response contains `contact` key for bridges as can be tested in the response for the following api, https://onionoo.torpro...Contrary to the key-value pairs listed at https://metrics.torproject.org/onionoo.html#details_bridge,
Details API Response contains `contact` key for bridges as can be tested in the response for the following api, https://onionoo.torproject.org/details?limit=4&search=scriptonhttps://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/issues/40041Details API returning undocumented `contact` for bridges2023-11-27T14:49:33ZSarthik Guptasarthikg@icloud.comDetails API returning undocumented `contact` for bridgesContrary to the key-value pairs listed at https://metrics.torproject.org/onionoo.html#details_bridge,
Details API Response contains `contact` key for bridges as can be tested in the response for the following api, https://onionoo.torpro...Contrary to the key-value pairs listed at https://metrics.torproject.org/onionoo.html#details_bridge,
Details API Response contains `contact` key for bridges as can be tested in the response for the following api, https://onionoo.torproject.org/details?limit=4&search=scriptonhttps://gitlab.torproject.org/tpo/web/blog/-/issues/40066Update CoC link2023-10-25T21:24:35ZGusUpdate CoC linkTor Code of Conduct document moved from gitweb to gitlab (https://gitlab.torproject.org/tpo/community/policies/-/blob/master/code_of_conduct.txt?ref_type=heads).
We need to change the link: https://gitlab.torproject.org/tpo/web/blog/-/b...Tor Code of Conduct document moved from gitweb to gitlab (https://gitlab.torproject.org/tpo/community/policies/-/blob/master/code_of_conduct.txt?ref_type=heads).
We need to change the link: https://gitlab.torproject.org/tpo/web/blog/-/blob/main/templates/macros/blog.html#L87Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/1057migrate from trust-dns to hickory2024-03-11T17:14:29Ztrinity-1686amigrate from trust-dns to hickorytrust-dns will soon get rebranded to Hicktory (this is not a change of ownership, just rebranding). We should migrate from one to the other to keep getting updates.
[public announcement](https://bluejekyll.github.io/blog/posts/announcin...trust-dns will soon get rebranded to Hicktory (this is not a change of ownership, just rebranding). We should migrate from one to the other to keep getting updates.
[public announcement](https://bluejekyll.github.io/blog/posts/announcing-hickory-dns/)https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41881Developer tools/Network/New Request remembers requests2023-10-03T15:37:59ZcypherpunksDeveloper tools/Network/New Request remembers requestsOn TBB 12.5.1, opening Developer tools, Network tab and then clicking on "New Request" causes address, headers, POST body to be autofilled with ones of previous request in other isolation domain or even after browser restart.On TBB 12.5.1, opening Developer tools, Network tab and then clicking on "New Request" causes address, headers, POST body to be autofilled with ones of previous request in other isolation domain or even after browser restart.cypherpunkscypherpunkshttps://gitlab.torproject.org/tpo/web/community/-/issues/316[Onion Services] Featured onions - EFF, Certbot, SSD2023-08-10T17:28:54ZGus[Onion Services] Featured onions - EFF, Certbot, SSDA little bit late to the party, but hey, let's add these new onions to the #featured-onions list:
```
Today, we’re announcing .onion addresses for eff.org and two of its affiliated projects: Certbot, an EFF-developed tool for automatica...A little bit late to the party, but hey, let's add these new onions to the #featured-onions list:
```
Today, we’re announcing .onion addresses for eff.org and two of its affiliated projects: Certbot, an EFF-developed tool for automatically obtaining and renewing TLS certificates for websites, and Surveillance Self-Defense, which provides resources and guidance for individuals and organizations to protect themselves from surveillance and other security threats.
```
https://www.eff.org/deeplinks/2023/04/eff-now-has-tor-onions
```
eff.org
iykpqm7jiradoeezzkhj7c4b33g4hbgfwelht2evxxeicbpjy44c7ead.onion
certbot.eff.org
5yl6j7al5iwjn3kltayvumj5d25agnq4t6rznkvphossoqyzb3batwid.onion
ssd.eff.org
y7yea4pmqqtznb33qiugvysyn2bob5v62e4pvoadoibrwkq3tsddjeyd.onion
```https://gitlab.torproject.org/tpo/web/support/-/issues/327Dead link to blog2023-11-06T19:25:02ZslrslrDead link to bloghttps://support.torproject.org/tbb/tbb-22/
contains 404 not found link to https://blog.torproject.org/why-tor-is-slow
It is not even on archive: https://web.archive.org/web/20220715000000*/https://blog.torproject.org/why-tor-is-slow
I a...https://support.torproject.org/tbb/tbb-22/
contains 404 not found link to https://blog.torproject.org/why-tor-is-slow
It is not even on archive: https://web.archive.org/web/20220715000000*/https://blog.torproject.org/why-tor-is-slow
I am unsure if the article is still present: https://www.ecosia.org/search?addon=firefox&q=tor+blog+why+tor+is+slow+site%3Ablog.torproject.org
Though the https://support.torproject.org/tbb/tbb-22/ should contain some more answer to the question in its title..https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/177Change help links in `about:preferences` and menu2023-10-03T13:30:05ZruihildtChange help links in `about:preferences` and menuRight now, we link to https://mullvad.net/en/help/ in:
- `about:preferences` under `Mullvad Browser Support` link at the bottom left
- the menu `Help > Get Help`
I might be forgetting other places where this link exists.
There's now a ...Right now, we link to https://mullvad.net/en/help/ in:
- `about:preferences` under `Mullvad Browser Support` link at the bottom left
- the menu `Help > Get Help`
I might be forgetting other places where this link exists.
There's now a dedicated sub-section link we can use instead https://mullvad.net/en/help/tag/mullvad-browser/richardrichard