Re: [tor-bugs] #5084 [Tor Bridge]: pt_prepare_proxy_list_for_config_read: Assertion unconfigured_proxies_n == 0 failed
#5084: pt_prepare_proxy_list_for_config_read: Assertion unconfigured_proxies_n == 0 failed +--- Reporter: arma| Owner: Type: defect | Status: new Priority: major | Milestone: Tor: 0.2.3.x-final Component: Tor Bridge |Version: Keywords: | Parent: Points: | Actualpoints: +--- Comment(by arma): Progress! I don't need TBB. I can run my Tor with an open control port, and then connect a Vidalia to it and it dies. Consistently. Now I can run my own Tor. But if I break on pt_prepare_proxy_list_for_config_read(), it won't die. Fun. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5084#comment:5 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5083 [Obfsproxy]: Implement heartbeat message in obfsproxy
#5083: Implement heartbeat message in obfsproxy -+-- Reporter: karsten | Owner: asn Type: enhancement | Status: needs_review Priority: normal | Milestone: Component: Obfsproxy|Version: Keywords: | Parent: Points: | Actualpoints: -+-- Comment(by karsten): I just updated my heartbeat_uniqueips branch with a minor clarification of the log message. Still needs review. Thanks! -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5083#comment:5 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
[tor-bugs] #5098 [Obfsproxy]: obfsproxy src/main.h has prototype for tor_main
#5098: obfsproxy src/main.h has prototype for tor_main
---+
Reporter: rransom| Owner: asn
Type: defect | Status: new
Priority: minor | Milestone:
Component: Obfsproxy |Version:
Keywords: | Parent:
Points: | Actualpoints:
---+
This prototype does not belong in obfsproxy's src/main.h:
{{{
int tor_main(int argc, char *argv[]);
}}}
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/5098
Tor Bug Tracker Wiki https://trac.torproject.org/
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
[tor-bugs] #5099 [Tor Client]: When ServerTransportPlugin specifies a non-existent file, there's only a debug log
#5099: When ServerTransportPlugin specifies a non-existent file, there's only a debug log +--- Reporter: Sebastian | Owner: Type: defect | Status: new Priority: normal | Milestone: Tor: 0.2.3.x-final Component: Tor Client |Version: Keywords: | Parent: Points: | Actualpoints: +--- Instead we should warn the user about it. This is a very easy to make mistake, and the error messages that follow don't make sense. The debug message you'd have to parse is: [Debug] handle_proxy_line(): Got a line from managed proxy: ERR: Failed to spawn background process - code 9/2 -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5099 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5097 [Tor Bridge]: “TOR_PT_EXTENDED_SERVER_PORT=127.0.0.1:4200”
#5097: “TOR_PT_EXTENDED_SERVER_PORT=127.0.0.1:4200” +--- Reporter: rransom | Owner: Type: defect | Status: new Priority: blocker | Milestone: Tor: 0.2.3.x-final Component: Tor Bridge |Version: Keywords: | Parent: Points: | Actualpoints: +--- Comment(by Sebastian): branch bug5097 in my obfsproxy repository -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5097#comment:3 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5097 [Tor Bridge]: “TOR_PT_EXTENDED_SERVER_PORT=127.0.0.1:4200”
#5097: “TOR_PT_EXTENDED_SERVER_PORT=127.0.0.1:4200” +--- Reporter: rransom | Owner: Type: defect | Status: needs_review Priority: blocker | Milestone: Tor: 0.2.3.x-final Component: Tor Bridge |Version: Keywords: | Parent: Points: | Actualpoints: +--- Changes (by Sebastian): * status: new = needs_review Comment: branch bug5097 in rransom's tor repository -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5097#comment:4 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5084 [Tor Bridge]: pt_prepare_proxy_list_for_config_read: Assertion unconfigured_proxies_n == 0 failed
#5084: pt_prepare_proxy_list_for_config_read: Assertion unconfigured_proxies_n == 0 failed +--- Reporter: arma| Owner: Type: defect | Status: new Priority: major | Milestone: Tor: 0.2.3.x-final Component: Tor Bridge |Version: Keywords: | Parent: Points: | Actualpoints: +--- Comment(by arma): (gdb) print (char *)*(*(managed_proxy_t *)*managed_proxy_list-list)-transports-list $4 = 0x234c010 obfs2 -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5084#comment:6 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5084 [Tor Bridge]: pt_prepare_proxy_list_for_config_read: Assertion unconfigured_proxies_n == 0 failed
#5084: pt_prepare_proxy_list_for_config_read: Assertion unconfigured_proxies_n == 0 failed +--- Reporter: arma| Owner: Type: defect | Status: new Priority: major | Milestone: Tor: 0.2.3.x-final Component: Tor Bridge |Version: Keywords: | Parent: Points: | Actualpoints: +--- Comment(by arma): Vidalia is doing two setconfs in quick succession. The first one causes pt_kickstart_proxy() to find that mp-got_hup and mp-marked_for_removal are true, so it increments unconfigured_proxies_n to 1. The second one finds unconfigured_proxies_n to still be 1, yet the mp in the list has conf_state PT_PROTO_COMPLETED so it doesn't call managed_proxy_destroy() on it, and then triggers the assert since it finished going through the list yet unconfigured_proxies_n is still 1. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5084#comment:7 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5084 [Tor Bridge]: pt_prepare_proxy_list_for_config_read: Assertion unconfigured_proxies_n == 0 failed
#5084: pt_prepare_proxy_list_for_config_read: Assertion unconfigured_proxies_n == 0 failed +--- Reporter: arma| Owner: Type: defect | Status: new Priority: major | Milestone: Tor: 0.2.3.x-final Component: Tor Bridge |Version: Keywords: | Parent: Points: | Actualpoints: +--- Comment(by arma): Ok, I don't even need vidalia to trigger the assert. Run your Tor, connect to the control port, authenticate, then paste setconf socksport=9050 twice in quick succession. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5084#comment:8 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5084 [Tor Bridge]: pt_prepare_proxy_list_for_config_read: Assertion unconfigured_proxies_n == 0 failed
#5084: pt_prepare_proxy_list_for_config_read: Assertion unconfigured_proxies_n == 0 failed +--- Reporter: arma| Owner: Type: defect | Status: new Priority: major | Milestone: Tor: 0.2.3.x-final Component: Tor Bridge |Version: Keywords: | Parent: Points: | Actualpoints: +--- Comment(by arma): Or just hup it twice in quick succession. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5084#comment:9 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
[tor-bugs] #5100 [Obfsproxy]: Add notice log level to obfsproxy
#5100: Add notice log level to obfsproxy -+-- Reporter: karsten | Owner: asn Type: enhancement | Status: new Priority: normal | Milestone: Component: Obfsproxy|Version: Keywords: | Parent: Points: | Actualpoints: -+-- While working on heartbeat log messages (#5083) I was wondering which log level I should use. info doesn't make much sense if we're logging sensitive information to info. warn doesn't make sense, because a heartbeat message shouldn't make operators think something's wrong. Having a notice log level and making it the new default might be useful. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5100 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5100 [Obfsproxy]: Add notice log level to obfsproxy
#5100: Add notice log level to obfsproxy -+-- Reporter: karsten | Owner: asn Type: enhancement | Status: needs_review Priority: normal | Milestone: Component: Obfsproxy|Version: Keywords: | Parent: Points: | Actualpoints: -+-- Changes (by karsten): * status: new = needs_review Comment: Please review branch noticelogs in my public repository. (When merging this branch and #5083 shortly after, please change the heartbeat log message level to notice, too.) -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5100#comment:1 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5084 [Tor Bridge]: pt_prepare_proxy_list_for_config_read: Assertion unconfigured_proxies_n == 0 failed
#5084: pt_prepare_proxy_list_for_config_read: Assertion unconfigured_proxies_n
==
0 failed
+---
Reporter: arma| Owner:
Type: defect | Status: new
Priority: major | Milestone: Tor: 0.2.3.x-final
Component: Tor Bridge |Version:
Keywords: | Parent:
Points: | Actualpoints:
+---
Description changed by arma:
Old description:
Tor dies with
{{{
Feb 11 08:34:46.668 [Error] pt_prepare_proxy_list_for_config_read(): Bug:
transports.c:1221: pt_prepare_proxy_list_for_config_read: Assertion
unconfigured_proxies_n == 0 failed; aborting.
}}}
Steps to reproduce:
1) grab your favorite obfsproxy tbb from the download section on
https://www.torproject.org/projects/obfsproxy
2) unpack it and start it
3) click on settings in vidalia, then click ok.
New description:
Tor dies with
{{{
Feb 11 08:34:46.668 [Error] pt_prepare_proxy_list_for_config_read(): Bug:
transports.c:1221: pt_prepare_proxy_list_for_config_read: Assertion
unconfigured_proxies_n == 0 failed; aborting.
}}}
Steps to reproduce:
1) configure your tor to use a managed ClientTransportPlugin, e.g.
{{{
ClientTransportPlugin obfs2 exec /path/to/obfsproxy --managed
}}}
2) hup your Tor twice in quick succession
--
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/5084#comment:10
Tor Bug Tracker Wiki https://trac.torproject.org/
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5047 [Obfsproxy]: Implement basic usage statistics in obfsproxy
#5047: Implement basic usage statistics in obfsproxy
-+--
Reporter: karsten | Owner: karsten
Type: enhancement | Status: assigned
Priority: normal | Milestone:
Component: Obfsproxy|Version:
Keywords: | Parent:
Points: | Actualpoints:
-+--
Comment(by atagar):
Took a quick scan and looks good to me.
locale_to_reqs[locale] = 8 * (int((len(locale_to_ip[locale]) + 7) / 8))
Is the extra int conversion really necessary? int / int = int
{{{
foo = [1, 2, 3, 4, 5, 6, 7, 8, 9]
len(foo) / 8
1
type(len(foo) / 8)
type 'int'
}}}
print hashed-fingerprint %s % sha1(a2b_hex(fingerprint)).hexdigest()
Is this right? The fingerprint arg is already equal to...
{{{
fingerprint = sha1(a2b_hex(m.group(1))).hexdigest()
}}}
ccnn = []
I haven't a clue what 'ccnn' stands for. It might be the convention with
some languages to abbreviate variables to cryptic and largely un-guessable
acronyms, but with python it's preferable to spell it out.
Cheers! -Damian
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/5047#comment:5
Tor Bug Tracker Wiki https://trac.torproject.org/
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #4342 [Company]: move gettor to a tpo machine
#4342: move gettor to a tpo machine -+-- Reporter: erinn| Owner: phobos Type: task | Status: accepted Priority: normal | Milestone: Component: Company |Version: Keywords: | Parent: Points: | Actualpoints: -+-- Comment(by kaner): I can do steps 2 and 3. [3 should actually be a matter of configuration] -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/4342#comment:19 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5088 [Metrics Website]: CVS with platform strings of currently running relays can't be downloaded.
#5088: CVS with platform strings of currently running relays can't be
downloaded.
+---
Reporter: bastik | Owner:
Type: defect | Status: closed
Priority: normal | Milestone:
Component: Metrics Website | Version:
Resolution: wontfix |Keywords: CVS platform strings
Parent: | Points:
Actualpoints: |
+---
Changes (by karsten):
* status: new = closed
* resolution: = wontfix
Comment:
You're right, that URL doesn't work so well anymore since we partitioned
the statusentry table in the database. I tried to tweak the query, but
the fix that worked elsewhere didn't work here. I'm going to take the CSV
file off the metrics website. It's a job for TorStatus, not for Metrics
anyway.
Here's a workaround: Download the JSON file of running relays and bridges
from [https://github.com/kloesing/Onionoo Onionoo], strip off bridges, and
grep for platform lines:
{{{
$ curl http://85.214.195.203/details/running running
$ sed '/bridges_published/q' running | grep platform | less
}}}
So, I'm not fixing this bug. Thanks for reporting it anyway!
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/5088#comment:1
Tor Bug Tracker Wiki https://trac.torproject.org/
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5047 [Obfsproxy]: Implement basic usage statistics in obfsproxy
#5047: Implement basic usage statistics in obfsproxy -+-- Reporter: karsten | Owner: karsten Type: enhancement | Status: assigned Priority: normal | Milestone: Component: Obfsproxy|Version: Keywords: | Parent: Points: | Actualpoints: -+-- Comment(by karsten): Thanks for all the suggestions! I added a branch log2stats to my public obfsproxy repository that has an updated log2stats.py script. (Good catch with the int conversion and hashed fingerprints; I didn't implement the tuple-sorting thing, and I left ccnn unchanged.) It's still unclear if we should ask obfsproxy operators to log on info level and use this script, or if they should rather send us their heartbeat log messages (#5083). Let's not add this script to obfsproxy until we have a decision there. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5047#comment:6 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
[tor-bugs] #5102 [Tor Bridge]: segfault in entry_guard_register_connect_status on tor bridge running obfsproxy on openbsd
#5102: segfault in entry_guard_register_connect_status on tor bridge running
obfsproxy on openbsd
-+--
Reporter: therealditzydoo | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: Tor Bridge |Version: Tor: 0.2.3.11-alpha
Keywords: | Parent:
Points: | Actualpoints:
-+--
I am running a tor bridge on openbsd (uname -a output is OpenBSD
[REDACTED] 5.1 GENERIC.MP#2 i386). It is statically linked and runs in a
chroot. Here's the output when it's started not in the chroot:
{{{
Feb 12 05:53:04.331 [notice] Tor v0.2.3.11-alpha running on OpenBSD i386.
Feb 12 05:53:04.331 [notice] Tor can't help you if you use it wrong! Learn
how to be safe at https://www.torproject.org/download/download#warning
Feb 12 05:53:04.331 [notice] This version is not a stable Tor release.
Expect more bugs than usual.
Feb 12 05:53:04.347 [notice] Configuration file /usr/local/etc/tor/torrc
not present, using reasonable defaults.
Feb 12 05:53:04.349 [warn] It's a little hard to tell, but you seem to
have Libevent 1.4.0-beta header files, whereas you have linked against
Libevent 1.4.14b-stable. This will probably make Tor crash.
Feb 12 05:53:04.349 [notice] Initialized libevent version 1.4.14b-stable
using method kqueue. Good.
Feb 12 05:53:04.349 [notice] Opening Socks listener on 127.0.0.1:9050
Feb 12 05:53:04.000 [notice] Parsing GEOIP file
/usr/local/share/tor/geoip.
Feb 12 05:53:04.000 [notice] No AES engine found; using AES_* functions.
Feb 12 05:53:04.000 [notice] This OpenSSL has a good implementation of
counter mode; using it.
Feb 12 05:53:04.000 [notice] OpenSSL OpenSSL 1.0.0f 4 Jan 2012 looks like
version 0.9.8m or later; I will try SSL_OP to enable renegotiation
Feb 12 05:53:04.000 [notice] Reloaded microdescriptor cache. Found 3404
descriptors.
Feb 12 05:53:05.000 [notice] We now have enough directory information to
build circuits.
Feb 12 05:53:05.000 [notice] Bootstrapped 80%: Connecting to the Tor
network.
Feb 12 05:53:06.000 [notice] Heartbeat: Tor's uptime is 0:00 hours, with 2
circuits open. I've sent 0 kB and received 0 kB.
Feb 12 05:53:06.000 [notice] Bootstrapped 85%: Finishing handshake with
first hop.
Feb 12 05:53:07.000 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Feb 12 05:53:09.000 [notice] Tor has successfully opened a circuit. Looks
like client functionality is working.
Feb 12 05:53:09.000 [notice] Bootstrapped 100%: Done.
^CFeb 12 05:56:54.000 [notice] Interrupt: exiting cleanly.
}}}
When run in the chroot (with chroot -u _tor -g _tor /home/chrooted/tor
/bin/tor -f /etc/tor/torrc-relay), it runs for a bit, then crashes without
leaving anything in the logfile. It dumps a core. Here's the output of bt
from gdb:
{{{
gdb mytor mycore
GNU gdb 6.3
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-unknown-openbsd5.0...
Core was generated by `tor'.
Program terminated with signal 11, Segmentation fault.
#0 0x1c07b57b in entry_guard_register_connect_status ()
(gdb) bt
#0 0x1c07b57b in entry_guard_register_connect_status ()
#1 0x1c0ba387 in connection_or_set_state_open ()
#2 0x1c08bea5 in command_process_netinfo_cell ()
#3 0x1c08988d in command_process_cell ()
#4 0x1c0baa51 in connection_or_process_cells_from_inbuf ()
#5 0x1c0b7578 in connection_or_process_inbuf ()
#6 0x1c0a91db in connection_process_inbuf ()
#7 0x1c0a6e7a in connection_handle_read_impl ()
#8 0x1c0a6f94 in connection_handle_read ()
#9 0x1c001cb0 in conn_read_callback ()
#10 0x1c137b35 in event_base_loop (base=0x83cda000, flags=0) at
/usr/src/lib/libevent/event.c:402
#11 0x1c0045e7 in do_main_loop ()
#12 0x1c005cf7 in tor_main ()
#13 0x1c000406 in main ()
(gdb)
}}}
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/5102
Tor Bug Tracker Wiki https://trac.torproject.org/
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5102 [Tor Bridge]: segfault in entry_guard_register_connect_status on tor bridge running obfsproxy on openbsd
#5102: segfault in entry_guard_register_connect_status on tor bridge running
obfsproxy on openbsd
-+--
Reporter: therealditzydoo | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: Tor Bridge |Version: Tor: 0.2.3.11-alpha
Keywords: | Parent:
Points: | Actualpoints:
-+--
Comment(by therealditzydoo):
Here is the output after being compiled with -g -O0:
{{{
GNU gdb 6.3
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-unknown-openbsd5.0...
Core was generated by `tor'.
Program terminated with signal 11, Segmentation fault.
#0 0x1c07b57b in entry_guard_register_connect_status (digest=0x7d0e9b68
%ֲ$ⲯ�0370s-[, succeeded=1,
mark_relay_status=0, now=1329059709) at circuitbuild.c:3909
3909 SMARTLIST_FOREACH(entry_guards, entry_guard_t *, e,
(gdb) bt
#0 0x1c07b57b in entry_guard_register_connect_status (digest=0x7d0e9b68
%ֲ$ⲯ�0370s-[, succeeded=1,
mark_relay_status=0, now=1329059709) at circuitbuild.c:3909
#1 0x1c0ba387 in connection_or_set_state_open (conn=0x7d0e9b00) at
connection_or.c:1700
#2 0x1c08bea5 in command_process_netinfo_cell (cell=0xcfbc0620,
conn=0x7d0e9b00) at command.c:916
#3 0x1c08988d in command_process_cell (cell=0xcfbc0620, conn=0x7d0e9b00)
at command.c:201
#4 0x1c0baa51 in connection_or_process_cells_from_inbuf (conn=0x7d0e9b00)
at connection_or.c:1832
#5 0x1c0b7578 in connection_or_process_inbuf (conn=0x7d0e9b00) at
connection_or.c:390
#6 0x1c0a91db in connection_process_inbuf (conn=0x7d0e9b00,
package_partial=1) at connection.c:3760
#7 0x1c0a6e7a in connection_handle_read_impl (conn=0x7d0e9b00) at
connection.c:2656
#8 0x1c0a6f94 in connection_handle_read (conn=0x7d0e9b00) at
connection.c:2697
#9 0x1c001cb0 in conn_read_callback (fd=97, event=2, _conn=0x7d0e9b00) at
main.c:702
#10 0x1c137b35 in event_base_loop (base=0x87c47800, flags=0) at
/usr/src/lib/libevent/event.c:402
#11 0x1c0045e7 in do_main_loop () at main.c:1924
#12 0x1c005cf7 in tor_main (argc=3, argv=0xcfbc0cc4) at main.c:2619
#13 0x1c000406 in main (argc=Cannot access memory at address 0x0
) at tor_main.c:30
(gdb)
}}}
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/5102#comment:1
Tor Bug Tracker Wiki https://trac.torproject.org/
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5084 [Tor Bridge]: pt_prepare_proxy_list_for_config_read: Assertion unconfigured_proxies_n == 0 failed
#5084: pt_prepare_proxy_list_for_config_read: Assertion unconfigured_proxies_n
==
0 failed
+---
Reporter: arma| Owner:
Type: defect | Status: new
Priority: major | Milestone: Tor: 0.2.3.x-final
Component: Tor Bridge |Version:
Keywords: | Parent:
Points: | Actualpoints:
+---
Comment(by asn):
OK, as you have noticed, the SIGHUP code of src/or/transports.c is not
elegant. If you can find a better logic for it, I'd be very glad. The
current logic is the best I could think of when I was writing it.
This bug has to do with the way we count unconfigured proxies between
config reads.
In the first SIGHUP, the managed proxy is already launched and configured.
During the SIGHUP, we re-parse the config, find the proxy line and give it
to pt_kickstart_proxy()`. In `pt_kickstart_proxy()`, we go into the
{{{
} else { /* known proxy. add its transport to its transport list */
}}}
branch, since we've already parsed this managed proxy when we launched
tor. The proxy was there from before the SIGHUP, so it's already marked
with `got_hup` and `marked_for_removal`. So we go into the next two `if`
blocks and end up incrementing `unconfigured_proxies_n`. We need to do
that, so that in the next `run_scheduled_events()` tick, we execute
`pt_configure_remaining_proxies()` and examine if the proxy needs to be
restarted or not. In this case, the proxy wouldn't need to be restarted,
`proxy_needs_restart()` would have returned False, and
`unconfigured_proxies_n` would have been reduced back to 0. Meanwhile,,
the proxy has been in the `PT_PROTO_COMPLETED` state, since it was spawned
and configured back when we launched tor.
So in this bug, we never do another tick of `run_scheduled_events()`, and
instead we do a second SIGHUP. This means that we re-read the config, and
call `pt_prepare_proxy_list_for_config_read()`. In this code,
`unconfigured_proxies_n == 1` from the previous SIGHUP, and since the
proxy is in `PT_PROTO_COMPLETED` we don't decrement
`unconfigured_proxies_n`. Instead, we reach the bottom of the function and
hit the assert with `1 != 0`.
Notice how `unconfigured_proxies_n` is only actually used in
`pt_proxies_configuration_pending()`, to see whether we should configure
managed proxies in `run_scheduled_events()`. It's also used in some logs,
and to assert that the code does what I expect it to do.
My original stupid fix idea, was to remove `unconfigured_proxies_n--;`
from `pt_prepare_proxy_list_for_config_read()` and simply set
`unconfigured_proxies_n` to 0 in the end of the function, since we are
planning on re-parsing the config file anyway. That might have worked.
Maybe a cleaner solution, would be to remove the `unconfigured_proxies_n`
logic completely, and instead use a boolean, named `need_to_configure_pt`
or something, for pt_proxies_configuration_pending()`. This might be
cleaner, and still not too radical.
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/5084#comment:11
Tor Bug Tracker Wiki https://trac.torproject.org/
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5088 [Metrics Website]: CVS with platform strings of currently running relays can't be downloaded.
#5088: CVS with platform strings of currently running relays can't be downloaded. +--- Reporter: bastik | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: Metrics Website | Version: Resolution: wontfix |Keywords: CVS platform strings Parent: | Points: Actualpoints: | +--- Comment(by bastik): Thank you. Apparently no fix needed. As assumed no windows relay has picked up the latest alpha. Most certainly, due to the lack of compiling tools, as there are none included. Windows doesn't know grep, but thankfully there's a windows version of it. I'm confused. Onionoo is (...) to learn about currently running Tor relays and bridges From what I can tell, the IP addresses are modified. At least the first part. I can't read code well enough to figure out how it's modified. Also I'm unable to figure out what's the hashed fingerprint unless there's some kind of salt involved. I'm unable to find a currently running bridge I know of (IP:PORT and fingerprint), which wasn't my goal. I looked for it because the JSON might include it. Is there anything to read about Onionoo? (This is not the right place to talk about it.) Please don't write any long explanations I don't wanna waste your time. (It's not worth the time) -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5088#comment:2 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5088 [Metrics Website]: CVS with platform strings of currently running relays can't be downloaded.
#5088: CVS with platform strings of currently running relays can't be downloaded. +--- Reporter: bastik | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: Metrics Website | Version: Resolution: wontfix |Keywords: CVS platform strings Parent: | Points: Actualpoints: | +--- Comment(by karsten): You can learn more about sanitized bridge descriptors with their hashed fingerprints and 10.x.x.x IP addresses [https://metrics.torproject.org/formats.html#bridgedesc here]. More information about Onionoo is available [http://kloesing.github.com/Onionoo/ here] and [http://kloesing.github.com/Onionoo/protocol.html here]. If you have more questions feel free to ask on #tor-dev or mail to tor- assista...@lists.torproject.org. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5088#comment:3 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5102 [Tor Bridge]: segfault in entry_guard_register_connect_status on tor bridge running obfsproxy on openbsd
#5102: segfault in entry_guard_register_connect_status on tor bridge running
obfsproxy on openbsd
-+--
Reporter: therealditzydoo | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: Tor Bridge |Version: Tor: 0.2.3.11-alpha
Keywords: | Parent:
Points: | Actualpoints:
-+--
Comment(by therealditzydoo):
I'm using the script shown below to auto-restart tor so there isn't much
downtime on my host:
{{{
#!/bin/sh
while true;
do true
sleep 1
if ! ps aux|grep [t]orrc-relay /dev/null
then
echo -n RESPAWNING AT
date
chroot -u _tor -g _tor /home/chrooted/tor /bin/tor -f /etc/tor/torrc-relay
fi
done
}}}
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/5102#comment:2
Tor Bug Tracker Wiki https://trac.torproject.org/
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5083 [Obfsproxy]: Implement heartbeat message in obfsproxy
#5083: Implement heartbeat message in obfsproxy
-+--
Reporter: karsten | Owner: asn
Type: enhancement | Status: needs_revision
Priority: normal | Milestone:
Component: Obfsproxy|Version:
Keywords: | Parent:
Points: | Actualpoints:
-+--
Changes (by asn):
* status: needs_review = needs_revision
Comment:
Thanks for all the code, karsten!
I skimmed over the code while I was in the subway, here is a quick and
dirty code review:
The check
{{{
p = strrchr(addrport, ':');
if (p 0)
return;
}}}
in `status_note_connection()` seems wrong. `strrchr()` returns a pointer,
so `if (!p)` is probably better than `if (p 0)`. I wonder if we should
use `strchr()` like `util.c:resolve_address_port()` does; but it probably
doesn't really matter.
b) Should we use a hash table or something to query whether a connection
has been seen before? It seems that `smartlist_string_isin()` does a
linear search over a smartlist, and some obfsproxy bridge operators are
currently seeing 1500~ or so unique IPs. I'm not sure if that would cause
lots of load, but a hash table (I think that's a `strmap_t` in
`container.c`) might be better.
c) Are unique IPs and connections information useful/meaningful in the
case of obfsproxy clients?
Thanks for the code again!
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/5083#comment:6
Tor Bug Tracker Wiki https://trac.torproject.org/
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
[tor-bugs] #5103 [Tor Bridge]: --enable-static-tor barfs on openbsd 'cause it tries to link in -lrt which doesn't exist
#5103: --enable-static-tor barfs on openbsd 'cause it tries to link in -lrt
which
doesn't exist
-+--
Reporter: therealditzydoo | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: Tor Bridge |Version: Tor: 0.2.3.11-alpha
Keywords: | Parent:
Points: | Actualpoints:
-+--
CFLAGS= -g -O0 ./configure --with-libevent-dir=/home/SCRUBBED/lib
--prefix=/ --enable-static-tor fails with
{{{
checking for libevent directory... configure: WARNING: Could not find a
linkable libevent. If you have it installed somewhere unusual, you can
specify an explicit path using --with-libevent-dir
}}}
Looking at the config.log we see:
{{{
configure:6383: gcc -o conftest -g -O0 -static -I/home/irene/lib
-I${top_srcdir}/src/common -L/home/SCRUBBED/lib conftest.c -lpthread
-levent -lrt 5
/usr/bin/ld: cannot find -lrt
}}}
which causes the error, because there isn't a librt on openbsd. Indeed,
removing the -lrt in configure makes all work.
{{{
STATIC_LIBEVENT_FLAGS=
if test $enable_static_libevent = yes; then
if test $have_rt = yes; then
STATIC_LIBEVENT_FLAGS= -lrt
fi
fi
}}}
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/5103
Tor Bug Tracker Wiki https://trac.torproject.org/
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5083 [Obfsproxy]: Implement heartbeat message in obfsproxy
#5083: Implement heartbeat message in obfsproxy
-+--
Reporter: karsten | Owner: asn
Type: enhancement | Status: needs_revision
Priority: normal | Milestone:
Component: Obfsproxy|Version:
Keywords: | Parent:
Points: | Actualpoints:
-+--
Comment(by karsten):
Replying to [comment:6 asn]:
The check
{{{
p = strrchr(addrport, ':');
if (p 0)
return;
}}}
in `status_note_connection()` seems wrong. `strrchr()` returns a
pointer, so `if (!p)` is probably better than `if (p 0)`. I wonder if we
should use `strchr()` like `util.c:resolve_address_port()` does; but it
probably doesn't really matter.
Ah, there's the code I was looking for. I'm going to steal it from there.
b) Should we use a hash table or something to query whether a connection
has been seen before? It seems that `smartlist_string_isin()` does a
linear search over a smartlist, and some obfsproxy bridge operators are
currently seeing 1500~ or so unique IPs. I'm not sure if that would cause
lots of load, but a hash table (I think that's a `strmap_t` in
`container.c`) might be better.
Oh. You're right. strmap_t it is.
c) Are unique IPs and connections information useful/meaningful in the
case of obfsproxy clients?
They're the most basic statistics that we have about obfsproxy usage. I'd
prefer having a GeoIP database in obfsproxy and resolve both connections
and unique addresses to country codes. But that requires more coding,
reviewing, and time that we don't have.
Thanks for the code again!
Thanks for the review! I'll make the changes hopefully later today,
otherwise tomorrow morning.
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/5083#comment:7
Tor Bug Tracker Wiki https://trac.torproject.org/
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5068 [Obfsproxy]: memory leak in obfsproxy when using weird args
#5068: memory leak in obfsproxy when using weird args
---+
Reporter: arma | Owner: asn
Type: defect | Status: needs_review
Priority: normal | Milestone:
Component: Obfsproxy |Version:
Keywords: | Parent:
Points: | Actualpoints:
---+
Changes (by blackpaw):
* status: new = needs_review
Comment:
I wrote one line of code and now Valgrind has no complaints.
valgrind --leak-check=yes ./obfsproxy obfs2 --log-file=logfile
--dest=!127.0.0.1:9009 server !0.0.0.0:1051
{{{
==11227==
2012-02-12 12:22:48 [warn] obfs2: Unknown argument '--log-file=logfile'.
2012-02-12 12:22:48 [warn] You failed at creating a correct obfs2 line.
...
==11227==
==11227== HEAP SUMMARY:
==11227== in use at exit: 0 bytes in 0 blocks
==11227== total heap usage: 13 allocs, 13 frees, 3,197 bytes allocated
==11227==
==11227== All heap blocks were freed -- no leaks are possible
==11227==
}}}
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/5068#comment:1
Tor Bug Tracker Wiki https://trac.torproject.org/
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5083 [Obfsproxy]: Implement heartbeat message in obfsproxy
#5083: Implement heartbeat message in obfsproxy
-+--
Reporter: karsten | Owner: asn
Type: enhancement | Status: needs_revision
Priority: normal | Milestone:
Component: Obfsproxy|Version:
Keywords: | Parent:
Points: | Actualpoints:
-+--
Comment(by asn):
Replying to [comment:7 karsten]:
Replying to [comment:6 asn]:
c) Are unique IPs and connections information useful/meaningful in the
case of obfsproxy clients?
They're the most basic statistics that we have about obfsproxy usage.
I'd prefer having a GeoIP database in obfsproxy and resolve both
connections and unique addresses to country codes. But that requires more
coding, reviewing, and time that we don't have.
Hm, when I said 'obfsproxy clients', I meant 'obfsproxy configured as a
client'. We don't seem to count outgoing connections when we are in SOCKS
mode (since we use `open_outbound_hostname()` there), so an obfsproxy
configured with:
{{{
obfsproxy obfs2 socks 127.0.0.1:
}}}
will probably say we saw 0 connections from 0 unique addresses. all the
time.
I think, we should only call `status_note_connection()` if we are a
server, and we should only mention connection information in the heartbeat
message if we are a server.
Karsten, if you cba to do this, I think me or Nick can handle it.
BTW, there is something fishy with the address copying in
`status_note_connection()` it seems like you are using `strcpy()` and try
to copy the whole `addrport` which is bigger than `p - addrport` bytes
since it also contains the TCP port.
Maybe something like this:
{{{
delim = strchr(s, ':');
if (!delim)
return; /* bug of conn-peername? */
tor_assert(delim = s);
addr = xstrndup(s, delim-s);
}}}
could work.
If you are bored, Nick or me can probably handle this too!
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/5083#comment:8
Tor Bug Tracker Wiki https://trac.torproject.org/
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5103 [Tor Bridge]: --enable-static-tor barfs on openbsd 'cause it tries to link in -lrt which doesn't exist
#5103: --enable-static-tor barfs on openbsd 'cause it tries to link in -lrt which doesn't exist -+-- Reporter: therealditzydoo | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Tor Bridge |Version: Tor: 0.2.3.11-alpha Keywords: | Parent: Points: | Actualpoints: -+-- Comment(by Sebastian): Looks like the problem exists because we do AC_SEARCH_LIBS([clock_gettime], [rt], [have_rt=yes]). librt isn't available on openbsd, but clock_gettime is, so have_rt is set to yes and later we add -lrt -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5103#comment:1 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5009 [Obfsproxy]: obfsproxy does not build from instructions on debian squeeze
#5009: obfsproxy does not build from instructions on debian squeeze ---+ Reporter: arma | Owner: asn Type: defect | Status: new Priority: normal | Milestone: Component: Obfsproxy |Version: Keywords: | Parent: Points: | Actualpoints: ---+ Comment(by koolfy): On old debian/ubuntu distributions, libssl might not be recent enough for libevent (dep is = 0.9.8m-1) The easiest and most user-frienly workaround for now is to wget and sudo dpkg -i one of those : http://packages.ubuntu.com/oneiric/i386/libssl0.9.8/download As it's 0.9.8o the dep will be met and the build environment can therefore be installed with the dget described here (https://trac.torproject.org/projects/tor/ticket/5009#comment:9) and the sudo dpkg -i discribed there (https://trac.torproject.org/projects/tor/ticket/5009#comment:22) As opposed to building those manually and adding non-user-friendly and error-prone steps to the process described here (https://www.torproject.org/projects/obfsproxy-instructions.html.en) -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5009#comment:30 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5102 [Tor Bridge]: segfault in entry_guard_register_connect_status on tor bridge running obfsproxy on openbsd
#5102: segfault in entry_guard_register_connect_status on tor bridge running
obfsproxy on openbsd
-+--
Reporter: therealditzydoo | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: Tor Bridge |Version: Tor: 0.2.3.11-alpha
Keywords: | Parent:
Points: | Actualpoints:
-+--
Comment(by therealditzydoo):
Still fails when running with a recent libevent:
{{{
GNU gdb 6.3
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-unknown-openbsd5.0...
warning: exec file is newer than core file.
Core was generated by `tor'.
Program terminated with signal 11, Segmentation fault.
#0 0x1c07347f in entry_guard_register_connect_status (digest=0x7cd57e68
001\030���bR7@\202�TPa�\177, succeeded=1,
mark_relay_status=0, now=1329073119) at circuitbuild.c:3909
3909 SMARTLIST_FOREACH(entry_guards, entry_guard_t *, e,
(gdb) bt
#0 0x1c07347f in entry_guard_register_connect_status (digest=0x7cd57e68
001\030���bR7@\202�TPa�\177, succeeded=1,
mark_relay_status=0, now=1329073119) at circuitbuild.c:3909
#1 0x1c0b228b in connection_or_set_state_open (conn=0x7cd57e00) at
connection_or.c:1700
#2 0x1c083da9 in command_process_netinfo_cell (cell=0xcfbda160,
conn=0x7cd57e00) at command.c:916
#3 0x1c081791 in command_process_cell (cell=0xcfbda160, conn=0x7cd57e00)
at command.c:201
#4 0x1c0b2955 in connection_or_process_cells_from_inbuf (conn=0x7cd57e00)
at connection_or.c:1832
#5 0x1c0af47c in connection_or_process_inbuf (conn=0x7cd57e00) at
connection_or.c:390
#6 0x1c0a10df in connection_process_inbuf (conn=0x7cd57e00,
package_partial=1) at connection.c:3760
#7 0x1c09ed7e in connection_handle_read_impl (conn=0x7cd57e00) at
connection.c:2656
#8 0x1c09ee98 in connection_handle_read (conn=0x7cd57e00) at
connection.c:2697
#9 0x1c001cb0 in conn_read_callback (fd=216, event=2, _conn=0x7cd57e00)
at main.c:702
#10 0x1c133a4a in event_base_loop (base=0x7cb8d000, flags=0) at
event.c:1340
#11 0x1c0045e7 in do_main_loop () at main.c:1924
#12 0x1c005cff in tor_main (argc=3, argv=0xcfbda820) at main.c:2619
#13 0x1c000406 in main (argc=Cannot access memory at address 0x501
) at tor_main.c:30
(gdb)
}}}
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/5102#comment:3
Tor Bug Tracker Wiki https://trac.torproject.org/
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5083 [Obfsproxy]: Implement heartbeat message in obfsproxy
#5083: Implement heartbeat message in obfsproxy
-+--
Reporter: karsten | Owner: asn
Type: enhancement | Status: needs_review
Priority: normal | Milestone:
Component: Obfsproxy|Version:
Keywords: | Parent:
Points: | Actualpoints:
-+--
Comment(by karsten):
Replying to [comment:8 asn]:
Replying to [comment:7 karsten]:
Replying to [comment:6 asn]:
c) Are unique IPs and connections information useful/meaningful in
the case of obfsproxy clients?
They're the most basic statistics that we have about obfsproxy usage.
I'd prefer having a GeoIP database in obfsproxy and resolve both
connections and unique addresses to country codes. But that requires more
coding, reviewing, and time that we don't have.
Hm, when I said 'obfsproxy clients', I meant 'obfsproxy configured as a
client'. We don't seem to count outgoing connections when we are in SOCKS
mode (since we use `open_outbound_hostname()` there), so an obfsproxy
configured with:
{{{
obfsproxy obfs2 socks 127.0.0.1:
}}}
will probably say we saw 0 connections from 0 unique addresses. all
the time.
You're right. We shouldn't say that as a client.
I think, we should only call `status_note_connection()` if we are a
server, and we should only mention connection information in the heartbeat
message if we are a server.
Karsten, if you cba to do this, I think me or Nick can handle it.
To be honest, I don't know where in obfsproxy I'd learn whether we're a
client or a server. If you don't mind too much, would you fix that? Your
suggestion to only call status_note_connection() as a server and not
mention connection information as a client sounds perfectly fine to me.
BTW, there is something fishy with the address copying in
`status_note_connection()` it seems like you are using `strcpy()` and try
to copy the whole `addrport` which is bigger than `p - addrport` bytes
since it also contains the TCP port.
Maybe something like this:
{{{
delim = strchr(s, ':');
if (!delim)
return; /* bug of conn-peername? */
tor_assert(delim = s);
addr = xstrndup(s, delim-s);
}}}
could work.
If you are bored, Nick or me can probably handle this too!
Right, the fishy address copying was indeed fishy. That should now be
fixed in the new status_note_connection().
Thanks again for the very helpful review!
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/5083#comment:10
Tor Bug Tracker Wiki https://trac.torproject.org/
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5079 [Obfsproxy]: obfsproxy: scrub IPs before displaying them in logs
#5079: obfsproxy: scrub IPs before displaying them in logs
---+
Reporter: asn| Owner: asn
Type: defect | Status: new
Priority: normal | Milestone:
Component: Obfsproxy |Version:
Keywords: | Parent:
Points: | Actualpoints:
---+
Comment(by cjbprime):
The attached patch implements this feature. I'm pasting the output of two
runs below, one with scrubbing on and one with scrubbing off via --no-
safe-logging.
The scrubbing implemented here goes farther than Tor, in that it scrubs
the client addresses too, to avoid putting live obfsproxy bridge addresses
in the log. As a side effect, protocol traffic between obfsproxy and Tor
is no longer logged. Safe logging is turned on by default, in main.c.
With scrubbing turned on:
{{{
2012-02-12 15:11:46 [info] Starting.
2012-02-12 15:11:46 [debug] Proxy environment:
state_loc: './Data/Tor/pt_state/'
conf_proto_version: '1'
transports: 'obfs2'
2012-02-12 15:11:46 [debug] Now listening on 127.0.0.1:0 for protocol
obfs2.
2012-02-12 15:12:07 [debug] [scrubbed]: new connection from [scrubbed] (1
total)
2012-02-12 15:12:07 [debug] [scrubbed]: socks client connection
2012-02-12 15:12:07 [debug] [scrubbed]: setup complete
2012-02-12 15:12:07 [debug] [scrubbed]: socks_read_cb
2012-02-12 15:12:07 [debug] Got version 4
2012-02-12 15:12:07 [info] [scrubbed]: socks: trying to connect to
[scrubbed]:80
2012-02-12 15:12:07 [debug] [scrubbed]: new connection from [scrubbed] (3
total)
2012-02-12 15:12:07 [debug] [scrubbed]: socks client connection
2012-02-12 15:12:07 [debug] [scrubbed]: setup complete
2012-02-12 15:12:07 [debug] [scrubbed]: socks_read_cb
2012-02-12 15:12:07 [debug] Got version 4
2012-02-12 15:12:07 [info] [scrubbed]: socks: trying to connect to
[scrubbed]:80
2012-02-12 15:12:07 [debug] [scrubbed]: pending_socks_cb
2012-02-12 15:12:07 [debug] We connected to our SOCKS destination!
Replacing peername '[scrubbed]' with '[scrubbed]'
2012-02-12 15:12:07 [debug] [scrubbed]: Successful outbound connection to
[scrubbed]
2012-02-12 15:12:07 [debug] obfs2_handshake: initiator queued 7033 bytes
2012-02-12 15:12:07 [debug] [scrubbed]: upstream_read_cb, 336 bytes
available
2012-02-12 15:12:07 [debug] obfs2_send: handshake incomplete, queueing 336
bytes.
2012-02-12 15:12:07 [debug] [scrubbed]: transmitted 0 bytes
2012-02-12 15:12:07 [debug] [scrubbed]: pending_socks_cb
2012-02-12 15:12:07 [debug] We connected to our SOCKS destination!
Replacing peername '[scrubbed]' with '[scrubbed]'
2012-02-12 15:12:07 [debug] [scrubbed]: Successful outbound connection to
[scrubbed]
2012-02-12 15:12:07 [debug] obfs2_handshake: initiator queued 3240 bytes
2012-02-12 15:12:07 [debug] [scrubbed]: downstream_read_cb, 1448 bytes
available
2012-02-12 15:12:07 [debug] [scrubbed]: error during receive.
2012-02-12 15:12:07 [debug] Closing connection with [scrubbed]; 3
remaining
2012-02-12 15:12:07 [debug] Closing connection with [scrubbed]; 2
remaining
2012-02-12 15:12:07 [debug] [scrubbed]: downstream_read_cb, 808 bytes
available
2012-02-12 15:12:07 [debug] [scrubbed]: error during receive.
2012-02-12 15:12:07 [debug] Closing connection with [scrubbed]; 1
remaining
2012-02-12 15:12:07 [debug] Closing connection with [scrubbed]; 0
remaining
2012-02-12 15:12:08 [debug] [scrubbed]: new connection from [scrubbed] (1
total)
2012-02-12 15:12:08 [debug] [scrubbed]: socks client connection
2012-02-12 15:12:08 [debug] [scrubbed]: setup complete
2012-02-12 15:12:08 [debug] [scrubbed]: socks_read_cb
2012-02-12 15:12:08 [debug] Got version 4
2012-02-12 15:12:08 [info] [scrubbed]: socks: trying to connect to
[scrubbed]:80
2012-02-12 15:12:08 [debug] [scrubbed]: new connection from [scrubbed] (3
total)
2012-02-12 15:12:08 [debug] [scrubbed]: socks client connection
2012-02-12 15:12:08 [debug] [scrubbed]: setup complete
2012-02-12 15:12:08 [debug] [scrubbed]: socks_read_cb
2012-02-12 15:12:08 [debug] Got version 4
2012-02-12 15:12:08 [info] [scrubbed]: socks: trying to connect to
[scrubbed]:80
2012-02-12 15:12:08 [debug] [scrubbed]: pending_socks_cb
2012-02-12 15:12:08 [debug] We connected to our SOCKS destination!
Replacing peername '[scrubbed]' with '[scrubbed]'
2012-02-12 15:12:08 [debug] [scrubbed]: Successful outbound connection to
[scrubbed]
2012-02-12 15:12:08 [debug] obfs2_handshake: initiator queued 580 bytes
2012-02-12 15:12:08 [debug] [scrubbed]: upstream_read_cb, 340 bytes
available
2012-02-12 15:12:08 [debug] obfs2_send: handshake incomplete, queueing 340
bytes.
2012-02-12 15:12:08 [debug] [scrubbed]: transmitted 0 bytes
2012-02-12 15:12:08 [debug] [scrubbed]: pending_socks_cb
2012-02-12 15:12:08 [debug] We connected to our SOCKS destination!
Replacing
Re: [tor-bugs] #5094 [Obfsproxy]: What's with the extra blank line when exiting?
#5094: What's with the extra blank line when exiting? ---+ Reporter: arma | Owner: asn Type: defect | Status: new Priority: minor | Milestone: Component: Obfsproxy |Version: Keywords: | Parent: Points: | Actualpoints: ---+ Comment(by cjbprime): (Odd, can't reproduce this here.) -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5094#comment:1 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5059 [Pluggable transport]: Organize an obfsproxy/PTTB test run
#5059: Organize an obfsproxy/PTTB test run +--- Reporter: asn | Owner: asn Type: task | Status: closed Priority: normal | Milestone: Component: Pluggable transport | Version: Resolution: implemented |Keywords: Parent: #5038| Points: Actualpoints: | +--- Changes (by rransom): * status: new = closed * resolution: = implemented Comment: We're having a test run now! (Too bad we didn't get to organize it.) -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5059#comment:2 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5101 [Obfsproxy]: obfsproxy: trying to connect to 1.2.3.4:5678 message is confusing
#5101: obfsproxy: trying to connect to 1.2.3.4:5678 message is confusing ---+ Reporter: torland| Owner: asn Type: defect | Status: needs_review Priority: normal | Milestone: Component: Obfsproxy |Version: Keywords: | Parent: #5080 Points: | Actualpoints: ---+ Changes (by asn): * status: new = needs_review * parent: = #5080 Comment: Sounds like something we should do as part of #5080, indeed. Please see branch `bug5101` in `https://git.gitorious.org/obfsproxy/obfsproxy.git`. This will break the current #5047 script. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5101#comment:1 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5047 [Obfsproxy]: Implement basic usage statistics in obfsproxy
#5047: Implement basic usage statistics in obfsproxy
-+--
Reporter: karsten | Owner: karsten
Type: enhancement | Status: assigned
Priority: normal | Milestone:
Component: Obfsproxy|Version:
Keywords: | Parent:
Points: | Actualpoints:
-+--
Comment(by asn):
If #5101 gets merged, it will break the current version of the python
script. It changes:
{{{
2012-02-10 22:37:00 [info] 89.78.67.56:1234 (obfs2): trying to connect to
127.0.0.1:5001
}}}
to
{{{
2012-02-10 22:37:00 [info] 89.78.67.56:1234 (obfs2): Successful outbound
connection to '127.0.0.1:5001'.
}}}
BTW, the new log line will only appear when the connection is successful.
When the connection fails we still get:
{{{
89.78.67.56:1234: connection to 127.0.0.1:5001 failed: Connection timeout
}}}
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/5047#comment:7
Tor Bug Tracker Wiki https://trac.torproject.org/
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5098 [Obfsproxy]: obfsproxy src/main.h has prototype for tor_main
#5098: obfsproxy src/main.h has prototype for tor_main ---+ Reporter: rransom| Owner: asn Type: defect | Status: needs_review Priority: minor | Milestone: Component: Obfsproxy |Version: Keywords: easy | Parent: Points: | Actualpoints: ---+ Changes (by asn): * status: new = needs_review * keywords: = easy Comment: Please see branch `bug5098` in `https://git.gitorious.org/obfsproxy/obfsproxy.git`. It simply removes the line from src/main.h. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5098#comment:1 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5098 [Obfsproxy]: obfsproxy src/main.h has prototype for tor_main
#5098: obfsproxy src/main.h has prototype for tor_main ---+ Reporter: rransom| Owner: asn Type: defect | Status: needs_review Priority: minor | Milestone: Component: Obfsproxy |Version: Keywords: easy | Parent: Points: | Actualpoints: ---+ Comment(by rransom): Replying to [comment:1 asn]: Please see branch `bug5098` in `https://git.gitorious.org/obfsproxy/obfsproxy.git`. It simply removes the line from src/main.h. Should there be a prototype for `obfs_main`? -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5098#comment:2 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
[tor-bugs] #5104 [Tor Bridge]: Tor should give managed proxies its ORListenAddress
#5104: Tor should give managed proxies its ORListenAddress
+---
Reporter: rransom | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: Tor Bridge |Version:
Keywords: | Parent:
Points: | Actualpoints:
+---
koolfy tried to set up a managed obfsproxy on an instance of one of our
EC2 bridge images. It didn't work:
{{{
14:52 koolfy obfsproxy says
14:52 koolfy 2012-02-12 22:50:13 [debug] error_cb for 127.0.0.1:443:
what=0x0020 errno=111
14:52 koolfy 2012-02-12 22:50:13 [warn] Error talking to 127.0.0.1:443:
Connection refused
}}}
{{{
14:55 koolfy # What port to advertise for Tor connections.
14:56 koolfy ORPort 443
14:56 koolfy # advertise 443 but bind to 9001).
14:56 koolfy ORListenAddress 0.0.0.0:9001
}}}
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/5104
Tor Bug Tracker Wiki https://trac.torproject.org/
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5097 [Tor Bridge]: “TOR_PT_EXTENDED_SERVER_PORT=127.0.0.1:4200”
#5097: “TOR_PT_EXTENDED_SERVER_PORT=127.0.0.1:4200” +--- Reporter: rransom | Owner: Type: defect | Status: needs_review Priority: blocker | Milestone: Tor: 0.2.3.x-final Component: Tor Bridge |Version: Keywords: | Parent: Points: | Actualpoints: +--- Comment(by rransom): Replying to [comment:4 Sebastian]: branch bug5097 in rransom's tor repository I've pushed another commit, because I missed the Windows version of that function the first time. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5097#comment:5 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5097 [Tor Bridge]: “TOR_PT_EXTENDED_SERVER_PORT=127.0.0.1:4200”
#5097: “TOR_PT_EXTENDED_SERVER_PORT=127.0.0.1:4200” ---+ Reporter: rransom | Owner: Type: defect | Status: closed Priority: blocker | Milestone: Tor: 0.2.3.x-final Component: Tor Bridge | Version: Resolution: fixed |Keywords: Parent: | Points: Actualpoints: | ---+ Changes (by nickm): * status: needs_review = closed * resolution: = fixed Comment: Seriouly, git commit messages like Fix #5097 are not what we do. Fixed the commit message and merged. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5097#comment:6 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5101 [Obfsproxy]: obfsproxy: trying to connect to 1.2.3.4:5678 message is confusing
#5101: obfsproxy: trying to connect to 1.2.3.4:5678 message is confusing --+- Reporter: torland| Owner: asn Type: defect | Status: closed Priority: normal | Milestone: Component: Obfsproxy | Version: Resolution: fixed |Keywords: Parent: #5080 | Points: Actualpoints: | --+- Changes (by nickm): * status: needs_review = closed * resolution: = fixed Comment: Looks fine; merged it. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5101#comment:2 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
[tor-bugs] #5105 [Tor Bridge]: set_managed_proxy_environment should be OS-independent
#5105: set_managed_proxy_environment should be OS-independent +--- Reporter: rransom | Owner: Type: defect | Status: new Priority: major | Milestone: Tor: 0.2.3.x-final Component: Tor Bridge |Version: Keywords: | Parent: Points: | Actualpoints: +--- At least two people have been confused by the fact that there are two copies of `set_managed_proxy_environment` (one for Windows, and one for Unixoids), and that confusion has come close to producing at least two bugs. Time to refactor it to produce a smartlist on all OSes. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5105 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5079 [Obfsproxy]: obfsproxy: scrub IPs before displaying them in logs
#5079: obfsproxy: scrub IPs before displaying them in logs ---+ Reporter: asn| Owner: asn Type: defect | Status: needs_review Priority: normal | Milestone: Component: Obfsproxy |Version: Keywords: | Parent: Points: | Actualpoints: ---+ Comment(by nickm): Looks good, except for the function name. By the Tor convention, I think this should just be safe_str: obfsproxy doesn't have a separate notion of my activities as a client and my activities as a server. This is pretty easy to fix with perl, though. I'll tweak the patch and merge it. Thanks! -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5079#comment:3 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5079 [Obfsproxy]: obfsproxy: scrub IPs before displaying them in logs
#5079: obfsproxy: scrub IPs before displaying them in logs --+- Reporter: asn| Owner: asn Type: defect | Status: closed Priority: normal | Milestone: Component: Obfsproxy | Version: Resolution: fixed |Keywords: Parent: | Points: Actualpoints: | --+- Changes (by nickm): * status: needs_review = closed * resolution: = fixed -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5079#comment:4 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5098 [Obfsproxy]: obfsproxy src/main.h has prototype for tor_main
#5098: obfsproxy src/main.h has prototype for tor_main --+- Reporter: rransom| Owner: asn Type: defect | Status: closed Priority: minor | Milestone: Component: Obfsproxy | Version: Resolution: fixed |Keywords: easy Parent: | Points: Actualpoints: | --+- Changes (by nickm): * status: needs_review = closed * resolution: = fixed Comment: Merged -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5098#comment:3 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5102 [Tor Bridge]: segfault in entry_guard_register_connect_status on tor bridge running obfsproxy on openbsd
#5102: segfault in entry_guard_register_connect_status on tor bridge running obfsproxy on openbsd -+-- Reporter: therealditzydoo | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Tor Bridge |Version: Tor: 0.2.3.11-alpha Keywords: | Parent: Points: | Actualpoints: -+-- Comment(by nickm): I'm turning that SMARTLIST_FOREACH into a SMARTLIST_FOREACH_BEGIN/END pair in 61452299d1067298a2865deb6398b1fb269b2a81; that should make the line number a tiny bit easier to find. If you can find the value of the local variable e at the point of the crash, as well as the values of *e, entry_guards, and *entry_guards, that would be great. But looking at the code, it seems the only possibilities are: * one of the entries in entry_guards has become null, or corrupt, or something like that. * The entry_guards smartlist itself has somehow gotten messed up. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5102#comment:4 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5103 [Tor Bridge]: --enable-static-tor barfs on openbsd 'cause it tries to link in -lrt which doesn't exist
#5103: --enable-static-tor barfs on openbsd 'cause it tries to link in -lrt which doesn't exist -+-- Reporter: therealditzydoo | Owner: Type: defect | Status: needs_review Priority: normal | Milestone: Component: Tor Bridge |Version: Tor: 0.2.3.11-alpha Keywords: | Parent: Points: | Actualpoints: -+-- Changes (by nickm): * status: new = needs_review Comment: Branch bug5103 in my public tor repository may fix this. Please test/review? -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5103#comment:2 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5059 [Pluggable transport]: Organize an obfsproxy/PTTB test run
#5059: Organize an obfsproxy/PTTB test run +--- Reporter: asn | Owner: asn Type: task | Status: closed Priority: normal | Milestone: Component: Pluggable transport | Version: Resolution: implemented |Keywords: Parent: #5038| Points: Actualpoints: | +--- Comment(by nickm): After the test run is done, we should do a quick pass over pluggable transports need XYZ tickets and obfsproxy needs XYZ tickets, to see which of them turned out to actually be not so crucial as expected. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5059#comment:3 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5047 [Obfsproxy]: Implement basic usage statistics in obfsproxy
#5047: Implement basic usage statistics in obfsproxy -+-- Reporter: karsten | Owner: karsten Type: enhancement | Status: assigned Priority: normal | Milestone: Component: Obfsproxy|Version: Keywords: | Parent: Points: | Actualpoints: -+-- Comment(by nickm): Replying to [comment:7 asn]: If #5101 gets merged, it will break the current version of the python script. #5101 got merged; the script will need tweaking. Also, IPs are now scrubbed by default; the script will need to handle that if it doesn't already. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5047#comment:8 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5053 [Tor Bridge]: Fix IPv6 implementation for bridge statistics
#5053: Fix IPv6 implementation for bridge statistics +--- Reporter: karsten | Owner: Type: defect | Status: needs_revision Priority: major | Milestone: Tor: 0.2.3.x-final Component: Tor Bridge |Version: Keywords: | Parent: Points: | Actualpoints: +--- Changes (by nickm): * status: needs_review = needs_revision Comment: I think that the return value for geop_get_country_by_addr() is wrong: -1 means we have no geoip file loaded, not country unknown. The unknown country is 0, right? Note to self: When I merge this, I should also change clientmap_entry_hash so that it considers the 'action' field as well. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5053#comment:9 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5083 [Obfsproxy]: Implement heartbeat message in obfsproxy
#5083: Implement heartbeat message in obfsproxy -+-- Reporter: karsten | Owner: asn Type: enhancement | Status: needs_review Priority: normal | Milestone: Component: Obfsproxy|Version: Keywords: | Parent: Points: | Actualpoints: -+-- Comment(by nickm): Reviewing the whole series as one diff... Why strmap_set_lc, and not strmap_set? Should connections be static? -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5083#comment:11 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5093 [Obfsproxy]: Mysterious Resource temporarily unavailable errors
#5093: Mysterious Resource temporarily unavailable errors ---+ Reporter: arma | Owner: asn Type: defect | Status: new Priority: normal | Milestone: Component: Obfsproxy |Version: Keywords: | Parent: Points: | Actualpoints: ---+ Comment(by nickm): Replying to [comment:10 therealditzydoo]: I am now running libevent-2.0.17-stable (the latest version) and still get these errors. Here is some example output at debug level. I'm not seeing any Resource temporarily available instances in those logs. Are they showing up in a different section, or am I missing something here? -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5093#comment:11 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5093 [Obfsproxy]: Mysterious Resource temporarily unavailable errors
#5093: Mysterious Resource temporarily unavailable errors ---+ Reporter: arma | Owner: asn Type: defect | Status: new Priority: normal | Milestone: Component: Obfsproxy |Version: Keywords: | Parent: Points: | Actualpoints: ---+ Comment(by nickm): Replying to [comment:8 arma]: I'm seeing it on moria1 too, with libevent 2.0.16. EAGAIN accounts for the majority of the errnos that I see, actually. Can you paste some of those? It is okay for errno=EAGAIN to be set, so long as the BEV_EVENT_ERROR flag is not set. If there is no BEV_EVENT_ERROR, then a socket error hasn't occurred (it's probably just an eof or timeout), and so it is okay for errno to be whatever it wants to be. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5093#comment:12 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5093 [Obfsproxy]: Mysterious Resource temporarily unavailable errors
#5093: Mysterious Resource temporarily unavailable errors ---+ Reporter: arma | Owner: asn Type: defect | Status: new Priority: normal | Milestone: Component: Obfsproxy |Version: Keywords: | Parent: Points: | Actualpoints: ---+ Comment(by arma): Replying to [comment:11 nickm]: Replying to [comment:10 therealditzydoo]: I am now running libevent-2.0.17-stable (the latest version) and still get these errors. Here is some example output at debug level. I'm not seeing any Resource temporarily available instances in those logs. Are they showing up in a different section, or am I missing something here? Errno 35 is EAGAIN on openbsd. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5093#comment:13 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5093 [Obfsproxy]: Mysterious Resource temporarily unavailable errors
#5093: Mysterious Resource temporarily unavailable errors ---+ Reporter: arma | Owner: asn Type: defect | Status: new Priority: normal | Milestone: Component: Obfsproxy |Version: Keywords: | Parent: Points: | Actualpoints: ---+ Comment(by nickm): Replying to [comment:13 arma]: Replying to [comment:11 nickm]: Replying to [comment:10 therealditzydoo]: I am now running libevent-2.0.17-stable (the latest version) and still get these errors. Here is some example output at debug level. I'm not seeing any Resource temporarily available instances in those logs. Are they showing up in a different section, or am I missing something here? Errno 35 is EAGAIN on openbsd. But those have what=0x0011 errno=35 ; 0x11 is BEV_EVENT_READING|BEV_EVENT_EOF. There's no error there. As noted above, unless BEV_EVENT_ERROR (0x20) is set in the what argument, the value of errno is unlikely to be meaningful. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5093#comment:14 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5093 [Obfsproxy]: Mysterious Resource temporarily unavailable errors
#5093: Mysterious Resource temporarily unavailable errors --+- Reporter: arma | Owner: asn Type: defect | Status: closed Priority: normal | Milestone: Component: Obfsproxy | Version: Resolution: not a bug |Keywords: Parent: | Points: Actualpoints: | --+- Changes (by nickm): * status: new = closed * resolution: = not a bug Comment: Sounds like a reasonable change. Done in 9fe5f1c79b0161a6aecfa3dc7c80204fe9ddfee1. Closing. Thanks for being patient here! -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5093#comment:16 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5053 [Tor Bridge]: Fix IPv6 implementation for bridge statistics
#5053: Fix IPv6 implementation for bridge statistics +--- Reporter: karsten | Owner: Type: defect | Status: needs_revision Priority: major | Milestone: Tor: 0.2.3.x-final Component: Tor Bridge |Version: Keywords: | Parent: Points: | Actualpoints: +--- Comment(by arma): Replying to [comment:9 nickm]: I think that the return value for geop_get_country_by_addr() is wrong: -1 means we have no geoip file loaded, not country unknown. The unknown country is 0, right? Well, we don't have any geoip information about ipv6 addresses loaded. So I think it could count as ambiguous. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5053#comment:10 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5082 [Tor Client]: Tor cleans out environment before launching obfsproxy
#5082: Tor cleans out environment before launching obfsproxy
+---
Reporter: Sebastian | Owner:
Type: task| Status: needs_review
Priority: major | Milestone: Tor: 0.2.3.x-final
Component: Tor Client |Version:
Keywords: | Parent:
Points: | Actualpoints:
+---
Comment(by arma):
Replying to [comment:7 arma]:
I also tested it and it works.
For posterity, here was my obfsproxy patch for testing it:
{{{
diff --git a/src/managed.c b/src/managed.c
index 01814f8..ffa40a8 100644
--- a/src/managed.c
+++ b/src/managed.c
@@ -26,6 +26,9 @@
#include container.h
+#include unistd.h
+extern char **environ;
+
#include event2/event.h
#include event2/listener.h
@@ -430,6 +433,12 @@ handle_environment(managed_proxy_t *proxy)
char *tmp;
enum env_parsing_status status=ST_ENV_SMOOTH;
+ char **environ_tmp = environ;
+ while (*environ_tmp) {
+log_info(env: %s, *environ_tmp);
+environ_tmp++;
+ }
+
tmp = getenv(TOR_PT_STATE_LOCATION);
if (!tmp) {
status = ST_ENV_FAIL_STATE_LOC;
}}}
--
Ticket URL: https://trac.torproject.org/projects/tor/ticket/5082#comment:11
Tor Bug Tracker Wiki https://trac.torproject.org/
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5053 [Tor Bridge]: Fix IPv6 implementation for bridge statistics
#5053: Fix IPv6 implementation for bridge statistics +--- Reporter: karsten | Owner: Type: defect | Status: needs_revision Priority: major | Milestone: Tor: 0.2.3.x-final Component: Tor Bridge |Version: Keywords: | Parent: Points: | Actualpoints: +--- Comment(by nickm): Replying to [comment:10 arma]: Replying to [comment:9 nickm]: I think that the return value for geop_get_country_by_addr() is wrong: -1 means we have no geoip file loaded, not country unknown. The unknown country is 0, right? Well, we don't have any geoip information about ipv6 addresses loaded. So I think it could count as ambiguous. If we want to count ipv6 as ??, then the answer must be unknown country. If we return -1, then we won't count it. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5053#comment:11 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5084 [Tor Bridge]: pt_prepare_proxy_list_for_config_read: Assertion unconfigured_proxies_n == 0 failed
#5084: pt_prepare_proxy_list_for_config_read: Assertion unconfigured_proxies_n == 0 failed +--- Reporter: arma| Owner: Type: defect | Status: needs_review Priority: critical| Milestone: Tor: 0.2.3.x-final Component: Tor Bridge |Version: Keywords: | Parent: Points: | Actualpoints: +--- Changes (by nickm): * status: new = needs_review Comment: My public branch bug5084 works for armadev. It should get squashed and merged. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5084#comment:13 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5065 [Tor Client]: Executable paths for shasum/openssl not protected against whitespace
#5065: Executable paths for shasum/openssl not protected against whitespace ---+ Reporter: Sebastian | Owner: Type: defect | Status: closed Priority: major | Milestone: Tor: 0.2.2.x-final Component: Tor Client | Version: Resolution: fixed |Keywords: Parent: | Points: Actualpoints: | ---+ Changes (by nickm): * status: needs_review = closed * resolution: = fixed Comment: Merged into 0.2.2 and master. Cherry-picked the checkspaces thing. Thanks! -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5065#comment:5 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5084 [Tor Bridge]: pt_prepare_proxy_list_for_config_read: Assertion unconfigured_proxies_n == 0 failed
#5084: pt_prepare_proxy_list_for_config_read: Assertion unconfigured_proxies_n == 0 failed ---+ Reporter: arma| Owner: Type: defect | Status: closed Priority: critical| Milestone: Tor: 0.2.3.x-final Component: Tor Bridge | Version: Resolution: fixed |Keywords: Parent: | Points: Actualpoints: | ---+ Changes (by nickm): * status: needs_review = closed * resolution: = fixed Comment: Merging; thanks for the help here, everybody! -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5084#comment:14 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5103 [Tor Bridge]: --enable-static-tor barfs on openbsd 'cause it tries to link in -lrt which doesn't exist
#5103: --enable-static-tor barfs on openbsd 'cause it tries to link in -lrt which doesn't exist -+-- Reporter: therealditzydoo | Owner: Type: defect | Status: needs_review Priority: normal | Milestone: Tor: 0.2.2.x-final Component: Tor Bridge |Version: Tor: 0.2.3.11-alpha Keywords: | Parent: Points: | Actualpoints: -+-- Changes (by nickm): * milestone: = Tor: 0.2.2.x-final Comment: Whoops; this should go onto 0.2.2. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5103#comment:4 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5085 [Obfsproxy]: managed obfsproxy does not quit if tor dies
#5085: managed obfsproxy does not quit if tor dies ---+ Reporter: arma | Owner: asn Type: defect | Status: new Priority: minor | Milestone: Component: Obfsproxy |Version: Keywords: | Parent: Points: | Actualpoints: ---+ Comment(by arma): I think it's not urgent to get a fix for this in, if it involves a whole lot of code, assuming it really only happens when Tor crashes. We should fix the Tor crashes in that case. Apparently twilde saw it happen on a normal Tor exit though? If that's the case then there's a Tor bug there too. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5085#comment:3 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
[tor-bugs] #5106 [Obfsproxy]: Clarify obfsproxy proposal wrt use of TOR_PT_EXTENDED_SERVER_PORT env variable
#5106: Clarify obfsproxy proposal wrt use of TOR_PT_EXTENDED_SERVER_PORT env variable ---+ Reporter: Sebastian | Owner: asn Type: defect | Status: new Priority: normal | Milestone: Component: Obfsproxy |Version: Keywords: | Parent: Points: | Actualpoints: ---+ In #5097 we made some changes, and then made some more changes in Tor on top of rransom's 5097 branches. We should extend the spec to say that if Tor sets an empty env variable, that means tor doesn't use the extended orport functionality. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5106 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5104 [Tor Bridge]: Tor should give managed proxies its ORListenAddress
#5104: Tor should give managed proxies its ORListenAddress +--- Reporter: rransom | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Tor Bridge |Version: Keywords: | Parent: Points: | Actualpoints: +--- Comment(by nickm): I think this is related to, or a duplicate of, #4865. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5104#comment:1 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5103 [Tor Bridge]: --enable-static-tor barfs on openbsd 'cause it tries to link in -lrt which doesn't exist
#5103: --enable-static-tor barfs on openbsd 'cause it tries to link in -lrt which doesn't exist -+-- Reporter: therealditzydoo | Owner: Type: defect | Status: needs_review Priority: normal | Milestone: Tor: 0.2.2.x-final Component: Tor Bridge |Version: Tor: 0.2.3.11-alpha Keywords: | Parent: Points: | Actualpoints: -+-- Comment(by Sebastian): Currently failing to get --enable-static-tor to work on debian without the patch, so testing isn't exactly trivial. I think we should postpone this here, because there's a workaround and building completely static tor isn't exactly standard -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5103#comment:5 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5087 [Obfsproxy]: configure should realize libssl-dev is missing
#5087: configure should realize libssl-dev is missing -+-- Reporter: Monotoko | Owner: asn Type: defect | Status: new Priority: normal | Milestone: Component: Obfsproxy|Version: Keywords: make, openssl, implicit declaration | Parent: #5009 Points: | Actualpoints: -+-- Changes (by Sebastian): * priority: major = normal -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5087#comment:4 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #4566 [Obfsproxy]: Make Tor work with obfsproxy and obfs2
#4566: Make Tor work with obfsproxy and obfs2 ---+ Reporter: karsten| Owner: asn Type: project| Status: new Priority: normal | Milestone: Sponsor G: June 30, 2012 Component: Obfsproxy |Version: Keywords: | Parent: Points: | Actualpoints: ---+ Comment(by Sebastian): Users are doing obfs2. Does that count already? -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/4566#comment:2 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #4566 [Obfsproxy]: Make Tor work with obfsproxy and obfs2
#4566: Make Tor work with obfsproxy and obfs2 ---+ Reporter: karsten| Owner: asn Type: project| Status: new Priority: normal | Milestone: Sponsor G: June 30, 2012 Component: Obfsproxy |Version: Keywords: | Parent: Points: | Actualpoints: ---+ Comment(by arma): Yes, I think it counts. We even have a bundle, in the hands of thousands of users, so we've gone beyond the milestone. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/4566#comment:3 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5068 [Obfsproxy]: memory leak in obfsproxy when using weird args
#5068: memory leak in obfsproxy when using weird args --+- Reporter: arma | Owner: asn Type: defect | Status: closed Priority: normal | Milestone: Component: Obfsproxy | Version: Resolution: fixed |Keywords: Parent: | Points: Actualpoints: | --+- Changes (by arma): * status: needs_review = closed * resolution: = fixed Comment: Merged. Thanks! -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5068#comment:2 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5053 [Tor Bridge]: Fix IPv6 implementation for bridge statistics
#5053: Fix IPv6 implementation for bridge statistics +--- Reporter: karsten | Owner: Type: defect | Status: needs_revision Priority: major | Milestone: Tor: 0.2.3.x-final Component: Tor Bridge |Version: Keywords: | Parent: Points: | Actualpoints: +--- Comment(by karsten): Replying to [comment:11 nickm]: Replying to [comment:10 arma]: Replying to [comment:9 nickm]: I think that the return value for geop_get_country_by_addr() is wrong: -1 means we have no geoip file loaded, not country unknown. The unknown country is 0, right? Well, we don't have any geoip information about ipv6 addresses loaded. So I think it could count as ambiguous. If we want to count ipv6 as ??, then the answer must be unknown country. If we return -1, then we won't count it. I was wondering about -1 vs. 0, too. I picked -1 here because we have no geoip file loaded is the correct answer and because all places calling geoip_get_country_by_ip() check for country_idx 0 and set it to 0 if they want to treat both cases as country unknown. Now, I'm not sure if that's the cleanest approach, but I didn't want to touch it. Linus and I are going to test this patch today. We're going to check whether IPv6 addresses are counted as ?? with the -1 result. But if you like 0 better, I don't mind at all changing that. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5053#comment:12 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
[tor-bugs] #5107 [Vidalia]: Usability problem: if you add a bridge and click ok, but didn't click +, you don't add the bridge
#5107: Usability problem: if you add a bridge and click ok, but didn't click +, you don't add the bridge -+-- Reporter: arma | Owner: chiiph Type: defect | Status: new Priority: normal | Milestone: Component: Vidalia |Version: Keywords: | Parent: Points: | Actualpoints: -+-- Go to settings-network, have some bridges already, paste a new onto the bridge text box, then click ok. You don't end up using the bridge. This is related to #4290, but is even more subtle since if your other bridges work you'll never even notice you didn't add this one. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5107 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5107 [Vidalia]: Usability problem: if you add a bridge and click ok, but didn't click +, you don't add the bridge
#5107: Usability problem: if you add a bridge and click ok, but didn't click +, you don't add the bridge -+-- Reporter: arma | Owner: chiiph Type: defect | Status: new Priority: normal | Milestone: Component: Vidalia |Version: Keywords: | Parent: Points: | Actualpoints: -+-- Comment(by arma): Maybe the right fix is for the 'ok' button to notice that there's text in the bridge text box, and automatically do the equivalent of clicking + for it? Are there any downsides to that approach? That would probably also be a better fix for mikeperry's bug in #4290 than git commit e46a569dd, since it would do-what-he-meant rather than tell- him-it-didn't-do-what-he-meant. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5107#comment:1 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #4898 [Vidalia]: Build Korean TBB
#4898: Build Korean TBB -+-- Reporter: runa | Owner: chiiph Type: task | Status: assigned Priority: normal | Milestone: Component: Vidalia |Version: Keywords: | Parent: Points: | Actualpoints: -+-- Changes (by runa): * status: new = assigned * owner: erinn = chiiph * component: Tor bundles/installation = Vidalia -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/4898#comment:1 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
[tor-bugs] #5108 [Tor Check]: Enable Korean for Tor Check
#5108: Enable Korean for Tor Check ---+ Reporter: runa | Owner: nickm Type: task | Status: new Priority: normal | Milestone: Component: Tor Check |Version: Keywords: | Parent: Points: | Actualpoints: ---+ The Korean translation of the Tor Check page is done, please enable it. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5108 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
Re: [tor-bugs] #5083 [Obfsproxy]: Implement heartbeat message in obfsproxy
#5083: Implement heartbeat message in obfsproxy -+-- Reporter: karsten | Owner: asn Type: enhancement | Status: needs_review Priority: normal | Milestone: Component: Obfsproxy|Version: Keywords: | Parent: Points: | Actualpoints: -+-- Comment(by karsten): Replying to [comment:11 nickm]: Reviewing the whole series as one diff... Why strmap_set_lc, and not strmap_set? I was thinking of two IPv6 addresses with uppercase and lowercase hex characters that should be considered equal. If we're sure that doesn't happen, strmap_set should be fine. Should connections be static? Yes! Fixed in the updated heartbeat_uniqueips branch. I also found another problem with strmap_t not liking NULL values, even though we don't care about values. -- Ticket URL: https://trac.torproject.org/projects/tor/ticket/5083#comment:12 Tor Bug Tracker Wiki https://trac.torproject.org/ The Tor Project: anonymity online ___ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
