Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T17:18:20Zhttps://gitlab.torproject.org/legacy/trac/-/issues/1039subdomain.torproject.org as www.torproject.org/subdomain2020-06-13T17:18:20ZTracsubdomain.torproject.org as www.torproject.org/subdomainI suggest to make all the subdomain.torproject.org websites (also) available as www.torproject.org/subdomain
So instead of
https://bridges.torproject.org/
the should be also a https://www.torproject.org/bridges
In this case there is a ...I suggest to make all the subdomain.torproject.org websites (also) available as www.torproject.org/subdomain
So instead of
https://bridges.torproject.org/
the should be also a https://www.torproject.org/bridges
In this case there is a https://www.torproject.org/bridges, but it has other content.
So maybe name it https://www.torproject.org/list-bridges
The reason for this is to make it harder to find out on which pages of the tor website a user was browsing.
A HTTPS request is encrypted, but if you sniff it you can see the complete hostname (host.domain.tld).
You can't see the directory/file which is requested (https://torproject.org/this/stuff).
It's also be easier for a the great wall or an ISP to block or even redirect the user to a malicious set of
bridges and therefore get aware of bridge user/their IP addresses.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Athabahttps://gitlab.torproject.org/legacy/trac/-/issues/1066Restarting all the authorities at once would halt all the clients.2020-06-13T14:02:28ZNick MathewsonRestarting all the authorities at once would halt all the clients.For a while after an authority has started, it doesn't have any opinion about which routers are Running,
so it doesn't vote on that. But if every authority were restarted at once right before it was time to
vote, no authority would vote...For a while after an authority has started, it doesn't have any opinion about which routers are Running,
so it doesn't vote on that. But if every authority were restarted at once right before it was time to
vote, no authority would vote on the Running flag, and so no router would be listed as Running in the
next consensus. Clients would then think that all the routers were down.
Let's fix this DOS before it happens. One possible fix would be for authorities to refuse to build a consensus
if nobody has voted on certain essential flags, to include running. As a belt-and-suspenders approach, newer
clients could assume every router was Running if nobody voted on Running, rather than assuming no router was
Running.
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/1064warnings in log related to consensus problems2020-06-13T14:02:28ZSebastian Hahnwarnings in log related to consensus problemsYesterday I had this in my logs:
Aug 19 06:25:08.854 [notice] Tor 0.2.1.19 opening new log file.
Aug 19 11:11:24.080 [warn] couldn't find start of hashed material "network-status-version"
Aug 19 11:11:24.080 [warn] Unable to compute dig...Yesterday I had this in my logs:
Aug 19 06:25:08.854 [notice] Tor 0.2.1.19 opening new log file.
Aug 19 11:11:24.080 [warn] couldn't find start of hashed material "network-status-version"
Aug 19 11:11:24.080 [warn] Unable to compute digest of network-status
Aug 19 11:11:24.080 [warn] Unable to parse networkstatus consensus
Aug 19 11:11:24.080 [warn] Unable to load consensus directory downloaded from server '80.190.246.100:80'. I'll try again soon.
Aug 19 14:15:21.864 [warn] 1 unknown, 0 missing key, 3 good, 0 bad, 2 no signature, 4 required
Aug 19 14:15:21.864 [warn] Not enough good signatures on networkstatus consensus
Aug 19 14:15:21.866 [warn] Unable to load consensus directory downloaded from server '128.31.0.34:9031'. I'll try again soon.
Aug 19 14:25:30.496 [warn] 1 unknown, 0 missing key, 3 good, 0 bad, 2 no signature, 4 required
Aug 19 14:25:30.496 [warn] Not enough good signatures on networkstatus consensus
Aug 19 14:25:30.498 [warn] Unable to load consensus directory downloaded from server '86.59.21.38:80'. I'll try again soon.
Aug 19 14:56:01.852 [warn] 1 unknown, 0 missing key, 3 good, 0 bad, 2 no signature, 4 required
Aug 19 14:56:01.852 [warn] Not enough good signatures on networkstatus consensus
Aug 19 14:56:01.854 [warn] Unable to load consensus directory downloaded from server '216.224.124.114:9030'. I'll try again soon.
Aug 20 06:25:09.481 [notice] Received reload signal (hup). Reloading config and resetting internal state.
No idea where these warnings would come from. Does anyone with an authority have any useful logs?
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/1045Framing TLS records violates the protocol specification.2020-06-13T14:02:26ZTracFraming TLS records violates the protocol specification.
The problem is _connection_write_to_buf_impl(), if it
flushes forcely a some bytes from outbuf.
For queued cells (in_flushed_some is true), it never plays
with outbuf_flushlen. So call for connection_handle_write()
triggered only in ca...
The problem is _connection_write_to_buf_impl(), if it
flushes forcely a some bytes from outbuf.
For queued cells (in_flushed_some is true), it never plays
with outbuf_flushlen. So call for connection_handle_write()
triggered only in case of overlapping sets of conditions;
If outbuf_flushlen was equal 15360 before cell_destroy
(or cell_padding) was appended, then flushes of 15872
bytes to TLS record.
Such behavior can leak a type of the last cell, and a some
internal information likes a outbuf's length.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: OTUhttps://gitlab.torproject.org/legacy/trac/-/issues/1044Make it actually work.2020-06-13T14:02:25ZTracMake it actually work.I've been trying to use TOR for a few years now. Every single instance I've installed on more than 8 different computers using both windows and linux fails to operate.
TOR is failware. Every forum I read says "we'll fix that bug next tim...I've been trying to use TOR for a few years now. Every single instance I've installed on more than 8 different computers using both windows and linux fails to operate.
TOR is failware. Every forum I read says "we'll fix that bug next time."
It is next time. And another next time.
Torbutton is the worst pile I've seen since freenet, another vaporware project of fail.
Tell me, is there any plan to have this firefox addon actually function at ALL?
It's a POS.
I'm writing the guys at firefox to ask them to strip this plugin off their recommended list until the ONE major bug is repaired: It doesn't fucking work.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: demopolyhttps://gitlab.torproject.org/legacy/trac/-/issues/1035Relay on dynamic IP marked as stable and guard2020-06-13T14:02:22ZTracRelay on dynamic IP marked as stable and guardHi,
I'm running a Tor relay on a dynamic IP which changes every day. At the moment
my node is marked as stable and guard which AFAIK shouldn't happen as it isn't
stable. I got the information from https://trunk.torstatus.kgprog.com:444/...Hi,
I'm running a Tor relay on a dynamic IP which changes every day. At the moment
my node is marked as stable and guard which AFAIK shouldn't happen as it isn't
stable. I got the information from https://trunk.torstatus.kgprog.com:444/.
This may be related to bug #969 which was marked as fixed.
Thanks,
Simon
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: rudisTor: 0.2.4.x-finalSebastian HahnSebastian Hahnhttps://gitlab.torproject.org/legacy/trac/-/issues/1029Tor relay should log message when it's working again after marking as down2020-06-13T14:02:19ZTracTor relay should log message when it's working again after marking as downHi,
I'm running a Tor relay on a dynamic IP which changes once per day.
Sometimes there seems to be some problems and I get the following
error message:
We just marked ourself as down. Are your external addresses reachable?
Now th...Hi,
I'm running a Tor relay on a dynamic IP which changes once per day.
Sometimes there seems to be some problems and I get the following
error message:
We just marked ourself as down. Are your external addresses reachable?
Now this is no problem and the message is fine. But I would like to
be informed when the relay knows it's up again. Something like this:
We just marked ourself as up again.
So that I'm not worried when I see the first message and know (when
I see the second message) that my relay works fine. At the moment I
have have to do the check manually.
Thanks for your help,
Simon
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: rudisTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/1027tor logs data that it should not2020-06-13T14:02:19ZTractor logs data that it should not[warn] Invalid hostname www.abcdefghijklmnop.onion; rejecting
Onion hostnames being accessed are confidential information. Tor should never log details of what's going through it to disk by default, even on error. All data like this s...[warn] Invalid hostname www.abcdefghijklmnop.onion; rejecting
Onion hostnames being accessed are confidential information. Tor should never log details of what's going through it to disk by default, even on error. All data like this should be masked unless debugging is enabled explicitly. This is a major breach of reasonable expectations.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: anonyuserhttps://gitlab.torproject.org/legacy/trac/-/issues/1026tor-0.2.1.15-rc posts inappropriate descriptor update, resulting in eventual ...2020-06-13T14:02:18ZTractor-0.2.1.15-rc posts inappropriate descriptor update, resulting in eventual expiration from consen-- Submitted on behalf of "Scott Bennett <bennett@cs.niu.edu>" --
If a currently valid descriptor (#1) is on file at the authorities
based upon the following data rate information from torrc:
BandwidthRate 100 KB
Bandwidt...-- Submitted on behalf of "Scott Bennett <bennett@cs.niu.edu>" --
If a currently valid descriptor (#1) is on file at the authorities
based upon the following data rate information from torrc:
BandwidthRate 100 KB
BandwidthBurst 140 KB
MaxAdvertisedBandwidth 85 KB
and torrc is changed to read:
BandwidthRate 85 KB
BandwidthBurst 140 KB
and no other torrc information has changed and the observed peak
ten-second data rate in the previous 24 hours is unchanged since the
publication of descriptor #1, a SIGHUP sent to tor causes a new
descriptor (#2) to be posted to the authorities, where the only
changed information is the publication timestamp. The authorities
then reject descriptor #2 as "not new". The tor relay, however, has
changed its own idea of when the next descriptor update should be
posted to ~18 hours later than the timestamp on #2. At ~18 hours
after the posting of descriptor #1, the authorities assume for the
next consensus vote that the relay is no longer running because they
have not received an update around ~18 hours from the posting of #1.
This results in the relay being dropped from consensus documents
until the relay posts an update ~18 hours from the timestamp of #2.
This can cause a running tor relay to be dropped inappropriately
from the consensus documents for many hours before the situation is
corrected.
Relays should not post early descriptor updates that will be rejected
by the authorities, or alternatively, relays should not reset their
18-hour timers for descriptor updates until a majority of the
authorities has accepted the new updates.
This bug may also be related to bug report #962.
Submitted by:
Scott Bennett <bennett@cs.niu.edu>
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Jon_Screamhttps://gitlab.torproject.org/legacy/trac/-/issues/1025Completion of error handling2020-06-13T14:02:18ZTracCompletion of error handlingSome checks for return codes are missing.
Examples:
Would you like to add more error handling for return values from "pthread_cond_signal" like in the function
"tor_cond_signal_one" and from "fprintf" in the function "write_pidfile"?
h...Some checks for return codes are missing.
Examples:
Would you like to add more error handling for return values from "pthread_cond_signal" like in the function
"tor_cond_signal_one" and from "fprintf" in the function "write_pidfile"?
https://svn.torproject.org/cgi-bin/viewvc.cgi/tor/trunk/src/common/compat.c?view=markup&revision=18761
https://svn.torproject.org/cgi-bin/viewvc.cgi/tor/trunk/src/common/util.c?view=markup&revision=18761
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: elfringhttps://gitlab.torproject.org/legacy/trac/-/issues/1069Torbutton does not appear in Firefox status bar2010-06-22T23:26:49ZTracTorbutton does not appear in Firefox status barSummary: Vidalia installed, no Torbutton displayed in status bar
Installed the Vidalia pack on Firefox 3.5.2 - Torbutton not present in status bar
Removed Torbutton from Firefox Add-ons, and installed latest (1.2.2) via Firefox add-on s...Summary: Vidalia installed, no Torbutton displayed in status bar
Installed the Vidalia pack on Firefox 3.5.2 - Torbutton not present in status bar
Removed Torbutton from Firefox Add-ons, and installed latest (1.2.2) via Firefox add-on search.
Still no Torbutton in status bar.
Checked Firefox Add-ons, torbutton listed, "Test settings" works.
The key problem is I can't toggle browsing through tor, and not through tor.
This may be due to having installed Vidalia several months ago (earlier version of Firefox) and subsequently removing it.
I don't know if that left any issues behind that could be causing this.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: brianmchttps://gitlab.torproject.org/legacy/trac/-/issues/1041Tor Button - drops firefox tab history2009-11-17T05:16:00ZTracTor Button - drops firefox tab historyRecently updated to Firefox 3.5.1. Tor Button 1.2.1 addon causes Firefox to loose its previously open tabs at start up.
Browser returns the following error on start up when Tor Button is enabled:
Torbutton logger online
[DATE] Torbutt...Recently updated to Firefox 3.5.1. Tor Button 1.2.1 addon causes Firefox to loose its previously open tabs at start up.
Browser returns the following error on start up when Tor Button is enabled:
Torbutton logger online
[DATE] Torbutton NOTE: Skipping no location: chrome://browser/content/browser.xul
When Tor Button is disable the browser performs as expected.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: sjk303https://gitlab.torproject.org/legacy/trac/-/issues/1054Tor VM does not monitor interface changes2009-09-29T11:21:07ZcodermanTor VM does not monitor interface changesThanks to keiner for reporting:
If a service or application is running which periodically configures or renews a
network interface side channels may be exposed to the local area network or overlay
networks. This may also expose DNS requ...Thanks to keiner for reporting:
If a service or application is running which periodically configures or renews a
network interface side channels may be exposed to the local area network or overlay
networks. This may also expose DNS requests sent to the Transparent DNSPort (not
SOCKS/polipo) to a local area resolver or gateway.
NOTE: To be fixed in 0.0.3 using the NotifyIpInterfaceChange API and a dedicated
network mgmt thread.
WORKAROUND: disable any software using WinPCAP, Tap32, or similar devices.
any applications which activate network devices or perform DHCP client
requests must also be disabled. the sysinternals tools from Microsoft can
be used to verify no unexpected access to network interfaces is occuring.
[Automatically added by flyspray2trac: Operating System: All]codermancodermanhttps://gitlab.torproject.org/legacy/trac/-/issues/1067More entropy needed on Qemu VM instantiation2009-08-21T01:20:54ZcodermanMore entropy needed on Qemu VM instantiationQemu is passed a number of kernel parameters which are hashed and added to the host entropy pool
when Tor VM starts up.
The amount of entropy in this approach is less than ideal. CryptGenRandom should be used to add
a sufficient amount ...Qemu is passed a number of kernel parameters which are hashed and added to the host entropy pool
when Tor VM starts up.
The amount of entropy in this approach is less than ideal. CryptGenRandom should be used to add
a sufficient amount of entropy to the command line to ensure a well seeded /dev/[u]random.
To be fixed in 0.0.3.
[Automatically added by flyspray2trac: Operating System: All]codermancoderman