date:20161203

Re: [tor-bugs] #20879 [Applications/Tor Browser Sandbox]: Set rlimits in the containers.

2016-12-03 Thread Tor Bug Tracker & Wiki

#20879: Set rlimits in the containers.
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by yawning):

 Clarification, RLIMIT_STACK is 8192 KiB (when setting it, the unit used is
 bytes).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20881 [Core Tor/Tor]: Select 200 fallbacks for each release

2016-12-03 Thread Tor Bug Tracker & Wiki

#20881: Select 200 fallbacks for each release
--+
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  fallback
Actual Points:  0.1   |  Parent ID:  #18828
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+
 This allows us to remove fallbacks as needed for 6-12 months, without the
 list getting too small.

 Implemented in #18828.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20880 [Core Tor/Tor]: Make minimum fallback stability 6 months

2016-12-03 Thread Tor Bug Tracker & Wiki

#20880: Make minimum fallback stability 6 months
--+
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  fallback
Actual Points:  0.1   |  Parent ID:  #18828
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+
 Now that we've fixed #18050, we can revert the fallback minimum address
 stability to a longer period. I suggest 6 months - the period between
 releases.

 This will be implemented as part of #18828.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20879 [Applications/Tor Browser Sandbox]: Set rlimits in the containers.

2016-12-03 Thread Tor Bug Tracker & Wiki

#20879: Set rlimits in the containers.
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 The containers should have rlimits set to prevent runaway resource use,
 though some of these (eg: address space) are tricky and require thought.

 After discussion on IRC, sensible defaults that could be applied to
 everything as a first pass would be something like:

 RLIMIT_STACK: 8192
 RLIMIT_RSS: 0 (No effect as of Linux 2.6.x)
 RLIMIT_CORE: 0
 RLIMIT_NPROC: 512
 RLIMIT_NOFILE: 1024 (512?, lower?)
 RLIMIT_MEMLOCK: 64 (KiB)
 RLIMIT_LOCKS: (check how much firefox/tor uses flock, set to something
 low)
 RLIMIT_SIGPENDING: 64
 RLIMIT_MSGQUEUE: 0 (assuming nothing uses this)
 RLIMIT_NICE: 0
 RLIMIT_RTPRIO: 0
 RLIMIT_RTTIME: 0

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20878 [Core Tor/Tor]: Add bandwidth to fallback comments

2016-12-03 Thread Tor Bug Tracker & Wiki

#20878: Add bandwidth to fallback comments
--+
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  fallback
Actual Points:  0.1   |  Parent ID:  #18828
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+
 Implemented as part of #18828

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20877 [Core Tor/Tor]: Fix a bug in updateFallbackDirs.py's comment handling

2016-12-03 Thread Tor Bug Tracker & Wiki

#20877: Fix a bug in updateFallbackDirs.py's comment handling
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.3-alpha
 Severity:  Normal| Resolution:
 Keywords:  fallback  |  Actual Points:
Parent ID:  #18828| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * parent:   => #18828


Comment:

 I'll post a branch to #18828 with a fix for this.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20877 [Core Tor/Tor]: Fix a bug in updateFallbackDirs.py's comment handling

2016-12-03 Thread Tor Bug Tracker & Wiki

#20877: Fix a bug in updateFallbackDirs.py's comment handling
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.3-alpha
 Severity:  Normal|   Keywords:  fallback
Actual Points:|  Parent ID:
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+
 Turns out we weren't returning the comment string. Oops!

 Bugfix on 99983432 in tor-0.2.8.3-alpha.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20876 [Core Tor/Tor]: Avoid contacting fallback operators who are unlikely to be accepted

2016-12-03 Thread Tor Bug Tracker & Wiki

#20876: Avoid contacting fallback operators who are unlikely to be accepted
--+--
 Reporter:  teor  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  fallback
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 After we automatically calculate the fallback threshold in #20192, it
 would be great to update that threshold based on whether the operator
 would be selected if they opted-in.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20679 [Applications/Tor Browser]: Tor Bowser Address Spoofing.

2016-12-03 Thread Tor Bug Tracker & Wiki

#20679: Tor Bowser Address Spoofing.
--+--
 Reporter:  Dhiraj_Mishra |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Dhiraj_Mishra):

 Hi Team ,

 Any follow-Up , Please let me know about the Issue.
 Looking forward to it.

 Thank you

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20871 [Core Tor/Torsocks]: Regression in Torsocks 2.2.0 breaks wget, among others

2016-12-03 Thread Tor Bug Tracker & Wiki

#20871: Regression in Torsocks 2.2.0 breaks wget, among others
---+---
 Reporter:  cypherpunks|  Owner:  dgoulet
 Type:  defect | Status:  needs_information
 Priority:  High   |  Milestone:
Component:  Core Tor/Torsocks  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by sysrqb):

 Replying to [comment:2 cypherpunks]:

 > In 2.2.0 in `src/lib/gethostbyname.c`, there's an if statement which
 checks if `name` is a valid IPv4 address. If it is valid IPv4 address, it
 should return 1, otherwise a negative value. What's weirder still is in
 `src/common/utils.c`, the `check_addr()` function is written in such a way
 that it cannot possibly return 0, only 1 or -1 (which both evaluate true
 in C).

 Nice catch, indeed that is likely broken and should be corrected. However,
 wget doesn't use gethostbyname(), it uses getaddrinfo(). Can you provide
 debug level logs that show how the name is being resolved (as dgoulet
 requested)? Setting something like `TORSOCKS_LOG_LEVEL=5
 TORSOCKS_LOG_FILE_PATH=torsocks.log` should be sufficient. Logging to a
 file maybe better than stdio.

 Debug logging shows:
 {{{
 1480831284 DEBUG torsocks[11468]: Setting up a connection to the Tor
 network on fd 5 (in setup_tor_connection() at torsocks.c:367)
 1480831284 DEBUG torsocks[11468]: Socks5 sending method ver: 5, nmethods
 0x01, methods 0x00 (in socks5_send_method() at socks5.c:229)
 1480831284 DEBUG torsocks[11468]: Socks5 received method ver: 5, method
 0x00 (in socks5_recv_method() at socks5.c:262)
 1480831284 DEBUG torsocks[11468]: [socks5] Resolve for www.torproject.org
 sent successfully (in socks5_send_resolve_request() at socks5.c:639)
 1480831284 DEBUG torsocks[11468]: [socks5] Resolve reply received
 successfully (in socks5_recv_resolve_reply() at socks5.c:716)
 1480831284 DEBUG torsocks[11468]: [getaddrinfo] Node www.torproject.org
 resolved to 82.195.75.101 (in tsocks_getaddrinfo() at getaddrinfo.c:107)
 }}}

 Specifically:
 {{{
 amnesia@amnesia:~/torsocks$ git show --pretty=oneline | head -n 1
 e54d80bc9595beeceac637b03e5c5395c07e62f7 Update version to v2.2.0
 amnesia@amnesia:~/torsocks$ git describe
 v2.2.0
 amnesia@amnesia:~/torsocks$ /usr/lib/wget/wget -V | head -n 3
 GNU Wget 1.16 built on linux-gnu.

 +digest +https +ipv6 +iri +large-file +nls +ntlm +opie +psl +ssl/gnutls
 }}}

 {{{
 amnesia@amnesia:~/torsocks$ TORSOCKS_CONF_FILE=doc/torsocks.conf
 TORSOCKS_LOG_LEVEL=5 TORSOCKS_LOG_FILE_PATH=torsocks.log
 LD_PRELOAD=src/lib/.libs/libtorsocks.so.0.0.0 /usr/lib/wget/wget --spider
 https://www.torproject.org/
 Spider mode enabled. Check if remote file exists.
 --2016-12-04 06:16:22--  https://www.torproject.org/
 Resolving www.torproject.org (www.torproject.org)... 82.195.75.101
 Connecting to www.torproject.org
 (www.torproject.org)|82.195.75.101|:443... connected.
 HTTP request sent, awaiting response... 200 OK
 Length: 15845 (15K) [text/html]
 Remote file exists and could contain further links,
 but recursion is disabled -- not retrieving.
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20875 [Core Tor/Tor]: Non-fatal assertion !(delay == INT_MAX) failed in next_random_exponential_delay at src/or/directory.c:3792

2016-12-03 Thread Tor Bug Tracker & Wiki

#20875: Non-fatal assertion !(delay == INT_MAX) failed in
next_random_exponential_delay at src/or/directory.c:3792
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.5-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * version:   => Tor: 0.2.9.5-alpha
 * points:   => 0.1


Comment:

 I think we introduced this one in 0.2.9.5-alpha.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20875 [Core Tor/Tor]: Non-fatal assertion !(delay == INT_MAX) failed in next_random_exponential_delay at src/or/directory.c:3792

2016-12-03 Thread Tor Bug Tracker & Wiki

#20875: Non-fatal assertion !(delay == INT_MAX) failed in
next_random_exponential_delay at src/or/directory.c:3792
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Having delay == INT_MAX is entirely reasonable, and isn't a bug.
 It happens every time the last delay was INT_MAX.

 I think we should turn:
 {{{
  if (BUG(delay == INT_MAX))
delay -= 1; /* prevent overflow */
 }}}

 Into:
 {{{
  if (delay == INT_MAX)
delay -= 1; /* prevent overflow */
 }}}

 Or:
 {{{
  if (delay == INT_MAX)
return INT_MAX;
 }}}

 I also think we should add a precondition right at the top:
 {{{
  if (BUG(max_delay < 0))
max_delay = 0;
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20875 [Core Tor/Tor]: Non-fatal assertion !(delay == INT_MAX) failed in next_random_exponential_delay at src/or/directory.c:3792

2016-12-03 Thread Tor Bug Tracker & Wiki

#20875: Non-fatal assertion !(delay == INT_MAX) failed in
next_random_exponential_delay at src/or/directory.c:3792
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 {{{
 Dec 03 19:59:44.346 [info] Received http status code 304 ("Not modified")
 from server '149.56.233.142:443' while fetching consensus directory.
 Dec 03 19:59:44.346 [debug] conn_close_if_marked(): Cleaning up connection
 (fd -1).
 Dec 03 19:59:44.346 [warn] tor_bug_occurred_(): Bug:
 src/or/directory.c:3792: next_random_exponential_delay: Non-fatal
 assertion !(delay == INT_MAX) failed. (on Tor 0.2.9.5-alpha-dev
 8a767ba7fbeedb3d)
 Dec 03 19:59:44.347 [warn] Bug: Non-fatal assertion !(delay == INT_MAX)
 failed in next_random_exponential_delay at src/or/directory.c:3792. Stack
 trace: (on Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
 Dec 03 19:59:44.347 [warn] Bug: src/or/tor(log_backtrace+0x42)
 [0x7f8e125a6562] (on Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
 Dec 03 19:59:44.347 [warn] Bug: src/or/tor(tor_bug_occurred_+0xb7)
 [0x7f8e125bf117] (on Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
 Dec 03 19:59:44.347 [warn] Bug: src/or/tor(+0x116615) [0x7f8e12571615]
 (on Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
 Dec 03 19:59:44.347 [warn] Bug:
 src/or/tor(download_status_increment_failure+0xa6) [0x7f8e12575f06] (on
 Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
 Dec 03 19:59:44.347 [warn] Bug:
 src/or/tor(networkstatus_consensus_download_failed+0x66) [0x7f8e124a9746]
 (on Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
 Dec 03 19:59:44.347 [warn] Bug:
 src/or/tor(connection_dir_about_to_close+0x24f) [0x7f8e1257a36f] (on Tor
 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
 Dec 03 19:59:44.347 [warn] Bug: src/or/tor(+0x4236d) [0x7f8e1249d36d]
 (on Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
 Dec 03 19:59:44.347 [warn] Bug: src/or/tor(+0x42b0c) [0x7f8e1249db0c]
 (on Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
 Dec 03 19:59:44.347 [warn] Bug: /usr/lib/x86_64-linux-
 gnu/libevent-2.0.so.5(event_base_loop+0x7fc) [0x7f8e11ae43dc] (on Tor
 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
 Dec 03 19:59:44.347 [warn] Bug: src/or/tor(do_main_loop+0x234)
 [0x7f8e1249f1e4] (on Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
 Dec 03 19:59:44.347 [warn] Bug: src/or/tor(tor_main+0x1c25)
 [0x7f8e124a2935] (on Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
 Dec 03 19:59:44.347 [warn] Bug: src/or/tor(main+0x19) [0x7f8e1249aac9]
 (on Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
 Dec 03 19:59:44.347 [warn] Bug: /lib/x86_64-linux-
 gnu/libc.so.6(__libc_start_main+0xf5) [0x7f8e10ab5b45] (on Tor 0.2.9.5
 -alpha-dev 8a767ba7fbeedb3d)
 Dec 03 19:59:44.347 [warn] Bug: src/or/tor(+0x3fb19) [0x7f8e1249ab19]
 (on Tor 0.2.9.5-alpha-dev 8a767ba7fbeedb3d)
 Dec 03 19:59:44.347 [debug] connection_remove(): removing socket -1 (type
 Directory), n_conns now 12
 }}}

 This is an ordinary Tor client minding its own business. (Sorry that it is
 a few weeks before the 0.2.9.6-rc release.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17070 [Core Tor/Tor]: ".local" is mDNS for the local network, but tor assumes localhost

2016-12-03 Thread Tor Bug Tracker & Wiki

#17070: ".local" is mDNS for the local network, but tor assumes localhost
+
 Reporter:  teor|  Owner:  jryans
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  security lorax doc  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * status:  needs_review => merge_ready
 * milestone:  Tor: 0.3.??? => Tor: 0.2.9.x-final


Comment:

 Looks good!
 Sticking this in 0.2.9 because it's a documentation-only change.
 (nickm, feel free to disagree.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20874 [Core Tor/Tor]: ReachableAddresses adds an extra reject : on every SAVECONF

2016-12-03 Thread Tor Bug Tracker & Wiki

#20874: ReachableAddresses adds an extra reject *:* on every SAVECONF
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.???
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-client
Actual Points:|  Parent ID:
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+--
 To fix this issue, we can do two things:

 1) We should add the reject *:* to a copy of the list after it has been
 parsed in parse_reachable_addresses() using append_exit_policy_string(),
 rather than adding it to the option itself in options_validate().

 2) We might also want to call exit_policy_remove_redundancies() on the
 parsed policy, so that long policies with redundancies are handled more
 efficiently. This is only likely to ever matter on busy hidden services.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17070 [Core Tor/Tor]: ".local" is mDNS for the local network, but tor assumes localhost

2016-12-03 Thread Tor Bug Tracker & Wiki

#17070: ".local" is mDNS for the local network, but tor assumes localhost
+--
 Reporter:  teor|  Owner:  jryans
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.3.???
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  security lorax doc  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by jryans):

 * status:  assigned => needs_review


Comment:

 I updated the function header for `tor_addr_hostname_is_local` and man
 page entry for `ClientRejectInternalAddresses` to describe that multicast
 DNS hostnames for machines on the local network (of the form *.local) are
 also rejected.

 https://github.com/jryans/tor/commits/local-hostname

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17070 [Core Tor/Tor]: ".local" is mDNS for the local network, but tor assumes localhost

2016-12-03 Thread Tor Bug Tracker & Wiki

#17070: ".local" is mDNS for the local network, but tor assumes localhost
+--
 Reporter:  teor|  Owner:  jryans
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:  Tor: 0.3.???
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  security lorax doc  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by jryans):

 * owner:   => jryans
 * status:  new => assigned


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19381 [Core Tor/Tor]: wish: conditionally build man page (tor.1) and html doc using independent configure options

2016-12-03 Thread Tor Bug Tracker & Wiki

#19381: wish: conditionally build man page (tor.1) and html doc using 
independent
configure options
-+--
 Reporter:  toralf   |  Owner:  atagar
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  easy docs lorax  |  Actual Points:
Parent ID:   | Points:  .2
 Reviewer:   |Sponsor:
-+--
Changes (by jryans):

 * cc: jryans@… (added)


Comment:

 It appears that `a2x` calls `xsltproc` even for manpages.  The separate
 configure flags could still be added, but it seems like you'd still need
 the same libs to create the manpage (if I am following correctly).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20871 [Core Tor/Torsocks]: Regression in Torsocks 2.2.0 breaks wget, among others

2016-12-03 Thread Tor Bug Tracker & Wiki

#20871: Regression in Torsocks 2.2.0 breaks wget, among others
---+---
 Reporter:  cypherpunks|  Owner:  dgoulet
 Type:  defect | Status:  needs_information
 Priority:  High   |  Milestone:
Component:  Core Tor/Torsocks  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by cypherpunks):

 It's not an exit relay issue because the error is instant and occurs no
 matter what exit is in use. I did find out what line is causing the
 problem though, and know a fix. I'm very confused why it works for you,
 because it seems like the logic is fundamentally flawed.

 In 2.2.0 in `src/lib/gethostbyname.c`, there's an if statement which
 checks if `name` is a valid IPv4 address. If it is valid IPv4 address, it
 should return 1, otherwise a negative value. What's weirder still is in
 `src/common/utils.c`, the `check_addr()` function is written in such a way
 that it cannot possibly return 0, only 1 or -1 (which both evaluate true
 in C). Later on, `utils_is_address_ipv4()`, which is just a wrapper for
 that function, is called. The if statement it's called in will always
 return true (because it can only possibly evaluate to 1 or -1), never
 false.

 Since `utils_is_address_ipv4()` cannot return 0, the if statement it is in
 will always assume that Torsocks has been passed an IP address directly,
 so it will never attempt to resolve it, and instead will try to convert it
 to network byte order. This is why it works when it's passed an IP address
 directly, but not a hostname. The only reason I can think of that it might
 work for you is if, for some reason, the domain is being resolved early
 and the IP is passed to `tsocks_gethostbyname()` (which is where the stuck
 if statement is located) on your system but not mine, bypassing the buggy
 logic.

 A fix would involve having `check_addr()` return 0 instead of -1 when it's
 passed a host which is a valid IPv4/IPv6 instead of a string hostname.
 Only `tests/unit/test_utils.c` would have to be changed because it
 explicitly checks for -1, but everything else would work.

 First two code blocks are from src/common/utils.c. The third is from
 src/lib/gethostbyname.c.

 {{{
 static int check_addr(const char *ip, int af)
 {
 int ret = 0;
 char buf[128];

 assert(ip);

 ret = inet_pton(af, ip, buf);
 if (ret != 1) {
 ret = -1;
 }

 return ret;
 }
 }}}

 {{{
 int utils_is_address_ipv4(const char *ip)
 {
 return check_addr(ip, AF_INET);
 }
 }}}

 {{{
 /* Man page specifies that it can either be an hostname or IPv4 address.
  * If it's an address, go with it else try to resolve it through Tor. */
 if (utils_is_address_ipv4(name)) {
 if (inet_pton(AF_INET, name, ) <= 0) {
 goto error;
 }
 /* "ip" now contains the network byte order of the address. */
 } else {
 /* We have a hostname so resolve it through Tor. */
 ret = tsocks_tor_resolve(AF_INET, name, );
 if (ret < 0) {
 goto error;
 }
 }
 }}}

 tl;dr
 `utils_is_address_ipv4()` is broken, as is the if statement which uses it,
 because it cannot return 0.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20715 [Core Tor/Tor]: memory leak in tor_cert_parse()

2016-12-03 Thread Tor Bug Tracker & Wiki

#20715: memory leak in tor_cert_parse()
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor:
  |  0.2.9.x-final
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.2.9.5-alpha
 Severity:  Normal| Resolution:
 Keywords:  028-backport review-group-13  |  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+

Comment (by neel):

 I am new to contributing to Tor. Is it possible for you to give me more
 information on this so I can be able to track down the bug? (where to
 look, what functions, etc.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20348 [Metrics/Censorship analysis]: kz no need tor, tor no need kz, if anybody want they can to use ultrasurf. cyberoam assists bloody dictatorships.

2016-12-03 Thread Tor Bug Tracker & Wiki

#20348: kz no need tor, tor no need kz, if anybody want they can to use 
ultrasurf.
cyberoam assists bloody dictatorships.
-+-
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:  censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 How to reliably confirm/deny vendor of censorship box? It can be fortinet,
 cyberoam, bluecoat, something yet.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20873 [- Select a component]: Trademark violations on Apple AppStore

2016-12-03 Thread Tor Bug Tracker & Wiki

#20873: Trademark violations on Apple AppStore
--+-
 Reporter:  mrphs |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by mtigas):

 See also #10549 from a few years ago. Also vaguely remember Wendy helping
 file some complaints about App Store apps named Tor, at a tor meeting last
 year.

 Not sure what the process was back then, but recently I've had a tiny bit
 of luck filing my own (Onion Browser) trademark violation disputes with
 Apple, via https://www.apple.com/legal/internet-
 services/itunes/appstorenotices/ which accepts a batch of links. For each
 app listed, I've been put on an e-mail thread with Apple legal and the
 developer of the app in question for them to provide evidence that the
 complaint is false or an assurance that they will change or remove the
 app.

 It's not perfect, though. All the apps I originally complained about are
 still on sale, most of them renamed. (Well, in one case, the developer
 receiving the complaint seems to have blown it off for a few months now
 and Apple hasn't done anything about it; I actually just followed up on
 that last week.)

 But anyway that's what I know, in case that helps.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20873 [- Select a component]: Trademark violations on Apple AppStore

2016-12-03 Thread Tor Bug Tracker & Wiki

#20873: Trademark violations on Apple AppStore
--+-
 Reporter:  mrphs |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by saint):

 Android:

 Judging by the reviews, a lot of these seem quite broken to boot. There's
 probably not a great way to convince people to unpublish their broken
 apps, but it might be worth reaching out. There are various others (like
 [https://play.google.com/store/apps/details?id=onion.fire Fire.onion])
 that use the Tor network in some way but don't seem to be violating TPI's
 trademarks.

 https://play.google.com/store/apps/details?id=com.globus.vpn

 https://play.google.com/store/apps/details?id=tornado.browser=en

 https://play.google.com/store/apps/details?id=com.inetric.orxy=en

 https://play.google.com/store/apps/details?id=com.inetric.anonify=en

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20813 [Obfuscation/Snowflake]: Start producing snowflakes

2016-12-03 Thread Tor Bug Tracker & Wiki

#20813: Start producing snowflakes
---+-
 Reporter:  arlolra|  Owner:
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by saint):

 I worked on Snowflake integration to Cupcake a bit during the dev meeting,
 then sidelined it to work on something else for a while. Integration will
 continue next week. The update will be rolled out to (chrome) Cupcake
 users before the January Tor Browser alpha release.

 The Firefox extension is
 [https://github.com/glamrock/cupcake/issues/24#issuecomment-264611770
 slightly more complicated]. However, there are only around 100 users on
 Firefox vs ~5100-6500 on Chrome (the way Chrome web store counts active
 users is very inconsistent).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20873 [- Select a component]: Trademark violations on Apple AppStore

2016-12-03 Thread Tor Bug Tracker & Wiki

#20873: Trademark violations on Apple AppStore
--+-
 Reporter:  mrphs |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Description changed by mrphs:

Old description:

> There are a bunch of snakeoil and typically closed source apps with ads
> injected in them under the name of Tor for iOS in Apple App Store. Some
> of them have pretty good rating (which I believe is because of lack of
> any official or even free and trusted-community-based Tor Browser for
> iOS). Now that 'Onion Browser' is finally free for everyone to download
> and use, I think we should get more serious about taking those fake ones
> down. Specially those that use the name or logo of Tor.
>
> If they have hundreds of 5star reviews, who knows how many people are
> actually using them and thinking they're anonymous and secure online.

New description:

 There are a bunch of snakeoil and typically closed source apps with ads
 injected in them under the name of Tor for iOS in Apple App Store. Some of
 them have pretty good rating (which I believe is because of lack of any
 official or even free and trusted-community-based Tor Browser for iOS).
 Now that the [https://itunes.apple.com/us/app/onion-browser-tor-
 powered/id519296448 Onion Browser] by Mike Tigas is finally free for
 everyone to download and use, I think we should get serious about taking
 those fake ones down. Specially those that use the name or logo of Tor.

 If they have hundreds of 5star reviews, who knows how many people are
 actually using them and thinking they're anonymous and secure online.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20873 [- Select a component]: Trademark violations on Apple AppStore

2016-12-03 Thread Tor Bug Tracker & Wiki

#20873: Trademark violations on Apple AppStore
--+-
 Reporter:  mrphs |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by mrphs):

 Here are some that I found. They are either using Tor name/logo, claiming
 to be anonymous or the only Tor browser for iOS:

 https://itunes.apple.com/us/app/tor-powered-onion-web-browser/id1125965631

 https://itunes.apple.com/us/app/secure-onion-web-browser-
 tor/id1146423813?mt=8

 https://itunes.apple.com/us/app/tor-powered-browser-secure/id1157080332

 https://itunes.apple.com/us/app/onion-browser-tor-powered/id1139111958

 https://itunes.apple.com/us/app/red-onion-tor-powered-web/id829739720

 https://itunes.apple.com/us/app/onion-vpn-with-tor/id793839665

 https://itunes.apple.com/us/app/tor-vpn-free-vpn-onion-vpn/id1180290098

 https://itunes.apple.com/us/app/onion-tor-powered-browser/id1052323344

 https://itunes.apple.com/us/app/red-onion-tor-browser/id1109277833

 https://itunes.apple.com/us/app/onion-tor-browser-for-
 anonymous/id1152322705

 https://itunes.apple.com/us/app/onion-tor-powered-browser/id1140845347

 https://itunes.apple.com/us/app/onion-tor-browser-for-
 anonymous/id1162607213

 https://itunes.apple.com/us/app/tor-vpn-browser-for-anonymous/id914252107

 https://itunes.apple.com/us/app/secret-secure-web-browser/id1146417816

 https://itunes.apple.com/us/app/safe-browser-secure-photo/id966483488

 https://itunes.apple.com/us/app/onion-vpn-with-tor/id793879925

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20873 [- Select a component]: Trademark violations on Apple AppStore

2016-12-03 Thread Tor Bug Tracker & Wiki

#20873: Trademark violations on Apple AppStore
--+-
 Reporter:  mrphs |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 There are a bunch of snakeoil and typically closed source apps with ads
 injected in them under the name of Tor for iOS in Apple App Store. Some of
 them have pretty good rating (which I believe is because of lack of any
 official or even free and trusted-community-based Tor Browser for iOS).
 Now that 'Onion Browser' is finally free for everyone to download and use,
 I think we should get more serious about taking those fake ones down.
 Specially those that use the name or logo of Tor.

 If they have hundreds of 5star reviews, who knows how many people are
 actually using them and thinking they're anonymous and secure online.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20348 [Metrics/Censorship analysis]: kz no need tor, tor no need kz, if anybody want they can to use ultrasurf. cyberoam assists bloody dictatorships.

2016-12-03 Thread Tor Bug Tracker & Wiki

#20348: kz no need tor, tor no need kz, if anybody want they can to use 
ultrasurf.
cyberoam assists bloody dictatorships.
-+-
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:  censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Default:
 .150 conn closed
 .161 conn closed
 .162 conn stalled
 .163 conn stalled

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20348 [Metrics/Censorship analysis]: kz no need tor, tor no need kz, if anybody want they can to use ultrasurf. cyberoam assists bloody dictatorships.

2016-12-03 Thread Tor Bug Tracker & Wiki

#20348: kz no need tor, tor no need kz, if anybody want they can to use 
ultrasurf.
cyberoam assists bloody dictatorships.
-+-
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:  censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 > for the same bridge depends

 not sure again, i messed test conditions and 3 addr so similar to lost
 there

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19634 [Metrics/metrics-lib]: support shared randomness lines

2016-12-03 Thread Tor Bug Tracker & Wiki

#19634: support shared randomness lines
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  metrics-lib 1.6.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * milestone:  metrics-lib 2.0.0 => metrics-lib 1.6.0


Comment:

 We could try again for 1.6.0.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20252 [Metrics/metrics-lib]: Identify changes to dir-spec.txt from proposal 264

2016-12-03 Thread Tor Bug Tracker & Wiki

#20252: Identify changes to dir-spec.txt from proposal 264
-+---
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  metrics-lib 1.6.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * milestone:   => metrics-lib 1.6.0


Comment:

 Maybe something for 1.6.0.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20525 [Metrics/metrics-lib]: Be more careful when deleting extraneous local descriptor files

2016-12-03 Thread Tor Bug Tracker & Wiki

#20525: Be more careful when deleting extraneous local descriptor files
-+---
 Reporter:  karsten  |  Owner:  karsten
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  metrics-lib 1.6.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * milestone:   => metrics-lib 1.6.0


Comment:

 Let's try to fix this in 1.6.0.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20348 [Metrics/Censorship analysis]: kz no need tor, tor no need kz, if anybody want they can to use ultrasurf. cyberoam assists bloody dictatorships.

2016-12-03 Thread Tor Bug Tracker & Wiki

#20348: kz no need tor, tor no need kz, if anybody want they can to use 
ultrasurf.
cyberoam assists bloody dictatorships.
-+-
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:  censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 > default:8080 connection closed after request
 > another_default:8080 connection stalled after request

 It closes or stalls connection for the same bridge depends something

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20521 [Metrics/metrics-lib]: Deprecate `DescriptorReader.setExcludeFiles()` and add two separate methods for loading and saving a history file

2016-12-03 Thread Tor Bug Tracker & Wiki

#20521: Deprecate `DescriptorReader.setExcludeFiles()` and add two separate 
methods
for loading and saving a history file
-+---
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 1.6.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-help |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * status:  new => needs_review


Comment:

 Please review [https://gitweb.torproject.org/user/karsten/metrics-
 lib.git/log/?h=task-20521 my updated task-20521 branch] with another fixup
 commit and the requested tests.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20348 [Metrics/Censorship analysis]: kz no need tor, tor no need kz, if anybody want they can to use ultrasurf. cyberoam assists bloody dictatorships.

2016-12-03 Thread Tor Bug Tracker & Wiki

#20348: kz no need tor, tor no need kz, if anybody want they can to use 
ultrasurf.
cyberoam assists bloody dictatorships.
-+-
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:  censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 > default:8080 connection closed after request

 another_default:8080 connection stalled after request

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20348 [Metrics/Censorship analysis]: kz no need tor, tor no need kz, if anybody want they can to use ultrasurf. cyberoam assists bloody dictatorships.

2016-12-03 Thread Tor Bug Tracker & Wiki

#20348: kz no need tor, tor no need kz, if anybody want they can to use 
ultrasurf.
cyberoam assists bloody dictatorships.
-+-
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:  censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 > Here is an FTE bridge to test.

 default:8080 connection closed after request
 23.92.21.42:8080 connection stalled after request
 23.92.21.42:38195 works

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20348 [Metrics/Censorship analysis]: kz no need tor, tor no need kz, if anybody want they can to use ultrasurf. cyberoam assists bloody dictatorships.

2016-12-03 Thread Tor Bug Tracker & Wiki

#20348: kz no need tor, tor no need kz, if anybody want they can to use 
ultrasurf.
cyberoam assists bloody dictatorships.
-+-
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:  censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dcf):

 Here is an FTE bridge to test.

   port 8080
   {{{
 Bridge fte 23.92.21.42:8080 E7A116DA39105C617E952CB809FEC1102BC36BD3
 }}}
   port 38195
   {{{
 Bridge fte 23.92.21.42:38195 E7A116DA39105C617E952CB809FEC1102BC36BD3
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20857 [Applications/Tor Browser]: Unable to complete initial configuration

2016-12-03 Thread Tor Bug Tracker & Wiki

#20857: Unable to complete initial configuration
--+---
 Reporter:  sigsegv   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by sigsegv):

 To add a bit more insight into what I suspect is going on here,
 DisableNetwork is being set dependent on the selections one makes on a
 screen asking how one is connected to the Internet (directly/bridge/etc),
 which I suspect is not currently accessible and hence causing usability
 issues. In the meantime, what file (s) should I edit to properly set
 DisableNetwork given editing torn in ~/Library appears to not do the
 trick? I ask because currently TBB is completely unusable for visually
 impaired MacOS users as a result of this issue. Thanks.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20871 [Core Tor/Torsocks]: Regression in Torsocks 2.2.0 breaks wget, among others

2016-12-03 Thread Tor Bug Tracker & Wiki

#20871: Regression in Torsocks 2.2.0 breaks wget, among others
---+---
 Reporter:  cypherpunks|  Owner:  dgoulet
 Type:  defect | Status:  needs_information
 Priority:  High   |  Milestone:
Component:  Core Tor/Torsocks  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by dgoulet):

 * status:  new => needs_information


Comment:

 This works for me:

 {{{
 $ torsocks --version
 Torsocks 2.2.0
 $ torsocks wget --spider www.torproject.org
 Spider mode enabled. Check if remote file exists.
 --2016-12-03 11:52:48--  http://www.torproject.org/
 Resolving www.torproject.org (www.torproject.org)... 38.229.72.16
 [...]
 }}}

 My bet here is that you got an Exit relay that wasn't cooperating well. If
 you try with `-i` multiple time, do you still get the issue? (that option
 will make you use a different circuit per execution).

 If yes, next step would be to provide the output of `TORSOCKS_LOG_LEVEL=5
 torsocks ...` so we can look at the debug logs and see where it went
 wrong.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20348 [Metrics/Censorship analysis]: kz no need tor, tor no need kz, if anybody want they can to use ultrasurf. cyberoam assists bloody dictatorships.

2016-12-03 Thread Tor Bug Tracker & Wiki

#20348: kz no need tor, tor no need kz, if anybody want they can to use 
ultrasurf.
cyberoam assists bloody dictatorships.
-+-
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:  censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Delete this ticket! No software solution here.
 Wait till trump will install zillion cyberoam boxes around US.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20707 [Applications/Tor Browser]: Preferences tab is broken in non-en-US 6.5a4(-hardened) builds

2016-12-03 Thread Tor Bug Tracker & Wiki

#20707: Preferences tab is broken in non-en-US 6.5a4(-hardened) builds
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  reopened
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-usability,   |  Actual Points:
  TorBrowserTeam201611R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by viktorj):

 I noticed that this is indeed fixed in the 45.5.0esr-6.5-1 branch, but the
 commit was not included in the 6.5a5(-hardened) upload. So feel free to
 close this ticket again or see this as a reminder to include the fix in
 the next upload.

 BTW, there were also three other commits in the 45.5.0esr-6.5-1 branch
 which were not included in the 6.5a5(-hardened) upload. I couldn't find
 any "master" branch or something similar, so I assumed that only the
 latest branch is relevant for bug fixing, especially since this is a
 ticket concerning the alpha version.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20588 [Core Tor/Tor]: Compiler breakage when strange CPU meets new OpenSSL

2016-12-03 Thread Tor Bug Tracker & Wiki

#20588: Compiler breakage when strange CPU meets new OpenSSL
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  reopened
 Priority:  High  |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  028-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by yawning):

 * keywords:   => 028-backport
 * status:  closed => reopened
 * resolution:  implemented =>


Comment:

 This came up again as #20868 because we didn't backport it.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20868 [Core Tor/Tor]: fails to build on arm

2016-12-03 Thread Tor Bug Tracker & Wiki

#20868: fails to build on arm
--+
 Reporter:  weasel|  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.10
 Severity:  Major | Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by yawning):

 * status:  new => closed
 * resolution:   => duplicate


Comment:

 This is a dup of #20588.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20872 [Core Tor/Tor]: option to build non-standard code paths on x86

2016-12-03 Thread Tor Bug Tracker & Wiki

#20872: option to build non-standard code paths on x86
--+
 Reporter:  weasel|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.10
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 #20868 is a case where one code path gets almost always built on x86, and
 another is used everywhere else.

 This means that we don't notice build or test failures on that other code
 path.

 Should we have options to use the alternate path even on x86, so we can
 build and run tests on our CI using fast machines?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19376 [Core Tor/Torsocks]: Fix a few torsocks bugs caused by unquoted variables

2016-12-03 Thread Tor Bug Tracker & Wiki

#19376: Fix a few torsocks bugs caused by unquoted variables
---+
 Reporter:  cypherpunks|  Owner:  dgoulet
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:
Component:  Core Tor/Torsocks  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by cypherpunks):

 Replying to [comment:4 dgoulet]:
 > I can't apply this patch. Can you send me a git diff or a branch or git
 format-patch? The diff file assume that torsocks is in `/usr/bin/torsocks`
 and thus fails :S ... If you can't let me know, I'll apply it by hand but
 I would rather not.

 Even after all this time, the script is just as horrifying. It's
 reminiscent of reading glibc. Not as traumatic though, it's a lot shorter.

 Since the bug is still present in 2.2.0 (and I had forgot about this bug),
 I wrote a quick new one in git diff format. The new patch assumes it's in
 src/bin/torsocks (where it is in the source tgz).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20868 [Core Tor/Tor]: fails to build on arm

2016-12-03 Thread Tor Bug Tracker & Wiki

#20868: fails to build on arm
--+
 Reporter:  weasel|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.10
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by weasel):

 also FTBFS on arm64, ppc64el, and s390x.  (Other archs haven't been
 attempted yet.)

 This is [https://bugs.debian.org/846781 Debian bug #846781].

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20871 [Core Tor/Torsocks]: Regression in Torsocks 2.2.0 breaks wget, among others

2016-12-03 Thread Tor Bug Tracker & Wiki

#20871: Regression in Torsocks 2.2.0 breaks wget, among others
---+-
 Reporter:  cypherpunks|  Owner:  dgoulet
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Core Tor/Torsocks  |Version:
 Severity:  Major  |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 Various applications no longer work due to a regression in the latest
 Torsocks update, such as tlsdate and wget, whereas curl and youtube-dl
 work. I've tested this by compiling both 2.1.0 and 2.2.0 and exporting the
 library with LD_PRELOAD, and trying wget with both.

 The problem is not with name resolution, as would be suggested in the wget
 error, or with the TLS handshake, as tlsdate suggests, because the strace
 output does not even get to socket() and connect(). However, when an IP
 address is passed directly to wget rather than a hostname, 2.2.0 works. It
 appears to me like the problem, at least in wget's case, is with the
 hostname resolution code being hooked incorrectly by Torsocks. That's just
 a guess though.

 With wget and curl:
 {{{
 $ LD_PRELOAD=libtorsocks-2.1.0.so curl https://www.torproject.org/
 >/dev/null
   % Total% Received % Xferd  Average Speed   TimeTime Time
 Current
  Dload  Upload   Total   SpentLeft
 Speed
 100 15868  100 158680 0   6158  0  0:00:02  0:00:02 --:--:--
 8369

 $ LD_PRELOAD=libtorsocks-2.1.0.so wget --spider
 https://www.torproject.org/
 Spider mode enabled. Check if remote file exists.
 --2016-12-03 10:08:57--  https://www.torproject.org/
 Resolving www.torproject.org... 38.229.72.16
 Connecting to www.torproject.org|38.229.72.16|:443... connected.
 HTTP request sent, awaiting response... 200 OK
 Length: 15868 (15K) [text/html]
 Remote file exists and could contain further links,
 but recursion is disabled -- not retrieving.

 $ LD_PRELOAD=libtorsocks-2.2.0.so curl https://www.torproject.org/
 >/dev/null
   % Total% Received % Xferd  Average Speed   TimeTime Time
 Current
  Dload  Upload   Total   SpentLeft
 Speed
 100 15868  100 158680 0   7227  0  0:00:02  0:00:02 --:--:--
 10494

 $ LD_PRELOAD=libtorsocks-2.2.0.so wget --spider
 https://www.torproject.org/
 Spider mode enabled. Check if remote file exists.
 --2016-12-03 10:09:20--  https://www.torproject.org/
 Resolving www.torproject.org... failed: Unknown error.
 wget: unable to resolve host address www.torproject.org

 $ LD_PRELOAD=libtorsocks-2.2.0.so wget --spider $(tor-resolve
 torproject.org)
 Spider mode enabled. Check if remote file exists.
 --2016-12-03 10:11:12--  http://138.201.14.197/
 Connecting to 138.201.14.197:80... connected.
 HTTP request sent, awaiting response... 200 OK
 Length: 496 [text/html]
 Remote file exists and could contain further links,
 but recursion is disabled -- not retrieving.
 }}}

 And with tlsdate:
 {{{
 $ LD_PRELOAD=libtorsocks-2.1.0.so tlsdate -n -V
 Sat Dec  3 10:11:57 UTC 2016

 $ LD_PRELOAD=libtorsocks-2.2.0.so tlsdate -n -V
 SSL connection failed
 child process failed in SSL handshake
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20868 [Core Tor/Tor]: fails to build on arm

2016-12-03 Thread Tor Bug Tracker & Wiki

#20868: fails to build on arm
--+
 Reporter:  weasel|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.10
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by weasel):

 It's a bit of a shame that our CI has pointed at this issue for a month
 but we ignored it.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20869 [Internal Services/Tor Sysadmin Team]: Please shut down globe.torproject.org

2016-12-03 Thread Tor Bug Tracker & Wiki

#20869: Please shut down globe.torproject.org
-+
 Reporter:  karsten  |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by karsten):

 Wow, this caused more changes than I anticipated.  Thanks!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20869 [Internal Services/Tor Sysadmin Team]: Please shut down globe.torproject.org

2016-12-03 Thread Tor Bug Tracker & Wiki

#20869: Please shut down globe.torproject.org
-+
 Reporter:  karsten  |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 I cleaned up and
 * removed it from puppet (ssl::service, onion::service, static component,
 vhost)
 * removed files from the static mirrors
 (/srv/static.torproject.org/mirrors/globe.torproject.org/) and their
 apache logs
 * removed the copy of files on the static master
 (/srv/static.tpo/master/globe.tpo)
 * removed the nagios sync check
 * removed ssl keys on the static mirrors
 * removed globe from the letsencrypt domain list and removed key material
 and certs from our LE host and the puppet host.
 * removed backup keys from the repository
 * removed the DNS entry.
 * checked for remains of the onion service on the leaves and on the
 balancer.

 I wonder if I forgot anything.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20801 [Metrics/Atlas]: atlas should show "Last Restarted" either in UTC or should show the time zone

2016-12-03 Thread Tor Bug Tracker & Wiki

#20801: atlas should show "Last Restarted" either in UTC or should show the time
zone
---+
 Reporter:  toralf |  Owner:  irl
 Type:  defect | Status:  closed
 Priority:  Low|  Milestone:
Component:  Metrics/Atlas  |Version:  Tor: 0.2.9.5-alpha
 Severity:  Minor  | Resolution:  worksforme
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by karsten):

 * status:  needs_information => closed
 * resolution:   => worksforme


Comment:

 Okay.  Then let's close this as works-for-me.  Note that this is unrelated
 to #20802 which uses different functions for parsing and formatting
 timestamps.  Thanks for the report anyway!  Closing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20802 [Metrics/Atlas]: last metric point of "1 Week graph" of exit probability is 1 hour ahead in the future

2016-12-03 Thread Tor Bug Tracker & Wiki

#20802: last metric point of "1 Week graph" of exit probability is 1 hour ahead 
in
the future
---+
 Reporter:  toralf |  Owner:  irl
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:  Tor: 0.2.9.5-alpha
 Severity:  Minor  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by karsten):

 Good catch, confirmed!  This is likely related to
 [https://gitweb.torproject.org/atlas.git/tree/js/views/details/main.js#n115
 d3.time.format()] using the browser's timezone for formatting timestamps
 rather than the UTC timezone.  There might be similar lines.  I could try
 to fix this, but I'd prefer to leave this to somebody else who is better
 at JavaScript development than I.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20801 [Metrics/Atlas]: atlas should show "Last Restarted" either in UTC or should show the time zone

2016-12-03 Thread Tor Bug Tracker & Wiki

#20801: atlas should show "Last Restarted" either in UTC or should show the time
zone
---+
 Reporter:  toralf |  Owner:  irl
 Type:  defect | Status:  needs_information
 Priority:  Low|  Milestone:
Component:  Metrics/Atlas  |Version:  Tor: 0.2.9.5-alpha
 Severity:  Minor  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by toralf):

 indeed, it is right now (well, I do have 0.2.9.6-rc since yesterday but
 that shouldn't make a difference)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20801 [Metrics/Atlas]: atlas should show "Last Restarted" either in UTC or should show the time zone

2016-12-03 Thread Tor Bug Tracker & Wiki

#20801: atlas should show "Last Restarted" either in UTC or should show the time
zone
---+
 Reporter:  toralf |  Owner:  irl
 Type:  defect | Status:  needs_information
 Priority:  Low|  Milestone:
Component:  Metrics/Atlas  |Version:  Tor: 0.2.9.5-alpha
 Severity:  Minor  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by karsten):

 * status:  new => needs_information


Comment:

 Hmm, I cannot confirm this issue.  Right now,
 [https://atlas.torproject.org/#details/1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA
 Atlas] says that your relay was last restarted at 2016-12-02 17:25:59,
 which is UTC.
 
[https://onionoo.torproject.org/details?search=1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA
 Onionoo] says the same: `"last_restarted":"2016-12-02 17:25:59"`.  And
 your relay server descriptor contains the lines `published 2016-12-03
 06:38:21` and `uptime 47542`, which leads to the same UTC time (using R):
 `as.POSIXct("2016-12-03 06:38:21", tz = "UTC") - 47542` == `[1]
 "2016-12-02 17:25:59 UTC"`.

 Can you look again and say which of these sources shows you a different
 timestamp?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20853 [Core Tor/Tor]: rend_config_services should use service_is_ephemeral rather than old/new->directory

2016-12-03 Thread Tor Bug Tracker & Wiki

#20853: rend_config_services should use service_is_ephemeral rather than
old/new->directory
+
 Reporter:  teor|  Owner:  jryans
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.2.9.5-alpha
 Severity:  Normal  | Resolution:
 Keywords:  easy refactor intro hs  |  Actual Points:
Parent ID:  | Points:  0.1
 Reviewer:  |Sponsor:
+
Changes (by jryans):

 * status:  needs_revision => needs_review


Comment:

 Updated patch at
 https://github.com/jryans/tor/commits/service_is_ephemeral.

 Replying to [comment:9 teor]:
 > Replying to [comment:8 jryans]:
 > > Replying to [comment:6 teor]:
 > > > Similarly, we can't change this part of rend_config_services:
 > > > {{{
 > > > if (new->directory && old->directory &&
 > > > !strcmp(old->directory, new->directory)) {
 > > > }}}
 > > > without adding explicit checks for the directories being valid
 before doing a strcmp on them.
 > >
 > > Okay, I added explicit `BUG` checks for the directory in addition to
 the ephemeral check for both of these cases.
 >
 > Thanks for this change.
 > The `BUG(new->directory)` and the old check are inverted, they will log
 a message when the directory exists, but we want to log a message when it
 doesn't.

 Ah, good catch!  I inverted the part inside `BUG` to log in the correct
 case, but I also have to invert outside `BUG` to chain with the rest of
 the conditional.  Not sure if `&& !BUG(!...) &&` is okay style.

 > Oh, and can we do them in the same order in
 rend_service_verify_single_onion_poison?
 > (That is, the ephemeral check first, then the directory check?)
 > Let's not log a BUG unless we really have to.

 Makes sense, updated the order.

 > > > > Not sure if a changes file was needed for this, but I added one
 anyway just to get familiar with the process.
 > > >
 > > > Thanks! Minor comment changes don't get a changes file, everything
 else does.
 > > > (I've submitted a number of code changes that were "Refactoring, no
 behaviour change", and then ended up being "unexpected bug in ticket X
 because behaviour changed during refactor".)
 > > >
 > > > One nitpick:
 > > >
 > > > the changes file format starts with
 > > > `Minor bugfix (optional categories):`
 > > >
 https://gitweb.torproject.org/tor.git/tree/doc/HACKING/CodingStandards.md#n56
 > >
 > > I wasn't sure if you wanted me to add an optional category or change
 to "Minor bugfix".  The current file (using the group "Code simplification
 and refactoring") passes the `lintChanges.py` script.  Let me know if
 there's still a change needed.
 >
 > Yes, please change it to 'Minor bugfix (hidden services)'.

 Okay, updated.  Added `bugfix on ...` as requested by lint tool as well.
 Comment 1 suspected that #20526 made it into 0.2.9.5, but `git describe
 --contains` on the commit from #20526 didn't find any tags, so I listed it
 as not in any released version.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20348 [Metrics/Censorship analysis]: kz no need tor, tor no need kz, if anybody want they can to use ultrasurf. cyberoam assists bloody dictatorships.

2016-12-03 Thread Tor Bug Tracker & Wiki

#20348: kz no need tor, tor no need kz, if anybody want they can to use 
ultrasurf.
cyberoam assists bloody dictatorships.
-+-
 Reporter:  dcf  |  Owner:
 Type:  project  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:  censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 > I found a Tor exit in kz.

 This relay is not from kz, 100%.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20765 [Metrics/metrics-lib]: adapt to new lines in votes and consensus and make the adaption to protocol changes easier

2016-12-03 Thread Tor Bug Tracker & Wiki

#20765: adapt to new lines in votes and consensus and make the adaption to 
protocol
changes easier
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  metrics-lib 1.6.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 See also #19634 here for the `shared-rand-*` lines.

 Regarding making these changes without compiling, I'm not certain what the
 benefit would be.  We'll have to put out a new release to make sense of
 these new lines anyway.  And we'll want to include tests.

 Speaking of, I think we accumulated enough changes for a new metrics-lib
 release in December.  Let's discuss that either here or at the next
 meeting.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20710 [Core Tor/Tor]: memory leak in sandbox_getaddrinfo()

2016-12-03 Thread Tor Bug Tracker & Wiki

#20710: memory leak in sandbox_getaddrinfo()
-+-
 Reporter:  arma |  Owner:
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.5.5-alpha
 Severity:  Normal   | Resolution:
 Keywords:  025-backport, 026-backport,  |  Actual Points:
  027-backport, 028-backport, review-group-13|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 LGTM

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20870 [Internal Services/Service - git]: Please move globe.git to Attic

2016-12-03 Thread Tor Bug Tracker & Wiki

#20870: Please move globe.git to Attic
-+
 Reporter:  karsten  |  Owner:  tor-gitadm
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 As the subject says, please move globe.git to the attic.  Thanks in
 advance!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20869 [Internal Services/Tor Sysadmin Team]: Please shut down globe.torproject.org

2016-12-03 Thread Tor Bug Tracker & Wiki

#20869: Please shut down globe.torproject.org
-+-
 Reporter:  karsten  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 The "manual redirect" on https://globe.torproject.org/ has been in place
 for a couple of weeks now, and it says "This page will be removed November
 30, 2016."  Time to remove that page.

 Please remove that static page and DNS entry at any time.  Thanks for
 keeping it in place until now.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20868 [Core Tor/Tor]: fails to build on arm

2016-12-03 Thread Tor Bug Tracker & Wiki

#20868: fails to build on arm
--+
 Reporter:  weasel|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.8.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.10
 Severity:  Major |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 On arm and armhf, with openssl 1.1:
 {{{
 gcc -DHAVE_CONFIG_H -I. -I..  -I../src/ext -Isrc/ext -I../src/ext/trunnel
 -I../src/trunnel -I../src/common -Isrc/common -I../src/ext/trunnel
 -I../src/trunnel -I../src/or -Isrc/or -DSHARE_DATADIR="\"/usr/share\""
 -DLOCALSTATEDIR="\"/var\"" -DBINDIR="\"/usr/bin\"" -Wdate-time
 -D_FORTIFY_SOURCE=2 -I../src/common -g -O2 -fdebug-prefix-
 map=/<>=. -fstack-protector-strong -Wformat -Werror=format-
 security -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-all
 -Wstack-protector -fwrapv --param ssp-buffer-size=1 -fPIE -fasynchronous-
 unwind-tables -Wall -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 -Winit-self -Wmissing-field-initializers -Wold-style-
 definition -Waddress -Wmissing-noreturn -Wstrict-overflow=1
 -Wnormalized=id -Woverride-init -Wextra -Warray-bounds -Wlogical-op -c -o
 src/common/crypto.o ../src/common/crypto.c
 ../src/common/aes.c:158:20: error: field 'evp' has incomplete type
  EVP_CIPHER_CTX evp;
 ^~~
 ../src/common/aes.c: In function 'evaluate_ctr_for_aes':
 ../src/common/aes.c:254:5: warning: implicit declaration of function
 'AES_ctr128_encrypt' [-Wimplicit-function-declaration]
  AES_ctr128_encrypt([i], [i], 1, , ivec, ivec_tmp,
 );
  ^~
 ../src/common/aes.c:254:5: warning: nested extern declaration of
 'AES_ctr128_encrypt' [-Wnested-externs]
 Makefile:3347: recipe for target 'src/common/aes.o' failed
 }}}

 
https://volatile.noreply.org/2016-12-02-JueousgnOYk/tor_0.2.8.10-1_armel-2016-12-02T182943Z.build
 has a more complete log of a (different) build.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

61 matches

Mail list logo