date:20161025

Re: [tor-bugs] #20265 [User Experience/Translations]: Remove Tor Messenger resources from Transifex

2016-10-25 Thread Tor Bug Tracker & Wiki

#20265: Remove Tor Messenger resources from Transifex
--+---
 Reporter:  sukhbir   |  Owner:  phoul
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  User Experience/Translations  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by phoul):

 This has been completed, however finger.properties was not present on
 Transifex. If this should be added, please provide a link to the strings.

--
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] #20458 [Core Tor/Tor]: Integration tests should be run locally before committing code changes

2016-10-25 Thread Tor Bug Tracker & Wiki

#20458: Integration tests should be run locally before committing code changes
--+
 Reporter:  chelseakomlo  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  test, doc |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by chelseakomlo):

 If someone hasn't set up chutney and runs `make test-network-all`, the
 output is:

 `$CHUTNEY_PATH was not set.`

 `To run these tests, git clone https://git.torproject.org/chutney.git ;
 export CHUTNEY_PATH=`pwd`/chutney`

 I personally think this helpful, and there are further instructions in the
 chutney repo. This just means that someone who wants to contribute code
 changes will need to set up both projects independently.

--
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] #19969 [Core Tor/Tor]: tor client does not immediately open new circuits after standby

2016-10-25 Thread Tor Bug Tracker & Wiki

#19969: tor client does not immediately open new circuits after standby
--+
 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.6
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Next piece of the mystery:
 {{{
 Oct 25 18:51:45.580 [info] routerlist_remove_old_routers(): We have 0 live
 routers and 0 old router descriptors.
 Oct 25 21:58:43.520 [notice] Your system clock just jumped 11174 seconds
 forward; assuming established circuits no longer work.
 Oct 25 21:58:54.825 [info] routerlist_remove_old_routers(): We have 0 live
 routers and 0 old router descriptors.
 }}}

 How come my Tor client didn't spring into action after it noticed the
 clock jump?

--
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] #20469 [Core Tor/Tor]: Expose predicted-ports state over the control port

2016-10-25 Thread Tor Bug Tracker & Wiki

#20469: Expose predicted-ports state over the control port
--+--
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 While debugging #19969 I wanted to ask my Tor whether it had any predicted
 ports in its internal state. But I think there is no way to ask it? I
 would like a 'getinfo predicted-ports' or the like.

--
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] #19969 [Core Tor/Tor]: tor client does not immediately open new circuits after standby

2016-10-25 Thread Tor Bug Tracker & Wiki

#19969: tor client does not immediately open new circuits after standby
--+
 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.6
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Ok, it just happened to me (running "Tor 0.2.9.3-alpha-dev (git-
 bfaded9143d127cb)"). My tor client has been on an airplane all day,
 firewalled from the internet. Now I made a request to it, and it just sat
 there -- it received the request but did not attempt to make any circuits
 or anything.

 I connected over the control port and asked it 'getinfo circuit-status'
 and it has no circuits open.

 It is *supposed* to say
 {{{
 log_fn(severity, LD_APP|LD_DIR,
"Application request when we haven't %s. "
"Optimistically trying directory fetches again.",
!router_have_minimum_dir_info() ?
"used client functionality lately" :
"received a consensus with exits");
 }}}
 and then start making circuits and stuff.

 It's weird that it didn't even try to make a circuit for the new stream
 request though.

--
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] #20204 [Applications/Tor Browser]: Windows don't drag on macOS Sierra

2016-10-25 Thread Tor Bug Tracker & Wiki

#20204: Windows don't drag on macOS Sierra
-+-
 Reporter:  arlolra  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr-will-have, tbb-usability,   |  Actual Points:
  TorBrowserTeam201610R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * status:  reopened => needs_review
 * keywords:  ff52-esr-will-have, tbb-usability, TorBrowserTeam201609R =>
 ff52-esr-will-have, tbb-usability, TorBrowserTeam201610R


Comment:

 It took us most of the day, but Kathy and I found the problem: when we
 modified one of the Firefox patches to avoid RectIter (which is not
 available in ESR 45), we introduced a bug that caused some non-draggable
 regions to be ignored: we were iterating twice each time through a loop.
 Please review the following "fixup" patch:
 https://gitweb.torproject.org/user/brade/tor-
 
browser.git/commit/?h=bug20204-fixup-01=a6b4bb9a9d2769e8be110f2f0486b9ec74882575

--
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] #20204 [Applications/Tor Browser]: Windows don't drag on macOS Sierra

2016-10-25 Thread Tor Bug Tracker & Wiki

#20204: Windows don't drag on macOS Sierra
-+-
 Reporter:  arlolra  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr-will-have, tbb-usability,   |  Actual Points:
  TorBrowserTeam201609R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

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


--
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] #20468 [Applications/Tor Browser]: TorBrowser using a secert HASHEDPASSWORD

2016-10-25 Thread Tor Bug Tracker & Wiki

#20468: TorBrowser using a secert HASHEDPASSWORD
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 One way to work around this is to use a control port filter on your tor.

--
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] #20468 [Applications/Tor Browser]: TorBrowser using a secert HASHEDPASSWORD

2016-10-25 Thread Tor Bug Tracker & Wiki

#20468: TorBrowser using a secert HASHEDPASSWORD
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 For security reasons, I was trying force the TorBrowser to work with it's
 own tor instance (and SocksPort) but without allowing it to have access to
 the ControlPort.

 I don't care for the TorButton New Identity or circuit path display
 features.

 I tried setting CookieAuthentication to 0 in torrc-defaults. But was
 surprised to find that the TorBrowser still managed to authenticate with
 the control port and the TorButton was able to display the circuit path.

 With the help of the folks on irc, we were able to determine that the
 TorLauncher uses it's own secret hashed password if it's unable to find a
 cookie or env password.

 Protocolinfo says: 250-AUTH METHODS=HASHEDPASSWORD

 I think the TorBrowser and TorLauncher should respect the users wishes and
 not set a secret password for itself. Instead just work without the
 ControlPort.

--
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] #20410 [Core Tor/Tor]: Tor master breaks bridge clients

2016-10-25 Thread Tor Bug Tracker & Wiki

#20410: Tor master breaks bridge clients
-+
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  needs_revision
 Priority:  High |  Milestone:
Component:  Core Tor/Tor |Version:  Tor: 0.3.0.0-alpha-dev
 Severity:  Major| Resolution:
 Keywords:  crash bridge-client  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+
Changes (by teor):

 * status:  new => needs_revision


Comment:

 make test-network-all passes everything, with the following patch on top
 of nickm's branch:

 {{{
 diff --git a/src/or/connection_edge.c b/src/or/connection_edge.c
 index faf658c..1ee0c0f 100644
 --- a/src/or/connection_edge.c
 +++ b/src/or/connection_edge.c
 @@ -2434,7 +2434,8 @@
 connection_ap_handshake_send_begin(entry_connection_t *ap_conn)
   * Otherwise, directory connections are typically one-hop.
   * This matches the earlier check for directory connection path
 anonymity
   * in directory_initiate_command_rend(). */
 -if (purpose_needs_anonymity(linked_dir_conn_base->purpose, 0,
 +if (purpose_needs_anonymity(linked_dir_conn_base->purpose,
 +TO_DIR_CONN(linked_dir_conn_base)->router_purpose,
 TO_DIR_CONN(linked_dir_conn_base)->requested_resource)) {
assert_circ_anonymity_ok(circ, options);
  }
 }}}

 I'd like to see this merged soon, we're already getting duplicate bug
 reports.

--
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] #20410 [Core Tor/Tor]: Tor master breaks bridge clients

2016-10-25 Thread Tor Bug Tracker & Wiki

#20410: Tor master breaks bridge clients
-+
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Core Tor/Tor |Version:  Tor: 0.3.0.0-alpha-dev
 Severity:  Major| Resolution:
 Keywords:  crash bridge-client  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+

Comment (by teor):

 I also see some whitespace issues, are any of these yours (or from
 #20077)?
 {{{
  DoubleNL:./src/test/test_dir.c:3290
  Wide:./src/test/test_dir.c:3314
  Wide:./src/test/test_dir.c:3315
  Wide:./src/test/test_dir.c:3318
  Wide:./src/test/test_dir.c:3319
  Wide:./src/test/test_dir.c:3320
  Wide:./src/test/test_dir.c:3321
  Wide:./src/test/test_dir.c:3322
 }}}

--
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] #20410 [Core Tor/Tor]: Tor master breaks bridge clients

2016-10-25 Thread Tor Bug Tracker & Wiki

#20410: Tor master breaks bridge clients
-+
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Core Tor/Tor |Version:  Tor: 0.3.0.0-alpha-dev
 Severity:  Major| Resolution:
 Keywords:  crash bridge-client  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+

Comment (by teor):

 That's not a kludge, that's almost exactly what I would have done.

 We need to look up the dir_conn's router purpose here, instead of passing
 zero:
 {{{
 -if (purpose_needs_anonymity(linked_dir_conn_base->purpose, 0)) {
 +if (purpose_needs_anonymity(linked_dir_conn_base->purpose, 0,
 +
 TO_DIR_CONN(linked_dir_conn_base)->requested_resource)) {
 }}}

 Then I think we're good to run make test-network-all etc., then merge.

--
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] #20410 [Core Tor/Tor]: Tor master breaks bridge clients

2016-10-25 Thread Tor Bug Tracker & Wiki

#20410: Tor master breaks bridge clients
-+
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Core Tor/Tor |Version:  Tor: 0.3.0.0-alpha-dev
 Severity:  Major| Resolution:
 Keywords:  crash bridge-client  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+

Comment (by nickm):

 (that's in my public repository at
 https://git.torproject.org/nickm/tor.git )

--
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] #20410 [Core Tor/Tor]: Tor master breaks bridge clients

2016-10-25 Thread Tor Bug Tracker & Wiki

#20410: Tor master breaks bridge clients
-+
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Core Tor/Tor |Version:  Tor: 0.3.0.0-alpha-dev
 Severity:  Major| Resolution:
 Keywords:  crash bridge-client  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+

Comment (by nickm):

 I've done a complete kludge to see if we're on the right track, as branch
 `bug20410_kludge`. Is that about what you had in mind? Does is work for
 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

[tor-bugs] #20467 [Metrics/Torflow]: bwauth aggregator divides by zero if a node class is missing

2016-10-25 Thread Tor Bug Tracker & Wiki

#20467: bwauth aggregator divides by zero if a node class is missing
-+
 Reporter:  teor |  Owner:  aagbsn
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Torflow  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 The bwauth code expects there to always be a non-zero number of each of
 "Guard+Exit", "Guard", "Exit", and "Middle" nodes.

 In small networks, this isn't always the case:
 {{{
 diff --git a/NetworkScanners/BwAuthority/aggregate.py
 b/NetworkScanners/BwAuthority/aggregate.py
 index 01ea8b5..cae436b 100755
 --- a/NetworkScanners/BwAuthority/aggregate.py
 +++ b/NetworkScanners/BwAuthority/aggregate.py
 @@ -489,10 +489,15 @@ def main(argv):

  for cl in ["Guard+Exit", "Guard", "Exit", "Middle"]:
c_nodes = filter(lambda n: n.node_class() == cl,
 nodes.itervalues())
 -  true_filt_avg[cl] = sum(map(lambda n: n.filt_bw,
 c_nodes))/float(len(c_nodes))
 -  true_strm_avg[cl] = sum(map(lambda n: n.strm_bw,
 c_nodes))/float(len(c_nodes))
 -  true_circ_avg[cl] = sum(map(lambda n: (1.0-n.circ_fail_rate),
 +  if len(c_nodes) > 0:
 +true_filt_avg[cl] = sum(map(lambda n: n.filt_bw,
 c_nodes))/float(len(c_nodes))
 +true_strm_avg[cl] = sum(map(lambda n: n.strm_bw,
 c_nodes))/float(len(c_nodes))
 +true_circ_avg[cl] = sum(map(lambda n: (1.0-n.circ_fail_rate),
   c_nodes))/float(len(c_nodes))
 +  else:
 +true_filt_avg[cl] = 0.0
 +true_strm_avg[cl] = 0.0
 +true_circ_avg[cl] = 0.0

# FIXME: This may be expensive
pid_tgt_avg[cl] = true_filt_avg[cl]
 @@ -835,10 +840,13 @@ def main(argv):
  c_nodes = filter(lambda n: n.node_class() == cl, nodes.itervalues())
  nc_nodes = filter(lambda n: n.pid_error < 0, c_nodes)
  pc_nodes = filter(lambda n: n.pid_error > 0, c_nodes)
 -plog("INFO", "Avg "+cl+"  pid_error="+str(sum(map(lambda n:
 n.pid_error, c_nodes))/len(c_nodes)))
 -plog("INFO", "Avg "+cl+" |pid_error|="+str(sum(map(lambda n:
 abs(n.pid_error), c_nodes))/len(c_nodes)))
 -plog("INFO", "Avg "+cl+" +pid_error=+"+str(sum(map(lambda n:
 n.pid_error, pc_nodes))/len(pc_nodes)))
 -plog("INFO", "Avg "+cl+" -pid_error="+str(sum(map(lambda n:
 n.pid_error, nc_nodes))/len(nc_nodes)))
 +if len(c_nodes) > 0:
 +  plog("INFO", "Avg "+cl+"  pid_error="+str(sum(map(lambda n:
 n.pid_error, c_nodes))/len(c_nodes)))
 +  plog("INFO", "Avg "+cl+" |pid_error|="+str(sum(map(lambda n:
 abs(n.pid_error), c_nodes))/len(c_nodes)))
 +if len(pc_nodes) > 0:
 +  plog("INFO", "Avg "+cl+" +pid_error=+"+str(sum(map(lambda n:
 n.pid_error, pc_nodes))/len(pc_nodes)))
 +if len(nc_nodes) > 0:
 +  plog("INFO", "Avg "+cl+" -pid_error="+str(sum(map(lambda n:
 n.pid_error, nc_nodes))/len(nc_nodes)))

n_nodes = filter(lambda n: n.pid_error < 0, nodes.itervalues())
p_nodes = filter(lambda n: n.pid_error > 0, nodes.itervalues())
 }}}

 We could fix this by guarding every division by a length with a check.
 Refactoring would make this much easier.

--
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] #20466 [Metrics/Torflow]: Replacing python path sometimes breaks bwauths

2016-10-25 Thread Tor Bug Tracker & Wiki

#20466: Replacing python path sometimes breaks bwauths
-+
 Reporter:  teor |  Owner:  aagbsn
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Torflow  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 When I let run_scan.sh replace my python path, the script can't find
 necessary libraries. When I prepend instead, it works.

 I'm not sure whether this means my pip / python install is broken, or the
 bwauth code is.

--
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] #20451 [Obfuscation/meek]: The communication stream of managed proxy '/usr/bin/meek-client' is 'closed'

2016-10-25 Thread Tor Bug Tracker & Wiki

#20451: The communication stream of managed proxy '/usr/bin/meek-client' is
'closed'
--+-
 Reporter:  tagener-noisu |  Owner:  dcf
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by dcf):

 You might have to report this bug to the maintainer of the AUR package.

 What do you get when you run this command?
 {{{
 TOR_PT_MANAGED_TRANSPORT_VER=1 TOR_PT_CLIENT_TRANSPORTS=meek /usr/bin
 /meek-client --log meek-client.log
 }}}

 It should produce on the terminal:
 {{{
 VERSION 1
 CMETHOD meek socks5 127.0.0.1:38561
 CMETHODS DONE
 }}}

 meek-client.log should contain at least:
 {{{
 2016/10/25 15:42:28 listening on 127.0.0.1:38561
 }}}

 (Of course the port number may be different.)

--
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] #20431 [Core Tor/DirAuth]: do not recommend vulnerable tor versions - update "recommended versions"

2016-10-25 Thread Tor Bug Tracker & Wiki

#20431: do not recommend vulnerable tor versions - update "recommended versions"
--+--
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Is that done even if dir auths disagree? (which is the case here)
 https://consensus-health.torproject.org/#recommendedversions

--
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] #20431 [Core Tor/DirAuth]: do not recommend vulnerable tor versions - update "recommended versions"

2016-10-25 Thread Tor Bug Tracker & Wiki

#20431: do not recommend vulnerable tor versions - update "recommended versions"
--+--
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

 * status:  closed => reopened
 * resolution:  implemented =>


Comment:

 Hrm I see that we've reached consensus on those but this hasn't been
 pushed to dirauth-conf git repository. Can a dirauth do that?

--
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] #20384 [Core Tor/Tor]: TROVE-2016-10-001: out-of-bounds read on buffer chunks

2016-10-25 Thread Tor Bug Tracker & Wiki

#20384: TROVE-2016-10-001: out-of-bounds read on buffer chunks
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  closed
 Priority:  Very High |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by cypherpunks):

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


--
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] #20431 [Core Tor/DirAuth]: do not recommend vulnerable tor versions - update "recommended versions"

2016-10-25 Thread Tor Bug Tracker & Wiki

#20431: do not recommend vulnerable tor versions - update "recommended versions"
--+-
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by cypherpunks):

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


Comment:

 I'm surprised you even removed the latest shipped tor in current TBB
 (there is no TBB with tor v0.2.8.9 yet) but so be it.

 New consensus is:
 {{{
 consensus
 client-versions 0.2.5.12, 0.2.7.6, 0.2.8.9, 0.2.9.4-alpha
 server-versions 0.2.5.12, 0.2.7.6, 0.2.8.9, 0.2.9.4-alpha
 }}}

 Ever TBB user will get a warning in now?


 This ticket is implemented.

--
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] #20465 [User Experience/Website]: Call it Tor Browser, not "The Tor Browser"

2016-10-25 Thread Tor Bug Tracker & Wiki

#20465: Call it Tor Browser, not "The Tor Browser"
-+-
 Reporter:  arthuredelstein  |  Owner:  arthuredelstein
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 Here's a proposed patch for review:
 https://github.com/arthuredelstein/webml/commit/20465

--
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] #20465 [User Experience/Website]: Call it Tor Browser, not "The Tor Browser"

2016-10-25 Thread Tor Bug Tracker & Wiki

#20465: Call it Tor Browser, not "The Tor Browser"
-+-
 Reporter:  arthuredelstein  |  Owner:  arthuredelstein
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 The website is inconsistent about this. I would suggest just calling it
 "Tor Browser". Just as it's not longer "The Facebook".

--
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] #19459 [Applications/Tor Browser]: Write (C++) patch for window resizing parts

2016-10-25 Thread Tor Bug Tracker & Wiki

#19459: Write (C++) patch for window resizing parts
-+-
 Reporter:  gk   |  Owner:
 |  arthuredelstein
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton-conversion,|  Actual Points:
  TorBrowserTeam201610   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-
Changes (by arthuredelstein):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:30 gk]:
 > The second part of comment:26 seems still to be unaddressed, no? I.e.
 let's keep the multiple of 200x100 for now and decide in a separate bug if
 we need to adjust that and if so how.

 Sorry! I had misinterpreted your comment. My mistake in any case. Here's
 the new version.
 https://github.com/arthuredelstein/tor-browser/commit/19459+12

--
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] #19459 [Applications/Tor Browser]: Write (C++) patch for window resizing parts

2016-10-25 Thread Tor Bug Tracker & Wiki

#19459: Write (C++) patch for window resizing parts
-+-
 Reporter:  gk   |  Owner:
 |  arthuredelstein
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton-conversion,|  Actual Points:
  TorBrowserTeam201610   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorU
-+-
Changes (by gk):

 * keywords:  tbb-torbutton-conversion, TorBrowserTeam201610R => tbb-
 torbutton-conversion, TorBrowserTeam201610
 * status:  needs_review => needs_revision


Comment:

 The second part of comment:26 seems still to be unaddressed, no? I.e.
 let's keep the multiple of 200x100 for now and decide in a separate bug if
 we need to adjust that and if so how.

--
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] #20464 [- Select a component]: Consensus-Health vote_data table gets out of date when a dirauth is added

2016-10-25 Thread Tor Bug Tracker & Wiki

#20464: Consensus-Health vote_data table gets out of date when a dirauth is 
added
--+-
 Reporter:  tom   |  Owner:  tom
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-


--
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] #20463 [User Experience/Translations]: Translate the download page

2016-10-25 Thread Tor Bug Tracker & Wiki

#20463: Translate the download page
--+-
 Reporter:  arthuredelstein   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  User Experience/Translations  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by arthuredelstein):

 * cc: phoul (added)
 * component:  User Experience/Website => User Experience/Translations


--
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] #20463 [User Experience/Website]: Translate the download page

2016-10-25 Thread Tor Bug Tracker & Wiki

#20463: Translate the download page
-+-
 Reporter:  arthuredelstein  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Let's create localizations for the primary Tor Browser download page
 (download-easy.html). We don't have to localize the whole website, but
 this would be a good start. It would default to download the browser with
 the same locale. And it will make it easier for people to share on social
 media.

--
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] #20114 [Applications/Tor Check]: Tor Browser v6.0.4 on Linux reported that exiting via node 162.243.117.41 was "not connected through tor" on check.torproject.org

2016-10-25 Thread Tor Bug Tracker & Wiki

#20114: Tor Browser v6.0.4 on Linux reported that exiting via node 
162.243.117.41
was "not connected through tor" on check.torproject.org
+-
 Reporter:  6h72Q484AddGha8H|  Owner:  arlolra
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Check  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by cypherpunks):

 Again today:
 {{{
  Sorry. You are not using Tor.
 Your IP address appears to be: 45.55.164.171
 }}}

 Known exits with this IP:
 https://atlas.torproject.org/#details/D383A17C97EEA50B820FE0F5D60DA2D436535AE6
 https://atlas.torproject.org/#details/FD5E1C921C2ED9A8428BBEED9179C6C8BB4E7E4A

--
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] #20442 [Applications/Tor Browser]: Backport fix for CVE-2016-5279: local path disclosure after drag and drop (bug 1249522)

2016-10-25 Thread Tor Bug Tracker & Wiki

#20442: Backport fix for CVE-2016-5279: local path disclosure after drag and 
drop
(bug 1249522)
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  TorBrowserTeam201610R,   |  Actual Points:
  GeorgKoppen201610  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  TorBrowserTeam201610, GeorgKoppen201610 =>
 TorBrowserTeam201610R, GeorgKoppen201610
 * status:  new => needs_review


Comment:

 bug_20442 (https://gitweb.torproject.org/user/gk/tor-
 browser.git/log/?h=bug_20442) in my public tor-browser repo has the
 backport up for review (three patches). I built it for all three platforms
 and tested the Linux variant.

--
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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-25 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Replying to [comment:85 iwakeh]:
 > Please find four more commits on
 [https://gitweb.torproject.org/user/iwakeh/collector.git/?h=task-18910
 -release-prep the above branch] addressing
 >
 > * the microcons-path
 > * the sync history files
 > * and the storage.

 Looks good, merged to master!

 > For the latter I added a PersistenceUtils test class and corrected the
 behavior you described in an earlier comment:80 (will the comment count
 reach 100 here ;-)
 >
 > Thanks for looking so carefully through all the code!

 Sure!  I'll start a new test and let it run tonight.

--
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] #20462 [Core Tor/Tor]: Make test failures/bugs on Raspberry Pi 3

2016-10-25 Thread Tor Bug Tracker & Wiki

#20462: Make test failures/bugs on Raspberry Pi 3
--+
 Reporter:  cypherpunks   |  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:|
--+
 Three test failures and some [warn] bugs on a raspberry pi 3 (Raspbian):

 control/rend_service_parse_port_config:
   FAIL src/test/test_controller.c:190: assert(!cfg)
   [rend_service_parse_port_config FAILED]

 options/validate__authdir: [forking]
   FAIL src/test/test_options.c:660: assert(msg OP_EQ "Failed to
 resolve/guess local address. See logs for" " details."): <> vs
 
   [validate__authdir FAILED]

 util/socketpair_ersatz: [forking]
   FAIL src/test/test_util.c:5188: assert(0 OP_EQ socketpair_result): 0 vs
 -111
   [socketpair_ersatz FAILED]


 util/time: Oct 25 18:17:48.092 [warn] tor_timegm(): Bug: Result does not
 fit in tor_timegm (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
 Oct 25 18:17:48.093 [warn] tor_timegm(): Bug: Result does not fit in
 tor_timegm (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
 Oct 25 18:17:48.093 [warn] tor_timegm(): Bug: Result does not fit in
 tor_timegm (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)
 OK
 util/parse_http_time: Oct 25 18:17:48.093 [warn] tor_timegm(): Bug: Result
 does not fit in tor_timegm (on Tor 0.2.9.4-alpha 8b0755c9bb296ae2)

 I've attached the buildlog - gcc -v:

 Using built-in specs.
 COLLECT_GCC=gcc
 COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.9/lto-wrapper
 Target: arm-linux-gnueabihf
 Configured with: ../src/configure -v --with-pkgversion='Raspbian 4.9.2-10'
 --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-
 languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-
 suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib
 --without-included-gettext --enable-threads=posix --with-gxx-include-
 dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/
 --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
 --enable-gnu-unique-object --disable-libitm --disable-libquadmath
 --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-
 awt=gtk --enable-gtk-cairo --with-java-
 home=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf/jre --enable-java-home --with-
 jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf --with-jvm-jar-
 dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-armhf --with-arch-
 directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-
 objc-gc --enable-multiarch --disable-sjlj-exceptions --with-arch=armv6
 --with-fpu=vfp --with-float=hard --enable-checking=release --build=arm-
 linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
 Thread model: posix
 gcc version 4.9.2 (Raspbian 4.9.2-10)

--
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] #20460 [Core Tor/Tor]: tortls test failures with recent LibreSSL (OpenBSD -current)

2016-10-25 Thread Tor Bug Tracker & Wiki

#20460: tortls test failures with recent LibreSSL (OpenBSD -current)
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.0-alpha-dev
 Severity:  Normal| Resolution:
 Keywords:  libressl openbsd  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by yawning):

 * milestone:   => Tor: 0.3.0.x-final


Comment:

 This is probably a backport candidate to all supported stable releases.

--
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] #20460 [Core Tor/Tor]: tortls test failures with recent LibreSSL (OpenBSD -current)

2016-10-25 Thread Tor Bug Tracker & Wiki

#20460: tortls test failures with recent LibreSSL (OpenBSD -current)
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.0-alpha-dev
 Severity:  Normal| Resolution:
 Keywords:  libressl openbsd  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by yawning):

 * cc: yawning (added)


--
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] #19142 [Core Tor/Tor]: Remove the environ configure check

2016-10-25 Thread Tor Bug Tracker & Wiki

#19142: Remove the environ configure check
-+
 Reporter:  cypherpunks  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Trivial  | Resolution:
 Keywords:  review-group-10  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cypherpunks):

 This ticket has been stuck on the following section.
 > If someone could give the reasoning why FreeBSD requires declaring
 environ that would be helpful because i don't have a FreeBSD machine and
 cannot test it myself.

 IMO the environ configure can be removed because nobody has given reasons
 for it being necessary and all the documentation says it is defined by
 default.

--
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] #20458 [Core Tor/Tor]: Integration tests should be run locally before committing code changes

2016-10-25 Thread Tor Bug Tracker & Wiki

#20458: Integration tests should be run locally before committing code changes
--+
 Reporter:  chelseakomlo  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  test, doc |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 Replying to [ticket:20458 chelseakomlo]:
 > Two changes could help with this:
 > 1. Adding this information to documentation for contributors
 There is already documentation in
 
[https://gitweb.torproject.org/tor.git/tree/doc/HACKING/CodingStandards.md?id=01482e30ad8a453f3721ef17a4a9633806b90684#n12
 CodingStandards.md].
 > 2. Adding a make task that runs all necessary tasks before contributing
 new code
 `make check` is the default target for running tests so I'd move every
 test under this target. This will also make the jenkins builds run these
 tests automatically, making catching issues easier. I would even go
 further and encourage people to run `make distcheck` which tests whether
 the distribution works (see
 https://www.gnu.org/software/automake/manual/automake.html#Checking-the-
 Distribution).

 Lastly, integrating `make check-spaces` into the distribution process has
 also been discussed in #5500.

--
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] #20461 [Applications/Tor Browser]: Ship “static cache” of intermediate CAs

2016-10-25 Thread Tor Bug Tracker & Wiki

#20461: Ship “static cache” of intermediate CAs
--+--
 Reporter:  nicoo |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nicoo):

 * cc: nicoo (added)


--
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] #20461 [Applications/Tor Browser]: Ship “static cache” of intermediate CAs

2016-10-25 Thread Tor Bug Tracker & Wiki

#20461: Ship “static cache” of intermediate CAs
--+--
 Reporter:  nicoo |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nicoo):

 Log of the (asynchronous) discussion about this on Mozilla/#security:

 {{{
 12:55:46   ⤷ │ ulfr: I wanted to enquire about using TLS
 Observatory data to find
  │ specific misconfigurations (typically, incomplete
 cert chains) that lead
  │ to cert errors in Tor Browser (which doesn't cache
 subCAs, since that ca
  │ be used as a supercookie), and check if some Tor
 exit nodes (ab)use that
  │ for stealthy MitM
 12:56:56 freddyb │ (that's interesting. what wold also be interesting:
 a prepopulated subCA
  │ cache)
 12:57:09   nicoo │ freddyb: Oooh, great idea
 12:57:47   ⤷ │ And TLS Obs data should have the most popular-
 amongst-broken-servers
  │ subCAs
 12:57:57   ⤷ │ (Let's Encrypt, anyone?)
 13:02:03 │ nicoo hilights GeKo, as it is topically relevant
 13:02:15   nicoo │ GeKo: Does this sound like a good/sane idea ?
 14:27:43ulfr │ nicoo: I don't capture that data directly (that
 would require a bit of
  │ code to detect missing intermediates), but I can
 query for certs issued
  │ by valid intermediates that have not passed
 validation.
 14:28:17   ⤷ │ the query gets a bit complicated though
 18:01:35GeKo │ nicoo: why not? might be interesting to look at the
 data.
 19:47:43   nicoo │ GeKo: I was more asking about pre-seeding the TBB
 with a intermediary CA
  │ “cache” to avoid spurious cert validation errors
 with incomplete chains
  │ (and avoid letting users get used to clicking
 through those)
 19:54:20ulfr │ or just automate intermediate retrieval using the
 AIA extension
 20:24:41   nicoo │ ulfr: Wouldn't that be slow, without caching?
 20:25:12   ⤷ │ (And with caching, I would assume the timing
 sidechannel can be used as a
  │ supercookie)
 20:39:13   Peng_ │ Downloading an intermediate or two would be kind of
 slow -- especially
  │ over Tor -- but "untrusted issuer" error pages are
 infinity slow.
 20:39:52   ⤷ │ Without caching? That sounds painful.
 20:40:13   nicoo │ Peng_: And they teach users terrible security
 practices, hence why I want
  │ to do something about it
 20:40:15   ⤷ │ :V
 20:46:35ulfr │ there something to be said for not encouraging bad
 practices
 20:46:47   ⤷ │ admins should learn to serve intermediates
 20:49:18   nicoo │ ulfr: Yes, but I doubt that the TBB userbase is
 large enough to push
  │ non-broken practices
 20:49:50   nicoo │ OTOH, not “fixing” it (from a user perspective)
 seems like a security
  │ issue to me.
 20:49:44   Peng_ │ If Firefox were changed to hard fail instead of
 accepting
  │ misconfiguration when the intermediate is already
 cached... ;-)
 20:50:41   Peng_ │ Firefox is already being semi-forgiving and semi-
 encouraging bad
  │ practices. But TBB can't afford to cache as
 generously and is getting the
  │ short end of the stick.
 -- Tue, 25 Oct 2016 --
 06:39:36GeKo │ nicoo: oh, okay. file a ticket on trac and get the
 discussion going?
 06:39:54   ⤷ │ it seems worthwhile to think about
 }}}

--
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] #20461 [Applications/Tor Browser]: Ship “static cache” of intermediate CAs

2016-10-25 Thread Tor Bug Tracker & Wiki

#20461: Ship “static cache” of intermediate CAs
--+--
 Reporter:  nicoo |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 TBB produces certificate validation errors on incomplete certificate
 chains, which may “somewhat work” on other browsers due to intermediary
 CAs being present in caches.

 This is problematic, as this leads users to expect certificate errors on
 certain sites and simply click-through, effectively teaching them terrible
 security practices.

 We could ship, with TBB, a builtin list of “cached” intermediate CAs that
 are prevalent among misconfigured servers. This data can be obtained from
 TLS Observatory's data, according to ulfr.

--
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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-25 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Please find four more commits on
 [https://gitweb.torproject.org/user/iwakeh/collector.git/?h=task-18910
 -release-prep the above branch] addressing

 * the microcons-path
 * the sync history files
 * and the storage.

 For the latter I added a PersistenceUtils test class and corrected the
 behavior you described in an earlier comment:80 (will the comment count
 reach 100 here ;-)

 Thanks for looking so carefully through all the code!

--
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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-25 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Addendum to the hist-file topic:
 The added string from the path is just a work-around.  There should be
 different interfaces for consensus flavors (#17861 and #19640) before
 there are too many flavors.

--
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] #19142 [Core Tor/Tor]: Remove the environ configure check

2016-10-25 Thread Tor Bug Tracker & Wiki

#19142: Remove the environ configure check
-+
 Reporter:  cypherpunks  |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Trivial  | Resolution:
 Keywords:  review-group-10  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by asn):

 * status:  needs_review => new


Comment:

 I don't actually see a patch here to review. Am I missing something? Let's
 turn it to `needs_review` when there is one?

--
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] #19642 [Core Tor/Tor]: Add a descriptor line for Single Onion Services

2016-10-25 Thread Tor Bug Tracker & Wiki

#19642: Add a descriptor line for Single Onion Services
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, rsos, sos, prop224,  |  Actual Points:
  TorCoreTeam201610, proposal|
Parent ID:  #17238   | Points:  0.5
 Reviewer:   |Sponsor:
 |  SponsorR-can
-+-
Changes (by asn):

 * status:  needs_review => new


Comment:

 (Switching this to new as tor.git patch is also required)

--
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] #20459 [Core Tor/Tor]: ewma_cmp_cmux never considers policies different

2016-10-25 Thread Tor Bug Tracker & Wiki

#20459: ewma_cmp_cmux never considers policies different
--+
 Reporter:  pastly|  Owner:
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.6.2-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by pastly):

 * status:  merge_ready => needs_review


Comment:

 FWIW, I've watched the order the scheduler picks channels. A few months
 ago, based on memory, the scheduler would pick channels in an order
 something like this:

 3, 2, 5, 3, 2, 5, 3, 2, 3, 2, 3, 2, 3, 3, 3, 3

 With this fix, it picks channels in an order something like this:

 11, 7, 7, 1, 1, 1, 1, 1

 I encourage us to verify the before behavior as memory <<< logs.

 Of course, this tells us nothing about how circuits are picked within a
 channel, which is very important.

 I'm moving this out of merge_ready because I think we have too many
 questions right now. Hopefully needs_review is a more accurate
 description.

--
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] #20460 [Core Tor/Tor]: tortls test failures with recent LibreSSL (OpenBSD -current)

2016-10-25 Thread Tor Bug Tracker & Wiki

#20460: tortls test failures with recent LibreSSL (OpenBSD -current)
--+
 Reporter:  rubiate   |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.0-alpha-dev
 Severity:  Normal|   Keywords:  libressl openbsd
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Some tortls tests will segfault with recent LibreSSL

 {{{
 tortls/classify_client_ciphers: [forking] [Lost connection!]
   [classify_client_ciphers FAILED]
 tortls/client_is_using_v2_ciphers: [forking] [Lost connection!]
   [client_is_using_v2_ciphers FAILED]
 [...]
 tortls/session_secret_cb: [forking] [Lost connection!]
   [session_secret_cb FAILED]
 }}}

 The tests all do something like this:

   one = get_cipher_by_name("ECDH-RSA-AES256-GCM-SHA384");
   one->id = 0x00ff;

 The problem is LibreSSL has removed support for ECDH ciphers
 (https://marc.info/?l=openbsd-cvs=147689515531541=2), so
 get_cipher_by_name() returns NULL.

 This isn't in any released LibreSSL version yet but is in OpenBSD
 -current.

--
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] #20459 [Core Tor/Tor]: ewma_cmp_cmux never considers policies different

2016-10-25 Thread Tor Bug Tracker & Wiki

#20459: ewma_cmp_cmux never considers policies different
--+
 Reporter:  pastly|  Owner:
 Type:  defect| Status:  merge_ready
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.6.2-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  new => merge_ready


Comment:

 lgtm; There could be an argument for "Major bugfixes" in the change file
 but I let that to nickm :). Thanks 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

Re: [tor-bugs] #20459 [Core Tor/Tor]: ewma_cmp_cmux never considers policies different

2016-10-25 Thread Tor Bug Tracker & Wiki

#20459: ewma_cmp_cmux never considers policies different
--+
 Reporter:  pastly|  Owner:
 Type:  defect| Status:  merge_ready
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.6.2-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:5 dgoulet]:
 > Oh and consider backporting probably?

 Not for a performance issue, surely?

 I could see an argument for a backport to 0.2.9, but that would risk
 destabilising the whole 0.2.9 series.

 Since we've never actually run much of this code, it could do anything. It
 could be broken in other ways.

--
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] #20459 [Core Tor/Tor]: ewma_cmp_cmux never considers policies different

2016-10-25 Thread Tor Bug Tracker & Wiki

#20459: ewma_cmp_cmux never considers policies different
--+
 Reporter:  pastly|  Owner:
 Type:  defect| Status:  merge_ready
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.6.2-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Oh and consider backporting probably?

--
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] #20459 [Core Tor/Tor]: ewma_cmp_cmux never considers policies different

2016-10-25 Thread Tor Bug Tracker & Wiki

#20459: ewma_cmp_cmux never considers policies different
--+--
 Reporter:  pastly|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by pastly):

 [https://github.com/pastly/public-tor/tree/ticket20459 branch here]

--
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] #20459 [Core Tor/Tor]: ewma_cmp_cmux never considers policies different

2016-10-25 Thread Tor Bug Tracker & Wiki

#20459: ewma_cmp_cmux never considers policies different
--+
 Reporter:  pastly|  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.6.2-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * priority:  Medium => High
 * version:  Tor: unspecified => Tor: 0.2.6.2-alpha
 * milestone:   => Tor: 0.3.0.x-final


--
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] #20458 [Core Tor/Tor]: Integration tests should be run locally before committing code changes

2016-10-25 Thread Tor Bug Tracker & Wiki

#20458: Integration tests should be run locally before committing code changes
--+
 Reporter:  chelseakomlo  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  test, doc |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 We should also make the docs as well.
 But because they're slow, many of us configure without asciidoc.

--
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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-25 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Replying to [comment:83 iwakeh]:
 > Replying to [comment:81 iwakeh]:
 > > Replying to [comment:79 karsten]:
 > > > First bug report: configuration property `"ExitlistSources"` is
 disregarded.  I believe we're looking at the non-existent property
 `"ExitlistsSources"` (plural).
 > >
 > > Good catch!  I'll work on a patch and a test preventing this in
 future.
 >
 > Here is
 [https://gitweb.torproject.org/user/iwakeh/collector.git/commit/?h=task-18910
 -release-prep=b8386ce0e39aeadff82bdb9bc155ad6e69c23ec7 the branch] with
 a patch and test.  Please review.

 Looks good.  Merged to master!

--
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] #20459 [Core Tor/Tor]: ewma_cmp_cmux never considers policies different

2016-10-25 Thread Tor Bug Tracker & Wiki

#20459: ewma_cmp_cmux never considers policies different
--+--
 Reporter:  pastly|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Wow, that's awkward.
 Thanks for finding this.
 We should add some unit tests to make sure that we don't regress.

--
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] #20440 [Metrics/metrics-lib]: endless wait in BlockingIteratorImpl

2016-10-25 Thread Tor Bug Tracker & Wiki

#20440: endless wait in BlockingIteratorImpl
-+-
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 Ah fix does work! Thanks a lot 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

Re: [tor-bugs] #20458 [Core Tor/Tor]: Integration tests should be run locally before committing code changes

2016-10-25 Thread Tor Bug Tracker & Wiki

#20458: Integration tests should be run locally before committing code changes
--+
 Reporter:  chelseakomlo  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  test, doc |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * keywords:   => test, doc
 * component:  - Select a component => Core Tor/Tor
 * milestone:   => Tor: 0.3.0.x-final


--
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] #20459 [Core Tor/Tor]: ewma_cmp_cmux never considers policies different

2016-10-25 Thread Tor Bug Tracker & Wiki

#20459: ewma_cmp_cmux never considers policies different
--+--
 Reporter:  pastly|  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Looks like a copy/paste bug from
 [https://gitweb.torproject.org/tor.git/commit/?id=700d6e75 700d6e75]. See
 
[https://gitweb.torproject.org/tor.git/tree/src/or/circuitmux_ewma.c?id=01482e30ad8a453f3721ef17a4a9633806b90684#n502
 line 502].

 The earliest branches I see this commit in are {maint,release}-0.2.6.

 Branch incoming once I get a ticket number.

--
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] #20458 [- Select a component]: Integration tests should be run locally before committing code changes

2016-10-25 Thread Tor Bug Tracker & Wiki

#20458: Integration tests should be run locally before committing code changes
--+-
 Reporter:  chelseakomlo  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Currently, it is easy to submit a patch for code changes without first
 running integration tests locally.

 Two changes could help with this:
 1. Adding this information to documentation for contributors
 2. Adding a make task that runs all necessary tasks before contributing
 new code, which are:

 `make check-spaces`
 `make check .`
 `make test-network-all`

 We should investigate how to handle:
 - Someone not having have chutney
 - Someone not having the necessary network connection for integration
 tests to succeed
 - If chutney tests fail because of flakiness (race conditions for example)
 rather than legitimate failures.

--
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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-25 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Replying to [comment:81 iwakeh]:
 > Replying to [comment:79 karsten]:
 > > First bug report: configuration property `"ExitlistSources"` is
 disregarded.  I believe we're looking at the non-existent property
 `"ExitlistsSources"` (plural).
 >
 > Good catch!  I'll work on a patch and a test preventing this in future.

 Here is
 [https://gitweb.torproject.org/user/iwakeh/collector.git/commit/?h=task-18910
 -release-prep=b8386ce0e39aeadff82bdb9bc155ad6e69c23ec7 the branch] with
 a patch and test.  Please review.

--
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] #20380 [Metrics/CollecTor]: Expand INSTALL.md to a more complete operator's guide

2016-10-25 Thread Tor Bug Tracker & Wiki

#20380: Expand INSTALL.md to a more complete operator's guide
---+-
 Reporter:  karsten|  Owner:
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Replying to [comment:8 iwakeh]:
 > Thanks for the start here!

 Thanks for looking! :)

 > Please see some suggestions
 
[https://gitweb.torproject.org/user/iwakeh/collector.git/commit/?h=task-20380-install=87e81a64517986571e5f47c99c9bbb52d3ced749
 here] based on your file.

 A few thoughts:

  - When you say that closer monitoring will be needed when disk space
 drops below a given number, do you mean 200G or 20G or a different number?

  - We shouldn't add new section headers easily.  The chosen section
 headers and even paragraphs in this document (will) have equivalents in
 the other operator's guides for other metrics tools.  If we want to add
 new sections, we'll also have to add those sections to the other manuals.
 The current sections are:

 {{{
 $ grep "^#" INSTALL.md
 # CollecTor Operator's Guide
 ## Setting up the host
 ## Setting up the service
 ## Maintaining the service
 }}}

  - (continued) What other sections or even subsections should we include,
 and what instructions would go into those vs. the existing sections?

 > The idea behind my changes is that I think the service shouldn't be run
 from the unpacked tar
 > folder.  The tar contains a development environment, so the jar would
 disappear after 'ant clean' or changed etc.
 > The runtime directory should only contain files that are really
 necessary for the application or which were created by the application.
 > Hope this doesn't make the description too complicated.

 Yes, makes sense, let's change that.  There are still a few paths left
 where we refer to files in `collector-/` and where we should tell
 the user to copy those files to the working directory and run them from
 there.  I can update those places.

 > I also would like have even less description of tools from the OS,
 because such things should be decided by the operator.

 Which parts would that include?  The crontab, `@reboot`, `screen`, etc.?
 Can you make a list?

 Again, thanks for the review!

--
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] #20451 [Obfuscation/meek]: The communication stream of managed proxy '/usr/bin/meek-client' is 'closed'

2016-10-25 Thread Tor Bug Tracker & Wiki

#20451: The communication stream of managed proxy '/usr/bin/meek-client' is
'closed'
--+-
 Reporter:  tagener-noisu |  Owner:  dcf
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by tagener-noisu):

 Replying to [comment:1 yawning]:
 > Why are you using that anyway?  From the PKGBUILD it's running helper-
 less so it's going to be blatantly obvious that it's a meek client.
 Using what?

--
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] #20427 [Applications/Tor Browser]: Could not connect to TOR Control Port

2016-10-25 Thread Tor Bug Tracker & Wiki

#20427: Could not connect to TOR Control Port
--+---
 Reporter:  Dad   |  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 gk):

 Weird that you are not getting any debug output. Let's try it a bit
 differently. Could you download the standalone bundle:

 https://dist.torproject.org/torbrowser/6.0.5/tor-win32-0.2.8.7.zip
 https://dist.torproject.org/torbrowser/6.0.5/tor-win32-0.2.8.7.zip.asc

 and copy the tor.exe from there over the one in your Tor Browser? The
 latter is located in path\to\Tor Browser\Browser\TorBrowser\Tor.

 If you now start Tor Browser you should see minimal debug output (like
 that Tor gets started etc.) in a console window popping up. Could you give
 us that log? Maybe we can spot the issue already there. You can try the
 thing that mcs said above (adjusting your paths, of course) and add the
 log line:
 `Log debug stdout` which should give you lots of output in the console
 window (in fact it might give you too much but I am not sure). If that
 works there is something else that went wrong while using tor's logging
 capabilities which we then can sort out.

 Thanks for your patience and help.

--
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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-25 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Here's another one.  The path for microdescriptor consensuses is wrong,
 which leads to us not syncing any of those:

 {{{
 diff --git
 a/src/main/java/org/torproject/collector/relaydescs/ArchiveWriter.java
 b/src/main/java/org/torproject/collector/relaydescs/ArchiveWriter.java
 index 30b6569..20d0663 100644
 --- a/src/main/java/org/torproject/collector/relaydescs/ArchiveWriter.java
 +++ b/src/main/java/org/torproject/collector/relaydescs/ArchiveWriter.java
 @@ -99,7 +99,7 @@ public class ArchiveWriter extends CollecTorMain {
  this.mapPathDescriptors.put("recent/relay-descriptors/consensuses",
  RelayNetworkStatusConsensus.class);
  this.mapPathDescriptors.put(
 -"relay-descriptors/microdescs/consensus-microdesc",
 +"recent/relay-descriptors/microdescs/consensus-microdesc",
  RelayNetworkStatusConsensus.class);
  this.mapPathDescriptors.put("recent/relay-descriptors/server-
 descriptors",
  RelayServerDescriptor.class);
 }}}

 Related to this, I believe that we'd use `sync/sync-history-
 collector.torproject.org-Relay-RelayNetworkStatusConsensus` for the parse
 history, which would be the exact same file as for unflavored consensuses.
 We should use a different parse history file here.

--
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] #20457 [Metrics/Torflow]: Turn pathbias off in bwauth tors

2016-10-25 Thread Tor Bug Tracker & Wiki

#20457: Turn pathbias off in bwauth tors
-+
 Reporter:  teor |  Owner:  aagbsn
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Torflow  |Version:
 Severity:  Normal   |   Keywords:  easy
Actual Points:   |  Parent ID:
   Points:  0.2  |   Reviewer:
  Sponsor:   |
-+
 When running the bandwidth scanner with recent tor versions, the pathbias
 detector complains about circuit state at notice level.
 This could quickly fill the logs.

 I suggest we add this to the bottom of tor.1/torrc and tor.2/torrc:
 {{{
 # Turn pathbias off, so it doesn't flood the logs
 UseEntryGuards 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] #20455 [Metrics/Torflow]: bwauth cron scripts need to be run in the BwAuthority directory

2016-10-25 Thread Tor Bug Tracker & Wiki

#20455: bwauth cron scripts need to be run in the BwAuthority directory
-+
 Reporter:  teor |  Owner:  aagbsn
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Torflow  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy |  Actual Points:
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+

Comment (by teor):

 (See #20456 for the relevant tor bug)

--
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] #20456 [Core Tor/Tor]: Relative paths don't work for PidFile and control_auth_cookie

2016-10-25 Thread Tor Bug Tracker & Wiki

#20456: Relative paths don't work for PidFile and control_auth_cookie
--+--
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.9
 Severity:  Normal|   Keywords:  regression?
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 When I use relative paths in my torrc, tor tells me what it will use for
 the PidFile, and then claims it can't find it.
 It also has a similar issue with a relative data directory and
 control_auth_cookie.

 {{{
 Oct 25 11:24:12.784 [warn] Path for PidFile (./data/tor.2/tor.pid) is
 relative and will resolve to
 /home/ubuntu/bwauth/torflow/NetworkScanners/BwAuthority/./data/tor.2/tor.pid.
 Is this what you wanted?
 ...
 Oct 25 11:24:12.000 [warn] Unable to open "./data/tor.2/tor.pid" for
 writing: No such file or directory
 Oct 25 11:24:12.000 [warn] Couldn't open
 "./data/tor.2/control_auth_cookie.tmp" (./data/tor.2/control_auth_cookie)
 for writing: No such file or directory
 }}}

--
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] #20221 [Applications/Tor Browser]: Hardened Tor Browser does not produce stack traces.

2016-10-25 Thread Tor Bug Tracker & Wiki

#20221: Hardened Tor Browser does not produce stack traces.
--+--
 Reporter:  mikeperry |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Some notes before I forget them:

 1) This is not selfrando related but happens with a normal ASan build done
 in our Gitian environment as well
 2) Not stripping the binaries solves the problem
 3) Building the code locally and stripping it works fine
 4) Stripping the Gitian build results locally breaks, too

--
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] #20455 [Metrics/Torflow]: bwauth cron scripts need to be run in the BwAuthority directory

2016-10-25 Thread Tor Bug Tracker & Wiki

#20455: bwauth cron scripts need to be run in the BwAuthority directory
-+
 Reporter:  teor |  Owner:  aagbsn
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Torflow  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy |  Actual Points:
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+

Comment (by teor):

 Not quite, it seems that the relative paths in the torrc files also don't
 work.

--
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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-25 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Replying to [comment:79 karsten]:
 > First bug report: configuration property `"ExitlistSources"` is
 disregarded.  I believe we're looking at the non-existent property
 `"ExitlistsSources"` (plural).

 Good catch!  I'll work on a patch and a test preventing this in future.

--
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] #20295 [Internal Services/Service - git]: Git onion server is down

2016-10-25 Thread Tor Bug Tracker & Wiki

#20295: Git onion server is down
-+
 Reporter:  larsl|  Owner:  tor-gitadm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:  worksforme
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


--
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] #20219 [Internal Services/Tor Sysadmin Team]: Redirect alpha and hardened channels to dist.tpo rather than aus1.tpo

2016-10-25 Thread Tor Bug Tracker & Wiki

#20219: Redirect alpha and hardened channels to dist.tpo rather than aus1.tpo
-+-
 Reporter:  boklm|  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-sandboxing   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by weasel):

 is this still current?

--
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] #20122 [Internal Services/Tor Sysadmin Team]: Create VM for Tor Browser tests

2016-10-25 Thread Tor Bug Tracker & Wiki

#20122: Create VM for Tor Browser tests
-+-
 Reporter:  boklm|  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  user
 |  disappeared
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by weasel):

 * status:  new => closed
 * resolution:   => user disappeared


Comment:

 closing due to lack of feedback.  re-open if you want.

--
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] #20180 [Internal Services/Tor Sysadmin Team]: Pin public keys for aus1.tpo and cdn.tpo

2016-10-25 Thread Tor Bug Tracker & Wiki

#20180: Pin public keys for aus1.tpo and cdn.tpo
-+
 Reporter:  gk   |  Owner:  tpa
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:  #19481   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


Comment:

 added hpkp for cdn and aus1.

--
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] #20396 [Internal Services/Tor Sysadmin Team]: Tor Project crypto signatures will deceive with 32-bit key ids

2016-10-25 Thread Tor Bug Tracker & Wiki

#20396: Tor Project crypto signatures will deceive with 32-bit key ids
-+-
 Reporter:  chadmiller   |  Owner:  tpa
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Critical | Resolution:  invalid
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by weasel):

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


Comment:

 not a sysadmin issue.

--
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] #20455 [Metrics/Torflow]: bwauth cron scripts need to be run in the BwAuthority directory

2016-10-25 Thread Tor Bug Tracker & Wiki

#20455: bwauth cron scripts need to be run in the BwAuthority directory
-+
 Reporter:  teor |  Owner:  aagbsn
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Torflow  |Version:
 Severity:  Normal   |   Keywords:  easy
Actual Points:   |  Parent ID:
   Points:  0.1  |   Reviewer:
  Sponsor:   |
-+
 This can be fixed by adding a cd
 /home/bwauth/torflow/NetworkScanners/BwAuthority before the command.

--
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] #20451 [Obfuscation/meek]: The communication stream of managed proxy '/usr/bin/meek-client' is 'closed'

2016-10-25 Thread Tor Bug Tracker & Wiki

#20451: The communication stream of managed proxy '/usr/bin/meek-client' is
'closed'
--+-
 Reporter:  tagener-noisu |  Owner:  dcf
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by yawning):

 Why are you using that anyway?  From the PKGBUILD it's running helper-less
 so it's going to be blatantly obvious that it's a meek client.

--
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] #20454 [Metrics/Torflow]: Work out why BwAuth setup.sh doesn't work on macOS

2016-10-25 Thread Tor Bug Tracker & Wiki

#20454: Work out why BwAuth setup.sh doesn't work on macOS
-+
 Reporter:  teor |  Owner:  aagbsn
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Torflow  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 When I run the individual steps, they work fine. But the script itself
 seems to exit without producing any output.

--
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] #20453 [Metrics/Torflow]: Update bwauth setup.sh to use tor 0.2.8.9

2016-10-25 Thread Tor Bug Tracker & Wiki

#20453: Update bwauth setup.sh to use tor 0.2.8.9
-+
 Reporter:  teor |  Owner:  aagbsn
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Torflow  |Version:
 Severity:  Normal   |   Keywords:  easy
Actual Points:   |  Parent ID:
   Points:  0.1  |   Reviewer:
  Sponsor:   |
-+
 Currently, the bwauth script uses tor 0.2.6, which is getting pretty old.
 There are performance and security improvements in 0.2.8, so we sould use
 that.

--
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] #20452 [Metrics/Torflow]: macOS and BSD don't support readlink -f in bwauth setup.sh

2016-10-25 Thread Tor Bug Tracker & Wiki

#20452: macOS and BSD don't support readlink -f in bwauth setup.sh
-+
 Reporter:  teor |  Owner:  aagbsn
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Torflow  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:  0.1  |   Reviewer:
  Sponsor:   |
-+
 But plain readlink seems to work just fine.

--
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] #20440 [Metrics/metrics-lib]: endless wait in BlockingIteratorImpl

2016-10-25 Thread Tor Bug Tracker & Wiki

#20440: endless wait in BlockingIteratorImpl
-+-
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by iwakeh):

 With the provided data I could reproduce. And actually it seems that one
 thread is caught in 'wait' not in the while-loop while anything else
 finished already.  The jvm jut waits too and doesn't shutdown.
 The immediate 'cure' is to make the responsible thread a daemon thread
 which works in my test setting.

 Please, use this [https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/commit/?h=task-20440-endless-
 wait=a22d4a400329d4fd0e7b95af05dd5abb012c48e7 branch task-20440
 -endless-wait] for a 'hot-fix'.

 This issue needs some more investigation in order to fix it properly.

--
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] #20451 [Obfuscation/meek]: The communication stream of managed proxy '/usr/bin/meek-client' is 'closed'

2016-10-25 Thread Tor Bug Tracker & Wiki

#20451: The communication stream of managed proxy '/usr/bin/meek-client' is
'closed'
--+-
 Reporter:  tagener-noisu |  Owner:  dcf
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Tested on archlinux, using this package
 https://aur.archlinux.org/packages/meek/. PKGBUILD seems ok, meek-client
 is working (tested with {{{meek-client --help}}})
 torrc file:
 {{{
 Log notice syslog
 DataDirectory /var/lib/tor
 UseBridges 1
 ClientTransportPlugin meek exec /usr/bin/meek-client --log meek-client.log
 Bridge meek 0.0.2.0:3 url=https://az668014.vo.msecnd.net/
 front=ajax.aspnetcdn.com
 Bridge meek 0.0.2.0:2 url=https://d2zfqthxsdq309.cloudfront.net/
 front=a0.awsstatic.com
 }}}
 Tor service status:
 {{{
 ● tor.service - Anonymizing Overlay Network
Loaded: loaded (/usr/lib/systemd/system/tor.service; disabled; vendor
 preset: disabled)
Active: inactive (dead)

 Oct 25 05:20:07 laptop Tor[26070]: Delaying directory fetches: No running
 bridges
 Oct 25 05:20:08 laptop Tor[26070]: The communication stream of managed
 proxy '/usr/bin/meek-client' is 'closed'. Most probably the managed proxy
 stopped running. This might be a bug of the managed proxy, a bug of Tor,
 or a misconfiguration. Please enable logging on your managed proxy and
 check the logs for errors.
 Oct 25 05:20:09 laptop Tor[26070]: Bootstrapped 5%: Connecting to
 directory server
 Oct 25 05:20:09 laptop Tor[26070]: We were supposed to connect to bridge
 '0.0.2.0:3' using pluggable transport 'meek', but we can't find a
 pluggable transport proxy supporting 'meek'. This can happen if you
 haven't provided a ClientTransportPlugin line, or if your pluggable
 transport proxy stopped running.
 Oct 25 05:20:09 laptop Tor[26070]: Problem bootstrapping. Stuck at 5%:
 Connecting to directory server. (Can't connect to bridge; PT_MISSING;
 count 1; recommendation warn; host
  at 0.0.2.0:3)
 Oct 25 05:20:09 laptop Tor[26070]: We were supposed to connect to bridge
 '0.0.2.0:2' using pluggable transport 'meek', but we can't find a
 pluggable transport proxy supporting 'meek'. This can happen if you
 haven't provided a ClientTransportPlugin line, or if your pluggable
 transport proxy stopped running.
 Oct 25 05:20:09 laptop Tor[26070]: Problem bootstrapping. Stuck at 5%:
 Connecting to directory server. (Can't connect to bridge; PT_MISSING;
 count 2; recommendation warn; host
  at 0.0.2.0:2)
 Oct 25 05:21:31 laptop systemd[1]: Stopping Anonymizing Overlay Network...
 Oct 25 05:21:31 laptop Tor[26070]: Interrupt: exiting cleanly.
 Oct 25 05:21:31 laptop systemd[1]: Stopped Anonymizing Overlay Network.
 }}}
 Meek doesn't create any log files.

--
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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-25 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Second bug report: I believe that we're disregarding
 `StandardOpenOption.CREATE_NEW` in `PersistenceUtils.storeToFileSystem()`
 since the switch to temporary files.  We're checking that the temporary
 file does not exist, writing to it, and later renaming to the original
 file, thus replacing it.  What we should really do, when storing a file
 with `StandardOpenOption.CREATE_NEW`, is check whether the file exists and
 return false.

--
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] #18910 [Metrics/CollecTor]: distributing descriptors accross CollecTor instances

2016-10-25 Thread Tor Bug Tracker & Wiki

#18910: distributing descriptors accross CollecTor instances
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.1.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ctip   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 First bug report: configuration property `"ExitlistSources"` is
 disregarded.  I believe we're looking at the non-existent property
 `"ExitlistsSources"` (plural).

--
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] #20450 [Applications/Tor Browser]: Add extra Referer protection when security slider is higher?

2016-10-25 Thread Tor Bug Tracker & Wiki

#20450: Add extra Referer protection when security slider is higher?
--+--
 Reporter:  lunar |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 François Marier wrote [http://feeding.cloud.geek.nz/posts/tweaking-
 referrer-for-privacy-in-firefox/ a good overview] of the various tweaks
 that can be enabled in recent Firefox to protect Referer leaks.

 It seems there's again a number of site-breakage tradeoff to be made, so I
 wonder if it would made sense to enable more painful protections when the
 security slider is set higher.

--
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] #20447 [Applications/Tor Browser]: Tor Browser Spec is not accurate regarding Session IDs

2016-10-25 Thread Tor Bug Tracker & Wiki

#20447: Tor Browser Spec is not accurate regarding Session IDs
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very Low  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #15988| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * parent:   => #15988


--
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] #15988 [Applications/Tor Browser]: Update Tor Browser design documentation for 6.0 (was: Update Tor Browser design documentation for 5.0)

2016-10-25 Thread Tor Bug Tracker & Wiki

#15988: Update Tor Browser design documentation for  6.0
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  GeorgKoppen201610,   |  Actual Points:
  TorBrowserTeam201610   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

--
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] #20441 [Applications/Tor Browser]: Backport missing unix domain socket bug fix (bug 1311044)

2016-10-25 Thread Tor Bug Tracker & Wiki

#20441: Backport missing unix domain socket bug fix (bug 1311044)
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-sandboxing,  |  Actual Points:
  TorBrowserTeam201610R, GeorgKoppen201610   |
Parent ID:  #14270   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Fixed with commit b91682cd038d63eb2dbec1303c2ab9a65a43775b on tor-
 browser-45.4.0esr-6.5-1.

--
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

86 matches

Mail list logo