Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:02:42Zhttps://gitlab.torproject.org/legacy/trac/-/issues/1102Queuing v3 signature for next consensus, an hour later?2020-06-13T14:02:42ZRoger DingledineQueuing v3 signature for next consensus, an hour later?On moria1, which I started at
Sep 21 01:51:04.434 (after some parts of the consensus generation were
supposed to start)
Sep 21 01:51:47.809 [notice] Uploaded a vote to dirserver 128.31.0.34:9031
Sep 21 01:51:47.832 [notice] Uploaded a v...On moria1, which I started at
Sep 21 01:51:04.434 (after some parts of the consensus generation were
supposed to start)
Sep 21 01:51:47.809 [notice] Uploaded a vote to dirserver 128.31.0.34:9031
Sep 21 01:51:47.832 [notice] Uploaded a vote to dirserver 216.224.124.114:9030
Sep 21 01:51:47.833 [notice] Uploaded a vote to dirserver 208.83.223.34:443
Sep 21 01:51:48.045 [notice] Uploaded a vote to dirserver 86.59.21.38:80
Sep 21 01:51:48.311 [notice] Uploaded a vote to dirserver 194.109.206.212:80
Sep 21 01:51:49.618 [notice] Uploaded a vote to dirserver 213.73.91.31:80
Sep 21 01:51:49.662 [notice] Uploaded a vote to dirserver 80.190.246.100:80
...
Sep 21 01:52:31.466 [notice] Time to fetch any votes that we're missing.
Sep 21 01:52:31.466 [notice] We're missing votes from 6 authorities. Asking every other authority for a copy.
...
Sep 21 01:55:01.379 [notice] Time to compute a consensus.
Sep 21 01:55:01.586 [notice] Consensus computed; uploading signature(s)
Sep 21 01:55:01.587 [notice] Signature(s) posted.
Sep 21 01:55:01.611 [notice] Got a signature from 128.31.0.34. Adding it to the pending consensus.
Sep 21 01:55:01.612 [notice] Uploaded signature(s) to dirserver 128.31.0.34:9031
Sep 21 01:55:01.763 [notice] Uploaded signature(s) to dirserver 216.224.124.114:9030
Sep 21 01:55:01.770 [notice] Uploaded signature(s) to dirserver 208.83.223.34:443
Sep 21 01:55:01.846 [notice] Uploaded signature(s) to dirserver 86.59.21.38:80
Sep 21 01:55:01.854 [notice] Got a signature from 86.59.21.38. Adding it to the pending consensus.
Sep 21 01:55:01.930 [notice] Uploaded signature(s) to dirserver 194.109.206.212:80
Sep 21 01:55:01.934 [notice] Got a signature from 194.109.206.212. Adding it to the pending consensus.
Sep 21 01:55:02.827 [notice] Got a signature from 208.83.223.34. Adding it to the pending consensus.
Sep 21 01:55:02.869 [notice] Got a signature from 216.224.124.114. Adding it to the pending consensus.
Sep 21 01:55:05.121 [notice] Got a signature from 213.73.91.31. Adding it to the pending consensus.
Sep 21 01:55:05.675 [notice] Uploaded signature(s) to dirserver 213.73.91.31:80
Sep 21 01:55:08.879 [notice] Got a signature from 80.190.246.100. Adding it to the pending consensus.
Sep 21 01:55:09.307 [notice] Uploaded signature(s) to dirserver 80.190.246.100:80
Sep 21 01:57:31.840 [notice] Time to fetch any signatures that we're missing.
Sep 21 02:00:01.204 [notice] Time to publish the consensus and discard old votes
Sep 21 02:00:01.231 [notice] Choosing expected valid-after time as 2009-09-21 07:00:00: consensus_set=1, interval=3600
Sep 21 02:00:01.300 [notice] Consensus published.
Sep 21 02:00:01.301 [notice] Choosing expected valid-after time as 2009-09-21 07:00:00: consensus_set=1, interval=3600
Sep 21 02:00:09.474 [notice] Got a signature from 38.229.70.2. Queuing it for the next consensus.
It's that last line that concerns me. Queuing for the next consensus that's 59 minutes
and 50 seconds from now? Shouldn't we either be adding it to the current consensus even
though it's late, or discarding it because it's late?
(Note that this isn't from an authority that moria1 recognizes)
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/1103circuit_build_times_generate_sample() asserting2020-06-13T14:02:42ZRoger Dingledinecircuit_build_times_generate_sample() assertingApparently running 0.2.2.2-alpha.
<hexa> my relay just died with 15:12:00 [ERR] Bug: circuitbuild.c:576:
circuit_build_times_generate_sample: Assertion q_lo < q_hi failed; aborting.
Looks like we should a) make this not fatal, and b) f...Apparently running 0.2.2.2-alpha.
<hexa> my relay just died with 15:12:00 [ERR] Bug: circuitbuild.c:576:
circuit_build_times_generate_sample: Assertion q_lo < q_hi failed; aborting.
Looks like we should a) make this not fatal, and b) figure out if there's a
further bug.
[Automatically added by flyspray2trac: Operating System: All]Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/1104We should have an option that disables connections to bridge auth and fallback2020-06-13T14:02:43ZSebastian HahnWe should have an option that disables connections to bridge auth and fallback] I meant UpdateBridgesFromAuthority 0
] Or does that not prevent connections to the Authority?
] If it doesn't, I think we should have some config option that means
"never talk to the bridge authority". Else it's easier to spot that
...] I meant UpdateBridgesFromAuthority 0
] Or does that not prevent connections to the Authority?
] If it doesn't, I think we should have some config option that means
"never talk to the bridge authority". Else it's easier to spot that
someone is trying to use Tor
arma] right. we've never really solved that part of the problem. i
figured i'd do it once somebody blocks it.
arma] whether tor decides to go to the bridge authority directly
depends on a couple of things.
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/1105Proxy-Server refuses connection2009-11-17T04:41:12ZTracProxy-Server refuses connectionI installed Torbutton v1.2.2 on Firefox v3.5.1 with recommeded proxy adjustments and privoxy use.
but :
- Tor proxy test failed with "Internal error" and [Java Script - Anwendung] popup
- when enabling the Torbutton I can't load any web...I installed Torbutton v1.2.2 on Firefox v3.5.1 with recommeded proxy adjustments and privoxy use.
but :
- Tor proxy test failed with "Internal error" and [Java Script - Anwendung] popup
- when enabling the Torbutton I can't load any web page anymore even after restarting Firefox. I always get the failure message
"Fehler: Proxy-Server verweigert die Verbindung
Firefox wurde konfiguriert, einen Proxy-Server zu nutzen, der die Verbindung zurückweist."
- when enabling the Torbutton I don't see a privoxy task running in the Windows task list
My PC is using Windows XP with Avira Antivir software and a WLAN router firewall.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: boxterhttps://gitlab.torproject.org/legacy/trac/-/issues/1106More information after Settings Test fail2010-05-27T06:28:07ZTracMore information after Settings Test failWhen I click "test settings" in the torbutton preferences window, it tells me:
"Tor proxy test FAILED! Check your proxy and Privoxy settings."
...This doesn't help me figure anything out.
I have tor running through vidalia, and its log ...When I click "test settings" in the torbutton preferences window, it tells me:
"Tor proxy test FAILED! Check your proxy and Privoxy settings."
...This doesn't help me figure anything out.
I have tor running through vidalia, and its log says:
"[Notice] Tor has successfully opened a circuit. Looks like client functionality is working."
I have privoxy running.
Netstat shows listening ports open on 8118, 9050, and 9051.
I wish the test failure message gave information about what failed, so I'd know where to look.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: phiphttps://gitlab.torproject.org/legacy/trac/-/issues/1107PublishServerDescriptor allows options 0 and 1 simultaneously2020-06-13T14:02:43ZSebastian HahnPublishServerDescriptor allows options 0 and 1 simultaneouslyThat doesn't make sense, and I think we should reject a config like that.
[Automatically added by flyspray2trac: Operating System: All]That doesn't make sense, and I think we should reject a config like that.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1108Assertion Failed2020-06-13T14:02:44ZTracAssertion FailedI have to roll back to version 0.2.1.19-alpha
cause version 0.2.2.2-alpha did not start
[code]
Sep 28 11:04:21.640 [Notice] Tor v0.2.2.2-alpha (git-54ba86d9d0cff2ce). This is experimental software. Do not rely on it for strong anon...I have to roll back to version 0.2.1.19-alpha
cause version 0.2.2.2-alpha did not start
[code]
Sep 28 11:04:21.640 [Notice] Tor v0.2.2.2-alpha (git-54ba86d9d0cff2ce). This is experimental software. Do not rely on it for strong anonymity. (Running on Windows XP Service Pack 3 [workstation] {terminal services, single user})
Sep 28 11:04:21.750 [Notice] Initialized libevent version 1.4.12-stable using method win32. Good.
Sep 28 11:04:21.750 [Notice] Opening OR listener on 0.0.0.0:9001
Sep 28 11:04:21.750 [Notice] Opening Directory listener on 0.0.0.0:563
Sep 28 11:04:21.750 [Notice] Opening Socks listener on 127.0.0.1:9050
Sep 28 11:04:21.750 [Notice] Opening Socks listener on 192.168.254.1:9050
Sep 28 11:04:21.750 [Notice] Opening DNS listener on 127.0.0.1:53
Sep 28 11:04:21.750 [Notice] Opening Control listener on 127.0.0.1:9051
Sep 28 11:04:21.796 [Error] Bug: circuitbuild.c:380: circuit_build_times_shuffle_array: Assertion cbt->total_build_times == cbt->build_times_idx failed; aborting.
Sep 28 11:05:28.062 [Notice] Tor v0.2.2.2-alpha (git-54ba86d9d0cff2ce). This is experimental software. Do not rely on it for strong anonymity. (Running on Windows XP Service Pack 3 [workstation] {terminal services, single user})
Sep 28 11:05:28.171 [Notice] Initialized libevent version 1.4.12-stable using method win32. Good.
Sep 28 11:05:28.171 [Notice] Opening OR listener on 0.0.0.0:9001
Sep 28 11:05:28.171 [Notice] Opening Directory listener on 0.0.0.0:563
Sep 28 11:05:28.171 [Notice] Opening Socks listener on 127.0.0.1:9050
Sep 28 11:05:28.171 [Notice] Opening Socks listener on 192.168.254.1:9050
Sep 28 11:05:28.171 [Notice] Opening DNS listener on 127.0.0.1:53
Sep 28 11:05:28.171 [Notice] Opening Control listener on 127.0.0.1:9051
Sep 28 11:05:28.218 [Error] Bug: circuitbuild.c:380: circuit_build_times_shuffle_array: Assertion cbt->total_build_times == cbt->build_times_idx failed; aborting.
Sep 28 11:08:06.468 [Notice] Tor v0.2.2.2-alpha (git-54ba86d9d0cff2ce). This is experimental software. Do not rely on it for strong anonymity. (Running on Windows XP Service Pack 3 [workstation] {terminal services, single user})
Sep 28 11:08:06.468 [Notice] Initialized libevent version 1.4.12-stable using method win32. Good.
Sep 28 11:08:06.468 [Notice] Opening OR listener on 0.0.0.0:9001
Sep 28 11:08:06.562 [Notice] Opening Directory listener on 0.0.0.0:563
Sep 28 11:08:06.562 [Notice] Opening Socks listener on 127.0.0.1:9050
Sep 28 11:08:06.562 [Notice] Opening Socks listener on 192.168.254.1:9050
Sep 28 11:08:06.562 [Notice] Opening DNS listener on 127.0.0.1:53
Sep 28 11:08:06.562 [Notice] Opening Control listener on 127.0.0.1:9051
[/code]
Thanks
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: crphttps://gitlab.torproject.org/legacy/trac/-/issues/1109Assertion Failed2020-06-13T14:02:44ZTracAssertion FailedI was´nt able to re-open , nor to add data to task 1108
thus, I am reporting this again
thanks
> Sep 28 15:06:13.968 [Notice] Tor v0.2.2.3-alpha
> (git-0f3417d1dbffdf7a). This is experimental software. Do not rely on
> it for strong a...I was´nt able to re-open , nor to add data to task 1108
thus, I am reporting this again
thanks
> Sep 28 15:06:13.968 [Notice] Tor v0.2.2.3-alpha
> (git-0f3417d1dbffdf7a). This is experimental software. Do not rely on
> it for strong anonymity. (Running on Windows XP Service Pack 3
> [workstation] {terminal services, single user})
> Sep 28 15:06:14.187 [Notice] Initialized libevent version
> 1.4.12-stable using method win32. Good.
> Sep 28 15:06:14.187 [Notice] Opening OR listener on 0.0.0.0:9001
> Sep 28 15:06:14.296 [Notice] Opening Directory listener on 0.0.0.0:563
> Sep 28 15:06:14.406 [Notice] Opening Socks listener on 127.0.0.1:9050
> Sep 28 15:06:14.406 [Notice] Opening Socks listener on 192.168.254.1:9050
> Sep 28 15:06:14.406 [Notice] Opening DNS listener on 127.0.0.1:53
> Sep 28 15:06:14.406 [Notice] Opening Control listener on 127.0.0.1:9051
> Sep 28 15:06:14.437 [Error] Bug: circuitbuild.c:380:
> circuit_build_times_shuffle_array: Assertion cbt->total_build_times ==
> cbt->build_times_idx failed; aborting.
> Sep 28 15:07:19.296 [Notice] Tor v0.2.2.3-alpha
> (git-0f3417d1dbffdf7a). This is experimental software. Do not rely on
> it for strong anonymity. (Running on Windows XP Service Pack 3
> [workstation] {terminal services, single user})
> Sep 28 15:07:19.406 [Notice] Initialized libevent version
> 1.4.12-stable using method win32. Good.
> Sep 28 15:07:19.406 [Notice] Opening OR listener on 0.0.0.0:9001
> Sep 28 15:07:19.406 [Notice] Opening Directory listener on 0.0.0.0:563
> Sep 28 15:07:19.406 [Notice] Opening Socks listener on 127.0.0.1:9050
> Sep 28 15:07:19.406 [Notice] Opening Socks listener on 192.168.254.1:9050
> Sep 28 15:07:19.406 [Notice] Opening DNS listener on 127.0.0.1:53
> Sep 28 15:07:19.406 [Notice] Opening Control listener on 127.0.0.1:9051
> Sep 28 15:07:19.453 [Error] Bug: circuitbuild.c:380:
> circuit_build_times_shuffle_array: Assertion cbt->total_build_times ==
> cbt->build_times_idx failed; aborting.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: crphttps://gitlab.torproject.org/legacy/trac/-/issues/1110Popup box asking about language preference2020-10-18T15:00:07ZRoger DingledinePopup box asking about language preferenceSome Torbutton users complain that Tor is "english only", because it forces
you to ask for en pages. There's a checkbox to disable it, sure, but it's
hard to find and hard to know about.
How about Torbutton checks on its first start if ...Some Torbutton users complain that Tor is "english only", because it forces
you to ask for en pages. There's a checkbox to disable it, sure, but it's
hard to find and hard to know about.
How about Torbutton checks on its first start if your language prefs are
non-English, and pops up a dialog box:
"You have set your language preference to %s. Should I keep you safe
by making you blend together with all the other Torbutton users, or should I let
you use your own language?"
[Automatically added by flyspray2trac: Operating System: All]Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/1111assert on start up of 0.2.2.3-alpha2020-06-13T14:02:45ZAndrew Lewmanassert on start up of 0.2.2.3-alphaOn start up, Oct 02 07:38:44.749 [Error] Bug: circuitbuild.c:380: circuit_build_times_shuffle_array:
Assertion cbt->total_build_times == cbt->build_times_idx failed; aborting.
full log is:
Oct 02 07:42:06.995 [notice] Initialized libev...On start up, Oct 02 07:38:44.749 [Error] Bug: circuitbuild.c:380: circuit_build_times_shuffle_array:
Assertion cbt->total_build_times == cbt->build_times_idx failed; aborting.
full log is:
Oct 02 07:42:06.995 [notice] Initialized libevent version 1.3e using method epoll. Good.
Oct 02 07:42:06.995 [notice] Opening Socks listener on 127.0.0.1:9050
Oct 02 07:42:06.995 [notice] Opening Control listener on 127.0.0.1:9051
Oct 02 07:42:07.011 [err] Bug: circuitbuild.c:380: circuit_build_times_shuffle_array: Assertion cbt->total_build_times == cbt->build_times_idx failed; aborting.
(gdb) bt
#0 0x00007ffe9e44afb5 in raise () from /lib/libc.so.6
#1 0x00007ffe9e44cbc3 in abort () from /lib/libc.so.6
#2 0x000000000040feb0 in circuit_build_times_parse_state (cbt=0x719f00, state=0x8918b0, msg=0x7fffa7a56a38) at circuitbuild.c:380
#3 0x0000000000425fbb in set_options (new_val=<value optimized out>, msg=<value optimized out>) at config.c:5075
#4 0x0000000000426561 in options_init_from_string (
cf=0x87d540 "# This file was generated by Tor; if you edit it, comments will not be preserved\n# The old torrc file was renamed to torrc.orig.1 or similar, and Tor will ignore it\n\nBridge 97.107.129.143:80 06008EDA5"..., command=<value optimized out>, command_arg=0x0, msg=0x7fffa7a56b40) at config.c:4287
#5 0x000000000042696a in options_init_from_torrc (argc=3, argv=0x7fffa7a56dd8) at config.c:4161
#6 0x0000000000463115 in tor_init (argc=3, argv=0x7fffa7a56dd8) at main.c:1873
#7 0x0000000000466d16 in tor_main (argc=3, argv=<value optimized out>) at main.c:2120
#8 0x00007ffe9e4365a6 in __libc_start_main () from /lib/libc.so.6
#9 0x0000000000407819 in _start () at ../sysdeps/x86_64/elf/start.S:113
[Automatically added by flyspray2trac: Operating System: Other Linux]https://gitlab.torproject.org/legacy/trac/-/issues/1112Tor can´t open directory2020-06-13T14:02:45ZTracTor can´t open directoryAfter I installed Tor it ran. (I wanted to create a bridge, as requested in the blog ). After restarted the computer,
it doesn´t work. The message protocol says :
Okt 03 00:35:24.218 [Warnung] Error creating directory "C:\\Dokumente und...After I installed Tor it ran. (I wanted to create a bridge, as requested in the blog ). After restarted the computer,
it doesn´t work. The message protocol says :
Okt 03 00:35:24.218 [Warnung] Error creating directory "C:\\Dokumente und Einstellungen\\*****\366rg\\Anwendungsdaten\\tor": Invalid argument
Okt 03 00:35:24.218 [Warnung] Failed to parse/validate config: Couldn't access/create private data directory ""C:\\Dokumente und Einstellungen\\*****\366rg\\Anwendungsdaten\\tor""
Okt 03 00:35:24.218 [Fehler] Reading config failed--see warnings above.
Im not the only one, this question I found, but it wasn´t solved:
http://www.multimediaxis.de/showthread.php?t=119538
Also other directorys I can´t open to write since then.
But I´ll wait for an answer, before I try to deinstall tor.
MfG h
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: hhttps://gitlab.torproject.org/legacy/trac/-/issues/1113Bridge relays should deny all exits by default2020-06-13T14:02:46ZSebastian HahnBridge relays should deny all exits by defaultI think we should make it explicit that Bridges are entry points into
the Tor network, and not allow the default exit policy if no ExitPolicy
line is given.
Does that sound plausible?
[Automatically added by flyspray2trac: Operating Sy...I think we should make it explicit that Bridges are entry points into
the Tor network, and not allow the default exit policy if no ExitPolicy
line is given.
Does that sound plausible?
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/1114DH key warn message2020-06-13T14:02:46ZTracDH key warn messageHello,
got this warnings on Debian Etch with Tor 0.2.0.35:
Sep 19 06:00:09.581 [warn] DH key must be at least 2.
Sep 19 06:00:09.581 [warn] Rejecting insecure DH key [0]
Sep 19 06:00:09.581 [warn] Rejected invalid g!^x
Sep 21 08:25:16....Hello,
got this warnings on Debian Etch with Tor 0.2.0.35:
Sep 19 06:00:09.581 [warn] DH key must be at least 2.
Sep 19 06:00:09.581 [warn] Rejecting insecure DH key [0]
Sep 19 06:00:09.581 [warn] Rejected invalid g!^x
Sep 21 08:25:16.213 [warn] DH key must be at least 2.
Sep 21 08:25:16.213 [warn] Rejecting insecure DH key [0]
Sep 21 08:25:16.213 [warn] Rejected invalid g!^x
Sep 24 05:22:43.076 [warn] DH key must be at least 2.
Sep 24 05:22:43.077 [warn] Rejecting insecure DH key [0]
Sep 24 05:22:43.077 [warn] Rejected invalid g!^x
Sep 27 15:15:39.650 [warn] DH key must be at least 2.
Sep 27 15:15:39.650 [warn] Rejecting insecure DH key [0]
Sep 27 15:15:39.650 [warn] Rejected invalid g!^x
Sep 28 09:13:31.569 [warn] DH key must be at least 2.
Sep 28 09:13:31.569 [warn] Rejecting insecure DH key [0]
Sep 28 09:13:31.569 [warn] Rejected invalid g!^x
Sep 28 12:13:14.071 [warn] DH key must be at least 2.
Sep 28 12:13:14.071 [warn] Rejecting insecure DH key [0]
Sep 28 12:13:14.071 [warn] Rejected invalid g!^x
Sep 28 19:41:23.658 [warn] DH key must be at least 2.
Sep 28 19:41:23.659 [warn] Rejecting insecure DH key [0]
Sep 28 19:41:23.659 [warn] Rejected invalid g!^x
And also on Debian Lenny with Tor 0.2.2.3-alpha:
Sep 30 07:50:05.236 [warn] DH key must be at least 2.
Sep 30 07:50:05.236 [warn] Rejecting insecure DH key [0]
Sep 30 07:50:05.236 [warn] Rejected invalid g!^x
Oct 06 02:51:08.319 [warn] DH key must be at least 2.
Oct 06 02:51:08.319 [warn] Rejecting insecure DH key [0]
Oct 06 02:51:08.319 [warn] Rejected invalid g!^x
Anoyone else seeing them?
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: dragonflyhttps://gitlab.torproject.org/legacy/trac/-/issues/1115jqnotify.exe starting with tbb-firefox.exe2020-06-12T23:40:12ZTracjqnotify.exe starting with tbb-firefox.exeJava Quick Starter...
When Tor Browser Bundle starts and tbb-firefox.exe loads, tbb-firefox.exe scans the host registry for installed Add-Ons
at the following locations[1]:
HKEY_CURRENT_USER\Software\Mozilla\Firefox\Extensions\
HKEY_...Java Quick Starter...
When Tor Browser Bundle starts and tbb-firefox.exe loads, tbb-firefox.exe scans the host registry for installed Add-Ons
at the following locations[1]:
HKEY_CURRENT_USER\Software\Mozilla\Firefox\Extensions\
HKEY_LOCAL_MACHINE\Software\Mozilla\Firefox\Extensions\
If Java Plantform is installed on the host system it writes a registry value to one, or both, of those of those keys.
The registry value is the plugin "Java Quick Starter", and the value is named "jq@sun.com". The hard path to the file
is "C:\Program Files\Java\jre6\lib\deploy\jqs\ff".
Those two registry keys have been vectors for malware attacks to firefox via. add-ons in the past[1]...
Using the Sysinternals application "Process Explorer" one can watch in real-time as the file "jqnotify.exe" is called by
tbb-firefox.exe. One needs to pay attention, because it loads and then closes in a second or two. I apply this setting
in Process Explorer "View > Show New Process" so each new process called gets a highlighted color, makes seeing the files
sudden appearance easier. I am unsure how far back this has been a problem with Java Platform, version wise. But it's
been a problem for while at least.
When I start TBB in a sandbox I used to get errors about "jsnotify.exe" trying to access the "internet". Well, if I
am correct, and I could be wrong, jsnotify.exe doesn't connect to the internet, but does try to access the pipe
"\Device\Afd\Endpoint". That is when it hits the sandbox walls facing the internet.
To fix this I just prevent any application within the sandbox from reading those two keys. Maybe someone can hack the
firefoxportable which ships with TBB so it won't read those two keys? That seems like a good solution, though I have
no idea if it's 'hard' to accomplish or not.
From what Phobos said last night, TBB currently disables the "Java Quick Starter" Add-On in firefoxportable. But,
uninstalling the Add-On is not possible, it's always grayed out. That is a trick by Java Platform to prevent the
removal of their Add-On. If a user wants to remove the Add-On from their registry all they do is delete the value
"js@sun.com" and then configure the Java GUI to not load Java Quick Starter. OTOH, simply deleting the registry
value "js@sun.com" might be enough, I'll try to see if I can get Java to reinstall the Add-On into my registry and play
with it a bit more.
Here are some relevant threads from Mozilla and other pieces of background info, etc:
http://support.mozilla.com/tiki-view_forum_thread.php?locale=lt&comments_parentId=362460&forumId=1
http://forums.mozillazine.org/viewtopic.php?f=38&t=921325&sid=515e4e29b64ba8c12e52c5ce15504d40
Good forum post with registry info on removing the Java Add-on:
http://forums.mozillazine.org/viewtopic.php?p=4837715#p4837715
[1] http://kb.mozillazine.org/Uninstalling_add-ons#Windows_Registry_extension
Contact me at IRC if you need more info. I should be around the next few days at least.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: SandyAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/legacy/trac/-/issues/1116'Stable' flag assignment inconsistant2020-06-13T14:02:47ZTom Lowenthal'Stable' flag assignment inconsistantLooking at a consensus document [though I used torstatus.all.de for ease of sorting data] it seems that the 'stable' flag
is not being consistently assigned.
According to the v3 directory specification at https://git.torproject.org/che...Looking at a consensus document [though I used torstatus.all.de for ease of sorting data] it seems that the 'stable' flag
is not being consistently assigned.
According to the v3 directory specification at https://git.torproject.org/checkout/tor/master/doc/spec/dir-spec.txt ,
routers with a weighted MTBF more than either the median or seven days should be marked stable, and MTBF data more
than a month old shouldn't be that relevant when assigning the flag. Since the median uptime is about 3 days, one should
roughly expect that any router with more than 30 days of uptime (and which are still valid) should have the stable flag.
However when relays are sorted in order of uptime, several apparently-longrunning routers do not have the flag.
Since this data is liable to change as relays go up an down, here are some noted not-'stable' routers at the time of
writing. The routers have uptimes more than a month, so their (correctly) weighted MTBF should certainly be more than
a week, and more than the median, about three days.
wie6ud6be - 148d
anonymde - 112d
torpfaffenederorg - 110d
rentalsponge - 70d
xhyG5r96QGlRqL - 57d
niugnip - 56d
oeiwuqej - 49d
gremlin - 42d
editingconfigishard - 39d
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/1117bridge authorities mark every bridge stable+guard2020-06-13T14:02:47ZRoger Dingledinebridge authorities mark every bridge stable+guardTonga lists every bridge as Stable and Guard.
Nick suggests this is because "bridge authorities don't count a
bridge as having Failed for MTBF purposes when they find it to be
non-Running"
[Automatically added by flyspray2trac: Operati...Tonga lists every bridge as Stable and Guard.
Nick suggests this is because "bridge authorities don't count a
bridge as having Failed for MTBF purposes when they find it to be
non-Running"
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedMatthew FinkelMatthew Finkelhttps://gitlab.torproject.org/legacy/trac/-/issues/11180.2.2.4 fails to compile on osx x862020-06-13T14:02:48ZAndrew Lewman0.2.2.4 fails to compile on osx x86gcc -DHAVE_CONFIG_H -I. -I../.. -DSHARE_DATADIR="\"/Library/Tor/share\"" -DLOCALSTATEDIR="\"/Library/Tor/var\"" -DBINDIR="\"/Library/Tor\"" -I../../src/common -I/usr/local/include -I../or -O -g -mmacosx-version-min=10.4 -isysroot /Dev...gcc -DHAVE_CONFIG_H -I. -I../.. -DSHARE_DATADIR="\"/Library/Tor/share\"" -DLOCALSTATEDIR="\"/Library/Tor/var\"" -DBINDIR="\"/Library/Tor\"" -I../../src/common -I/usr/local/include -I../or -O -g -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -Wall -g -O2 -fno-strict-aliasing -c test.c
test.c:46:18: error: test.h: No such file or directory
test.c: In function ‘test_buffers’:
test.c:181: warning: implicit declaration of function ‘test_fail’
test.c:184: warning: implicit declaration of function ‘test_eq’
test.c:196: warning: implicit declaration of function ‘test_memeq’
test.c:400: warning: label ‘done’ defined but not used
test.c: In function ‘test_onion_handshake’:
test.c:427: warning: implicit declaration of function ‘test_assert’
test.c:445: warning: implicit declaration of function ‘test_memneq’
test.c:447: warning: label ‘done’ defined but not used
test.c: In function ‘test_circuit_timeout’:
test.c:612: warning: label ‘done’ defined but not used
test.c: In function ‘test_policy_summary_helper’:
test.c:637: warning: implicit declaration of function ‘test_streq’
test.c:639: warning: label ‘done’ defined but not used
test.c: In function ‘test_policies’:
test.c:792: warning: label ‘done’ defined but not used
test.c: In function ‘test_rend_fns’:
test.c:998: warning: label ‘done’ defined but not used
test.c: In function ‘test_geoip’:
test.c:1071: warning: label ‘done’ defined but not used
test.c: At top level:
test.c:1076: warning: ‘struct testcase_t’ declared inside parameter list
test.c:1076: warning: its scope is only this definition or declaration, which is probably not what you want
test.c: In function ‘legacy_test_setup’:
test.c:1078: error: dereferencing pointer to incomplete type
test.c: At top level:
test.c:1089: warning: ‘struct testcase_t’ declared inside parameter list
test.c:1096: error: variable ‘legacy_setup’ has initializer but incomplete type
test.c:1097: warning: excess elements in struct initializer
test.c:1097: warning: (near initialization for ‘legacy_setup’)
test.c:1098: warning: excess elements in struct initializer
test.c:1098: warning: (near initialization for ‘legacy_setup’)
test.c:1108: error: array type has incomplete element type
test.c:1116: error: ‘TT_SKIP’ undeclared here (not in a function)
test.c:1119: error: ‘END_OF_TESTCASES’ undeclared here (not in a function)
test.c:1121: error: array type has incomplete element type
test.c:1122: error: array type has incomplete element type
test.c:1123: error: array type has incomplete element type
test.c:1124: error: array type has incomplete element type
test.c:1125: error: array type has incomplete element type
test.c:1127: error: array type has incomplete element type
test.c:1135: error: ‘END_OF_GROUPS’ undeclared here (not in a function)
test.c: In function ‘main’:
test.c:1199: warning: implicit declaration of function ‘tinytest_main’
make[4]: *** [test.o] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [dist-osx] Error 2
[Automatically added by flyspray2trac: Operating System: OSX 10.5 Leopard]https://gitlab.torproject.org/legacy/trac/-/issues/1119Tor 0.2.2.4-alpha build failure2020-06-13T14:02:49ZAndrew LewmanTor 0.2.2.4-alpha build failuregcc -DHAVE_CONFIG_H -I. -I../.. -DSHARE_DATADIR="\"/Library/Tor/share\"" -DLOCALSTATEDIR="\"/Library/Tor/var\"" -DBINDIR="\"/Library/Tor\"" -I../../src/common -I../or -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT test.o -MD -MP -MF .d...gcc -DHAVE_CONFIG_H -I. -I../.. -DSHARE_DATADIR="\"/Library/Tor/share\"" -DLOCALSTATEDIR="\"/Library/Tor/var\"" -DBINDIR="\"/Library/Tor\"" -I../../src/common -I../or -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT test.o -MD -MP -MF .deps/test.Tpo -c -o test.o test.c
test.c:46:18: test.h: No such file or directory
test.c: In function `test_buffers':
test.c:181: warning: implicit declaration of function `test_fail'
test.c:184: warning: implicit declaration of function `test_eq'
test.c:196: warning: implicit declaration of function `test_memeq'
test.c:400: warning: label `done' defined but not used
test.c: In function `test_onion_handshake':
test.c:427: warning: implicit declaration of function `test_assert'
test.c:445: warning: implicit declaration of function `test_memneq'
test.c:447: warning: label `done' defined but not used
test.c: In function `test_circuit_timeout':
test.c:612: warning: label `done' defined but not used
test.c: In function `test_policy_summary_helper':
test.c:637: warning: implicit declaration of function `test_streq'
test.c:639: warning: label `done' defined but not used
test.c: In function `test_policies':
test.c:792: warning: label `done' defined but not used
test.c: In function `test_rend_fns':
test.c:998: warning: label `done' defined but not used
test.c: In function `test_geoip':
test.c:1071: warning: label `done' defined but not used
test.c: In function `legacy_test_setup':
test.c:1078: error: dereferencing pointer to incomplete type
test.c: At top level:
test.c:1096: error: variable `legacy_setup' has initializer but incomplete type
test.c:1097: warning: excess elements in struct initializer
test.c:1097: warning: (near initialization for `legacy_setup')
test.c:1098: warning: excess elements in struct initializer
test.c:1098: warning: (near initialization for `legacy_setup')
test.c:1108: error: elements of array `test_array' have incomplete type
test.c:1109: warning: excess elements in struct initializer
test.c:1109: warning: (near initialization for `test_array[0]')
test.c:1109: warning: excess elements in struct initializer
test.c:1109: warning: (near initialization for `test_array[0]')
test.c:1109: warning: excess elements in struct initializer
test.c:1109: warning: (near initialization for `test_array[0]')
test.c:1109: warning: excess elements in struct initializer
test.c:1109: warning: (near initialization for `test_array[0]')
test.c:1109: warning: excess elements in struct initializer
test.c:1109: warning: (near initialization for `test_array[0]')
test.c:1110: warning: excess elements in struct initializer
test.c:1110: warning: (near initialization for `test_array[1]')
test.c:1110: warning: excess elements in struct initializer
test.c:1110: warning: (near initialization for `test_array[1]')
test.c:1110: warning: excess elements in struct initializer
test.c:1110: warning: (near initialization for `test_array[1]')
test.c:1110: warning: excess elements in struct initializer
test.c:1110: warning: (near initialization for `test_array[1]')
test.c:1110: warning: excess elements in struct initializer
test.c:1110: warning: (near initialization for `test_array[1]')
test.c:1111: warning: excess elements in struct initializer
test.c:1111: warning: (near initialization for `test_array[2]')
test.c:1111: warning: excess elements in struct initializer
test.c:1111: warning: (near initialization for `test_array[2]')
test.c:1111: warning: excess elements in struct initializer
test.c:1111: warning: (near initialization for `test_array[2]')
test.c:1111: warning: excess elements in struct initializer
test.c:1111: warning: (near initialization for `test_array[2]')
test.c:1111: warning: excess elements in struct initializer
test.c:1111: warning: (near initialization for `test_array[2]')
test.c:1112: warning: excess elements in struct initializer
test.c:1112: warning: (near initialization for `test_array[3]')
test.c:1112: warning: excess elements in struct initializer
test.c:1112: warning: (near initialization for `test_array[3]')
test.c:1112: warning: excess elements in struct initializer
test.c:1112: warning: (near initialization for `test_array[3]')
test.c:1112: warning: excess elements in struct initializer
test.c:1112: warning: (near initialization for `test_array[3]')
test.c:1112: warning: excess elements in struct initializer
test.c:1112: warning: (near initialization for `test_array[3]')
test.c:1113: warning: excess elements in struct initializer
test.c:1113: warning: (near initialization for `test_array[4]')
test.c:1113: warning: excess elements in struct initializer
test.c:1113: warning: (near initialization for `test_array[4]')
test.c:1113: warning: excess elements in struct initializer
test.c:1113: warning: (near initialization for `test_array[4]')
test.c:1113: warning: excess elements in struct initializer
test.c:1113: warning: (near initialization for `test_array[4]')
test.c:1113: warning: excess elements in struct initializer
test.c:1113: warning: (near initialization for `test_array[4]')
test.c:1114: warning: excess elements in struct initializer
test.c:1114: warning: (near initialization for `test_array[5]')
test.c:1114: warning: excess elements in struct initializer
test.c:1114: warning: (near initialization for `test_array[5]')
test.c:1114: warning: excess elements in struct initializer
test.c:1114: warning: (near initialization for `test_array[5]')
test.c:1114: warning: excess elements in struct initializer
test.c:1114: warning: (near initialization for `test_array[5]')
test.c:1114: warning: excess elements in struct initializer
test.c:1114: warning: (near initialization for `test_array[5]')
test.c:1116: warning: excess elements in struct initializer
test.c:1116: warning: (near initialization for `test_array[6]')
test.c:1116: warning: excess elements in struct initializer
test.c:1116: warning: (near initialization for `test_array[6]')
test.c:1116: error: `TT_SKIP' undeclared here (not in a function)
test.c:1116: warning: excess elements in struct initializer
test.c:1116: warning: (near initialization for `test_array[6]')
test.c:1116: warning: excess elements in struct initializer
test.c:1116: warning: (near initialization for `test_array[6]')
test.c:1116: warning: excess elements in struct initializer
test.c:1116: warning: (near initialization for `test_array[6]')
test.c:1117: warning: excess elements in struct initializer
test.c:1117: warning: (near initialization for `test_array[7]')
test.c:1117: warning: excess elements in struct initializer
test.c:1117: warning: (near initialization for `test_array[7]')
test.c:1117: error: `TT_SKIP' undeclared here (not in a function)
test.c:1117: warning: excess elements in struct initializer
test.c:1117: warning: (near initialization for `test_array[7]')
test.c:1117: warning: excess elements in struct initializer
test.c:1117: warning: (near initialization for `test_array[7]')
test.c:1117: warning: excess elements in struct initializer
test.c:1117: warning: (near initialization for `test_array[7]')
test.c:1119: error: `END_OF_TESTCASES' undeclared here (not in a function)
test.c:1119: error: initializer element is not constant
test.c:1119: error: (near initialization for `test_array[8]')
test.c:1127: error: elements of array `testgroups' have incomplete type
test.c:1128: warning: excess elements in struct initializer
test.c:1128: warning: (near initialization for `testgroups[0]')
test.c:1128: warning: excess elements in struct initializer
test.c:1128: warning: (near initialization for `testgroups[0]')
test.c:1129: warning: excess elements in struct initializer
test.c:1129: warning: (near initialization for `testgroups[1]')
test.c:1129: warning: excess elements in struct initializer
test.c:1129: warning: (near initialization for `testgroups[1]')
test.c:1130: warning: excess elements in struct initializer
test.c:1130: warning: (near initialization for `testgroups[2]')
test.c:1130: warning: excess elements in struct initializer
test.c:1130: warning: (near initialization for `testgroups[2]')
test.c:1131: warning: excess elements in struct initializer
test.c:1131: warning: (near initialization for `testgroups[3]')
test.c:1131: warning: excess elements in struct initializer
test.c:1131: warning: (near initialization for `testgroups[3]')
test.c:1132: warning: excess elements in struct initializer
test.c:1132: warning: (near initialization for `testgroups[4]')
test.c:1132: warning: excess elements in struct initializer
test.c:1132: warning: (near initialization for `testgroups[4]')
test.c:1133: warning: excess elements in struct initializer
test.c:1133: warning: (near initialization for `testgroups[5]')
test.c:1133: warning: excess elements in struct initializer
test.c:1133: warning: (near initialization for `testgroups[5]')
test.c:1135: error: `END_OF_GROUPS' undeclared here (not in a function)
test.c:1135: error: initializer element is not constant
test.c:1135: error: (near initialization for `testgroups[6]')
test.c: In function `main':
test.c:1199: warning: implicit declaration of function `tinytest_main'
../or/or.h: At top level:
test.c:1096: error: storage size of `legacy_setup' isn't known
make[4]: *** [test.o] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [dist-osx] Error 2
[Automatically added by flyspray2trac: Operating System: OSX 10.3 Panther]https://gitlab.torproject.org/legacy/trac/-/issues/1120Private Browsing mode enforces Tor switched on2010-06-22T23:35:18ZTracPrivate Browsing mode enforces Tor switched onFirst of all, let me thank you for your wonderful work. Privacy matters!
Recently, Firefox received a private browsing mode.
I propose an additional configuration option for Tor button, that enforces that Tor is enabled in private brow...First of all, let me thank you for your wonderful work. Privacy matters!
Recently, Firefox received a private browsing mode.
I propose an additional configuration option for Tor button, that enforces that Tor is enabled in private browsing mode.
You're hitting CTRL-SHIFT-P and get the private browsing in conjunction with Tor.
You already seem to have provisions to enforce the Tor button's state.
What's probably missing is the hook in private browsing function of Firefox.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: TonyTorhttps://gitlab.torproject.org/legacy/trac/-/issues/1121reason unexpected while uploading descriptor2020-06-13T14:02:49ZTracreason unexpected while uploading descriptorHi,
since i upgraded my relay to 0.2.2.5-alpha i am getting these warn message below.
Oct 12 13:15:10.985 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Oct 12 13:15:18.207 [notice] Tor has successfully opened a circuit. Looks...Hi,
since i upgraded my relay to 0.2.2.5-alpha i am getting these warn message below.
Oct 12 13:15:10.985 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Oct 12 13:15:18.207 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Oct 12 13:15:18.207 [notice] Bootstrapped 100%: Done.
Oct 12 13:16:09.666 [warn] http status 404 ("Not Found") reason unexpected while uploading descriptor to server '194.109.206.212:80').
Oct 12 13:16:17.277 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent.
Oct 12 13:16:18.508 [notice] Performing bandwidth self-test...done.
Oct 12 13:17:10.924 [warn] http status 404 ("Not Found") reason unexpected while uploading descriptor to server '194.109.206.212:80').
Oct 12 13:23:16.169 [warn] http status 404 ("Not Found") reason unexpected while uploading descriptor to server '194.109.206.212:80').
Some kind of new bug?
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: dragonflyTor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1122reachability and bandwidth tests are not carried over2020-06-13T14:02:50ZTracreachability and bandwidth tests are not carried overhello, i run Kubuntu 9.10 x86 64 ,
commit 4b55ef26c93c5cadd866ca0be1e65547df7b6031 on branch origin/master 0.2.2.5 alpha
since last update, the tests of reachability and bandwidth are not carried over.. i think all tests are not exe...hello, i run Kubuntu 9.10 x86 64 ,
commit 4b55ef26c93c5cadd866ca0be1e65547df7b6031 on branch origin/master 0.2.2.5 alpha
since last update, the tests of reachability and bandwidth are not carried over.. i think all tests are not executed for unknown reason .
i run as Bridge server
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: starshttps://gitlab.torproject.org/legacy/trac/-/issues/1123Error parsing ListenAddress [::1]2020-06-13T14:02:50ZTracError parsing ListenAddress [::1]tor refuses to listen on an ipv6 address
Oct 15 18:33:37.140 [Notice] Tor v0.2.2.5-alpha (git-255245a2891cfa56). This is experimental software. Do not rely on it for strong anonymity. (Running on Windows XP Service Pack 3 [workstation] ...tor refuses to listen on an ipv6 address
Oct 15 18:33:37.140 [Notice] Tor v0.2.2.5-alpha (git-255245a2891cfa56). This is experimental software. Do not rely on it for strong anonymity. (Running on Windows XP Service Pack 3 [workstation] {terminal services, single user})
Oct 15 18:33:37.250 [Warning] Port ":1]" out of range
Oct 15 18:33:37.312 [Notice] Initialized libevent version 1.4.12-stable using method win32. Good.
Oct 15 18:33:37.312 [Notice] Opening OR listener on 0.0.0.0:9001
Oct 15 18:33:37.312 [Notice] Opening Directory listener on 0.0.0.0:9030
Oct 15 18:33:37.312 [Warning] Port ":1]" out of range
Oct 15 18:33:37.312 [Warning] Error parsing/resolving ListenAddress [::1]
Oct 15 18:33:37.312 [Notice] Opening Socks listener on 192.168.254.1:9050
Oct 15 18:33:37.312 [Notice] Closing partially-constructed listener OR listener on 0.0.0.0:9001
Oct 15 18:33:37.312 [Notice] Closing partially-constructed listener Directory listener on 0.0.0.0:9030
Oct 15 18:33:37.312 [Notice] Closing partially-constructed listener Socks listener on 192.168.254.1:9050
Oct 15 18:33:37.312 [Warning] Failed to parse/validate config: Failed to bind one of the listener ports.
Oct 15 18:33:37.312 [Error] Reading config failed--see warnings above.
my pc has full ipv6 connectivity as shown
netstat -on
TCP [::1]:8181 [::1]:1346 TIME_WAIT 0
TCP [::1]:8181 [::1]:1348 TIME_WAIT 0
TCP [::1]:8181 [::1]:1353 TIME_WAIT 0
TCP [::1]:8181 [::1]:1354 TIME_WAIT 0
TCP [::1]:8181 [::1]:1356 TIME_WAIT 0
TCP [::1]:8181 [::1]:1358 TIME_WAIT 0
TCP [::1]:8181 [::1]:1359 TIME_WAIT 0
TCP [::1]:8181 [::1]:1360 TIME_WAIT 0
TCP [::1]:8181 [::1]:1361 TIME_WAIT 0
TCP [::1]:8181 [::1]:1362 ESTABLISHED 1936
TCP [::1]:8181 [::1]:1363 ESTABLISHED 1936
TCP [::1]:8181 [::1]:1364 ESTABLISHED 1936
TCP [2001:470:7:ff::2]:30806 [2001:41e0:ff16:0:224:81ff:fe36:25fc]:35656
TIME_WAIT 0
TCP [2001:470:7:ff::2]:30806 [2001:41e0:ff16:0:224:81ff:fe36:25fc]:43507
TIME_WAIT 0
TCP [2001:470:7:ff::2]:30806 [2001:41e0:ff16:0:224:81ff:fe36:25fc]:43600
TIME_WAIT 0
TCP [2001:470:7:ff::2]:30806 [2001:41e0:ff16:0:224:81ff:fe36:25fc]:44485
TIME_WAIT 0
TCP [2001:470:7:ff::2]:30806 [2001:41e0:ff16:0:224:81ff:fe36:25fc]:44638
TIME_WAIT 0
TCP [2001:470:7:ff::2]:30806 [2001:41e0:ff16:0:224:81ff:fe36:25fc]:45372
SYN_RECEIVED 5792
TCP [2001:470:7:ff::2]:30806 [2001:41e0:ff16:0:224:81ff:fe36:25fc]:48601
TIME_WAIT 0
TCP [2001:470:7:ff::2]:30806 [2001:41e0:ff16:0:224:81ff:fe36:25fc]:54029
TIME_WAIT 0
TCP [2001:470:7:ff::2]:30806 [2001:41e0:ff16:0:224:81ff:fe36:25fc]:56457
TIME_WAIT 0
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: crpTor: 0.2.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1124Proxy error 504 connecting hidden serrvice2020-06-13T14:02:51ZTracProxy error 504 connecting hidden serrvicethis url used to works OK
http://3xofiggysc6rgygv.onion:8181/
this is yacy hidden search engine, available for all tor users.
use: well , to seach for objectionable things , et all
However stopped working after I update tor software...this url used to works OK
http://3xofiggysc6rgygv.onion:8181/
this is yacy hidden search engine, available for all tor users.
use: well , to seach for objectionable things , et all
However stopped working after I update tor software
the error is
[code]
504 Connect to 3xofiggysc6rgygv.onion:8181 failed: SOCKS error: host unreachable
The following error occurred while trying to access http://3xofiggysc6rgygv.onion:8181/:
504 Connect to 3xofiggysc6rgygv.onion:8181 failed: SOCKS error: host unreachable
Generated Fri, 16 Oct 2009 21:34:47 E. South America Standard Time by Polipo on localhost:8118.
[/code]
Thanks
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: crphttps://gitlab.torproject.org/legacy/trac/-/issues/1125(*chp)->next assertion fail?2020-06-13T14:02:52ZRoger Dingledine(*chp)->next assertion fail?I found this on irc. So I have no idea if it's for real. The person indicated
it was on 0.2.2.5-alpha.
[Info] buf_shrink_freelists():
Cleaning freelist for 4096-byte chunks: keeping 9, dropping 1.
[Error] Bug: buffers.c:269: buf_shrink_...I found this on irc. So I have no idea if it's for real. The person indicated
it was on 0.2.2.5-alpha.
[Info] buf_shrink_freelists():
Cleaning freelist for 4096-byte chunks: keeping 9, dropping 1.
[Error] Bug: buffers.c:269: buf_shrink_freelists: Assertion
(*chp)->next fail
He also said "polipo still not starting with vidalai 2.5", so I'm thinking
probably Windows.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/1126Error from libevent setting read event state for 10232020-06-13T14:02:52ZTracError from libevent setting read event state for 1023Hello,
This morning i have a error in my log:
oct. 18 11:23:48.810 [Warning] Error from libevent setting read event state for 1023 to watched: No such file or directory
oct. 18 11:23:58.355 [Warning] Couldn't open "/home/moonlights/Tor...Hello,
This morning i have a error in my log:
oct. 18 11:23:48.810 [Warning] Error from libevent setting read event state for 1023 to watched: No such file or directory
oct. 18 11:23:58.355 [Warning] Couldn't open "/home/moonlights/TorTeamHelp/state.tmp" (/home/moonlights/TorTeamHelp/state) for writing: Too many open files
oct. 18 11:23:58.355 [Warning] Unable to write state to file "/home/moonlights/TorTeamHelp/state"
oct. 18 11:23:59.291 [Warning] Couldn't open "/home/moonlights/TorTeamHelp/state.tmp" (/home/moonlights/TorTeamHelp/state) for writing: Too many open files
oct. 18 11:23:59.291 [Warning] Unable to write state to file "/home/moonlights/TorTeamHelp/state"
oct. 18 11:24:01.577 [Warning] Couldn't open "/home/moonlights/TorTeamHelp/state.tmp" (/home/moonlights/TorTeamHelp/state) for writing: Too many open files
oct. 18 11:24:01.577 [Warning] Unable to write state to file "/home/moonlights/TorTeamHelp/state"
oct. 18 11:24:02.724 [Warning] Couldn't open "/home/moonlights/TorTeamHelp/state.tmp" (/home/moonlights/TorTeamHelp/state) for writing: Too many open files
oct. 18 11:24:02.725 [Warning] Unable to write state to file "/home/moonlights/TorTeamHelp/state"
oct. 18 11:24:04.593 [Warning] Couldn't open "/home/moonlights/TorTeamHelp/state.tmp" (/home/moonlights/TorTeamHelp/state) for writing: Too many open files
oct. 18 11:24:04.594 [Warning] Unable to write state to file "/home/moonlights/TorTeamHelp/state"
oct. 18 11:24:05.923 [Warning] Couldn't open "/home/moonlights/TorTeamHelp/state.tmp" (/home/moonlights/TorTeamHelp/state) for writing: Too many open files
oct. 18 11:24:05.923 [Warning] Unable to write state to file "/home/moonlights/TorTeamHelp/state"
i run Kubuntu KArmic 9.10 x86 64 on 64 bits 4 cores
Tor origin/master commit 5ef97ddd42dfd51fc296bb51b612780aec09c5c7
torrc spec: ports exit policy reject all */*
libevent + libevent extra 1.4.2 1.4.11-stable-1 (amd64)
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: starshttps://gitlab.torproject.org/legacy/trac/-/issues/1127no shutdown descriptor published when ORPort is closed but client stays up2020-06-13T14:02:53ZNick Mathewsonno shutdown descriptor published when ORPort is closed but client stays up(Posted by request from Scott Bennett.)
Category: tor router -> tor client
Operating System: observed on FreeBSD 7.2-STABLE
Reported Version: 0.2.2.3-alpha ...(Posted by request from Scott Bennett.)
Category: tor router -> tor client
Operating System: observed on FreeBSD 7.2-STABLE
Reported Version: 0.2.2.3-alpha
Title: no shutdown descriptor published when ORPort is closed but client stays up
Reported By: Scott Bennett
Description: When tor is running as both a router and a client, if a SIGINT
is sent to tor, tor closes the ORPort (and DirPort if applicable),
publishes a shutdown descriptor (i.e., a new descriptor in which the
"observed maximum 10s data rate in previous 24 hrs" is set to 0 to
discourage further attempts to include the node in new circuits), and
proceeds with the rest of the shutdown procedure. However, given the
same starting conditions, if the ORPort line in torrc is commented out
and a SIGHUP is sent to tor, tor will read the updated torrc, notice
that the ORPort is no longer to be used, close the ORPort (and DirPort
if applicable), and continue operation as a client process *without*
publishing a shutdown procedure. This situation results in many
unnecessary attempts by clients and routers to connect to the ORPort
(and DirPort if applicable) after it has been closed, wasting time and
causing avoidable circuit construction failures. This was observed in
tor 0.2.2.3-alpha. I haven't yet tried it in 0.2.2.5-alpha.
[Automatically added by flyspray2trac: Operating System: BSD]Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/1128Latex is a build dependency for our tarball?2009-10-24T20:25:35ZRoger DingledineLatex is a build dependency for our tarball?doc/Makefile.am pulls in design-paper
and doc/design-paper/Makefile.am demands latex
This shouldn't be needed for our tarball.
[Automatically added by flyspray2trac: Operating System: All]doc/Makefile.am pulls in design-paper
and doc/design-paper/Makefile.am demands latex
This shouldn't be needed for our tarball.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/1129fedora rpm refers to old tor.eff.org url2020-06-13T16:07:39ZRoger Dingledinefedora rpm refers to old tor.eff.org urlURL: http://tor.eff.org
Source0: http://tor.eff.org/dist/%name-%version.tar.gz
Source1: http://tor.eff.org/dist/%name-%version.tar.gz.asc
The correct url should be https://www.torproject.org/dist/...
[Automatic...URL: http://tor.eff.org
Source0: http://tor.eff.org/dist/%name-%version.tar.gz
Source1: http://tor.eff.org/dist/%name-%version.tar.gz.asc
The correct url should be https://www.torproject.org/dist/...
[Automatically added by flyspray2trac: Operating System: All]Patrick McDonaldPatrick McDonaldhttps://gitlab.torproject.org/legacy/trac/-/issues/1130fedora rpm: init.d/tor/restart on relay will kill the relay2011-02-13T20:05:18ZRoger Dingledinefedora rpm: init.d/tor/restart on relay will kill the relayInstall the fedora tor rpm. Make yourself a relay (i.e. uncomment ORPort in
your /etc/tor/torrc). Then restart your Tor so your relay starts.
Then do an init.d/tor/restart. It will tell your Tor to start shutting down,
and Tor will exit...Install the fedora tor rpm. Make yourself a relay (i.e. uncomment ORPort in
your /etc/tor/torrc). Then restart your Tor so your relay starts.
Then do an init.d/tor/restart. It will tell your Tor to start shutting down,
and Tor will exit in 30 seconds (or whatever the ShutdownWaitLength config
option is set to). But the restart thinks it's dead right then, and tries
to start Tor, which fails.
End result: upgrade your Tor and your relay ends up not running.
[Automatically added by flyspray2trac: Operating System: All]Erinn ClarkErinn Clarkhttps://gitlab.torproject.org/legacy/trac/-/issues/1131fedora rpm doesn't set ulimit -n, so you can't run a fast relay2020-06-13T16:07:39ZRoger Dingledinefedora rpm doesn't set ulimit -n, so you can't run a fast relayIf you run a fast relay, you will end up using more than the default
1024 file descriptors. Currently we point people who run relays to
https://www.torproject.org/docs/tor-doc-relay.html.en and hope they
read through to item #14.
Debian...If you run a fast relay, you will end up using more than the default
1024 file descriptors. Currently we point people who run relays to
https://www.torproject.org/docs/tor-doc-relay.html.en and hope they
read through to item #14.
Debian, on the other hand, has a clause in the init script:
https://gitweb.torproject.org/debian/tor.git/blob_plain/HEAD:/debian/tor.init
that sets MAX_FILEDESCRIPTORS based on how many file descriptors are
available on the machine, before it launches the Tor process.
[Automatically added by flyspray2trac: Operating System: All]Ondrej MikleOndrej Miklehttps://gitlab.torproject.org/legacy/trac/-/issues/1132fedora rpm fabricates its own geoip file?2011-02-13T20:02:04ZRoger Dingledinefedora rpm fabricates its own geoip file?It looks like the fedora rpm has a script that the maintainer
wrote to create a new geoip file at the time of building the rpm.
It should really get the geoip file out of src/config/geoip in the
tarball.
If you make your own, then the ...It looks like the fedora rpm has a script that the maintainer
wrote to create a new geoip file at the time of building the rpm.
It should really get the geoip file out of src/config/geoip in the
tarball.
If you make your own, then the user of that rpm could be making
routing decisions differently than other users. That could have bad
anonymity implications. Not a good plan.
[Automatically added by flyspray2trac: Operating System: All]Erinn ClarkErinn Clarkhttps://gitlab.torproject.org/legacy/trac/-/issues/1133fedora rpm doesn't log by default?2020-06-13T16:07:40ZRoger Dingledinefedora rpm doesn't log by default?It looks like the fedora rpm doesn't set any Log lines in the torrc,
but it does set RunAsDaemon 1 so it forks into the background. If you
don't set any Log lines in the torrc file, then Tor will log to stdout
by default. And the fork wi...It looks like the fedora rpm doesn't set any Log lines in the torrc,
but it does set RunAsDaemon 1 so it forks into the background. If you
don't set any Log lines in the torrc file, then Tor will log to stdout
by default. And the fork will close that log.
Are all the rpm users supposed to know to uncomment a Log line?
The deb patches the Tor code so Tor defaults to logging to a file rather
than stdout:
https://git.torproject.org/checkout/tor/master/debian/patches/07_log_to_file_by_default.dpatch
Or maybe the torrc on fedora rpm should just uncomment the 'log notice file ...'
line?
[Automatically added by flyspray2trac: Operating System: All]Ondrej MikleOndrej Miklehttps://gitlab.torproject.org/legacy/trac/-/issues/1134Our configure.in still handles --with-tor-group2012-03-09T02:25:48ZRoger DingledineOur configure.in still handles --with-tor-groupEven though the Group torrc option is obsolete as of 0.2.0.x, our
configure.in script still handles --with-tor-group
Then our contributed tor.spec file still tries to pass in things like
%configure --with-tor-user=%{toruser} --with-tor-...Even though the Group torrc option is obsolete as of 0.2.0.x, our
configure.in script still handles --with-tor-group
Then our contributed tor.spec file still tries to pass in things like
%configure --with-tor-user=%{toruser} --with-tor-group=%{torgroup}
Also, contrib/osx/Tor launches tor with the --group option, which Tor
ignores:
$TORCMD -f "$TORCONF" --runasdaemon 1 --pidfile "$TORPID" --data
directory "$TORDATA" --user "$TORUSER" --group "$TORGROUP" --log "notice file $T
ORLOG" &
We should change the packages so they stop trying to call the obsolete
Group config option, and change configure.in to either ignore it or complain.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1135Fedora init scripts kill all tor processes2011-02-13T19:46:04ZMike PerryFedora init scripts kill all tor processesInstead of using the Tor pidfile, the Fedora init scripts end up doing a 'killall tor' on stop and restart.
This has the nasty effect of killing all other running tors on your system, in addition to the system one.
[Automatically added...Instead of using the Tor pidfile, the Fedora init scripts end up doing a 'killall tor' on stop and restart.
This has the nasty effect of killing all other running tors on your system, in addition to the system one.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/1136When Tor is offline, it doesn't quite run out of relays, so doesn't realize i...2020-06-13T14:02:54ZRoger DingledineWhen Tor is offline, it doesn't quite run out of relays, so doesn't realize it's offlineIf your Tor client goes offline, it will keep trying to establish circuits,
and as each TLS connection fails, it will mark that relay down.
In update_router_have_minimum_dir_info() Tor checks whether (num_present < 2)
but we never actua...If your Tor client goes offline, it will keep trying to establish circuits,
and as each TLS connection fails, it will mark that relay down.
In update_router_have_minimum_dir_info() Tor checks whether (num_present < 2)
but we never actually mark down the last few relays, either because we don't
have enough left to make a circuit so we don't ever try another TLS connection,
or because none of the remaining relays are suitable exit nodes so we can't
pick a path that would be a useful circuit so we don't try.
I think we need to catch the case where we failed to pick a path because we
don't have enough circuits, and if it case occurs and many of our relays are
marked down, we should mark them up.
That will cause us to attempt circuits for a lot longer than currently, but on
the other hand Tor will actually work when you come back to the network and
try to make a new application request.
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/1137Mac OS X Tor crash2020-06-13T14:02:55ZcypherpunksMac OS X Tor crashI'm running Vidalia 0.2.4 with Tor 0.2.2.3-alpha (git-0f3417d1dbffdf7a). It appears that Mr. Mike Perry has caused some bugs with his circuit build time "improvements" in Tor. :-)
Here's the crash log:
Process: tor [204]
Path: ...I'm running Vidalia 0.2.4 with Tor 0.2.2.3-alpha (git-0f3417d1dbffdf7a). It appears that Mr. Mike Perry has caused some bugs with his circuit build time "improvements" in Tor. :-)
Here's the crash log:
Process: tor [204]
Path: /Applications/Vidalia.app/Contents/MacOS/tor
Identifier: tor
Version: ??? (???)
Code Type: X86 (Native)
Parent Process: Vidalia [188]
Interval Since Last Report: 2883864 sec
Crashes Since Last Report: 2
Per-App Interval Since Last Report: 0 sec
Per-App Crashes Since Last Report: 2
Date/Time: 2009-10-25 21:40:30.778 -0700
OS Version: Mac OS X 10.5.8 (9L31a)
Report Version: 6
Anonymous UUID: 40FE94CF-131D-4773-90D7-DCB7EFF18865
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread: 0
Thread 0 Crashed:
0 libSystem.B.dylib 0x91a70e42 __kill + 10
1 libSystem.B.dylib 0x91ae323a raise + 26
2 libSystem.B.dylib 0x91aef679 abort + 73
3 tor 0x0000db0e circuit_build_times_parse_state + 958
4 tor 0x0002131a or_state_load + 602
5 tor 0x00022435 options_act + 3285
6 tor 0x0002267d set_options + 365
7 tor 0x000263c7 options_init_from_string + 567
8 tor 0x000267f6 options_init_from_torrc + 694
9 tor 0x0006f453 tor_init + 259
10 tor 0x000735d3 tor_main + 67
11 tor 0x00001ee2 _start + 216
12 tor 0x00001e09 start + 41
Thread 0 crashed with X86 Thread State (32-bit):
eax: 0x00000000 ebx: 0x91aef639 ecx: 0xbfffeffc edx: 0x91a70e42
edi: 0x000e5e80 esi: 0x000e5fd8 ebp: 0xbffff018 esp: 0xbfffeffc
ss: 0x0000001f efl: 0x00000286 eip: 0x91a70e42 cs: 0x00000007
ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037
cr2: 0xa02e1690
Binary Images:
0x1000 - 0x11bfef +tor ??? (???) <d67657b9b5e05c547bfeb1ac91c0ad69> /Applications/Vidalia.app/Contents/MacOS/tor
0x8fe00000 - 0x8fe2db43 dyld 97.1 (???) <458eed38a009e5658a79579e7bc26603> /usr/lib/dyld
0x90676000 - 0x9067dfe9 libgcc_s.1.dylib ??? (???) <f53c808e87d1184c0f9df63aef53ce0b> /usr/lib/libgcc_s.1.dylib
0x91a02000 - 0x91b69ff3 libSystem.B.dylib ??? (???) <ae47ca9b1686b065f8ac4d2de09cc432> /usr/lib/libSystem.B.dylib
0x940b2000 - 0x94164ffb libcrypto.0.9.7.dylib ??? (???) <9d714c92872a93dd127ea8556b2c8945> /usr/lib/libcrypto.0.9.7.dylib
0x94cd6000 - 0x94cfafeb libssl.0.9.7.dylib ??? (???) <8084593b773bec8f2b9614fd23c5ed73> /usr/lib/libssl.0.9.7.dylib
0x9529e000 - 0x952acffd libz.1.dylib ??? (???) <5ddd8539ae2ebfd8e7cc1c57525385c7> /usr/lib/libz.1.dylib
0x9608c000 - 0x96090fff libmathCommon.A.dylib ??? (???) /usr/lib/system/libmathCommon.A.dylib
0xffff0000 - 0xffff1780 libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib
Here's my system info:
Model: Macmini2,1, BootROM MM21.009A.B00, 2 processors, Intel Core 2 Duo, 2 GHz, 1 GB
Graphics: kHW_IntelGMA950Item, GMA 950, spdisplays_builtin, spdisplays_integrated_vram
Memory Module: global_name
AirPort: spairport_wireless_card_type_airport_extreme (0x168C, 0x86), 1.4.16.2
Bluetooth: Version 2.1.8f2, 2 service, 1 devices, 1 incoming serial ports
Network Service: Ethernet, Ethernet, en0
Serial ATA Device: Hitachi HTS541612J9SA00, 111.79 GB
Parallel ATA Device: PIONEER DVD-RW DVR-K06
USB Device: My Book, (null) mA
USB Device: Extreme III USB2.0 Reader/Writer, (null) mA
USB Device: Back-UPS ES 550 FW:840.B2.D USB FW:B2, (null) mA
USB Device: Apple Optical USB Mouse, (null) mA
USB Device: Bluetooth USB Host Controller, (null) mA
USB Device: IR Receiver, (null) mA
Tor crashes every time that I attempt to start it with Vidalia:
Oct 25 21:46:26.909 [Notice] Tor v0.2.2.3-alpha (git-0f3417d1dbffdf7a). This is experimental software. Do not rely on it for strong anonymity. (Running on Darwin i386)
Oct 25 21:46:26.910 [Notice] Initialized libevent version 1.4.12-stable using method kqueue. Good.
Oct 25 21:46:26.910 [Notice] Opening OR listener on 0.0.0.0:9001
Oct 25 21:46:26.910 [Notice] Opening Directory listener on 0.0.0.0:9030
Oct 25 21:46:26.911 [Notice] Opening Socks listener on 127.0.0.1:9050
Oct 25 21:46:26.911 [Notice] Opening Control listener on 127.0.0.1:9051
Oct 25 21:46:26.912 [Error] Bug: circuitbuild.c:380: circuit_build_times_shuffle_array: Assertion cbt->total_build_times == cbt->build_times_idx failed; aborting.
If I remove the state file from my ~/.tor/ directory, I am able to start Tor as expected. I do however expect it to crash or have this problem again at some point. I sadly unlinked the state file or I would have included it in this bug report.
[Automatically added by flyspray2trac: Operating System: OSX 10.5 Leopard]https://gitlab.torproject.org/legacy/trac/-/issues/1138If bridge authority is unreachable, client doesn't fallback to bridge2020-06-13T14:06:35ZRoger DingledineIf bridge authority is unreachable, client doesn't fallback to bridgeWhen a Tor client starts up using a bridge, and UpdateBridgesFromAuthority is
set (which it is when Vidalia configures you to use a bridge), Tor will go to
the authority first and look up the bridge by fingerprint.
If the bridge authori...When a Tor client starts up using a bridge, and UpdateBridgesFromAuthority is
set (which it is when Vidalia configures you to use a bridge), Tor will go to
the authority first and look up the bridge by fingerprint.
If the bridge authority doesn't have the bridge, or Tor doesn't know the
fingerprint, then Tor will fall back to asking the bridge directly.
If the bridge authority is filtered, though, then Tor will never notice that
the bridge authority lookup failed. So it will never fall back. Fail.
Our workaround for now is to stop giving out fingerprints via bridgedb.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalRobert HoganRobert Hoganhttps://gitlab.torproject.org/legacy/trac/-/issues/1139alpha gcc bug: circuitbuild.c:608: circuit_build_times_generate_sample: Asser...2020-06-13T14:02:57Zweasel (Peter Palfrader)alpha gcc bug: circuitbuild.c:608: circuit_build_times_generate_sample: Assertion q_lo < q_hi failedHi,
on alpha, in 0.2.2.4 and latest git the testsuite fails with:
[sid] weasel@albeniz:~/tmp/tor$ ./src/test/test --info
Oct 26 09:07:09.931 [info] crypto_global_init(): NOT using OpenSSL engine support.
Oct 26 09:07:09.932 [info] crypt...Hi,
on alpha, in 0.2.2.4 and latest git the testsuite fails with:
[sid] weasel@albeniz:~/tmp/tor$ ./src/test/test --info
Oct 26 09:07:09.931 [info] crypto_global_init(): NOT using OpenSSL engine support.
Oct 26 09:07:09.932 [info] crypto_seed_rng(): Seeding RNG from "/dev/urandom"
Oct 26 09:07:09.934 [info] crypto_seed_rng(): Seeding RNG from "/dev/urandom"
buffers: OK
onion_handshake: OK
circuit_timeout: Oct 26 09:07:10.206 [err] Bug: circuitbuild.c:608: circuit_build_times_generate_sample: Assertion q_lo < q_hi failed; aborting.
circuitbuild.c:608 circuit_build_times_generate_sample: Assertion q_lo < q_hi failed; aborting.
zsh: abort (core dumped) ./src/test/test --info
See also http://experimental.ftbfs.de/fetch.php?pkg=tor&arch=alpha&ver=0.2.2.4-alpha-1&stamp=1255305733&file=log&as=raw
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/1140Cookies don't get cleared when Torbutton addon is enabled2010-05-27T09:35:33ZKamran KhanCookies don't get cleared when Torbutton addon is enabledI'm using FF 3.5.4 and have the Torbutton *addon* enabled on my installation. Usually, the Torbutton *itself* is disabled.
Whenever I clear cookies in FF while Torbutton is disabled (but addon itself is enabled), FF seems to have cleare...I'm using FF 3.5.4 and have the Torbutton *addon* enabled on my installation. Usually, the Torbutton *itself* is disabled.
Whenever I clear cookies in FF while Torbutton is disabled (but addon itself is enabled), FF seems to have cleared all cookies. If I go to the individually remove cookies panel, it's empty. However, as soon as I restart FF, *all* the previous cookies magically appear there again. I have been able to fix the issue by:
1) Deleting cookies* files in the FF profile.
2) Disabling the Torbutton addon altogether.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/1141bug in networkstatus.c using 0.2.1.202020-06-13T14:09:03ZTracbug in networkstatus.c using 0.2.1.20Here is the config from the Tor client where the crash is happening:
TestingTorNetwork 1
DirServer bridgedirauth v3ident=3C1DA30FB6C8760E43C89ED36A700F429C5763E5 orport=443 172.16.234.136:995 B8F4F6B623E787C47A70111E7E5DE4A53A7A1840
Dat...Here is the config from the Tor client where the crash is happening:
TestingTorNetwork 1
DirServer bridgedirauth v3ident=3C1DA30FB6C8760E43C89ED36A700F429C5763E5 orport=443 172.16.234.136:995 B8F4F6B623E787C47A70111E7E5DE4A53A7A1840
DataDirectory /root/.tor/
UseBridges 1
Bridge 172.16.234.136:443
ClientOnly 1
Here is the output from Tor when the bug happens:
(gdb) run -f torrc log info
Starting program: /root/tor-0.2.1.20/src/or/tor -f torrc log info
Oct 31 19:18:12.716 [notice] Tor v0.2.1.20. This is experimental software. Do not rely on it for strong anonymity. (Running on OpenBSD amd64)
Oct 31 19:18:12.720 [warn] You have used DirServer or AlternateDirAuthority to specify alternate directory authorities in your configuration. This is potentially dangerous: it can make you look different from all other Tor users, and hurt your anonymity. Even if you've specified the same authorities as Tor uses by default, the defaults could change in the future. Be sure you know what you're doing.
Oct 31 19:18:12.720 [warn] TestingTorNetwork is set. This will make your node almost unusable in the public Tor network, and is therefore only advised if you are building a testing Tor network!
Oct 31 19:18:12.721 [notice] Initialized libevent version 1.3e using method kqueue. Good.
Oct 31 19:18:12.721 [notice] Opening Socks listener on 127.0.0.1:9050
Oct 31 19:18:12.723 [info] tor_lockfile_lock(): Locking "/root/.tor//lock"
Oct 31 19:18:12.723 [info] or_state_load(): Loaded state from "/root/.tor//state"
Oct 31 19:18:12.724 [info] read_file_to_str(): Could not open "/root/.tor//router-stability": No such file or directory
Oct 31 19:18:12.725 [info] geoip_load_file(): Failed to open GEOIP file /usr/local/share/tor/geoip.
Oct 31 19:18:12.725 [warn] You are running Tor as root. You don't need to, and you probably shouldn't.
Oct 31 19:18:12.744 [info] crypto_seed_rng(): Seeding RNG from "/dev/srandom"
Oct 31 19:18:12.798 [info] Bootstrapped 0%: Starting.
Oct 31 19:18:12.800 [info] trusted_dirs_load_certs_from_string(): Adding cached certificate for directory authority bridgedirauth with signing key F554586AA4C6DFB571A33EEBA89D9D48A94B618B
Oct 31 19:18:12.800 [info] read_file_to_str(): Could not open "/root/.tor//cached-consensus": No such file or directory
Oct 31 19:18:12.800 [info] read_file_to_str(): Could not open "/root/.tor//unverified-consensus": No such file or directory
Oct 31 19:18:12.800 [info] read_file_to_str(): Could not open "/usr/local/share/tor/fallback-consensus": No such file or directory
Oct 31 19:18:12.801 [info] should_delay_dir_fetches(): delaying dir fetches (no running bridges known)
Oct 31 19:18:12.801 [info] router_load_routers_from_string(): 1 elements to add
Oct 31 19:18:12.801 [info] add_an_entry_guard(): Chose 'bridgedirauth' as new entry guard.
Oct 31 19:18:12.802 [info] log_entry_guards(): bridgedirauth (down never-contacted)
Oct 31 19:18:12.802 [notice] new bridge descriptor 'bridgedirauth' (cached)
Oct 31 19:18:12.802 [info] update_consensus_networkstatus_downloads(): Launching networkstatus consensus download.
Oct 31 19:18:12.802 [info] connection_ap_make_link(): Making internal direct tunnel to [scrubbed]:443 ...
Oct 31 19:18:12.803 [info] onion_pick_cpath_exit(): Using requested exit node 'bridgedirauth'
Oct 31 19:18:12.803 [info] circuit_handle_first_hop(): Next router is [scrubbed]: Router not connected (nothing is). Connecting.
Oct 31 19:18:12.803 [notice] Bootstrapped 5%: Connecting to directory server.
Oct 31 19:18:12.803 [info] get_interface_address6(): connect() failed: Invalid argument
Oct 31 19:18:12.804 [info] get_interface_address6(): connect() failed: Invalid argument
Oct 31 19:18:12.804 [info] connection_ap_make_link(): ... application connection created and linked.
Oct 31 19:18:12.804 [info] directory_send_command(): Downloading consensus from 172.16.234.136:443 using /tor/status-vote/current/consensus.z
Oct 31 19:18:12.805 [info] router_load_routers_from_string(): 0 elements to add
Oct 31 19:18:12.805 [info] tor_mmap_file(): Could not open "/root/.tor//cached-extrainfo" for mmap(): No such file or directory
Oct 31 19:18:12.805 [notice] I learned some more directory information, but not enough to build a circuit: We have no network-status consensus.
Oct 31 19:18:12.806 [info] connection_ap_make_link(): Making internal direct tunnel to [scrubbed]:443 ...
Oct 31 19:18:12.806 [info] onion_pick_cpath_exit(): Using requested exit node '0000000000000000000000000000000000000000'
Oct 31 19:18:12.806 [info] circuit_handle_first_hop(): Next router is [scrubbed]: Not connected. Connecting.
Oct 31 19:18:12.806 [info] get_interface_address6(): connect() failed: Invalid argument
Oct 31 19:18:12.807 [info] get_interface_address6(): connect() failed: Invalid argument
Oct 31 19:18:12.807 [info] connection_ap_make_link(): ... application connection created and linked.
Oct 31 19:18:12.809 [info] or_state_save(): Saved state to "/root/.tor//state"
Oct 31 19:18:12.809 [info] connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
Oct 31 19:18:12.810 [info] connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
Oct 31 19:18:12.810 [info] connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
Oct 31 19:18:12.810 [info] connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
Oct 31 19:18:12.810 [notice] Bootstrapped 10%: Finishing handshake with directory server.
Oct 31 19:18:12.866 [info] connection_or_check_valid_tls_handshake(): Connected to router $B8F4F6B623E787C47A70111E7E5DE4A53A7A1840 at 172.16.234.136:443 without knowing its key. Hoping for the best.
Oct 31 19:18:12.867 [info] command_process_versions_cell(): Negotiated version 2 with [scrubbed]:443; sending NETINFO.
Oct 31 19:18:12.868 [notice] Bootstrapped 15%: Establishing an encrypted directory connection.
Oct 31 19:18:12.868 [info] circuit_send_next_onion_skin(): First hop: finished sending CREATE_FAST cell to 'bridgedirauth'
Oct 31 19:18:12.868 [info] circuit_send_next_onion_skin(): First hop: finished sending CREATE_FAST cell to 'bridgedirauth'
Oct 31 19:18:12.868 [info] command_process_netinfo_cell(): Got good NETINFO cell from [scrubbed]:443; OR connection is now open, using protocol version 2
Oct 31 19:18:12.869 [info] command_process_versions_cell(): Negotiated version 2 with [scrubbed]:443; sending NETINFO.
Oct 31 19:18:12.869 [info] command_process_netinfo_cell(): Got good NETINFO cell from [scrubbed]:443; OR connection is now open, using protocol version 2
Oct 31 19:18:12.910 [info] circuit_finish_handshake(): Finished building fast circuit hop:
Oct 31 19:18:12.910 [info] exit circ (length 1, exit bridgedirauth): $B8F4F6B623E787C47A70111E7E5DE4A53A7A1840(open)
Oct 31 19:18:12.910 [info] circuit_send_next_onion_skin(): circuit built!
Oct 31 19:18:12.910 [notice] Bootstrapped 20%: Asking for networkstatus consensus.
Oct 31 19:18:12.910 [info] exit circ (length 1): $B8F4F6B623E787C47A70111E7E5DE4A53A7A1840(open)
Oct 31 19:18:12.911 [info] connection_ap_handshake_send_begin(): Address/port sent, ap socket -1, n_circ_id 23920
Oct 31 19:18:12.911 [info] circuit_finish_handshake(): Finished building fast circuit hop:
Oct 31 19:18:12.911 [info] exit circ (length 1, exit 0000000000000000000000000000000000000000): $0000000000000000000000000000000000000000(open)
Oct 31 19:18:12.912 [info] circuit_send_next_onion_skin(): circuit built!
Oct 31 19:18:12.912 [info] exit circ (length 1): $0000000000000000000000000000000000000000(open)
Oct 31 19:18:12.912 [info] connection_ap_handshake_send_begin(): Address/port sent, ap socket -1, n_circ_id 23921
Oct 31 19:18:12.913 [info] connection_edge_process_relay_cell_not_open(): 'connected' received after 0 seconds.
Oct 31 19:18:12.914 [info] exit circ (length 1): $B8F4F6B623E787C47A70111E7E5DE4A53A7A1840(open)
Oct 31 19:18:12.914 [notice] Bootstrapped 25%: Loading networkstatus consensus.
Oct 31 19:18:12.915 [info] connection_edge_process_relay_cell_not_open(): 'connected' received after 0 seconds.
Oct 31 19:18:12.915 [info] exit circ (length 1): $0000000000000000000000000000000000000000(open)
Oct 31 19:18:12.915 [notice] Bootstrapped 50%: Loading relay descriptors.
Oct 31 19:18:12.916 [info] connection_edge_process_relay_cell(): -1: end cell (closed normally) for stream 44628. Removing stream.
Oct 31 19:18:12.917 [info] _connection_free(): Freeing linked Socks connection [open] with 0 bytes on inbuf, 0 on outbuf.
Oct 31 19:18:12.918 [info] connection_dir_client_reached_eof(): Received consensus directory (size 1367) from server '172.16.234.136:443'
Oct 31 19:18:12.918 [info] 0 unknown, 0 missing key, 1 good, 0 bad, 0 no signature, 1 required
Oct 31 19:18:12.919 [err] Bug: networkstatus.c:1164: update_consensus_networkstatus_fetch_time: Assertion start+dl_interval < c->valid_until failed; aborting.
networkstatus.c:1164 update_consensus_networkstatus_fetch_time: Assertion start+dl_interval < c->valid_until failed; aborting.
Here is the backtrace from this crashed process:
(gdb) backtrace
#0 0x000000020c37137a in kill () from /usr/lib/libc.so.51.0
#1 0x000000020c3bd765 in abort () at /usr/src/lib/libc/stdlib/abort.c:68
#2 0x000000000045cb81 in update_consensus_networkstatus_fetch_time (now=1257016692) at networkstatus.c:1183
#3 0x000000000045d29d in networkstatus_set_current_consensus (
consensus=0x20f769800 "network-status-version 3\nvote-status consensus\nconsensus-method 5\nvalid-after 2009-10-31 19:15:00\nfresh-until 2009-10-31 19:20:00\nvalid-until 2009-10-31 19:30:00\nvoting-delay 20 20\nclient-versions \nse"..., flags=0) at networkstatus.c:1527
#4 0x000000000043feac in connection_dir_client_reached_eof (conn=0x2088f0d00) at directory.c:1638
#5 0x000000000044061e in connection_dir_reached_eof (conn=0x2088f0d00) at directory.c:2040
#6 0x000000000042626f in connection_handle_read (conn=0x2088f0d00) at connection.c:2037
#7 0x0000000000457b91 in conn_read_callback (fd=8833, event=6, _conn=0x37b7) at main.c:456
#8 0x000000020377f2e2 in event_process_active (base=0x201cfdc00) at /usr/src/lib/libevent/event.c:333
#9 0x000000020377f501 in event_base_loop (base=0x201cfdc00, flags=1) at /usr/src/lib/libevent/event.c:450
#10 0x000000020377f3b5 in event_loop (flags=8833) at /usr/src/lib/libevent/event.c:383
#11 0x0000000000459726 in do_main_loop () at main.c:1444
#12 0x000000000045a88b in tor_main (argc=5, argv=0x7f7fffff1850) at main.c:2070
#13 0x000000000040702c in ___start ()
#14 0x0000000000000005 in ?? ()
#15 0x00007f7fffff1d00 in ?? ()
#16 0x00007f7fffff1d1e in ?? ()
#17 0x00007f7fffff1d21 in ?? ()
#18 0x00007f7fffff1d27 in ?? ()
#19 0x00007f7fffff1d2b in ?? ()
#20 0x0000000000000000 in ?? ()
The configs used for the servers in this network can be found here: http://pastebin.com/m65b5da00
I'd also be keen to hear if the configs I have for such a network actually make sense, and that I haven't forgotten something crucial when testing Tor.
Thanks
mikeb
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: mikebTor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1142No button on Firefox2010-05-27T09:44:38ZTracNo button on FirefoxOn my Firefox browser window, I had two buttons at the bottom of the browsed page for activating or deactivating Tor.
They have now disappeared and I can not activate Tor, even though I have green onion.
I downloaded the Tor Button for F...On my Firefox browser window, I had two buttons at the bottom of the browsed page for activating or deactivating Tor.
They have now disappeared and I can not activate Tor, even though I have green onion.
I downloaded the Tor Button for Firefox, but no change.
Please help. I have Firefox 3.5.4
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: AlexW44https://gitlab.torproject.org/legacy/trac/-/issues/1143Tor can't start if DNS Port enabled in torrc2020-06-13T14:03:05ZTracTor can't start if DNS Port enabled in torrcHello,
Today i updated my tor origin/master 0.2.2.5 alpha commit 69c0147ea6725a63f254333867c0504528c62daf and i was unable to start tor.
I run kubuntu karmic 9.10 on x86 64, kernel: 2.6.31-15-generic and libevent 2.0.2 alpha Path: .
U...Hello,
Today i updated my tor origin/master 0.2.2.5 alpha commit 69c0147ea6725a63f254333867c0504528c62daf and i was unable to start tor.
I run kubuntu karmic 9.10 on x86 64, kernel: 2.6.31-15-generic and libevent 2.0.2 alpha Path: .
URL: https://levent.svn.sourceforge.net/svnroot/levent/trunk/libevent
Repository Root: https://levent.svn.sourceforge.net/svnroot/levent
Repository UUID: ce677c24-8c1a-0410-9497-a30ef3a96221
Revision: 1516
Node Kind: directory
Schedule: normal
Last Changed Author: nickm
Last Changed Rev: 1516
Last Changed Date: 2009-11-06 22:46:57 +0100 (ven, 06 nov 2009)
After a few hours , i have found that was the "DNSPort xx DNS , ListenAddress 127.0.0.1:xxxx " when enabled who crash tor at start.
If i disable it, it start normally .
i have already report in libevent bug tracker the 2 kernel errors found in my log but give info here while i dunno what cause it.
2009-11-08 21:40:22 moon kernel [ 6907.854009] tor[11345]: segfault at 0 ip 00007f39cf943b18 sp 00007fff6dd87860 error 4 in libevent.so.2.0.0[7f39cf929000+40000]
2009-11-08 21:41:10 moon kernel [ 6955.458940] tor[11355]: segfault at 0 ip 00007f8ae258bb18 sp 00007fff58df22a0 error 4 in libevent.so.2.0.0[7f8ae2571000+40000]
best regards
SwissTorExit
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: starshttps://gitlab.torproject.org/legacy/trac/-/issues/1144tor bridge can not work with openssl 0.9.8l2020-06-13T14:03:06ZTractor bridge can not work with openssl 0.9.8lDescription:
After upgrade to openssl-0.9.8l which fixed the MTM attack (for reference see https://bugzilla.redhat.com/show_bug.cgi?id=533125) by disabling renegotiating, tor(using bridge) stops working.
Tor should find another way with...Description:
After upgrade to openssl-0.9.8l which fixed the MTM attack (for reference see https://bugzilla.redhat.com/show_bug.cgi?id=533125) by disabling renegotiating, tor(using bridge) stops working.
Tor should find another way without renegotiating. For linux distributions, enabling a known insecure feature is not an option.
Tor log:
Nov 10 14:31:15 cruiser Tor[9287]: Bootstrapped 5%: Connecting to directory server.
Nov 10 14:31:15 cruiser Tor[9287]: Bootstrapped 10%: Finishing handshake with directory server.
Nov 10 14:31:16 cruiser Tor[9287]: TLS error: unexpected close while renegotiating
Nov 10 14:31:16 cruiser Tor[9287]: TLS error: unexpected close while renegotiating
Nov 10 14:31:16 cruiser Tor[9287]: TLS error: unexpected close while renegotiating
Nov 10 14:31:16 cruiser Tor[9287]: TLS error: unexpected close while renegotiating
Nov 10 14:31:16 cruiser Tor[9287]: TLS error: unexpected close while renegotiating
Nov 10 14:31:16 cruiser Tor[9287]: TLS error: unexpected close while renegotiating
Nov 10 14:31:16 cruiser Tor[9287]: TLS error: unexpected close while renegotiating
Nov 10 14:31:16 cruiser Tor[9287]: Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (DONE; DONE; count 7; recommendation warn)
reference:
http://bugs.archlinux.org/task/17088
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: lymanhttps://gitlab.torproject.org/legacy/trac/-/issues/1145Tor fails to load auth-certs2020-06-13T14:03:07ZTracTor fails to load auth-certsUsed the Tor Browser Bundle 1.2.9 under Windows 7 x64 German.
Worked smoothly, but today it was unable to build a circuit. Log and the Tor-Data is attached.
[Automatically added by flyspray2trac: Operating System: Windows Vista]
**Tra...Used the Tor Browser Bundle 1.2.9 under Windows 7 x64 German.
Worked smoothly, but today it was unable to build a circuit. Log and the Tor-Data is attached.
[Automatically added by flyspray2trac: Operating System: Windows Vista]
**Trac**:
**Username**: knappoTor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1146Tor tabs are saved and restored on crash in FF3.5 despite settings2009-11-17T04:23:25ZTracTor tabs are saved and restored on crash in FF3.5 despite settingsI have just upgraded to Firefox 3.5.5 and have noticed a strange behviour that causes Tor tabs to be opened in non-Tor mode after a browser crash.
Torbutton Startup settings:
- On normal startup, set Tor state to "Non-Tor"
- On session...I have just upgraded to Firefox 3.5.5 and have noticed a strange behviour that causes Tor tabs to be opened in non-Tor mode after a browser crash.
Torbutton Startup settings:
- On normal startup, set Tor state to "Non-Tor"
- On session restored startup, set Tor state to "Non-Tor"
- Have the session store save and restore these tabs: "Tabs loaded in Non-Tor" ("Tabs loaded in Tor" is NOT checked)
1. Open some tabs in non-Tor mode
2. Switch to Tor-mode
3. Open some more tabs
4. Kill Firefox process
5. Re-open Firefox and restore sessions if prompted
Expected result: Just open non-Tor tabs
Actual result: Opens all previous tabs (from Tor and non-Tor mode) in non-Tor mode(!)
This did not used to happen previously (using Firefox 3.x) - I could kill Firefox using 'xkill' and it would re-open with only my Non-Tor tabs restored.
Unless I'm missing something, this is a very insecure behaviour? As my Tor tabs have just been loaded in Non-Tor mode, thus violating the privacy settings?
I am using Torbutton 1.2.2 on Firefox 3.5.5, Ubuntu 9.10
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: greenlynxhttps://gitlab.torproject.org/legacy/trac/-/issues/1147mlockall prevents compile for Android2020-06-13T14:03:07ZJacob Appelbaummlockall prevents compile for Androidbionic doesn't have an actual implementation of mlockall();
mlockall() is merely in the headers but not actually in the library.
This prevents Tor compilation with the bionic libc for Android handsets.
[Automatically added by flyspray2t...bionic doesn't have an actual implementation of mlockall();
mlockall() is merely in the headers but not actually in the library.
This prevents Tor compilation with the bionic libc for Android handsets.
[Automatically added by flyspray2trac: Operating System: All]Jacob AppelbaumJacob Appelbaumhttps://gitlab.torproject.org/legacy/trac/-/issues/1148mlockall prevents compile for Android2020-06-13T14:03:07ZJacob Appelbaummlockall prevents compile for Androidbionic doesn't have an actual implementation of mlockall(); mlockall() is merely in the headers but not actually in the library. This prevents Tor compilation with the bionic libc for Android handsets.
[Automatically added by flyspray2t...bionic doesn't have an actual implementation of mlockall(); mlockall() is merely in the headers but not actually in the library. This prevents Tor compilation with the bionic libc for Android handsets.
[Automatically added by flyspray2trac: Operating System: All]Jacob AppelbaumJacob Appelbaumhttps://gitlab.torproject.org/legacy/trac/-/issues/1149Impossible to download files bigger then 32MB2020-06-13T00:09:50ZTracImpossible to download files bigger then 32MBThis is a bug in polipo not in tor, but since you included a 2 years abandoned app with knows bugs in a stable release of tor I will report it here in case you were unaware.
Bug #1
When downloading a file bigger then the chunkHighMark v...This is a bug in polipo not in tor, but since you included a 2 years abandoned app with knows bugs in a stable release of tor I will report it here in case you were unaware.
Bug #1
When downloading a file bigger then the chunkHighMark value in polipo.conf, currently set to 33554432 bytes, polipo stops sending output to the browser, but still continues to download the file from tor.
When this happens the browser is unable to disconnect the download or retry it because polipo blocks the requests until the connection is terminated by the server side or through the tor network map.
Bug #2
When downloading a file if the connection is closed by the server side or through tor, polipo automatically generates a background request to download the file again, however the way it does this contains a bug that instead of downloading from the part where the download was cut, it starts at the beginning of the file again, the result is a waste of bandwidth, and a long wait while polipo catches up to where the download stopped and starts outputting data to the browser again.
Bug #3
When using a download manager that supports resuming, the download manager will usually resume by sending a http header like "Range: bytes=1000-" indicating that the server should start sending from byte 1000.
However polipo strips this header from requests if the URL is one that has previously failed, meaning the download starts from 0 again.
This can be tested by use a download manager like getright, and pause the download and then try to resume it.
The combination of the 3 bugs above make it impossible to download a file larger then 32MB via tor, you cant download it, and cant resume it when it fails.
For speeding up testing, you can remove the "socksParentProxy" line from polipo.conf to make it connect to the internet directly, making it much faster to download 32mb and observe the bugs.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: dodahttps://gitlab.torproject.org/legacy/trac/-/issues/1150Tor crash on FreeBSD2020-06-13T14:03:09ZTracTor crash on FreeBSDTor crashes at random times, sometimes it will last days or even weeks, sometimes only a few hours until a crash.
This has been going on for a while over the past few months with various tor versions.
I just now got around to compiling ...Tor crashes at random times, sometimes it will last days or even weeks, sometimes only a few hours until a crash.
This has been going on for a while over the past few months with various tor versions.
I just now got around to compiling it with debug symbols.
This is the gdb from the crash today, its my first crash since compiling with debug so im not sure if it always crashes in the same place, I will update the bug on the next crash.
I'm not sure if I am doing this right, let me know if you need me to provide some different info.
OS is FreeBSD 7.2 32bit.
# gdb /usr/local/bin/tor tor.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
Core was generated by `tor'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libz.so.4...done.
Loaded symbols for /lib/libz.so.4
Reading symbols from /usr/local/lib/libevent-1.4.so.3...done.
Loaded symbols for /usr/local/lib/libevent-1.4.so.3
Reading symbols from /usr/local/lib/libssl.so.5...done.
Loaded symbols for /usr/local/lib/libssl.so.5
Reading symbols from /usr/local/lib/libcrypto.so.5...done.
Loaded symbols for /usr/local/lib/libcrypto.so.5
Reading symbols from /lib/libthr.so.3...done.
Loaded symbols for /lib/libthr.so.3
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /usr/lib/librt.so.1...done.
Loaded symbols for /usr/lib/librt.so.1
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 set_streams_blocked_on_circ (circ=Variable "circ" is not available.
) at relay.c:1764
1764 relay.c: No such file or directory.
in relay.c
[New Thread 0x28501040 (LWP 100379)]
(gdb) bt
#0 set_streams_blocked_on_circ (circ=Variable "circ" is not available.
) at relay.c:1764
#1 0x080b5774 in connection_or_flush_from_first_active_circuit (conn=0x28dedbb0, max=1, now=1258328897) at relay.c:1832
#2 0x0807c73b in connection_or_flushed_some (conn=0x28dedbb0) at connection_or.c:293
#3 0x0806f3b4 in connection_flushed_some (conn=0x28dedbb0) at connection.c:2832
#4 0x080731ad in connection_handle_write (conn=0x28dedbb0, force=0) at connection.c:2385
#5 0x080ab249 in conn_write_callback (fd=164, events=4, _conn=0x28dedbb0) at main.c:488
#6 0x28187692 in event_base_loop () from /usr/local/lib/libevent-1.4.so.3
#7 0x281879c9 in event_loop () from /usr/local/lib/libevent-1.4.so.3
#8 0x080aaf49 in do_main_loop () at main.c:1444
#9 0x080ab167 in tor_main (argc=11, argv=0xbfbfec08) at main.c:2070
#10 0x080e8a02 in main (argc=Cannot access memory at address 0x0
) at tor_main.c:30
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: foundbughttps://gitlab.torproject.org/legacy/trac/-/issues/1151Tor bundle fail to build on linux 64 bits2009-11-25T03:05:08ZTracTor bundle fail to build on linux 64 bitsHello,
I run ubunru karmic 9.10 on x86 64 , version 64 bits.
I have the last svn version:URL : https://tor-svn.freehaven.net/svn/torbrowser/trunk/build-scripts
Racine du dépôt : https://tor-svn.freehaven.net/svn
UUID du dépôt : 55e972c...Hello,
I run ubunru karmic 9.10 on x86 64 , version 64 bits.
I have the last svn version:URL : https://tor-svn.freehaven.net/svn/torbrowser/trunk/build-scripts
Racine du dépôt : https://tor-svn.freehaven.net/svn
UUID du dépôt : 55e972cd-5a19-0410-ae62-a4d7a52db4cd
Révision : 20956
Type de nœud : répertoire
Tâche programmée : normale
Auteur de la dernière modification : phobos
Révision de la dernière modification : 20956
Date de la dernière modification: 2009-11-16 12:27:23 +0100 (lun 16 nov 2009)
2.6.31-15-generic #50-Ubuntu SMP Tue Nov 10 14:53:52 UTC 2009 x86_64 GNU/Linux
I have this 2 errors on build:
/usr/bin/ld: /tmp/build//built//lib//libssl.a(s2_srvr.o): relocation R_X86_64_32 against `.data' can not be used when making a shared object; recompile with -fPIC
/tmp/build//built//lib//libssl.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[2]: *** [../../lib/libQtNetwork.so.4.5.3] Erreur 1
make[2]: quittant le répertoire « /tmp/build/qt-x11-opensource-src-4.5.3/src/network »
make[1]: *** [sub-network-make_default-ordered] Erreur 2
make[1]: quittant le répertoire « /tmp/build/qt-x11-opensource-src-4.5.3 »
make: *** [build-qt] Erreur 2
real 21m4.949s
user 2m4.880s
sys 2m39.200s
I have edited "make.linux" and "make" to use openssl-0.9.8k instead "l" but make no difference
Best regards
SwissToeExit
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: starshttps://gitlab.torproject.org/legacy/trac/-/issues/1152'Close all tabs on Tor Toggle' prevents toggling in FF3.52009-11-18T00:17:56ZMike Perry'Close all tabs on Tor Toggle' prevents toggling in FF3.5There appears to be a bug in Firefox 3.5 associated with closing all tabs on toggle. It seems almost as
if Firefox is not properly associating new tabs with their proper container window. The result is that
toggling is impossible due to ...There appears to be a bug in Firefox 3.5 associated with closing all tabs on toggle. It seems almost as
if Firefox is not properly associating new tabs with their proper container window. The result is that
toggling is impossible due to an error thrown from the firefox code in tabbrowser.xml (tabbrowser.removeTab()).
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/1153dirvote.c writes to stdout2020-06-13T14:03:10ZRoger Dingledinedirvote.c writes to stdoutnetworkstatus_add_detached_signatures() has a bunch of puts() lines, e.g.
puts("A"). It also has some printf lines, etc.
I can get rid of them. But perhaps you meant to convert them into log lines?
[Automatically added by flyspray2trac...networkstatus_add_detached_signatures() has a bunch of puts() lines, e.g.
puts("A"). It also has some printf lines, etc.
I can get rid of them. But perhaps you meant to convert them into log lines?
[Automatically added by flyspray2trac: Operating System: All]0.2.2.6-alphaNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/1154Proxy test failure language is confusing2009-11-20T01:55:25ZMike PerryProxy test failure language is confusingWhen Torbutton fails a proxy test, it sets the about:config preference extensions.torbutton.test_failed.
It then pops up a dialog warning the user that the most recent test has failed whenever they try to toggle,
but it is not clear how...When Torbutton fails a proxy test, it sets the about:config preference extensions.torbutton.test_failed.
It then pops up a dialog warning the user that the most recent test has failed whenever they try to toggle,
but it is not clear how the user should go about rerunning the test. We should at least tell them where it is
in this dialog.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/1155memset on mem or memset on circ?2020-06-13T14:03:10ZRoger Dingledinememset on mem or memset on circ?ABCD> "memset(circ, 0xAA, memlen)" and "memset(conn, 0xAA, memlen)"
theoretically incorrect. It should be "memset (mem, 0xAA, memlen)" instead.
> ABCD: ah. we're not poisoning all of it, because we're starting at the wrong
location?
ABCD...ABCD> "memset(circ, 0xAA, memlen)" and "memset(conn, 0xAA, memlen)"
theoretically incorrect. It should be "memset (mem, 0xAA, memlen)" instead.
> ABCD: ah. we're not poisoning all of it, because we're starting at the wrong
location?
ABCD> no, it's right becaouse offset zero. but actually circ and or_circ not
the same
> ah. yeah. i was just checking out TO_ORIGIN_CIRCUIT() to make sure the
offset is zero
> so the suggestion is to change it to mem, in case one day we make the offset
not zero?
ABCD> yes, at least DOWNCAST(or_connection_t, c) exist for something.
> explain that second part?
ABCD> as result it STRUCT_OFFSET(subtype, basemember) which zero if offset
strictly is zero.
> we're probably screwed in plenty of other places if we make _base not the
first element of these structs.
> also, why the heck are we poisoning the two types of structs with exactly
the same byte?
> shouldn't one of them by AB or something?
> 0xCC would probably make us happier
ABCD> I found only those two cases, introduced by r13414.
> ah. those are the commits we added when the cold boot attacks were first
known to us but hadn't been made public yet.
> we made sure to scribble on anything that might be sensitive, when we're
done using it.
> i do wonder how many compilers optimize it out, though.
> in fact. are the compilers more likely to optimize it out when we memset mem
and then free mem?
> whereas they'll leave it in if we memset circ and then free mem?
ABCD> compilers so smart this days, who knows.
So, three questions to ponder.
First: should we change circ and conn to mem in these two cases, to make it
clearer which struct we're clobbering? I would say yes.
Second: should we leave circ and conn alone, in hopes that the more complex
code is more likely to fool the compiler into not optimizing the code out?
I would say yes.
Third: should we change one of the AA's into CC, to reduce the chance that
one day we see AA in memory and realize we don't know which struct we're
looking at? I would say yes.
I think my 'yes' on #1 and #2 are incompatible, and I think yes for #1 should
take priority.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/1156Vidalia in OS X tiger bundle built with wrong libiconv?2009-11-21T10:44:46ZRoger DingledineVidalia in OS X tiger bundle built with wrong libiconv?minipli> when starting it from a shell it tells me something about
incompatible library versions for libiconv.2.dylib :(
minipli> arma: I would guess the app was linked against the wrong version of
the library, e.g. by building it on a ...minipli> when starting it from a shell it tells me something about
incompatible library versions for libiconv.2.dylib :(
minipli> arma: I would guess the app was linked against the wrong version of
the library, e.g. by building it on a newer version of MacOS X, maybe :/
minipli> arma: The error message I get is that Vidalia requires the version
7.0.0 but the systems version is 5.0.0, so I guess your Mac porter is using
Leopard or Snow Leapard that ship with this version of the library
[Automatically added by flyspray2trac: Operating System: All]Andrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/legacy/trac/-/issues/1157Properly handle torbutton crash state conflicts2010-03-11T23:50:59ZTracProperly handle torbutton crash state conflictsWhen I started Firefox, it says:
Torbutton crash state conflict! Please file bug report with these four values: true,true,true,false
OS: Fedora 12
Firefox 3.5.5
Torbutton 1.2.2
[Automatically added by flyspray2trac: Operating System: A...When I started Firefox, it says:
Torbutton crash state conflict! Please file bug report with these four values: true,true,true,false
OS: Fedora 12
Firefox 3.5.5
Torbutton 1.2.2
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: chen_torhttps://gitlab.torproject.org/legacy/trac/-/issues/1158[info] circuit_testing_failed() on Fedora 122020-06-13T14:03:11ZTrac[info] circuit_testing_failed() on Fedora 12Working Fedora 11 setup with 0.2.1.20 upgraded to Fedora 12.
Rebuilt tor because of newer OpenSSL 1.0.0-fips-beta4 10 Nov 2009
Tor keeps mentioning:
[info] circuit_testing_failed(): Our testing circuit (to see if your ORPort is reachable...Working Fedora 11 setup with 0.2.1.20 upgraded to Fedora 12.
Rebuilt tor because of newer OpenSSL 1.0.0-fips-beta4 10 Nov 2009
Tor keeps mentioning:
[info] circuit_testing_failed(): Our testing circuit (to see if your ORPort is reachable) has failed. I'll try again later.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: udohttps://gitlab.torproject.org/legacy/trac/-/issues/1159Changing Tor proxy settings seems to require FF restart2018-03-11T07:33:13ZMike PerryChanging Tor proxy settings seems to require FF restartWhen Tor proxy settings are changed in Firefox 3.5, for some reason they don't seem to apply until a
firefox restart happens. Could be a firefox bug. Or could be ours.
[Automatically added by flyspray2trac: Operating System: All]When Tor proxy settings are changed in Firefox 3.5, for some reason they don't seem to apply until a
firefox restart happens. Could be a firefox bug. Or could be ours.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/1160AllowSingleHopExits setting can be bypassed by client2020-06-13T14:03:12ZTracAllowSingleHopExits setting can be bypassed by clientUsing the software Tortunnel
http://www.thoughtcrime.org/software/tortunnel/
it is easy to setup a 1-hop proxy through a selected exit node,
even if the node has AllowSingleHopExits set to 0 (default).
Maybe i'm being alarmist, but thi...Using the software Tortunnel
http://www.thoughtcrime.org/software/tortunnel/
it is easy to setup a 1-hop proxy through a selected exit node,
even if the node has AllowSingleHopExits set to 0 (default).
Maybe i'm being alarmist, but this seems like abuse waiting to happen -
a disaster for exit node operators and for network capacity re:p2p.
If this isnt fixable in a few days i'll be switching to non-exit.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: kebhttps://gitlab.torproject.org/legacy/trac/-/issues/1161What is this2009-12-02T08:44:22ZTracWhat is thisXML Parsing Error: undefined entity
Location: jar:file:///C:/Program%20Files/Mozilla%20Firefox/chrome/toolkit.jar!/content/global/netError.xhtml
Line Number 60, Column 12: <title>&loadError.label;</title>
-----------!^
And test dont p...XML Parsing Error: undefined entity
Location: jar:file:///C:/Program%20Files/Mozilla%20Firefox/chrome/toolkit.jar!/content/global/netError.xhtml
Line Number 60, Column 12: <title>&loadError.label;</title>
-----------!^
And test dont pass
Tor proxy test: Internal error
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: PetkoGhttps://gitlab.torproject.org/legacy/trac/-/issues/1162cant start a relay2020-06-13T14:03:12ZTraccant start a relayHello . I just tried your software. It works ok as long as I use it as a client but not if I try to relay : it crashes every time, it says tor as unexpedly exits.
here the log :
déc. 02 19:20:13.594 [Notice] Tor v0.2.1.20. This is experi...Hello . I just tried your software. It works ok as long as I use it as a client but not if I try to relay : it crashes every time, it says tor as unexpedly exits.
here the log :
déc. 02 19:20:13.594 [Notice] Tor v0.2.1.20. This is experimental software. Do not rely on it for strong anonymity. (Running on Windows XP Service Pack 3 [workstation] {terminal services, single user})
déc. 02 19:20:15.454 [Notice] Initialized libevent version 1.4.12-stable using method win32. Good.
déc. 02 19:20:15.454 [Notice] Opening Socks listener on 127.0.0.1:9050
déc. 02 19:20:15.454 [Notice] Opening Control listener on 127.0.0.1:9051
déc. 02 19:20:28.766 [Notice] Parsing GEOIP file.
déc. 02 19:20:28.766 [Notice] We now have enough directory information to build circuits.
déc. 02 19:20:28.766 [Notice] Bootstrapped 80%: Connecting to the Tor network.
déc. 02 19:20:28.766 [Notice] Bootstrapped 85%: Finishing handshake with first hop.
déc. 02 19:20:28.766 [Notice] Bootstrapped 90%: Establishing a Tor circuit.
déc. 02 19:20:28.766 [Notice] Tor has successfully opened a circuit. Looks like client functionality is working.
déc. 02 19:20:28.766 [Notice] Bootstrapped 100%: Done.
déc. 02 19:20:28.766 [Notice] Your ContactInfo config option is not set. Please consider setting it, so we can contact you if your server is misconfigured or something else goes wrong.
déc. 02 19:20:28.766 [Notice] Opening OR listener on 0.0.0.0:443
déc. 02 19:20:28.766 [Notice] Opening Directory listener on 0.0.0.0:9030
déc. 02 19:20:28.766 [Notice] Your Tor server's identity key fingerprint is 'Unnamed AC09D7B124DE36F537AD17F586BF41C397F0B67F'
déc. 02 19:20:28.766 [Error] libevent call with win32 failed: Socket operation on nonsocket [WSAENOTSOCK ] [10038]
No matter what I try the last line always occur and crash the software.
Im under xp sp3 pro.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: tedtedhttps://gitlab.torproject.org/legacy/trac/-/issues/1163personal links & history lost on FF 3.6 b42009-12-06T16:00:27ZTracpersonal links & history lost on FF 3.6 b4Torbutton 1.2.2 on new Firefox 3.6beta4 (installed from developper's site with appropriate FF about:config overrides). OS = Windows 2k SP4.
Extension basically works but while torbutton is isntalled in browser (even in OFF state = non p...Torbutton 1.2.2 on new Firefox 3.6beta4 (installed from developper's site with appropriate FF about:config overrides). OS = Windows 2k SP4.
Extension basically works but while torbutton is isntalled in browser (even in OFF state = non proxying):
- all bookmarks are gone, including personal toolbar :=(
- history, ditto .
Those come back to life if extension is *removed* from FF ; maybe *deactivate* Torbutton will do, too (not tried)
I did not seem to have any problem with Torbutton on the non beta 3.5.5 (which I ditched because it crashed too much, unrelated to Torbutton)
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: noino667https://gitlab.torproject.org/legacy/trac/-/issues/1164Error torbutton 1.2.3 with firefox 3.6 b42009-12-16T02:15:09ZTracError torbutton 1.2.3 with firefox 3.6 b4Hi. I have installed a new version of torbutton add-on for firefox,but in the firefox 3.6 b4 i have a error when i
click in the icon for disactivate it. It give me error in the java function. And other in the firefox 3.6 b4 the cronolog...Hi. I have installed a new version of torbutton add-on for firefox,but in the firefox 3.6 b4 i have a error when i
click in the icon for disactivate it. It give me error in the java function. And other in the firefox 3.6 b4 the cronology it's
disactivated after the installation of add-on 1.2.3.
Bye and good work.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: Tarantola46https://gitlab.torproject.org/legacy/trac/-/issues/1165Error Pop-up Message on Torbutton Enable - Fx 3.6 B32009-12-10T22:52:33ZTracError Pop-up Message on Torbutton Enable - Fx 3.6 B3Using Firefox 3.6 Beta 3 I received this error message when I enabled Torbutton.
Torbutton: Please file bug report! Error applying Tor settings: [Exception... "Could not convert JavaScript argument arg 0 [nsISupports.QueryInterface]" n...Using Firefox 3.6 Beta 3 I received this error message when I enabled Torbutton.
Torbutton: Please file bug report! Error applying Tor settings: [Exception... "Could not convert JavaScript argument arg 0 [nsISupports.QueryInterface]" nsresult: "0x80570009 (NS_ERROR_XPC_BAD_CONVERT_JS)" location: "JS frame :: chrome://torbutton/content/torbutton.js :: torbutton_toggle_win_jsplugins :: line 2011" data: no]
However it worked fine when I reverted back to using Firefox 3.5.5
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: stephenjudgehttps://gitlab.torproject.org/legacy/trac/-/issues/1166Memory leak in Polipo2011-01-26T19:47:03ZTracMemory leak in PolipoPolipo appears to leak atoms containing server headers. See the thread starting with
http://mid.gmane.org/20091015101315.GA8533@feather
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: jchPolipo appears to leak atoms containing server headers. See the thread starting with
http://mid.gmane.org/20091015101315.GA8533@feather
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: jchhttps://gitlab.torproject.org/legacy/trac/-/issues/1167Polipo doesn't like 200 replies with Content-Range.2011-01-26T19:47:35ZTracPolipo doesn't like 200 replies with Content-Range.Some web servers reportedly return content-range even with 200 replies.
See http://mid.gmane.org/20090823000216.GA105@subspacefield.org
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: jchSome web servers reportedly return content-range even with 200 replies.
See http://mid.gmane.org/20090823000216.GA105@subspacefield.org
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: jchhttps://gitlab.torproject.org/legacy/trac/-/issues/1168Memory leak in Polipo's DNS2011-01-26T19:46:42ZTracMemory leak in Polipo's DNSThere is apparently some minor memory leak in the DNS code.
http://mid.gmane.org/4cf999c70904230801o6bda7fcftb0f98b808ae7b177@mail.gmail.com
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: jchThere is apparently some minor memory leak in the DNS code.
http://mid.gmane.org/4cf999c70904230801o6bda7fcftb0f98b808ae7b177@mail.gmail.com
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: jchhttps://gitlab.torproject.org/legacy/trac/-/issues/1169Certain types of popups are blocked2020-06-12T23:39:16ZMike PerryCertain types of popups are blockedIn torbutton 1.2.3, certain types of website popups seem to be appearing as blank pages as opposed to working
properly.
I am still looking for popup examples to reproduce this behaviour. It has been reported to me second hand via
http:...In torbutton 1.2.3, certain types of website popups seem to be appearing as blank pages as opposed to working
properly.
I am still looking for popup examples to reproduce this behaviour. It has been reported to me second hand via
http://forums.mozillazine.org/viewtopic.php?f=38&t=1639705 but they did not list specific sites. Please
provide sites/html test cases if you have any.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/1170error rendering page in acid2 and acid3 tests2015-07-14T05:51:01ZTracerror rendering page in acid2 and acid3 testsFirefox 3.5.5 on Ubuntu 9.10
I get different results browsing to these pages
depending whether torbutton is on or off:
acid2.acidtests.org/#top - html4.01 +css2.1 only
acid3.acidtests.org - html4.01+css2.1+javascript
could be related ...Firefox 3.5.5 on Ubuntu 9.10
I get different results browsing to these pages
depending whether torbutton is on or off:
acid2.acidtests.org/#top - html4.01 +css2.1 only
acid3.acidtests.org - html4.01+css2.1+javascript
could be related to bug 1169
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: kebhttps://gitlab.torproject.org/legacy/trac/-/issues/1171network.dns.disablePrefetch resets to false2009-12-12T15:37:13ZTracnetwork.dns.disablePrefetch resets to falseThere's an option in Firefox to disable DNS automatic prefetching of URLs in a page by adding a boolean variable named
'network.dns.disablePrefetch' in about:config, and setting it to 'true'. Torbutton appears to be resetting this valu...There's an option in Firefox to disable DNS automatic prefetching of URLs in a page by adding a boolean variable named
'network.dns.disablePrefetch' in about:config, and setting it to 'true'. Torbutton appears to be resetting this value to
'false' on each usage.
Procedure:
Click Torbutton off ("Tor Disabled")
Add boolean value 'network.dns.disablePrefetch' in Firefox about:config and set to 'true'
Click Torbutton on ("Tor Enabled")
* Torbutton changes 'network.dns.disablePrefetch' to an empty 'string' value *
Click Torbutton off ("Tor Disabled")
* Torbutton changes 'network.dns.disablePrefetch' to 'false' *
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: bugmenothttps://gitlab.torproject.org/legacy/trac/-/issues/1172ORPort found reachable, but I have no routerinfo2020-06-13T14:03:13ZTracORPort found reachable, but I have no routerinfoHello,
Today i update the git version on master branch : commit d086c9a7f73ce5b9b7cf4add07fa7d071b829081
Merge: 9e6225a 28b29e0
and a bug are signaled on my log about the "router_or:port"
déc. 12 17:00:28.456 [Warning] router_orport_f...Hello,
Today i update the git version on master branch : commit d086c9a7f73ce5b9b7cf4add07fa7d071b829081
Merge: 9e6225a 28b29e0
and a bug are signaled on my log about the "router_or:port"
déc. 12 17:00:28.456 [Warning] router_orport_found_reachable(): Bug: ORPort found reachable, but I have no routerinfo yet. Failing to inform controller of success.
libevent: 2.03 alpha Repository UUID: ce677c24-8c1a-0410-9497-a30ef3a96221
Revision: 1557
libc6: 2.10.1 (ubuntu15) (amd64)
OS: kubuntu karmic 9.10 on x86 64 ,Linux moon 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 17:01:44 UTC 2009 x86_64 GNU/Linux
vidalia: 2.7svn Repository UUID: 819a2799-b909-0410-be78-af92f3896072
Revision: 4177
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: starshttps://gitlab.torproject.org/legacy/trac/-/issues/1173crypto.c:613: error: comparison of unsigned expression >= 0 is always true2020-06-13T14:03:13ZRoger Dingledinecrypto.c:613: error: comparison of unsigned expression >= 0 is always truehttps://buildbot.vidalia-project.net/builders/kore.fc12.tor-master/builds/0/steps/compile/logs/stdio
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/common -g -O2 -Wall -g -O2 -fno-strict-aliasing -W -Wfloat-equal -Wundef -Wpointer-ar...https://buildbot.vidalia-project.net/builders/kore.fc12.tor-master/builds/0/steps/compile/logs/stdio
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/common -g -O2 -Wall -g -O2 -fno-strict-aliasing -W -Wfloat-equal -Wundef -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -Wredundant-decls -Wchar-subscripts -Wcomment -Wformat=2 -Wwrite-strings -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wbad-function-cast -Wswitch-enum -Werror -Winit-self -Wmissing-field-initializers -Wdeclaration-after-statement -Wold-style-definition -Waddress -Wmissing-noreturn -Wnormalized=id -Woverride-init -Wstrict-overflow=1 -Wextra -Warray-bounds -MT crypto.o -MD -MP -MF .deps/crypto.Tpo -c -o crypto.o crypto.c
cc1: warnings being treated as errors
crypto.c: In function ‘crypto_pk_write_key_to_string_impl’:
crypto.c:613: error: comparison of unsigned expression >= 0 is always true
make[3]: *** [crypto.o] Error 1
Line is
tor_assert(buf->length >= 0);
where buf is
BUF_MEM *buf;
I bet fc12's openssl has a different BUF_MEM.
edmanm> [edmanm@kore ~]$ openssl version
edmanm> OpenSSL 1.0.0-fips-beta4 10 Nov 2009
Sebastian> the line hasn't been changed since r2461
Nick, any opinions?
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/1174Torbutton displays an exception error message on toggle in FF3.62010-03-11T23:18:33ZTracTorbutton displays an exception error message on toggle in FF3.6 Error applying Tor settings: [Exception... "Could not convert JavaScript argument arg 0 [nsISupports.QueryInterface]" nsresult: "0x80570009
(NS_ERROR_XPC_BAD_CONVERT_JS)" location: "JS frame :: chrome://torbutton/content/torbutton.js... Error applying Tor settings: [Exception... "Could not convert JavaScript argument arg 0 [nsISupports.QueryInterface]" nsresult: "0x80570009
(NS_ERROR_XPC_BAD_CONVERT_JS)" location: "JS frame :: chrome://torbutton/content/torbutton.js ::
torbutton_toggle_win_jsplugins :: line 2011" data: no]
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Boomchaoshttps://gitlab.torproject.org/legacy/trac/-/issues/1175Current Tor bundle crashing on Mac OS X 10.4.11/Intel2020-06-13T14:03:14ZTracCurrent Tor bundle crashing on Mac OS X 10.4.11/IntelI'm downloading the regular recommended Tor bundle from the web site. When it crashes, I find this in the Vidalia log:
http://pastebin.com/m35b7f26d
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
...I'm downloading the regular recommended Tor bundle from the web site. When it crashes, I find this in the Vidalia log:
http://pastebin.com/m35b7f26d
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: wAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/legacy/trac/-/issues/1176server_port_flush looks strange2020-06-13T14:03:14ZSebastian Hahnserver_port_flush looks strangeCoverity (cid 424) complains about us using a freed variable inside the
while loop. Technically we're not doing anything dangerous, because
we explicitly set that variable to null, but while looking at the loop, it
seems that it can neve...Coverity (cid 424) complains about us using a freed variable inside the
while loop. Technically we're not doing anything dangerous, because
we explicitly set that variable to null, but while looking at the loop, it
seems that it can never be executed more than once, because
port->pending_replies is never updated. It appears to me that a patch
like this should fix the problem:
diff --git a/src/or/eventdns.c b/src/or/eventdns.c
index 83bff67..70cf28c 100644
--- a/src/or/eventdns.c
+++ b/src/or/eventdns.c
@@ -1303,6 +1303,12 @@ server_port_flush(struct evdns_server_port *port)
return;
log(EVDNS_LOG_WARN, "Error %s (%d) while writing response to port; dropping", tor_socket_strerror(err), err);
}
+ if (req->next_pending && req->next_pending != req) {
+ port->pending_replies = req->next_pending;
+ } else {
+ port->pending_replies = NULL;
+ }
+
if (server_request_free(req)) {
/* we released the last reference to req->port. */
return;
But maybe I'm missing some subtleties here?
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/1177Segfault in unit tests on Mac OS X Panther2020-06-13T14:03:15ZedmanmSegfault in unit tests on Mac OS X Pantherhttps://buildbot.vidalia-project.net/builders/phobos.osx-panther.tor-master/builds/2101/steps/test/logs/stdio
Last few lines of output:
Dec 15 15:46:33.895 [info] circuit_build_times_add_timeout_worker(): Generated synthetic circuit bu...https://buildbot.vidalia-project.net/builders/phobos.osx-panther.tor-master/builds/2101/steps/test/logs/stdio
Last few lines of output:
Dec 15 15:46:33.895 [info] circuit_build_times_add_timeout_worker(): Generated synthetic circuit build time 102948 for timeout
Dec 15 15:46:33.895 [info] circuit_build_times_add_time(): Adding circuit build time 102948
Dec 15 15:46:33.895 [info] circuit_build_times_add_timeout_worker(): Generated synthetic circuit build time 65671 for timeout
Dec 15 15:46:33.895 [info] circuit_build_times_add_time(): Adding circuit build time 65671
Dec 15 15:46:33.895 [notice] Network connection speed appears to have changed. Resetting timeout to 120s after 16 timeouts and 55 buildtimes.
Dec 15 15:46:33.895 [notice] Network connection speed appears to have changed. Resetting timeout to 120s after 16 timeouts and 57 buildtimes.
process killed by signal 11
program finished with exit code -1
[Automatically added by flyspray2trac: Operating System: OSX 10.3 Panther]Tor: 0.2.2.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/1178buf_shrink_freelists: Assertion (*chp)->next failed;2020-06-12T23:55:49ZTracbuf_shrink_freelists: Assertion (*chp)->next failed;OS = OS 10.6.2 (Snow Leopard) running tor as a relay
Vidalia wanted the latest version of tor installed so I did so. It was annoying in that it lost all of my
application settings, but I reset them.
Now though it will relay for a few ...OS = OS 10.6.2 (Snow Leopard) running tor as a relay
Vidalia wanted the latest version of tor installed so I did so. It was annoying in that it lost all of my
application settings, but I reset them.
Now though it will relay for a few minutes and com up with this in the message log:
Dec 15 19:33:30.011 [Error] Bug: buffers.c:269: buf_shrink_freelists: Assertion (*chp)->next failed; aborting.
It looks like other bugs in here may be related, but was not sure if this would be best as a comment to a
random one or letting you decide where you wanted the info.
[Automatically added by flyspray2trac: Operating System: Other]
**Trac**:
**Username**: Kara_Hhttps://gitlab.torproject.org/legacy/trac/-/issues/1179Error applying Tor settings2009-12-17T02:53:11ZTracError applying Tor settingsHi,
The Torbutton icon appears in the lower right hand side of the browser but when I try to 'Toggle Tor Status' on I receive the following alert:
Torbutton: Please file bug report! Error applying Tor settings: [Exception... "Could not...Hi,
The Torbutton icon appears in the lower right hand side of the browser but when I try to 'Toggle Tor Status' on I receive the following alert:
Torbutton: Please file bug report! Error applying Tor settings: [Exception... "Could not convert JavaScript argument arg 0 [nsISupports.QueryInterface]" nsresult: "0x80570009 (NS_ERROR_XPC_BAD_CONVERT_JS)" location: "JS frame :: chrome://torbutton/content/torbutton.js :: torbutton_toggle_win_jsplugins :: line 2011" data: no]
My setup is as follows:
Browser: FireFox 3.6 beta 4
Torbutton: 1.2.3
Tor bundle: 0.2.1.20
OS: Windows XP (SP3)
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Dukeswharfhttps://gitlab.torproject.org/legacy/trac/-/issues/1180Firefox 3.6.4 similar/same as Id#1165 - verbatum2009-12-18T01:28:01ZTracFirefox 3.6.4 similar/same as Id#1165 - verbatumTorbutton: Please file bug report! Error applying Tor settings:
[Exception... "Could not convert JavaScript argument arg 0 [nsISupports.QueryInterface]" nsresult:
"0x80570009 (NS_ERROR_XPC_BAD_CONVERT_JS)" location:
"JS frame :: chro...Torbutton: Please file bug report! Error applying Tor settings:
[Exception... "Could not convert JavaScript argument arg 0 [nsISupports.QueryInterface]" nsresult:
"0x80570009 (NS_ERROR_XPC_BAD_CONVERT_JS)" location:
"JS frame :: chrome://torbutton/content/torbutton.js :: torbutton_toggle_win_jsplugins :: line 2011" data: no]
[Automatically added by flyspray2trac: Operating System: Other]
**Trac**:
**Username**: merodochttps://gitlab.torproject.org/legacy/trac/-/issues/1181evdns_server_request_format_response() sets TC flag wrong2020-06-13T14:03:15ZRoger Dingledineevdns_server_request_format_response() sets TC flag wrongkenobi> evdns_server_request_format_response() with dnsname_to_labels()
wrongly implements part of rfc1035 about logic for sets of TC bit.
kenobi> " Messages carried by UDP are restricted to 512 bytes (not counting
the IP or UDP headers)...kenobi> evdns_server_request_format_response() with dnsname_to_labels()
wrongly implements part of rfc1035 about logic for sets of TC bit.
kenobi> " Messages carried by UDP are restricted to 512 bytes (not counting
the IP or UDP headers). Longer messages are truncated and the TC bit is set
in the header"
kenobi> TC bits should be sets only if lenght of all message via UDP was more
than 512 bytes. Not alone lables or names.
kenobi> for now TC bit sets for wrongly lengthed labels, which stricly limits
for 63, but those means transmited error not signaling truncate bit.
> do you have a patch? :)
kenobi> I do not have patch, because it's should be designed for future tcp
transport too, so it's slightly hard for patch by one line.
> (does this affect anything in practice, or is it just a theoretical
correctness issue?)
kenobi> It's can be exploit via exotic attack, if reverse lookup was
controled by attacker and exit relay was too. And resolv.conf contained ISP's
DNS.
> what would the attack achieve, in that case?
kenobi> ip address of ISP's DNS
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/1182Polipo crashes2011-03-30T13:50:13ZTracPolipo crashesPolipo crashes when using blogger.com
Windows Vista Ultimate error report:
Application Version: 0.0.0.0
Application Timestamp: 47877dfd
Fault Module Name: polipo.exe
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 47877...Polipo crashes when using blogger.com
Windows Vista Ultimate error report:
Application Version: 0.0.0.0
Application Timestamp: 47877dfd
Fault Module Name: polipo.exe
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 47877dfd
Exception Code: c0000005
Exception Offset: 0001b5b2
OS Version: 6.0.6001.2.1.0.256.1
Locale ID: 1033
Additional Information 1: 81d9
Additional Information 2: 2428a4d88be3972117e6cca3ebfb2d55
Additional Information 3: 463e
Additional Information 4: 40bca99ca186e69317e10cb17b64883f
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: BChttps://gitlab.torproject.org/legacy/trac/-/issues/1183Typo on German index.html "Verööfentlichung"2020-06-13T17:18:21ZTracTypo on German index.html "Verööfentlichung"In the News/Neues section of the german index.html (index.html.de) it says
"28 July 2009: Tor 0.2.1.19 als stabile Version veröffentlicht. Lies die Verööfentlichung für weitere Informationen."
but the word "Verööfentlichung" should be ...In the News/Neues section of the german index.html (index.html.de) it says
"28 July 2009: Tor 0.2.1.19 als stabile Version veröffentlicht. Lies die Verööfentlichung für weitere Informationen."
but the word "Verööfentlichung" should be "Veröffentlichung", so one 'ö' and two 'f'.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Athabahttps://gitlab.torproject.org/legacy/trac/-/issues/1184Sending useless relay cells after the destroy cell2020-06-13T14:05:36ZRoger DingledineSending useless relay cells after the destroy cellr9913 took out the "clear cell queue after sending destroy cell" logic.
Bug 1150 (comment 3519) points out that the cells are just going to get
dropped by the other side anyway.
I think it's right.
There are three places that call con...r9913 took out the "clear cell queue after sending destroy cell" logic.
Bug 1150 (comment 3519) points out that the cells are just going to get
dropped by the other side anyway.
I think it's right.
There are three places that call connection_or_send_destroy().
The first is in relay.c, where we unlink the circ from the n_conn
immediately after.
The second is in command.c, where we refuse new circuits for various
reasons. No cells queued yet.
The third is in circuitlist.c, during circuit-mark-for-close. So the
question is, if the circuit is marked, do we really want to still be
trying to send its cells? Either it got marked from the other side,
in which case the other side has already decided it doesn't want to hear
from us. Or it got marked from our side, in which case either that was
an error (circuit needs to die) or it has no streams on it, in which
case there's no harm in clearing its queue.
Did I miss anything?
Perhaps we should check, in main.c when we're considering whether to mark
it because it's idle, whether there are any cells still in its queue.
Or maybe we should just pass an argument into connection_or_send_destroy()
from the truncate case in relay.c saying "clear the queue please". Then we
can remain ambiguous in the cases above where I said "no harm because surely
the queue has nothing in it". That's certainly the safest approach, but
wouldn't it be nice to simplify rather than complexify? :)
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1185HTTP 204 Triggers Retry Flood/DOS2009-12-21T09:52:58ZTracHTTP 204 Triggers Retry Flood/DOSUpon an origin server sending an HTTP 204 response, two chained instances of polipo (one having the other set as its parentProxy) may continually re-request the resource even after the http client has terminated.
This bug is present in ...Upon an origin server sending an HTTP 204 response, two chained instances of polipo (one having the other set as its parentProxy) may continually re-request the resource even after the http client has terminated.
This bug is present in the current version from git (commit 11af3996e126fe9042f869869fc1c7dbcdee3546), as well as earlier versions.
Here is the setup/replication, in detail:
env -i make PREFIX=$HOME/polipo-install LOCAL_ROOT=$HOME/polipo-install/www install
# Ensure defaults apply
[ -f ~/.polipo ] && mv ~/.polipo ~/.polipo-bak
# Invoke each polipo instance in a separate terminal. You will need to kill at least one of them *very* quickly.
env -i $HOME/polipo-install/bin/polipo logLevel=0xff proxyPort=8801
env -i $HOME/polipo-install/bin/polipo logLevel=0xff proxyPort=8802 parentProxy=127.0.0.1:8801
# In a third terminal, request a resource returning an HTTP 204
env -i http_proxy="http://127.0.0.1:8802/" curl http://stackoverflow.com/posts/1938932/ivc/621d
Curl exits immediately with the following output:
"""curl: (18) transfer closed with outstanding read data remaining"""
The second polipo(8802) produces no log output.
The first polipo(8801) repeats the following line for every request by the second polipo(8802):
"""Superseding object http://stackoverflow.com/posts/1938932/ivc/621d (204 -1 -1 (none) -> 204 -1 -1 (none))"""
Until the second polipo(8802) is killed, it will re-request the resource at an extremely high/abusive rate.
(12 times in the moment it took me to switch terminals and ctrl-c the second polipo.)
I do not have a capture of the traffic between the polipo instances, but I do have a tcpflow capture of the traffic between the first polipo (8801) and the Stackoverflow web server, as seen by my gateway, which I will attach momentarily.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: erikhttps://gitlab.torproject.org/legacy/trac/-/issues/1186Startup "non-tor" doesn't work...2010-05-27T09:34:24ZTracStartup "non-tor" doesn't work...I would like my browser to always start up with Tor / Torbutton disabled, regardless of how the browser was shut down.
I usually disable Tor / Torbutton before I exit my browser, but occasionally I forget, so I'd like it if it automatica...I would like my browser to always start up with Tor / Torbutton disabled, regardless of how the browser was shut down.
I usually disable Tor / Torbutton before I exit my browser, but occasionally I forget, so I'd like it if it automatically
was disabled on startup of the browser.
There is an option under Security Settings -> Startup that seems to be aimed at what I would like, but for some reason it
doesn't appear to work properly for me.
I have my setting currently set to:
On normal startup, set Tor state to: Non-Tor
On session restored startup, set Tor state to: Non-Tor
However, if I close my browser w/out first clicking tor / torbutton off and then restart my browser, the Tor status is
still set to disabled, which seems to be contrary to how my settings are set.
Am I missing something or is this feature not working properly? Does anyone else have this issue or am I doing
something wrong?
Thanx!!!
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: JofCorehttps://gitlab.torproject.org/legacy/trac/-/issues/1187getinfo bridge status2020-06-13T14:03:17ZRoger Dingledinegetinfo bridge statusA user from China suggests at
http://blog.torproject.org/blog/bridge-distribution-strategies#comment-3336 :
"I have a fairly long list of bridges in my settings tab now, and I have no
idea which are actually of any use to me, and which ...A user from China suggests at
http://blog.torproject.org/blog/bridge-distribution-strategies#comment-3336 :
"I have a fairly long list of bridges in my settings tab now, and I have no
idea which are actually of any use to me, and which are dead. Would it be
possible to have some visual indicator in the Vidalia bridge config dialog
that shows which bridges are healthy and which are not?"
This is a great idea, and we should do it. Perhaps Tor should expose this info
via a 'getinfo bridge-status' or equivalent, and then we can show which ones
are configured, which we have a fresh descriptor for, which we've found
reachable, etc. Once we've got the Tor side figured out, then Vidalia could
ask for the bridge status when you open the bridge config window, and mark them
as appropriate.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1188Back button broken on Firefox 3.6 b5 and 1.2.42010-03-11T23:50:43ZTracBack button broken on Firefox 3.6 b5 and 1.2.4Hi.Using firefox 3.6 b5 with the release 1.2.4 I have a problem with the come back button when the extension it's active.
When I click the button the browser not respond and the page not change
I use the 1.2.4 with the firefox 3.5.6 and ...Hi.Using firefox 3.6 b5 with the release 1.2.4 I have a problem with the come back button when the extension it's active.
When I click the button the browser not respond and the page not change
I use the 1.2.4 with the firefox 3.5.6 and the problem not exist.
Sorry for not selection of the just release,but is impossible.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Tarantola46https://gitlab.torproject.org/legacy/trac/-/issues/1189Torbutton 1.2.3 conflicts with Google Toolbar 7.0.20091216Wb12009-12-29T20:20:35ZTracTorbutton 1.2.3 conflicts with Google Toolbar 7.0.20091216Wb1When both Torbutton 1.2.3 and Google Toolbar 7.0.20091216Wb1 are installed, pop-up windows open without any content. Disabling either add-on resolves the issue.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
...When both Torbutton 1.2.3 and Google Toolbar 7.0.20091216Wb1 are installed, pop-up windows open without any content. Disabling either add-on resolves the issue.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: brianrosehttps://gitlab.torproject.org/legacy/trac/-/issues/1190Renegotiation bug still present on OpenBSD 4.6 stable2020-06-13T14:03:18ZTracRenegotiation bug still present on OpenBSD 4.6 stableRenegotiation bug still present on OpenBSD 4.6 with
ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.6/common/004_openssl.patch applied.
Results in the supposedly fixed TLS renegotiation errors in .21, and prevents it from working. Works wit...Renegotiation bug still present on OpenBSD 4.6 with
ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.6/common/004_openssl.patch applied.
Results in the supposedly fixed TLS renegotiation errors in .21, and prevents it from working. Works without the patch, but that
leaves the whole system vulnerable.
[warn] TLS error: unexpected close while renegotiating
same exact problem with 0.2.2.6-alpha
OpenBSD 4.6 ships with OpenSSL 0.9.8k
What is the work-around?
[Automatically added by flyspray2trac: Operating System: Other]
**Trac**:
**Username**: nixmlistsTor: 0.2.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/1191renegotiation bug still present in 0.2.2.6-alpha on OpenBSD 4.6 stable2020-06-13T14:03:18ZTracrenegotiation bug still present in 0.2.2.6-alpha on OpenBSD 4.6 stableRenegotiation bug still present on OpenBSD 4.6 with
ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.6/common/004_openssl.patch applied.
Results in the supposedly fixed TLS renegotiation errors in 0.2.2.6-alpha, and prevents it from working....Renegotiation bug still present on OpenBSD 4.6 with
ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.6/common/004_openssl.patch applied.
Results in the supposedly fixed TLS renegotiation errors in 0.2.2.6-alpha, and prevents it from working. Works without the patch, but that
leaves the whole system vulnerable.
[warn] TLS error: unexpected close while renegotiating
same exact problem with 0.2.1.21
OpenBSD 4.6 ships with OpenSSL 0.9.8k
What is the work-around?
[Automatically added by flyspray2trac: Operating System: Other]
**Trac**:
**Username**: nixmlistshttps://gitlab.torproject.org/legacy/trac/-/issues/1192Polipo doesn't accept conf. variables from command line2009-12-30T18:21:18ZTracPolipo doesn't accept conf. variables from command linePolipo's help and man says there are a possibility to change config from console with smth like `polipo proxyOffline=true`.
Such command outputs nothing and polipo doesn't change its config neither immediately nor after restart:
# polip...Polipo's help and man says there are a possibility to change config from console with smth like `polipo proxyOffline=true`.
Such command outputs nothing and polipo doesn't change its config neither immediately nor after restart:
# polipo -v | grep Offline
proxyOffline boolean false Avoid contacting remote servers.
# polipo proxyOffline=true
# polipo -v | grep Offline
proxyOffline boolean false Avoid contacting remote servers.
# service polipo restart
Stopping Web Cache: [ OK ]
Starting Web Cache: [ OK ]
# polipo -v | grep Offline
proxyOffline boolean false Avoid contacting remote servers.
Real behaviour doesn't changes too. Switching var on-the-fly from webface ("http://localhost:8123/polipo/config?") works fine.
Polipo version from git 2009-12-16, last commit 11af3996e126fe9042f869869fc1c7dbcdee3546.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: quxhttps://gitlab.torproject.org/legacy/trac/-/issues/1193Measured BW Authority will not work on private networks with less than 3 scan...2020-06-13T14:03:18ZTracMeasured BW Authority will not work on private networks with less than 3 scannersSince Measured BW votes are only used for consensus if there are at least 3 of them, this scheme will never work on a private tor network with less than 3 auth dirs.
I wonder if it would make sense to reduce this check to only one valid ...Since Measured BW votes are only used for consensus if there are at least 3 of them, this scheme will never work on a private tor network with less than 3 auth dirs.
I wonder if it would make sense to reduce this check to only one valid vote to be necessary if TestingTorNetwork is set.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: fabiTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/1194crypto_rand_uint64: Assertion max > 0 failed2020-06-13T14:28:12ZTraccrypto_rand_uint64: Assertion max > 0 failedI'm running tor-0.2.1.21 on an embedded device, a Sagem F@st 3464 modem/router.
some specs:
busybox-1.15.3
uclibc-0.9.26
libevent-1.4.12
openssl-0.9.8l
When starting tor it always fails with following error message:
[err] Bug: crypto.c...I'm running tor-0.2.1.21 on an embedded device, a Sagem F@st 3464 modem/router.
some specs:
busybox-1.15.3
uclibc-0.9.26
libevent-1.4.12
openssl-0.9.8l
When starting tor it always fails with following error message:
[err] Bug: crypto.c:1876: crypto_rand_uint64: Assertion max > 0 failed; aborting.
Is there anything I can do to locate the problem?
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: cygeushttps://gitlab.torproject.org/legacy/trac/-/issues/1195manpage doesn't talk about mbytes and friends2020-06-13T14:03:20ZSebastian Hahnmanpage doesn't talk about mbytes and friendsMaking this bug report so I don't forget
waltman| In setting a value like AccountingMax in torrc, is there a difference
between "500 MB" and "500 MBytes"?
waltman| It's a bit confusing because the manpage says "KB", "MB", etc., but
...Making this bug report so I don't forget
waltman| In setting a value like AccountingMax in torrc, is there a difference
between "500 MB" and "500 MBytes"?
waltman| It's a bit confusing because the manpage says "KB", "MB", etc., but
the examples values all are "KBytes", e.g. "RelayBandwidthRate 100 KBytes"
Sebastian| you can use either one
waltman| cool, thanks
Sebastian| we should fix that in the manpage.
Sebastian| we're thinking about how we can make the manpage easier to
understand for the average use. Hopefully we'll find something.
In our efforts to make the manpage less confusing and more usable for people
with less *nix experience, we might want to explore explaining what we mean
when we allow the user to specify some amount of bandwidth in one section,
and the refer to that section from all the options.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/legacy/trac/-/issues/1196upgrade log level of "Authenticated control connection" message to notice2020-06-13T14:03:20ZTracupgrade log level of "Authenticated control connection" message to noticeIt is important for normal operation and security
to know when something connects to the control port.
Don't really want to see all the other info logging
under normal circumstances though.
Suggest upgrading the message from log_info to...It is important for normal operation and security
to know when something connects to the control port.
Don't really want to see all the other info logging
under normal circumstances though.
Suggest upgrading the message from log_info to log_notice.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: kebhttps://gitlab.torproject.org/legacy/trac/-/issues/1197Graceful shutdown doesn't seem so graceful2020-06-13T14:03:20ZTracGraceful shutdown doesn't seem so gracefulMay be by design: When doing a graceful shutdown, bandwidth graph shows data still flowing at full BW when relay's plug is pulled.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: sponge...May be by design: When doing a graceful shutdown, bandwidth graph shows data still flowing at full BW when relay's plug is pulled.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: sponge_bob_128https://gitlab.torproject.org/legacy/trac/-/issues/1198Solaris 10 compile error "RLIMIT_MEMLOCK undeclared"2020-06-13T14:03:21ZTracSolaris 10 compile error "RLIMIT_MEMLOCK undeclared"When trying to compile tor-0.2.2.6-alpha I get the following error:
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/common -I/opt/csw/include -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT compat.o -MD -MP -MF .de...When trying to compile tor-0.2.2.6-alpha I get the following error:
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/common -I/opt/csw/include -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT compat.o -MD -MP -MF .deps/compat.Tpo -c -o compat.o compat.c
compat.c: In function `tor_set_max_memlock':
compat.c:2224: error: `RLIMIT_MEMLOCK' undeclared (first use in this function)
compat.c:2224: error: (Each undeclared identifier is reported only once
compat.c:2224: error: for each function it appears in.)
gmake[3]: *** [compat.o] Error 1
gmake[3]: Leaving directory `/usr/local/lib/tor-0.2.2.6-alpha/src/common'
This is not an issue with tor-0.2.1.21, I have compiled and running tor-0.2.1.21.
The Solaris 10 is the latest release "5.10 Generic_127112-10 i86pc i386 i86pc" (Nov. 2009) with all recommended
patches.
The details for configure and compiling are as follows:
usmine:/usr/local/lib/tor-0.2.2.6-alpha>
usmine:/usr/local/lib/tor-0.2.2.6-alpha> ./configure --with-libevent-dir=/opt/csw \
> --with-tor-user=tor \
> --with-tor-group=guest \
> --enable-eventdn \
> --sysconfdir=/home/tor
checking for a BSD-compatible install... /opt/sfw/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /opt/sfw/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... i386-pc-solaris2.10
checking host system type... i386-pc-solaris2.10
configure: You are running Solaris; Sometimes threading makes
cpu workers lock up here, so I will disable threads.
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking whether make sets $(MAKE)... (cached) yes
checking for ranlib... ranlib
checking for sed... sed
checking for sha1sum... /opt/sfw/bin/sha1sum
checking for openssl... /usr/local/ssl/bin/openssl
checking for win32... no
checking for MIPSpro compiler... no
checking for grep that handles long lines and -e... /usr/sfw/bin/ggrep
checking for egrep... /usr/sfw/bin/ggrep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether byte ordering is bigendian... no
checking for library containing socket... -lsocket
checking for library containing gethostbyname... -lnsl
checking for library containing dlopen... none required
checking for library containing inet_aton... -lresolv
checking for gettimeofday... yes
checking for ftime... yes
checking for socketpair... yes
checking for uname... yes
checking for inet_aton... yes
checking for strptime... yes
checking for getrlimit... yes
checking for strlcat... yes
checking for strlcpy... yes
checking for strtoull... yes
checking for getaddrinfo... yes
checking for localtime_r... yes
checking for gmtime_r... yes
checking for memmem... no
checking for strtok_r... yes
checking for writev... yes
checking for readv... yes
checking for flock... no
checking for prctl... no
checking for mallinfo... no
checking for malloc_good_size... no
checking for malloc_usable_size... no
checking for sys/types.h... (cached) yes
checking for u_int64_t... no
checking for u_int32_t... no
checking for u_int16_t... no
checking for u_int8_t... no
checking for libevent directory... /opt/csw
checking whether we need extra options to link libevent... (none)
checking for event_get_version... yes
checking for event_get_version_number... no
checking for event_get_method... yes
checking for event_set_log_callback... yes
checking for evdns_set_outgoing_bind_address... no
checking for event_base_loopexit... yes
checking for struct event.min_heap_idx... no
checking event2/event.h usability... no
checking event2/event.h presence... no
checking for event2/event.h... no
checking event2/dns.h usability... no
checking event2/dns.h presence... no
checking for event2/dns.h... no
checking for openssl directory... /usr/local/ssl
checking whether we need extra options to link openssl... (none)
checking for zlib directory... (system)
checking whether we need extra options to link zlib... (none)
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for unistd.h... (cached) yes
checking for string.h... (cached) yes
checking signal.h usability... yes
checking signal.h presence... yes
checking for signal.h... yes
checking for sys/stat.h... (cached) yes
checking for sys/types.h... (cached) yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking sys/fcntl.h usability... yes
checking sys/fcntl.h presence... yes
checking for sys/fcntl.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking errno.h usability... yes
checking errno.h presence... yes
checking for errno.h... yes
checking assert.h usability... yes
checking assert.h presence... yes
checking for assert.h... yes
checking time.h usability... yes
checking time.h presence... yes
checking for time.h... yes
checking netdb.h usability... yes
checking netdb.h presence... yes
checking for netdb.h... yes
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
checking for sys/ioctl.h... yes
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking arpa/inet.h usability... yes
checking arpa/inet.h presence... yes
checking for arpa/inet.h... yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking pwd.h usability... yes
checking pwd.h presence... yes
checking for pwd.h... yes
checking grp.h usability... yes
checking grp.h presence... yes
checking for grp.h... yes
checking sys/un.h usability... yes
checking sys/un.h presence... yes
checking for sys/un.h... yes
checking sys/uio.h usability... yes
checking sys/uio.h presence... yes
checking for sys/uio.h... yes
checking for stdint.h... (cached) yes
checking for sys/types.h... (cached) yes
checking for inttypes.h... (cached) yes
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking sys/wait.h usability... yes
checking sys/wait.h presence... yes
checking for sys/wait.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking sys/limits.h usability... no
checking sys/limits.h presence... no
checking for sys/limits.h... no
checking for netinet/in.h... (cached) yes
checking for arpa/inet.h... (cached) yes
checking machine/limits.h usability... no
checking machine/limits.h presence... no
checking for machine/limits.h... no
checking syslog.h usability... yes
checking syslog.h presence... yes
checking for syslog.h... yes
checking for sys/time.h... (cached) yes
checking sys/resource.h usability... yes
checking sys/resource.h presence... yes
checking for sys/resource.h... yes
checking for inttypes.h... (cached) yes
checking utime.h usability... yes
checking utime.h presence... yes
checking for utime.h... yes
checking sys/utime.h usability... yes
checking sys/utime.h presence... yes
checking for sys/utime.h... yes
checking sys/mman.h usability... yes
checking sys/mman.h presence... yes
checking for sys/mman.h... yes
checking netinet/in6.h usability... no
checking netinet/in6.h presence... no
checking for netinet/in6.h... no
checking malloc.h usability... yes
checking malloc.h presence... yes
checking for malloc.h... yes
checking sys/syslimits.h usability... no
checking sys/syslimits.h presence... no
checking for sys/syslimits.h... no
checking malloc/malloc.h usability... no
checking malloc/malloc.h presence... no
checking for malloc/malloc.h... no
checking linux/types.h usability... no
checking linux/types.h presence... no
checking for linux/types.h... no
checking sys/file.h usability... yes
checking sys/file.h presence... yes
checking for sys/file.h... yes
checking malloc_np.h usability... no
checking malloc_np.h presence... no
checking for malloc_np.h... no
checking sys/prctl.h usability... no
checking sys/prctl.h presence... no
checking for sys/prctl.h... no
checking for declaration of malloc_good_size... no
checking for net/if.h... yes
checking for net/pfvar.h... no
checking for linux/netfilter_ipv4.h... no
configure: Transparent proxy support enabled, but missing headers.
checking for struct timeval.tv_sec... yes
checking for int8_t... yes
checking size of int8_t... 1
checking for int16_t... yes
checking size of int16_t... 2
checking for int32_t... yes
checking size of int32_t... 4
checking for int64_t... yes
checking size of int64_t... 8
checking for uint8_t... yes
checking size of uint8_t... 1
checking for uint16_t... yes
checking size of uint16_t... 2
checking for uint32_t... yes
checking size of uint32_t... 4
checking for uint64_t... yes
checking size of uint64_t... 8
checking for intptr_t... yes
checking size of intptr_t... 4
checking for uintptr_t... yes
checking size of uintptr_t... 4
checking for char... yes
checking size of char... 1
checking for short... yes
checking size of short... 2
checking for int... yes
checking size of int... 4
checking for long... yes
checking size of long... 4
checking for long long... yes
checking size of long long... 8
checking for __int64... no
checking size of __int64... 0
checking for void *... yes
checking size of void *... 4
checking for time_t... yes
checking size of time_t... 4
checking for size_t... yes
checking size of size_t... 4
checking for uint... yes
checking for u_char... yes
checking for ssize_t... yes
checking for struct in6_addr... yes
checking for struct sockaddr_in6... yes
checking for sa_family_t... yes
checking for struct in6_addr.s6_addr32... no
checking for struct in6_addr.s6_addr16... no
checking for struct sockaddr_in.sin_len... no
checking for struct sockaddr_in6.sin6_len... no
checking for rlim_t... yes
checking whether time_t is signed... yes
checking for socklen_t... yes
checking size of socklen_t... 4
checking for cell_t... no
checking size of cell_t... 0
checking whether memset(0) sets pointers to NULL... yes
checking whether we can malloc(0) safely.... yes
checking whether we are using 2s-complement arithmetic... yes
checking whether to use dmalloc (debug memory allocation library)... no
checking for mlockall... yes
checking for getresuid... no
checking for getresgid... no
checking for gethostbyname_r... yes
checking how many arguments gethostbyname_r() wants... 5
checking whether the C compiler supports __func__... yes
checking whether the C compiler supports __FUNC__... no
checking whether the C compiler supports __FUNCTION__... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating tor.spec
config.status: creating Doxyfile
config.status: creating contrib/tor.sh
config.status: creating contrib/torctl
config.status: creating contrib/torify
config.status: creating contrib/tor.logrotate
config.status: creating contrib/Makefile
config.status: creating contrib/osx/Makefile
config.status: creating contrib/osx/TorBundleDesc.plist
config.status: creating contrib/osx/TorBundleInfo.plist
config.status: creating contrib/osx/TorDesc.plist
config.status: creating contrib/osx/TorInfo.plist
config.status: creating contrib/osx/TorStartupDesc.plist
config.status: creating src/config/torrc.sample
config.status: creating doc/tor.1
config.status: creating src/Makefile
config.status: creating doc/Makefile
config.status: creating doc/design-paper/Makefile
config.status: creating doc/spec/Makefile
config.status: creating src/config/Makefile
config.status: creating src/common/Makefile
config.status: creating src/or/Makefile
config.status: creating src/test/Makefile
config.status: creating src/win32/Makefile
config.status: creating src/tools/Makefile
config.status: creating contrib/suse/Makefile
config.status: creating contrib/suse/tor.sh
config.status: creating orconfig.h
config.status: executing depfiles commands
usmine:/usr/local/lib/tor-0.2.2.6-alpha> gmake
gmake all-recursive
gmake[1]: Entering directory `/usr/local/lib/tor-0.2.2.6-alpha'
Making all in src
gmake[2]: Entering directory `/usr/local/lib/tor-0.2.2.6-alpha/src'
Making all in common
gmake[3]: Entering directory `/usr/local/lib/tor-0.2.2.6-alpha/src/common'
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/common -I/opt/csw/include -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT address.o -MD -MP -MF .deps/address.Tpo -c -o address.o address.c
mv -f .deps/address.Tpo .deps/address.Po
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/common -I/opt/csw/include -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT log.o -MD -MP -MF .deps/log.Tpo -c -o log.o log.c
log.c:95: warning: 'log_mutex' defined but not used
mv -f .deps/log.Tpo .deps/log.Po
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/common -I/opt/csw/include -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT util.o -MD -MP -MF .deps/util.Tpo -c -o util.o util.c
mv -f .deps/util.Tpo .deps/util.Po
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/common -I/opt/csw/include -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT compat.o -MD -MP -MF .deps/compat.Tpo -c -o compat.o compat.c
compat.c: In function `tor_set_max_memlock':
compat.c:2224: error: `RLIMIT_MEMLOCK' undeclared (first use in this function)
compat.c:2224: error: (Each undeclared identifier is reported only once
compat.c:2224: error: for each function it appears in.)
gmake[3]: *** [compat.o] Error 1
gmake[3]: Leaving directory `/usr/local/lib/tor-0.2.2.6-alpha/src/common'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory `/usr/local/lib/tor-0.2.2.6-alpha/src'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/local/lib/tor-0.2.2.6-alpha'
gmake: *** [all] Error 2
usmine:/usr/local/lib/tor-0.2.2.6-alpha>
[Automatically added by flyspray2trac: Operating System: Solaris]
**Trac**:
**Username**: ottohttps://gitlab.torproject.org/legacy/trac/-/issues/1199German translation: forgotten English string2020-06-13T17:18:21ZTracGerman translation: forgotten English stringSeems like someone missed an English string on easy-download.html.de
It says "Willst du mehr über Tor im Allgemeinen lernen?learning more about Tor in general?"
The translation is correct, but everything after the first question mark n...Seems like someone missed an English string on easy-download.html.de
It says "Willst du mehr über Tor im Allgemeinen lernen?learning more about Tor in general?"
The translation is correct, but everything after the first question mark needs to be removed.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Athabahttps://gitlab.torproject.org/legacy/trac/-/issues/1200Add port share option to host HTTPS Server and Tor on same port2020-06-13T14:03:22ZTracAdd port share option to host HTTPS Server and Tor on same portOpenVPN includes a "port share" option that allows OpenVPN to run on port 443 and to pass through HTTPS
connections to a Web server running on the same machine (see http://christophe.vandeplas.com/2008/06/01/portsharing-with-openvpn). Th...OpenVPN includes a "port share" option that allows OpenVPN to run on port 443 and to pass through HTTPS
connections to a Web server running on the same machine (see http://christophe.vandeplas.com/2008/06/01/portsharing-with-openvpn). Thus, both applications are able to use
port 443 at the same time.
Implementing such a feature for Tor may allow to make it harder to detect Tor bridges from the outside, as they could
behave to non-Tor clients such as a regular Web server (and even include legitimate Web content).
Furthermore, such a feature may make it easier for people running bridges to run these bridges on port 443, as it is
still possible to run a HTTPS server at the same IP.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: gstTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/1201mapaddress broken2020-06-13T14:03:22ZTracmapaddress brokenSince an update to 0.2.1.21 from 0.2.1.20 in both Linux and Windows, the mapaddress feature in the torrc file broke.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: johndoe32102002Since an update to 0.2.1.21 from 0.2.1.20 in both Linux and Windows, the mapaddress feature in the torrc file broke.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: johndoe32102002Tor: 0.2.2.x-final