Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-21T18:05:29Zhttps://gitlab.torproject.org/legacy/trac/-/issues/20618GetTor does not return download links when using Protonmail.com2020-06-21T18:05:29ZTracGetTor does not return download links when using Protonmail.comUsing GetTor to get download links for TorBrowser works fine when using email (web)clients like gmail.com, yahoo.com, outlook.com (and presumably others).
However, using protonmail.com, GetTor does not return the download links, but inst...Using GetTor to get download links for TorBrowser works fine when using email (web)clients like gmail.com, yahoo.com, outlook.com (and presumably others).
However, using protonmail.com, GetTor does not return the download links, but instead replies with a 'help' message:
''Hi! This is the GetTor robot. I am here to help you download the
latest version of Tor Browser.''
_Please reply to this message with one of the options below:_
''android
windows
linux
osx
mirrors''
_I will then send you the download instructions._
_If you are unsure, just send a blank reply to this message._
Either replying with a blank message or mentioning any of the options (windows, linux, etc) returns the exact same 'help' message from GetTor, but no download links.
**Trac**:
**Username**: gajIsrael LeivaIsrael Leivahttps://gitlab.torproject.org/legacy/trac/-/issues/26133Add OnionBrowser to TorProject.org/download redesigned page2020-06-13T17:26:30ZTracAdd OnionBrowser to TorProject.org/download redesigned pageMany IOS users have a hard time finding an "IOS Torbrowser" that TorProject recommends, this can be seen by the [many questions](https://twitter.com/torproject/status/997206488715325441) that are asked on TorProject's twitter on how to d...Many IOS users have a hard time finding an "IOS Torbrowser" that TorProject recommends, this can be seen by the [many questions](https://twitter.com/torproject/status/997206488715325441) that are asked on TorProject's twitter on how to download TorBrowser for IOS. It would be great if A link is added to the redesigned TorProject download page that directs users to **Mike Tigas's** [OnionBrowser](https://itunes.apple.com/us/app/onion-browser/id519296448?mt=8). This would also reduce the number of IOS users that accidentally download a NON-recommended "IOS Torbrowser" like "Red Browser".
_A disclaimer could be added under the link to the OnionBrowser app saying_, "This app is recommend by TorProject but it is not directly developed by TorProject nor directly funded by TorProject".
**Trac**:
**Username**: Dbryrtfbcbhgfwebsite redesigntraumschuletraumschulehttps://gitlab.torproject.org/legacy/trac/-/issues/10524Document the use of tar.xz files2020-06-13T17:21:38ZTracDocument the use of tar.xz filesWhen downloading the Tor bundle for Debian today I got a 'tar.xz' file. However the help page located at https://www.torproject.org/docs/tor-doc-unix.html.en#using only explains how to deal with a 'tar.gz' file.
Maybe you should add her...When downloading the Tor bundle for Debian today I got a 'tar.xz' file. However the help page located at https://www.torproject.org/docs/tor-doc-unix.html.en#using only explains how to deal with a 'tar.gz' file.
Maybe you should add here the 'xJf' tar option needed to deal with the 'tar.xz' extension?
**Trac**:
**Username**: LilKSMatt PaganMatt Paganhttps://gitlab.torproject.org/legacy/trac/-/issues/7948It is hard to download the vidalia-bundle on torproject.org using web proxies2020-06-13T17:20:48ZTracIt is hard to download the vidalia-bundle on torproject.org using web proxiesHello,
I encountered problems when I was trying to download the vidalia-bundle on https://www.torproject.org/projects/obfsproxy.html.en using a web proxy.
This is how I usually try to do it:
1) Access a directory of web proxies (like ...Hello,
I encountered problems when I was trying to download the vidalia-bundle on https://www.torproject.org/projects/obfsproxy.html.en using a web proxy.
This is how I usually try to do it:
1) Access a directory of web proxies (like www.proxyliste.com)
2) Once I got a working proxy, I try to download the vidalia-bundle.
Why it is hard to download:
Instead of the direct download links you see when you browse the site using tor browser, the links become "obfuscated" in the web proxies. Often, it is not possible to download the actual bundle, but only a "browse(1).php"-file (or something similar), which is empty.
I don't know if there is anything you can do to prevent this behavior of the proxies, I just wanted to share my experiences and provide feedback.
Thank you so much for your work.
**Trac**:
**Username**: hans_meierhttps://gitlab.torproject.org/legacy/trac/-/issues/6985Tor, .torrents, Freedom2020-06-13T17:20:36ZTracTor, .torrents, FreedomHi.
I was seeding Tor project, bundle, obfs and Tails on my Seedbox (along with many many other Anti-Censorship applications) for couple of mounts. Unfortunately you don't provide public _.torrent_ files any more -except for Tails- and i...Hi.
I was seeding Tor project, bundle, obfs and Tails on my Seedbox (along with many many other Anti-Censorship applications) for couple of mounts. Unfortunately you don't provide public _.torrent_ files any more -except for Tails- and it's useless if I seed personal-made torrent files when no one else has them.
Please add torrent files to download section again.
**Trac**:
**Username**: CipherDeliverable-Sep2010https://gitlab.torproject.org/legacy/trac/-/issues/20601Clients should reject outdated consensuses as soon as they parse them2020-06-13T15:03:06ZteorClients should reject outdated consensuses as soon as they parse themWe should check when we reject outdated consensuses, and consider doing it sooner.
Split off #20511, defends against bugs similar to #20499.We should check when we reject outdated consensuses, and consider doing it sooner.
Split off #20511, defends against bugs similar to #20499.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19552Provide mechanism to find dirconns associated with a download_status_t, and e...2020-06-13T14:59:10ZAndrea ShepardProvide mechanism to find dirconns associated with a download_status_t, and expose active download attempts in GETINFO responseIt's hairy and complicated and different for every download status type to find out if / how many active attempts there are; we can do better.It's hairy and complicated and different for every download status type to find out if / how many active attempts there are; we can do better.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/9968Time out quicker on microdesc fetch failures while we're bootstrapping2020-06-13T14:32:36ZRoger DingledineTime out quicker on microdesc fetch failures while we're bootstrapping#9946 points out that "if one of our three guards is a bust, it will take 120 seconds for requests to it to time out, and even if the other 2 guards are working great, that typically isn't enough to get to 80% bootstrapped. So there will...#9946 points out that "if one of our three guards is a bust, it will take 120 seconds for requests to it to time out, and even if the other 2 guards are working great, that typically isn't enough to get to 80% bootstrapped. So there will remain cases where we wait 2 minutes to bootstrap -- and maybe this patch even increases the chance of those since any of the three guards can cause them."
We should be more eager to either rotate to a different guard, or try another request in parallel, if a) we're not bootstrapped yet, b) we have directory questions we want answers to, and c) we've recently gotten good answers from our other guards.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/6761PDS_NO_EXISTING_SERVERDESC_FETCH is somewhat archaic2020-06-13T14:22:14ZRoger DingledinePDS_NO_EXISTING_SERVERDESC_FETCH is somewhat archaicIn bug #366 we made it so Tor won't open a second dir fetch to an authority if it has one already. Great.
```
rs = router_pick_trusteddirserver(type, pds_flags);
if (rs == NULL && (pds_flags & (PDS_NO_EXISTING_SERVERDESC_...In bug #366 we made it so Tor won't open a second dir fetch to an authority if it has one already. Great.
```
rs = router_pick_trusteddirserver(type, pds_flags);
if (rs == NULL && (pds_flags & (PDS_NO_EXISTING_SERVERDESC_FETCH|
PDS_NO_EXISTING_MICRODESC_FETCH))) {
[...]
log_debug(LD_DIR, "Deferring serverdesc fetch: all authorities "
"are in use.");
```
But we didn't update it to look for begindir conns, so it only applies to direct dir fetches. Ok.
```
if (no_microdesc_fetching) {
if (connection_get_by_type_addr_port_purpose(
CONN_TYPE_DIR, &addr, d->dir_port, DIR_PURPOSE_FETCH_MICRODESC)) {
++n_busy;
continue;
```
So it doesn't apply to clients, only relays. That makes sense, because relays are the ones who typically would contact authorities anyway.
```
int prefer_authority = directory_fetches_from_authorities(options);
```
But when a relay starts up and gets a consensus, it has a line like this nowadays:
```
Sep 04 05:47:40.000 [info] launch_descriptor_downloads(): Launching 33 requests for 3114 routers, 96 at a time
```
33 requests! Surely that's way more than the 8 or so authorities we have. And relays don't use begindir to talk to authorities, since it slows them down too much:
```
int use_begindir = supports_begindir &&
directory_command_should_use_begindir(options, _addr,
or_port, router_purpose, anonymized_connection);
```
Doesn't that mean we hit the "one per authority" limit and drop the rest of those requests?
It turns out that directory_fetches_from_authorities() is false for most relays when they start up:
```
if (server_mode(options) && router_pick_published_address(options, &addr)<0)
return 1; /* we don't know our IP address; ask an authority. */
refuseunknown = ! router_my_exit_policy_is_reject_star() &&
should_refuse_unknown_exits(options);
if (options->DirPort == NULL && !refuseunknown)
return 0;
if (!server_mode(options) || !advertised_server_mode())
return 0;
me = router_get_my_routerinfo();
if (!me || (!me->dir_port && !refuseunknown))
return 0; /* if dirport not advertised, return 0 too */
return 1;
```
So these relays end up asking arbitrary other relays they found in the consensus! Cue Nick's circus music here. Not the best way to get fresh info.
In my case here (and I expect it's a common case), my relay failed the "!advertised_server_mode" check, since it hadn't done its reachability test yet so it hadn't published a descriptor yet.
Maybe this is actually a feature that just-starting-up relays don't fetch descriptors from authorities. It probably doesn't hurt much, and probably helps authority load a bit.
But I don't think it's a feature that we allow multiple descriptor-fetching dir requests in parallel to an authority iff they're begindir requests.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/2991Confusing log messages when a DA starts using a new key2020-06-13T14:09:58ZRobert RansomConfusing log messages when a DA starts using a new keyFrom IRC:
> [04:06:59] <ln5> karsten: seeing this repeatedly in maatuska logs:
> [04:07:02] <ln5> Apr 26 13:06:09.964 [notice] We're missing a certificate from authority with signing key B3F2CB9D75F87AE4D4A8ECEB3CAAECDC4B131010: launchin...From IRC:
> [04:06:59] <ln5> karsten: seeing this repeatedly in maatuska logs:
> [04:07:02] <ln5> Apr 26 13:06:09.964 [notice] We're missing a certificate from authority with signing key B3F2CB9D75F87AE4D4A8ECEB3CAAECDC4B131010: launching request.
> [04:07:02] <ln5> Apr 26 13:06:10.318 [warn] Got a certificate for maatuska, but we already have it. Maybe they haven't updated it. Waiting for a while.
> [04:08:27] <ln5> do i need to do anything else than dropping new authority_certificate and authority_signing_key files in the keys directory and restart tor?
> [04:09:50] <rransom> That ‘We're missing a certificate’ log message means it fetched the previous consensus as a client, and saw a signature with maatuska's old key, and set out to ask maatuska for its certificate for that old key.
> [04:10:35] <ln5> a, roles. makes sense. thanks.
> [04:10:55] <rransom> The second one you pasted means that when it got maatuska's (new) certificate, the certificate didn't match the directory-signing key used for that consensus.
>
> [04:29:37] <ln5> rransom: what makes you think that? to me it seems like it got a certificate it already had (maatuska's). i suppose that might happen if i fetch it from a DA that hasn't updated maatuskas cert yet.
> [04:30:43] <rransom> ln5: It did. It was hoping to get maatuska's old certificate, which would contain the key with which maatuska had signed the then-current consensus.
I suspect that a client bootstrapped between the time that a DA upgraded its signing key and the time that it used that key to sign a new consensus would emit these confusing messages as well.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/2303download breaks, traffic still flows somewhere...2020-06-13T00:09:50ZTracdownload breaks, traffic still flows somewhere...When download (file 300 mb)actually stops (or better breaks, 65 mb on disk, status in browser: 0 bytes/sec, unknown time remaining), the Vidalia Bandwidth Usage graph shows that the traffic still goes on, with considerable pace (40 kb/se...When download (file 300 mb)actually stops (or better breaks, 65 mb on disk, status in browser: 0 bytes/sec, unknown time remaining), the Vidalia Bandwidth Usage graph shows that the traffic still goes on, with considerable pace (40 kb/sec).
As counter shows, more than 100mb were downloaded after the browser showed that it stopped (no other pages were opened).
All that data goes "somewhere", but is not attached to the file.
So, it seems that the bug is not a minor one.
-------
Additional Info:
When downloading without Tor (Tor not started),
using Google chrome browser, all is ok.
System parameters:
1) OS Windows XP 5.1.2600
2) Antivirus Avira (webGuard off, firewall off)
3) Windows firewall is off
4) Event ID 4226 Patcher applied
5) Mozilla adjusted:
network.http.keep-alive.timeout:600 (300ms default is OK usually, but 600 is better.)
network.http.max-persistent-connections-per-proxy:16 (Default is 4)
network.http.pipelining:true (Default- false. Some old HTTP/1.0 servers can't handle it.)
network.http.pipelining.maxrequests:8 (No default)
network.http.proxy.keep-alive:true (Default- true, but double check)
network.http.proxy.pipelining:true (Default- false) -
**Trac**:
**Username**: alexnvhttps://gitlab.torproject.org/legacy/trac/-/issues/2222Download process stops - only fraction of file is downloaded2020-06-12T23:59:06ZTracDownload process stops - only fraction of file is downloadedWhat happens:
1. Start download (from file hosting)
2. Speed ok, download progress bar is filling
3. Some time passed...(no alerts)
4. Speed = 0, a fraction of file is on disk.
Notice:
1. I tried to download using Tor 0.2.1.26 and 0....What happens:
1. Start download (from file hosting)
2. Speed ok, download progress bar is filling
3. Some time passed...(no alerts)
4. Speed = 0, a fraction of file is on disk.
Notice:
1. I tried to download using Tor 0.2.1.26 and 0.2.1.27
different files from different hosts
with almost the same result: 60-65 mb downloaded on disk
2. When downloading without Tor (Tor not started),
using Google chrome browser, all is ok.
System parameters:
1) OS Windows XP 5.1.2600
2) Antivirus Avira (webGuard off, firewall off)
3) Windows firewall is off
4) Event ID 4226 Patcher applied
5) Mozilla adjusted:
network.http.keep-alive.timeout:600 (300ms default is OK usually, but 600 is better.)
network.http.max-persistent-connections-per-proxy:16 (Default is 4)
network.http.pipelining:true (Default- false. Some old HTTP/1.0 servers can't handle it.)
network.http.pipelining.maxrequests:8 (No default)
network.http.proxy.keep-alive:true (Default- true, but double check)
network.http.proxy.pipelining:true (Default- false) - See NOTE1 below.
QUESTION:
What can be done to fix the problem?
**Trac**:
**Username**: alexnvhttps://gitlab.torproject.org/legacy/trac/-/issues/17137easy download of the latest version of tor2018-07-03T22:32:19Zcypherpunkseasy download of the latest version of torGreetings,
Having the ability to easily download the latest version of tor{,browser} using something like:
https://dist.torproject.org/current{,/torbrowser}/torbrowser{.exe,.dmg,...}
https://dist.torproject.org/current{,/tor}/tor{.exe,...Greetings,
Having the ability to easily download the latest version of tor{,browser} using something like:
https://dist.torproject.org/current{,/torbrowser}/torbrowser{.exe,.dmg,...}
https://dist.torproject.org/current{,/tor}/tor{.exe,.dmg,...}
... would be nice.
Best regards,
cyperpunkscypherpunkscypherpunkshttps://gitlab.torproject.org/legacy/trac/-/issues/2834Download from Firefox hangs if file is greater than 30MB2011-04-03T04:02:02ZTracDownload from Firefox hangs if file is greater than 30MBDownload consistently hangs if I try and use Firefox to download a file larger than 30MB or if the download takes longer than 10 minutes. The download window shows a download in progress but the file size that has been downloaded so far ...Download consistently hangs if I try and use Firefox to download a file larger than 30MB or if the download takes longer than 10 minutes. The download window shows a download in progress but the file size that has been downloaded so far never changes. The progress bar is stuck and download never finishes. I have to kill the download and try again. Usually it always hangs on large files or if the download takes more than 10 minutes. Very annoying. Works if I don't use TOR and Vidalia. Using Windows 7 with FireFox 3.6.16. Using TOR 0.2.1.29 and Vidalia 0.2.10.
**Trac**:
**Username**: Twisted