Re: [tor-bugs] #23577 [Core Tor/Tor]: Make setup_introduce1_data() take a node instead of an extend_info

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23577: Make setup_introduce1_data() take a node instead of an extend_info
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:
Parent ID:  #23493   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Thanks for this patch, we're almost there!

 Code Logic:

 This check is incorrect, it should use `node_has_ipv6_orport()`:

 {{{
 if (node_ipv6_or_preferred(node)) {
 }}}

 `node_ipv6_or_preferred()` returns true if this client prefers IPv6 for
 this node. But link specifiers are sent to a remote client, which applies
 its own IPv6 preferences to the addresses. So we need to send the IPv6
 address whenever it is available.

 The code assumes that addr_len and the length of in6_addr are the same. I
 think it's probably ok for us to assume that.

 Code Structure:

 For consistency with `node_has_curve25519_onion_key()`, can you please
 change the name of `node_get_curve25519_key()` to
 `node_get_curve25519_onion_key()`?

--
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] #23966 [Core Tor/Tor]: Refactor node_has_curve25519_onion_key() to use node_get_curve25519_onion_key()

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23966: Refactor node_has_curve25519_onion_key() to use
node_get_curve25519_onion_key()
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  prop224, tor-hs, single-onion,
 Severity:  Normal   |  ipv6, easy, refactor
Actual Points:   |  Parent ID:  #23577
   Points:  0.2  |   Reviewer:
  Sponsor:   |
-+-
 In #23577, we will create node_get_curve25519_onion_key().
 We should use it to implement node_has_curve25519_onion_key(), so they
 give consistent results.

--
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] #23760 [Core Tor/Tor]: Use node_get_curve25519_onion_key() in extend_info_from_node() (was: Use node_get_curve25519_key() in extend_info_from_node())

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23760: Use node_get_curve25519_onion_key() in extend_info_from_node()
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, refactor, easy   |
Parent ID:  #23577   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  prop224, tor-hs, single-onion, ipv6, refactor => prop224, tor-
 hs, single-onion, ipv6, refactor, easy


Old description:

> In #23577, we are going to implement a node_get_curve25519_key()
> function. We can use this in extend_info_from_node() if we want to.

New description:

 In #23577, we are going to implement a node_get_curve25519_onion_key()
 function. We can use this in extend_info_from_node() if we want to.

--

Comment:

 Modify the name for consistency with node_has_curve25519_onion_key().

--
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] #23882 [Core Tor/Tor]: Investigate implementing a Rust allocator wrapping tor_malloc

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23882: Investigate implementing a Rust allocator wrapping tor_malloc
--+
 Reporter:  isis  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  rust, rust-pilot  |  Actual Points:
Parent ID:| Points:  3
 Reviewer:|Sponsor:  Sponsor8-can
--+
Changes (by chelseakomlo):

 * cc: chelseakomlo (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] #23965 [Metrics/Website]: 500 internal server error when trying to print svg from metrics graph

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23965: 500 internal server error when trying to print svg from metrics graph
-+--
 Reporter:  arma |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by arma):

 The "download as pdf" option works. It's just the "download as svg" that
 gives the error.

--
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] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23881: Implement a way to utilise tor's logging system from Rust code
--+
 Reporter:  isis  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust, rust-pilot  |  Actual Points:
Parent ID:| Points:  3
 Reviewer:|Sponsor:
--+
Changes (by chelseakomlo):

 * cc: chelseakomlo (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

[tor-bugs] #23965 [Metrics/Website]: 500 internal server error when trying to print svg from metrics graph

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23965: 500 internal server error when trying to print svg from metrics graph
-+--
 Reporter:  arma |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 https://metrics.torproject.org/userstats-relay-
 country.svg?start=2016-12-01=2017-10-24=ae=points
 tells me "Oops! Something went wrong here! We encountered a 500 Internal
 Server Error when processing your request!"

 I assume some backend thing is down. So (a) we should get it back up, and
 (b) we should figure out some way to automatically recognize if it fails
 again.

--
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] #23886 [Core Tor/Tor]: Write FFI bindings and function pointers for ed25519-dalek

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23886: Write FFI bindings and function pointers for ed25519-dalek
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, rust-pilot, ed25519, tor-  |  Actual Points:
  crypto, crypto |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
 |  Sponsor3-can
-+-
Changes (by chelseakomlo):

 * cc: chelseakomlo (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] #23891 [Core Tor/Tor]: Write blogpost on future/expectations for Rust in tor?

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23891: Write blogpost on future/expectations for Rust in tor?
---+
 Reporter:  isis   |  Owner:  (none)
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-blog-post  |  Actual Points:
Parent ID: | Points:  .5
 Reviewer: |Sponsor:
---+
Changes (by chelseakomlo):

 * cc: chelseakomlo (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

[tor-bugs] #23964 [Community/Outreach]: Rebecca have learning.

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23964: Rebecca have learning.
+---
 Reporter:  Rebecca |  Owner:  mrphs, alison
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Vidalia: 0.3.x
Component:  Community/Outreach  |Version:  Tor: 0.3.0.4-rc
 Severity:  Normal  |   Keywords:  Rebecca_need_help
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  SponsorU-can|
+---


--
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] #23577 [Core Tor/Tor]: Make setup_introduce1_data() take a node instead of an extend_info

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23577: Make setup_introduce1_data() take a node instead of an extend_info
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:
Parent ID:  #23493   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by neel):

 I have a new patch {{003-desriptive_msg.patch}} which introduces
 {{node_get_curve25519_key()}} (The Revision 2 lacked 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] #23577 [Core Tor/Tor]: Make setup_introduce1_data() take a node instead of an extend_info

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23577: Make setup_introduce1_data() take a node instead of an extend_info
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:
Parent ID:  #23493   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by neel):

 * Attachment "003-desriptive_msg.patch" added.

 Revised Patch (Revision 2) with node_get_curve25519_key()

--
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] #23963 [Applications/Tor Browser]: Tor Browser can use a Tor that's running under another user

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23963: Tor Browser can use a Tor that's running under another user
--+--
 Reporter:  teor  |  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):

 Here's an update from my original email:

 It's not possible to interact with this window, because Tor Launcher is
 still open. So if this isn't a security bug, it's still an annoying UI
 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] #23963 [Applications/Tor Browser]: Tor Browser can use a Tor that's running under another user

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23963: Tor Browser can use a Tor that's running under another user
--+--
 Reporter:  teor  |  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:|
--+--
 I've discovered an issue where Tor Browser fails to launch tor, but
 still connects to websites via whatever SOCKS proxy is running on port
 9150.

 I believe this issue only happens in Tor Browser 7.0 and later, because
 of the multiprocess feature. I believe it only happens on macOS, due to
 the way Tor Browser is launched to open links. But I haven't tested any
 other versions or platforms.

 I'm using Tor Browser 7.0.5 on macOS 10.12.6

 Here are the steps to reproduce:
 1. Open a copy of Tor Browser in one user account
 2. Switch to a second user account
 3. Set Tor Browser as the default browser
 4. Make sure Tor Browser is quit
 5. Open a link by right-clicking on the link text and selecting "open URL"
 (or by double-clicking a webloc file in Finder, or clicking a link in any
 rendered HTML, such as a Mail message)

 Tor Browser fails to launch tor, but opens the link in a browser window
 behind Tor launcher, and loads the link content via whatever SOCKS
 proxy is running on port 9150. (In this case, another tor instance run
 by another user.)

 This could also happen using another instance of Tor Browser run by the
 same user, but it's harder to reproduce, because links typically open
 in the instance of the default browser that's already open.

 I don't know if update checks or downloads occur over an untrusted
 SOCKSPort, but I haven't seen any update notifications appear in my
 testing.

--
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] #23874 [Core Tor/Tor]: Clear the address when node_get_prim_orport() returns early

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23874: Clear the address when node_get_prim_orport() returns early
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.2-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  technical-debt, memory-safety,   |  Actual Points:  0.1
  032-backport, 031-backport, 030-backport,  |
  029-backport, review-group-24  |
Parent ID:  #23873   | Points:  0.1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Seems fine to me, thanks for preserving the comment.

--
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] #23856 [Core Tor/Tor]: Reduce relay bandwidth stats interval to 24 hours

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23856: Reduce relay bandwidth stats interval to 24 hours
-+
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:  SponsorQ
-+

Comment (by teor):

 Replying to [comment:3 karsten]:
 > We briefly talked about this in Montreal and agreed that it's probably a
 good idea. What are the next steps?

 We change the code and potentially backport as a security issue.

 > What potentially bad consequences did we overlook? How do we find out?
 Who do we ask?

 How does metrics handle a network where some relays report every 6 hours,
 and others report every 24 hours?

 Do we need to remove some of the graphs from atlas, because they won't
 have data any more?

 I can't imagine any other consequences.

 > teor, do you think it would make sense to send a short summary of our
 Montreal discussion to tor-dev@, suggest our plan there, and ask for
 feedback? Or is that too much?

 Yes, that seems sensible. Did you want to do that, or should I?

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

Re: [tor-bugs] #23958 [Metrics/Onionoo]: Onionoo not fetching the bridge descriptor correctly?

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23958: Onionoo not fetching the bridge descriptor correctly?
-+--
 Reporter:  dgoulet  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dcf):

 Replying to [comment:9 dcf]:
 > I'm pretty sure that this is the case for all the Tor Browser default
 bridges, and it's because we ask the bridge operators to block their
 ORPort from outside access. This is to prevent reachability tests from
 succeeding, and so keep the default bridges out of BridgeDB.

 See for instance this thread about the addition of zipfelmuetze and
 griinchux:
   https://lists.torproject.org/pipermail/tor-
 project/2017-August/001369.html
   In addition, it is best if you use a firewall to block the bridge's
 regular ORPort (while leaving the obfs4 port unblocked). Blocking the
 bridge's ORPort is a hack to prevent the bridge from being included in
 BridgeDB, which eliminates a couple of ways a censor might discover and
 block the bridge: 1) by enumerating BridgeDB, and 2) by fingerprinting
 plain-Tor connections to the bridge's IP address (made by users who
 discovered the plain-Tor port through BridgeDB).

--
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] #23958 [Metrics/Onionoo]: Onionoo not fetching the bridge descriptor correctly?

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23958: Onionoo not fetching the bridge descriptor correctly?
-+--
 Reporter:  dgoulet  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dcf):

 I'm pretty sure that this is the case for all the Tor Browser default
 bridges, and it's because we ask the bridge operators to block their
 ORPort from outside access. This is to prevent reachability tests from
 succeeding, and so keep the default bridges out of BridgeDB.

 For the default bridges, having them in BridgeDB does nothing but make
 them more discoverable to a censor: in addition to being scraped from the
 source code, they can also be harvested through BridgeDB, or be detected
 on the wire when some user connects to them using vanilla Tor (easily
 fingerprintable) instead of obfs4.

 Blocking the ORPort is a workaround we have been applying for the default
 bridges for a long time, until #18329 is fixed. Also #7349 is related:
 most bridges can't hide their ORPort because they will be kept out of
 BridgeDB and be useless, but default bridges don't need BridgeDB so they
 can enhance their security by hiding their ORPort.

--
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] #13605 [Core Tor/Tor]: Create a client/relay-side ReducedExitPolicy

2017-10-23 Thread Tor Bug Tracker & Wiki 
#13605: Create a client/relay-side ReducedExitPolicy
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, easy, review-group-18,|  Actual Points:  3
  review-group-24|
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * points:  medium => 3
 * actualpoints:   => 3


Comment:

 This patch looks good to me.

 I've not compiled it or run unit tests (are there existing unit tests for
 the exit policy code?).

 We should do that before we 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] #23819 [Core Tor/Tor]: Support IPv6 link-local interface addresses

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23819: Support IPv6 link-local interface addresses
-+
 Reporter:  Zakhar   |  Owner:  (none)
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6 link-local  |  Actual Points:  1
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+
Changes (by teor):

 * status:  new => needs_revision
 * milestone:  Tor: unspecified => Tor: 0.3.3.x-final
 * points:   => 1
 * version:  Tor: unspecified =>
 * actualpoints:   => 1


Comment:

 Code review:

 This adds 4 bytes to every address in Tor, just for local addresses.
 Maybe there's a smarter way of doing this?

 We use address types AF_INET and AF_INET6, but there's no type or flag for
 full IPv6 addresses with scopes. We should add a flag or type, so that we
 don't confuse these different types of addresses. (Maybe it's sufficient
 to check if sin6_scope_id is non-zero?)

 Documentation:

 Tor patches need a changes file that contains a short changelog entry for
 the change (see tor/changes/ and `make check-changes`).

 We also need to document this in the manual page under the appropriate
 options.

 Code style:

 We typically put spaces on both sides of the assignment operator:
 {{{
 addr->addr.in6_full.sin6_scope_id= ((struct
 sockaddr_in6*)best->ai_addr)->sin6_scope_id;
 }}}

 Tor has line length limits, run `make check-spaces` to find lines that are
 too long.

--
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] #17064 [Core Tor/Torflow]: scanner.9 in torflow/bwauth failing

2017-10-23 Thread Tor Bug Tracker & Wiki 
#17064: scanner.9 in torflow/bwauth failing
--+
 Reporter:  tom   |  Owner:  aagbsn
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Torflow  |Version:
 Severity:  Blocker   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Seems like the NEWCONSENSUS event is broken somehow.

 What's meant to happen is that the NEWCONSENSUS event arrives, and then
 the list of relays is updated.

--
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] #23958 [Metrics/Onionoo]: Onionoo not fetching the bridge descriptor correctly?

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23958: Onionoo not fetching the bridge descriptor correctly?
-+--
 Reporter:  dgoulet  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by isis):

 netcatting to dgoulet's bridge's ORPort from the BridgeAuth seems to be
 working 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] #23958 [Metrics/Onionoo]: Onionoo not fetching the bridge descriptor correctly?

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23958: Onionoo not fetching the bridge descriptor correctly?
-+--
 Reporter:  dgoulet  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by isis):

 BridgeDB doesn't have the Running flag on the networkstatus-bridges entry
 for dgoulet's bridge:

 {{{
 bridgedb@polyanthum:/srv/bridges.torproject.org$ grep -R -A30 Lisbeth
 from-bifroest
 from-bifroest/networkstatus-bridges:r Lisbeth zfLoUr9Tm4K9EOJ+kRWjFzTjeMI
 43sBjkmml79Lm1k1LV7ZPx0XASM 2017-10-23 20:41:35 192.95.36.142 9001 0
 from-bifroest/networkstatus-bridges-s Fast Stable V2Dir Valid
 }}}

 So it's actually missing the Running flag entirely, and this is probably
 not Onionoo/Collector doing anything weird.

--
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] #23962 [Metrics/Onionoo]: Allow searching by bridges by version with the version parameter

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23962: Allow searching by bridges by version with the version parameter
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 The version search parameter returns "only relays running a Tor version
 that starts with the parameter value without leading "Tor"."

 This doesn't work for bridges although Onionoo has that data.

 Examples:

 https://onionoo.torproject.org/summary?type=relay=0.3.1=4
 https://onionoo.torproject.org/summary?type=bridge=0.3.1=4

 As the description does say "relays" not "relays and bridges", I'll let
 this be an enhancement not a defect. (Although really they are bridge
 relays...)

--
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] #23930 [Applications/Tor Browser]: Tor Browser 7.x for Mac crashes at startup

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23930: Tor Browser 7.x for Mac crashes at startup
--+---
 Reporter:  wga   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by wga):

 Xcode version 8.0 (build 8A218a)
 $ lldb -version
 lldb-360.1.50

 Ok for the debug version of Tor Browser.

--
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] #23958 [Metrics/Onionoo]: Onionoo not fetching the bridge descriptor correctly?

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23958: Onionoo not fetching the bridge descriptor correctly?
-+--
 Reporter:  dgoulet  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by isis):

 * cc: isis (added)


Comment:

 I don't see anything obviously wrong with the BridgeAuth; it appears to be
 doing reachability testing. Perhaps there's something wrong further down
 the line, like maybe CollecTor isn't successfully getting bridge
 descriptor tarballs from the BridgeDB machine?

--
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] #23929 [Metrics/Bot]: Don't tweet statistics from Onionoo when Onionoo is down

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23929: Don't tweet statistics from Onionoo when Onionoo is down
-+--
 Reporter:  irl  |  Owner:  irl
 Type:  defect   | Status:  accepted
 Priority:  Very High|  Milestone:
Component:  Metrics/Bot  |Version:
 Severity:  Critical | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by cypherpunks):

 it is happening again now:
 https://onionoo.torproject.org/details?limit=1
 {{{


 Error 503 Backend fetch failed

 Backend fetch failed
 Guru Meditation:

 XID: 370513704

 Varnish cache server
 }}}
 X-Varnish is set to:
 {{{370513703}}}

--
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] #23961 [Webpages/Website]: Upload fundraising images to media.torproject.org

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23961: Upload fundraising images to media.torproject.org
--+
 Reporter:  steph |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by steph):

 * Attachment "Fundraising2017-images.zip" added.

 zip of 6 images

--
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] #23961 [Webpages/Website]: Upload fundraising images to media.torproject.org

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23961: Upload fundraising images to media.torproject.org
--+
 Reporter:  steph |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Under https://media.torproject.org/image/
 Create new folders for Campaigns and Fundraising2017:
 Image > Campaigns > Fundraising2017 > [upload attached images 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] #23692 [Applications/Tor Browser Sandbox]: tabs crash in Sandboxed Tor Browser with Tor Browser 7.5.a5

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23692: tabs crash in Sandboxed Tor Browser with Tor Browser 7.5.a5
--+-
 Reporter:  pege  |  Owner:  yawning
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by yawning):

 Closed #23956 as a duplicate.

--
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] #23956 [Applications/Tor Browser Sandbox]: Sandbox unusable after update (Debian)

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23956: Sandbox unusable after update (Debian)
--+
 Reporter:  helpful_guy   |  Owner:  yawning
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:  Tor:
  |  0.3.1.7
 Severity:  Major | Resolution:  duplicate
 Keywords:  prctl |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by yawning):

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


Comment:

 Duplicate of #23692

--
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] #23930 [Applications/Tor Browser]: Tor Browser 7.x for Mac crashes at startup

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23930: Tor Browser 7.x for Mac crashes at startup
--+---
 Reporter:  wga   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by mcs):

 Thank you for posting the lldb output. Unfortunately, the fact that almost
 all of the functions show up as `lldb_unnamed_symbol...` makes
 interpreting the output difficult. What version of Xcode do you have
 installed? What does `lldb --version` produce?  Would you be willing to
 run an unofficial debug version of Tor Browser? If so, I could create one
 to help debug this problem.

--
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] #23958 [Metrics/Onionoo]: Onionoo not fetching the bridge descriptor correctly?

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23958: Onionoo not fetching the bridge descriptor correctly?
-+--
 Reporter:  dgoulet  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dgoulet):

 More example with names: `zipfelmuetze` or `griinchux` which are

 `011F2599C0E9B27EE74B353155E244813763C3E5`
 `91A6354697E6B02A386312F68D82CF86824D3606`

 Running flag has been stripped from them also...

--
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] #23874 [Core Tor/Tor]: Clear the address when node_get_prim_orport() returns early

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23874: Clear the address when node_get_prim_orport() returns early
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.2-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  technical-debt, memory-safety,   |  Actual Points:  0.1
  032-backport, 031-backport, 030-backport,  |
  029-backport, review-group-24  |
Parent ID:  #23873   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Looks good. Merged to 0.2.9 and forward. I resolved the merge conflict
 with 9ae4ffc0763fcb0a50d0d02be7d3362cc496adc1 ; please let me know if I
 messed anything up.

--
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] #23958 [Metrics/Onionoo]: Onionoo not fetching the bridge descriptor correctly?

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23958: Onionoo not fetching the bridge descriptor correctly?
-+--
 Reporter:  dgoulet  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dgoulet):

 Well almost all default Tor browser bridge I looked up today gave me a
 downtime from Onionoo. I can't get Atlas to query them now (backend error
 :S).

 {{{
 88CD36D45A35271963EF82E511C8827A24730913
 011F2599C0E9B27EE74B353155E244813763C3E5
 C73ADBAC8ADFDBF0FC0F3F4E8091C0107D093716
 CDF2E852BF539B82BD10E27E9115A31734E378C2
 A09D536DD1752D542E1FBB3C9CE4449D51298239
 FE7840FE1E21FE0A0639ED176EDA00A3ECA1E34D
 91A6354697E6B02A386312F68D82CF86824D3606
 8FB9F4319E89E5C6223052AA525A192AFBC85D55
 C8CBDB2464FC9804A69531437BCF2BE31FDD2EE4
 0BAC39417268B96B9F514E7F63FA6FBA1A788955
 A832D176ECD5C7C6B58825AE22FC4C90FA249637
 BBB28DF0F201E706BE564EFE690FE9577DD8386D
 D9A82D2F9C2F65A18407B1D2B764F130847F8B5D
 8DFCD8FB3285E855F5A55EDDA35696C743ABFC4E
 7B126FAB960E5AC6A629C729434FF84FB5074EC2
 00DC6C4FA49A65BD1472993CF6730D54F11E0DBB
 FC259A04A328A07FED1413E9FC6526530D9FD87A
 }}}

--
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] #23573 [Core Tor/Tor]: Do we want to close all connections when tor closes?

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23573: Do we want to close all connections when tor closes?
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  shutdown, privcount, correctness,|  Actual Points:
  chutney-wants, review-group-24 |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Needs a changes file.

 I'd rather have a real fix for #23570 than the sleep() call here, if at
 all possible.
 Maybe we should just fflush() everything?

 I think that rather than having main.c call hibernate_go_dormant, we
 should extract the relevant part of hibernate_go_dormant into a new
 function, and have main.c call that.

 Is the connection_mark_for_close() in hibernate_go_dormant enough here?
 It only marks the connections; it doesn't necessarily close them.

 The commit message says `Implements #435`, but I don't think that's right?

--
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] #23500 [Core Tor/Tor]: check-spaces.pl should check spaces after a comma when in functions.

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23500: check-spaces.pl should check spaces after a comma when in functions.
-+-
 Reporter:  ewong|  Owner:  (none)
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Trivial  | Resolution:
 Keywords:  code-style, review-group-24  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Hm. Did you use a script to add the missing spaces, or did you do it by
 hand?

 Ideally, there should be:
   * one commit that changes checkSpace.pl and nothing else.
   * a script that we can run on master to add the missing spaces when we
 merge.  This way, we don't get any conflicts, and it's easy to verify that
 the script does only what it claims.  Maybe something like this?
 {{{
 perl -i -pe 's/,(\S)/, $1/g' src/{common,or,ext,test,tools}/*.[ch]
 }}}
   * And then we can just run wrap the lines by hand.

 I've extracted the script as its own commit in a branch `ticket23500_033`
 in my public repository at https://gitweb.torproject.org/nickm/tor.git .
 If it looks okay, and somebody confirms the steps above, I can merge it
 and do the rest.

 Also, is there a reason to have the checkSpaces script check for
 `[\w|\d]+` instead of just `\S`?

--
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] #23958 [Metrics/Onionoo]: Onionoo not fetching the bridge descriptor correctly?

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23958: Onionoo not fetching the bridge descriptor correctly?
-+--
 Reporter:  dgoulet  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Hmm, that bridge is listed without the Running flag in the
 [https://collector.torproject.org/recent/bridge-
 descriptors/statuses/20171023-184135-1D8F3A91C37C5D1C4C19B1AD1D0CFBE8BF72D8E1
 current status]:

 {{{
 r Lisbeth 2cgFyVXLEk0YjA1E8nHpvlfeIQk dV+DnxzqEqZp2szNgJoirs4yI+A
 2017-10-23 17:39:35 10.244.31.79 59950 0
 s Fast Stable V2Dir Valid
 w Bandwidth=7175
 p reject 1-65535
 }}}

 Is there any reason why the bridge authority would take away the Running
 flag?

 Can you also check the other bridges that you think should have the
 Running flag in that status?

 If you can't resolve this easily, I can try to take another look tomorrow.
 Not sure what to look for yet, though.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23958#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23856 [Core Tor/Tor]: Reduce relay bandwidth stats interval to 24 hours

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23856: Reduce relay bandwidth stats interval to 24 hours
-+
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:  SponsorQ
-+

Comment (by karsten):

 We briefly talked about this in Montreal and agreed that it's probably a
 good idea. What are the next steps? What potentially bad consequences did
 we overlook? How do we find out? Who do we ask?

 teor, do you think it would make sense to send a short summary of our
 Montreal discussion to tor-dev@, suggest our plan there, and ask for
 feedback? Or is that too much?

--
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] #23937 [Metrics/Bot]: Add tweet templates about events in the Tor network

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23937: Add tweet templates about events in the Tor network
-+-
 Reporter:  irl  |  Owner:  irl
 Type:  task | Status:  new
 Priority:  Low  |  Milestone:
Component:  Metrics/Bot  |Version:
 Severity:  Minor| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:2 irl]:
 > Is the aggregation code that produces OrNetRadar and OrNetStats
 available?
 No these are just select queries.

--
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] #23486 [Applications/Tor Launcher]: nice icons for the progress bar

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23486: nice icons for the progress bar
---+---
 Reporter:  isabela|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201710  |  Actual Points:
Parent ID:  #23262 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by antonela):

 yes @linda! @cypherpunks There is not any bridge icon inside those sets.
 If we go with some of them, I'll work on the bridge icon. Thanks!

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

Re: [tor-bugs] #23777 [Core Tor/Tor]: tor spends a lot of time in malloc/free

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23777: tor spends a lot of time in malloc/free
--+
 Reporter:  Hello71   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 If there's anything you can share from heaptrack, that would sure be
 helpful

--
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] #23958 [Metrics/Onionoo]: Onionoo not fetching the bridge descriptor correctly?

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23958: Onionoo not fetching the bridge descriptor correctly?
-+--
 Reporter:  dgoulet  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dgoulet):

 One example, this is my bridge and I can confirm it is still working:

 `CDF2E852BF539B82BD10E27E9115A31734E378C2`

--
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] #23486 [Applications/Tor Launcher]: nice icons for the progress bar

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23486: nice icons for the progress bar
---+---
 Reporter:  isabela|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201710  |  Actual Points:
Parent ID:  #23262 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by cypherpunks):

 Replying to [comment:6 antonela]:
 > What do you think?
 Great looks! I tend to prefer the Material Design version although the
 bridge icon can be made better. Also why is the bridge icon in the Ion
 Framework a gray square?

--
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] #23960 [Applications/Tor Browser]: Clean possible IndexedDB and asm.js state during shutdown if we are in PBM

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23960: Clean possible IndexedDB and asm.js state during shutdown if we are in 
PBM
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-torbutton, tbb-
 Severity:  Normal   |  disk-leak
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We should as a defense in depth clean IndexedDB and asm.js state during
 shutdown as well not just during start-up when in Private Browsing Mode
 (PBM). kmodi reminded us to 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] #23958 [Metrics/Onionoo]: Onionoo not fetching the bridge descriptor correctly?

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23958: Onionoo not fetching the bridge descriptor correctly?
-+--
 Reporter:  dgoulet  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Hmm, which bridges are wrongly flagged offline? Can you paste hashed
 fingerprints 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] #23929 [Metrics/Bot]: Don't tweet statistics from Onionoo when Onionoo is down

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23929: Don't tweet statistics from Onionoo when Onionoo is down
-+--
 Reporter:  irl  |  Owner:  irl
 Type:  defect   | Status:  accepted
 Priority:  Very High|  Milestone:
Component:  Metrics/Bot  |Version:
 Severity:  Critical | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 So, I believe it's related to one of the Onionoo frontends. I sent mail to
 the admins and will comment here as soon as I know what's going on.

 In the meantime, adding host information to the logs somehow might make
 sense. If not for this time, then for the next time.

--
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] #23959 [Core Tor/Tor]: Š—Š°Š“Š¾Š»Š±Š°Š»Š¾ Š²Š°ŃˆŠµ ŠæŠøŠ“Š°Ń€ŃŃ‚Š²Š¾!

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23959: Š—Š°Š“Š¾Š»Š±Š°Š»Š¾ Š²Š°ŃˆŠµ ŠæŠøŠ“Š°Ń€ŃŃ‚Š²Š¾!
-+
 Reporter:  avn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Core Tor/Tor |Version:
 Severity:  Blocker  | Resolution:
 Keywords:  obfs4proxy ubuntu16.04 bridges fail  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cypherpunks):

 > Š–Š“у Š¾Ń‚ Š²Š°Ń, хŠøтрŠ¾Š¶Š¾ŠæыŠµ, Š¾Ń‚Š²ŠµŃ‚Š°!
 > Š•ŃŠ»Šø Š²Ń‹ Š½Šµ Š¾Ń‚Š·Š¾Š²ŠµŃ‚ŠµŃŃŒ, Š¼Ń‹ Š½Š°ŠæŠøшŠµŠ¼... Š² Š”ŠæŠ¾Ń€Ń‚Š»Š¾Ń‚Š¾!

 Š”Š°?

--
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] #23930 [Applications/Tor Browser]: Tor Browser 7.x for Mac crashes at startup

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23930: Tor Browser 7.x for Mac crashes at startup
--+---
 Reporter:  wga   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by wga):

 I can confirm that TorBrowser 7.0.7 indeed doesn't work even with Little
 Snitch 4 disabled.

--
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] #23899 [Applications/Tor Browser]: The incremental mar files script does not have an option to select the tmp dir

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23899: The incremental mar files script does not have an option to select the 
tmp
dir
+--
 Reporter:  boklm   |  Owner:  tbb-team
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tbb-rbm, TorBrowserTeam201710R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

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


Comment:

 Looks good. Applied to `master` in `tor-browser-build` (commit
 c64f614475954951619856f58e06f7890ff9fef2).

--
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] #23777 [Core Tor/Tor]: tor spends a lot of time in malloc/free

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23777: tor spends a lot of time in malloc/free
--+
 Reporter:  Hello71   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Hello71):

 I tried heaptrack, which seems pretty useful, but I found that there are
 no obvious culprits for either number of allocations or peak memory usage.
 it looks like a lot of time is spent in memmove through
 connection_or_process_cells_from_inbuf though, and it seems plausible that
 that mallocs buffers. maybe it's possible to avoid those if the outgoing
 channel is unblocked? might be complicated... I can do another heaptrack
 profile if you want 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] #23930 [Applications/Tor Browser]: Tor Browser 7.x for Mac crashes at startup

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23930: Tor Browser 7.x for Mac crashes at startup
--+---
 Reporter:  wga   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by wga):

 (lldb) bt all
 * thread #1: tid = 0x1263e8, 0x0001024f8d30
 XUL`___lldb_unnamed_symbol47072$$XUL + 64, queue = 'com.apple.main-
 thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
   * frame #0: 0x0001024f8d30 XUL`___lldb_unnamed_symbol47072$$XUL + 64
 frame #1: 0x0001024f88bb XUL`___lldb_unnamed_symbol47066$$XUL +
 315
 frame #2: 0x0001024f8736 XUL`___lldb_unnamed_symbol47065$$XUL +
 678
 frame #3: 0x0001024a7a76 XUL`___lldb_unnamed_symbol45337$$XUL + 70
 frame #4: 0x000102340488 XUL`___lldb_unnamed_symbol39517$$XUL +
 360
 frame #5: 0x000102336424 XUL`___lldb_unnamed_symbol39397$$XUL +
 244
 frame #6: 0x00010233687c XUL`___lldb_unnamed_symbol39402$$XUL +
 140
 frame #7: 0x000103907194 XUL`___lldb_unnamed_symbol132738$$XUL +
 436
 frame #8: 0x000103906fd3 XUL`___lldb_unnamed_symbol132737$$XUL +
 83
 frame #9: 0x0001039fbc03 XUL`___lldb_unnamed_symbol136070$$XUL +
 4115
 frame #10: 0x0001039f9fef XUL`___lldb_unnamed_symbol136068$$XUL +
 559
 frame #11: 0x0001039ffc88 XUL`___lldb_unnamed_symbol136086$$XUL +
 1800
 frame #12: 0x000103a10222 XUL`___lldb_unnamed_symbol136183$$XUL +
 82
 frame #13: 0x000103a1114e XUL`___lldb_unnamed_symbol136184$$XUL +
 686
 frame #14: 0x00010395f912 XUL`___lldb_unnamed_symbol134099$$XUL +
 914
 frame #15: 0x00010399a1d1 XUL`___lldb_unnamed_symbol134630$$XUL +
 177
 frame #16: 0x00010399ac92 XUL`___lldb_unnamed_symbol134633$$XUL +
 130
 frame #17: 0x000103ad3245 XUL`___lldb_unnamed_symbol139202$$XUL +
 421
 frame #18: 0x000103aadd8c XUL`___lldb_unnamed_symbol138502$$XUL +
 124
 frame #19: 0x000103ad3245 XUL`___lldb_unnamed_symbol139202$$XUL +
 421
 frame #20: 0x000103aadd8c XUL`___lldb_unnamed_symbol138502$$XUL +
 124
 frame #21: 0x000103ad3245 XUL`___lldb_unnamed_symbol139202$$XUL +
 421
 frame #22: 0x000103aadd8c XUL`___lldb_unnamed_symbol138502$$XUL +
 124
 frame #23: 0x000103ad3245 XUL`___lldb_unnamed_symbol139202$$XUL +
 421
 frame #24: 0x000103aadd8c XUL`___lldb_unnamed_symbol138502$$XUL +
 124
 frame #25: 0x0001039a8796 XUL`___lldb_unnamed_symbol134867$$XUL +
 38
 frame #26: 0x000103ad3c6d XUL`___lldb_unnamed_symbol139214$$XUL +
 109
 frame #27: 0x000103aadd8c XUL`___lldb_unnamed_symbol138502$$XUL +
 124
 frame #28: 0x000103ad2a38 XUL`___lldb_unnamed_symbol139197$$XUL +
 392
 frame #29: 0x000103ad1166 XUL`___lldb_unnamed_symbol139193$$XUL +
 422
 frame #30: 0x000103aae165 XUL`___lldb_unnamed_symbol138507$$XUL +
 69
 frame #31: 0x000103aac7fe XUL`___lldb_unnamed_symbol138470$$XUL +
 30
 frame #32: 0x000103ad47c1 XUL`___lldb_unnamed_symbol139219$$XUL +
 769
 frame #33: 0x000103aae165 XUL`___lldb_unnamed_symbol138507$$XUL +
 69
 frame #34: 0x000103aadbf6 XUL`___lldb_unnamed_symbol138501$$XUL +
 790
 frame #35: 0x00010397e39a XUL`___lldb_unnamed_symbol134351$$XUL +
 106
 frame #36: 0x000103a1a9d2 XUL`___lldb_unnamed_symbol136251$$XUL +
 530
 frame #37: 0x00010391daf3 XUL`___lldb_unnamed_symbol133004$$XUL +
 1571
 frame #38: 0x000103924127 XUL`___lldb_unnamed_symbol133111$$XUL +
 407
 frame #39: 0x000103923d84 XUL`___lldb_unnamed_symbol133110$$XUL +
 804
 frame #40: 0x0001038445a6 XUL`___lldb_unnamed_symbol130947$$XUL +
 2406
 frame #41: 0x000103848365 XUL`___lldb_unnamed_symbol131005$$XUL +
 421
 frame #42: 0x0001038480dc XUL`___lldb_unnamed_symbol131004$$XUL +
 188
 frame #43: 0x000103848e48 XUL`___lldb_unnamed_symbol131020$$XUL +
 40
 frame #44: 0x000101af6823 XUL`___lldb_unnamed_symbol3410$$XUL +
 739
 frame #45: 0x000101b1ef43 XUL`___lldb_unnamed_symbol4293$$XUL + 51
 frame #46: 0x000103bc50a6 XUL`___lldb_unnamed_symbol144134$$XUL +
 422
 frame #47: 0x000103b87e3b XUL`___lldb_unnamed_symbol142466$$XUL +
 6299
 frame #48: 0x000103b863fc XUL`___lldb_unnamed_symbol142464$$XUL +
 172
 frame #49: 0x000101b0270f XUL`NS_InvokeByIndex + 511
 frame #50: 0x0001021ae684 XUL`___lldb_unnamed_symbol33048$$XUL +
 4372
 frame #51: 0x0001021aff8b XUL`___lldb_unnamed_symbol33068$$XUL +

Re: [tor-bugs] #23930 [Applications/Tor Browser]: Tor Browser 7.x for Mac crashes at startup

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23930: Tor Browser 7.x for Mac crashes at startup
--+---
 Reporter:  wga   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by wga):

 $ lldb ./Contents/MacOS/firefox
 (lldb) target create "./Contents/MacOS/firefox"
 Current executable set to './Contents/MacOS/firefox' (x86_64).
 (lldb) run
 Process 18563 launched: './Contents/MacOS/firefox' (x86_64)
 1508782871500   addons.xpi-utilsERROR   Unable to read anything
 useful from the database
 1508782871800   addons.webextension.   WARNLoading extension
 'null': Reading manifest: Error processing devtools_page: An unexpected
 property was found in the WebExtension manifest.
 1508782872600   addons.webextension.   WARNLoading extension
 'null': Reading manifest: Error processing permissions.1: Unknown
 permission "privacy"
 1508782872600   addons.webextension.   WARNLoading extension
 'null': Reading manifest: Error processing permissions.4: Unknown
 permission "unlimitedStorage"
 1508782873200   addons.webextension.{73a6fe31-595d-460b-a920-fcc0f8843232}
 WARNLoading extension '{73a6fe31-595d-460b-a920-fcc0f8843232}':
 Reading manifest: Error processing permissions.1: Unknown permission
 "privacy"
 1508782873200   addons.webextension.{73a6fe31-595d-460b-a920-fcc0f8843232}
 WARNLoading extension '{73a6fe31-595d-460b-a920-fcc0f8843232}':
 Reading manifest: Error processing permissions.4: Unknown permission
 "unlimitedStorage"
 Oct 23 20:21:13.294 [notice] Tor 0.3.1.7 (git-6babd3d9ba9318b3) running on
 Darwin with Libevent 2.0.22-stable, OpenSSL 1.0.2k, Zlib 1.2.5, Liblzma
 N/A, and Libzstd N/A.
 Oct 23 20:21:13.295 [notice] Tor can't help you if you use it wrong! Learn
 how to be safe at https://www.torproject.org/download/download#warning
 Oct 23 20:21:13.296 [notice] Read configuration file
 "/Users/gander/Desktop/TorBrowser.app/Contents/Resources/TorBrowser/Tor
 /torrc-defaults".
 Oct 23 20:21:13.296 [notice] Read configuration file
 "/Users/gander/Desktop/TorBrowser-Data/Tor/torrc".
 Oct 23 20:21:13.313 [notice] Opening Control listener on 127.0.0.1:9151
 Oct 23 20:21:13.314 [notice] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 Oct 23 20:21:13.000 [notice] Parsing GEOIP IPv4 file
 /Users/gander/Desktop/TorBrowser.app/Contents/Resources/TorBrowser/Tor/geoip.
 Oct 23 20:21:13.000 [notice] Parsing GEOIP IPv6 file
 /Users/gander/Desktop/TorBrowser.app/Contents/Resources/TorBrowser/Tor/geoip6.
 Oct 23 20:21:13.000 [notice] Bootstrapped 0%: Starting
 Oct 23 20:21:13.000 [notice] Delaying directory fetches: DisableNetwork is
 set.
 Oct 23 20:21:13.000 [notice] New control connection opened from 127.0.0.1.
 Oct 23 20:21:13.000 [notice] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 Oct 23 20:21:13.000 [notice] Starting with guard context "default"
 Oct 23 20:21:13.000 [notice] New control connection opened from 127.0.0.1.
 1508782873700   addons.webextension.https-everywhere-...@eff.org
 WARNLoading extension 'https-everywhere-...@eff.org': Reading
 manifest: Error processing devtools_page: An unexpected property was found
 in the WebExtension manifest.
 1508782873800   addons.webextension.https-everywhere-...@eff.org
 WARNPlease specify whether you want browser_style or not in your
 browser_action options.
 0 migrated.
 Process 18563 stopped
 * thread #1: tid = 0x1263e8, 0x0001024f8d30
 XUL`___lldb_unnamed_symbol47072$$XUL + 64, queue = 'com.apple.main-
 thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
 frame #0: 0x0001024f8d30 XUL`___lldb_unnamed_symbol47072$$XUL + 64
 XUL`___lldb_unnamed_symbol47072$$XUL:
 ->  0x1024f8d30 <+64>: movq   (%r13), %rax
 0x1024f8d34 <+68>: leaq   0x30(%r14), %rsi
 0x1024f8d38 <+72>: leaq   0x20(%rsp), %rdx
 0x1024f8d3d <+77>: leaq   0x17(%rsp), %rcx
 (lldb) bt
 * thread #1: tid = 0x1263e8, 0x0001024f8d30
 XUL`___lldb_unnamed_symbol47072$$XUL + 64, queue = 'com.apple.main-
 thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
   * frame #0: 0x0001024f8d30 XUL`___lldb_unnamed_symbol47072$$XUL + 64
 frame #1: 0x0001024f88bb XUL`___lldb_unnamed_symbol47066$$XUL +
 315
 frame #2: 0x0001024f8736 XUL`___lldb_unnamed_symbol47065$$XUL +
 678
 frame #3: 0x0001024a7a76 XUL`___lldb_unnamed_symbol45337$$XUL + 70
 frame #4:

Re: [tor-bugs] #18329 [Core Tor/Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

2017-10-23 Thread Tor Bug Tracker & Wiki 
#18329: Let bridges indicate when they don't want BridgeDB to distribute their
address
---+---
 Reporter:  karsten|  Owner:  nickm
 Type:  enhancement| Status:
   |  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bridge, stem, review-group-24  |  Actual Points:
Parent ID: | Points:  .2
   |  remaining
 Reviewer:  isis   |Sponsor:  SponsorM
---+---

Comment (by nickm):

 Great!  Also feel free to declare that your patch is just plain better, if
 you think that's the right call.

--
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] #23959 [Core Tor/Tor]: Š—Š°Š“Š¾Š»Š±Š°Š»Š¾ Š²Š°ŃˆŠµ ŠæŠøŠ“Š°Ń€ŃŃ‚Š²Š¾!

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23959: Š—Š°Š“Š¾Š»Š±Š°Š»Š¾ Š²Š°ŃˆŠµ ŠæŠøŠ“Š°Ń€ŃŃ‚Š²Š¾!
-+-
 Reporter:  avn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Core |Version:
  Tor/Tor|
 Severity:  Blocker  |   Keywords:  obfs4proxy ubuntu16.04 bridges fail
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Š”Š¾Š±Ń€Š¾Šµ Š²Ń€ŠµŠ¼Ń сутŠ¾Šŗ!

 Š£ Š¼ŠµŠ½Ń сŠŗŠ»Š°Š“ыŠ²Š°ŠµŃ‚ся стŠ¾Š¹ŠŗŠ¾Šµ Š²ŠæŠµŃ‡Š°Ń‚Š»ŠµŠ½ŠøŠµ, чтŠ¾ Š²Ń‹ Šø Š²Š°ŃˆŠ° Š°Š½Š¾Š½ŠøŠ¼Š½Š°Ń сŠµŃ‚ŃŒ
 TOR рŠ°Š±Š¾Ń‚Š°ŠµŃ‚Šµ Š½Š° Š¼ŠøрŠ¾Š²Ń‹Šµ сŠæŠµŃ†ŃŠ»ŃƒŠ¶Š±Ń‹, т. Šŗ.:

 1. ŠŸŃ€Š¾ŠøсхŠ¾Š“Šøт Š¾Ń‡ŠµŠ²ŠøŠ“Š½Ń‹Š¹ ŠæŠµŃ€ŠµŃ…Š²Š°Ń‚ трŠ°Ń„ŠøŠŗŠ° TOR, чтŠ¾ ŠæрŠ¾ŃŠ²Š»ŃŠµŃ‚ся Š²
 Š“Š»ŠøтŠµŠ»ŃŒŠ½Š¾Š¼ ŠæŠµŃ€Š²Š¾Š½Š°Ń‡Š°Š»ŃŒŠ½Š¾Š¼ устŠ°Š½Š¾Š²Š»ŠµŠ½ŠøŠø сŠ¾ŠµŠ“ŠøŠ½ŠµŠ½ŠøŠ¹, Š“Š»ŠøтŠµŠ»ŃŒŠ½Š¾ŃŃ‚ŃŒ Š¾Š¶ŠøŠ“Š°Š½Šøя
 Š¼Š¾Š¶ŠµŃ‚ Š±Ń‹Ń‚ŃŒ Š½ŠµŃŠŗŠ¾Š»ŃŒŠŗŠ¾ Š¼ŠøŠ½ŃƒŃ‚, Š° тŠ°ŠŗŠ¶Šµ Š² ŠæŠµŃ€ŠøŠ¾Š“ŠøчŠµŃŠŗŠøх чŠ°ŃŃ‚Ń‹Ń… сŠ±Ń€Š¾ŃŠ°Ń…
 сŠ¾ŠµŠ“ŠøŠ½ŠµŠ½ŠøŠ¹!!!

 2. Š”Š»Ń Ubuntu 16.04 сŠ½Š¾Š²Š° Š½Šµ рŠ°Š±Š¾Ń‚Š°ŃŽŃ‚ obfs4proxy Šø Š¾Š±Ń‹Ń‡Š½Ń‹Šµ Š¼Š¾ŃŃ‚Ń‹ Š“Š»Ń
 сŠ±Š¾Ń€ŠŗŠø TOR daemon!!! ŠšŠ°Šŗ Š¶Šµ Š²Ń‹ Š·Š°ŠµŠ±Š°Š»Šø с Š²Š°ŃˆŠøŠ¼ ŠæŠøŠ“Š°Ń€ŃŃ‚Š²Š¾Š¼, урŠ¾Š“ы!!! Š£
 Š²Š°Ń ŠŗрŠøŠ²Ń‹Šµ руŠŗŠø ŠøŠ»Šø Š²Ń‹ сŠ¾Š·Š½Š°Ń‚ŠµŠ»ŃŒŠ½Š¾ этŠ¾ Š“ŠµŠ»Š°ŠµŃ‚Šµ? Š Š¼Š¾Š¶ŠµŃ‚ Š²Ń‹
 ŠæрŠµŠ“Š¾ŃŃ‚Š°Š²Š»ŃŠµŃ‚Šµ ŠøсхŠ¾Š“Š½Ń‹Šµ тŠµŠŗсты сŠæŠµŃ†ŃŠ»ŃƒŠ¶Š±Š°Š¼ Šø Š¾Š½Šø Š¼Š½Šµ ŠæŠ¾Š“сŠ¾Š²Ń‹Š²Š°ŃŽŃ‚ сŠ±Š¾Ń€Šŗу
 TORa, сŠ¾Š±Ń€Š°Š½Š½ŃƒŃŽ сŠæŠµŃ†ŃŠ»ŃƒŠ¶Š±Š°Š¼Šø, Š° Š½Šµ Š²Š°Š¼Šø? ŠÆ, ŠµŃŠ»Šø чŠµŃŃ‚Š½Š¾, Š±Š¾Š»ŃŒŃˆŠµ
 Š¾Š±ŃŠŃŃŠ½ŠµŠ½ŠøŠ¹ Š½Šµ Š½Š°Ń…Š¾Š¶Ńƒ.

 3. ŠšŠ¾Š³Š“Š° у Š²Š°Ń Š½Š°Ń‡Š½ŃƒŃ‚ рŠ°ŃŃ‚Šø руŠŗŠø Š½Šµ ŠøŠ· Š²Š°ŃˆŠµŠ¹ Š¶Š¾Šæы, Š° ŠøŠ· Š½ŃƒŠ¶Š½Š¾Š³Š¾ Š¼ŠµŃŃ‚Š°?
 Š˜Š»Šø Š²Š°Š¼ Š·Š° этŠ¾ хŠ¾Ń€Š¾ŃˆŠ¾ ŠæŠ»Š°Ń‚ŃŃ‚ Š¼ŠøрŠ¾Š²Ń‹Šµ сŠæŠµŃ†ŃŠ»ŃƒŠ¶Š±Ń‹?


 Š–Š“у Š¾Ń‚ Š²Š°Ń, хŠøтрŠ¾Š¶Š¾ŠæыŠµ, Š¾Ń‚Š²ŠµŃ‚Š°!


 ŠŠøŠŗŠøтушŠŗŠøŠ½ ŠŠ½Š“рŠµŠ¹.

--
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] #23958 [Metrics/Onionoo]: Onionoo not fetching the bridge descriptor correctly?

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23958: Onionoo not fetching the bridge descriptor correctly?
-+--
 Reporter:  dgoulet  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 All Tor browser bridges are flagged offline by Atlas where Onionoo is
 seeing a "last published timestamp" for all of them at:

 `bridges_published:"2017-10-23 16:41:35",`

 I suspect an Onionoo issue else could be a bridge auth problem?

--
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] #23784 [Core Tor/Tor]: Loading relay information failed (connection timeout - 109.163.234.9:443)

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23784: Loading relay information failed (connection timeout - 
109.163.234.9:443)
--+--
 Reporter:  Nom   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * status:  new => closed
 * resolution:   => not a bug
 * component:  - Select a component => Core Tor/Tor


Comment:

 Thanks for the speedy reply!

--
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] #23822 [Core Tor/Tor]: tor router not working

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23822: tor router not working
--+---
 Reporter:  y.net |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.2.5.12
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by nickm):

 * status:  needs_information => closed
 * resolution:   => not a bug


Comment:

 Sorry for the delay here -- it looks like you've got a support question,
 but this bugtracker isn't very good for those.  Maybe the tor-relays@
 mailing list, or the tor-talk mailing list, or the #tor IRC channel could
 help more?

--
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] #23777 [Core Tor/Tor]: tor spends a lot of time in malloc/free

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23777: tor spends a lot of time in malloc/free
--+
 Reporter:  Hello71   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Do you have any stack results on who the main callers of malloc() and
 free() are in your code?  Do you have a more complete profile you can
 share?

--
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] #18329 [Core Tor/Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

2017-10-23 Thread Tor Bug Tracker & Wiki 
#18329: Let bridges indicate when they don't want BridgeDB to distribute their
address
---+---
 Reporter:  karsten|  Owner:  nickm
 Type:  enhancement| Status:
   |  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bridge, stem, review-group-24  |  Actual Points:
Parent ID: | Points:  .2
   |  remaining
 Reviewer:  isis   |Sponsor:  SponsorM
---+---

Comment (by isis):

 BTW, this also makes it trivial to fix #16564, since DirAuths can check
 for a "bridge-distribution" line in descriptors submitted to them and not
 include in the consensus those which do have it.

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

Re: [tor-bugs] #23885 [Core Tor/Tor]: Assertion *buf_flushlen <= buf->datalen failed after circuit_handle_oom() has been called

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23885: Assertion *buf_flushlen <= buf->datalen failed after 
circuit_handle_oom()
has been called
--+--
 Reporter:  Jaym  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.7
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

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


Comment:

 If your openssl version is broken, then yeah--building with a better one
 would probably help.  If you install it in a nonstandard location, then
 Tor's --with-openssl-dir option might 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] #18329 [Core Tor/Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

2017-10-23 Thread Tor Bug Tracker & Wiki 
#18329: Let bridges indicate when they don't want BridgeDB to distribute their
address
---+---
 Reporter:  karsten|  Owner:  nickm
 Type:  enhancement| Status:
   |  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bridge, stem, review-group-24  |  Actual Points:
Parent ID: | Points:  .2
   |  remaining
 Reviewer:  isis   |Sponsor:  SponsorM
---+---
Changes (by isis):

 * reviewer:   => isis


Comment:

 Oh shoot.  I also wrote a patch for this last week, but didn't update the
 ticket.

 I'll gladly review and then see if there's anything left from my patch
 that's useful (maybe unittests are still a useful addition). If so, I'll
 pick those parts out and put them in a new commit on top.

--
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] #23783 [Core Tor/Tor]: Can't build Tor 0.3.2.2-alpha with mingw32 on Windows 7

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23783: Can't build Tor 0.3.2.2-alpha with mingw32 on Windows 7
--+
 Reporter:  Bizarreā„¢  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor:
  |  0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.3.2.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  0.3.2.2-alpha-blogpost-bugreport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:   => Tor: 0.3.2.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] #23243 [Metrics/Website]: Write a specification for Tor web server logs

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23243: Write a specification for Tor web server logs
-+
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by iwakeh):

 * status:  merge_ready => needs_revision


Comment:

 The spec might need to be extended:

 The implementation of the CollecTor webstats module triggered more
 questions about the way original logs are supplied.  One piece of
 information that is so far only supplied indirectly is the cue for when a
 log is finished.  In detail:

 * Functionality for bulk imports of log files is necessary.  Thus, the
 implementation cannot rely on the system date anymore to decide when a log
 day is complete.  (distinguishing between reference date as defined in the
 spec and the 'log for a day' which means all log lines for a given date
 are available).
 * Implicit assumption: input log files can be empty or not contain any
 valid lines as long as there naming pattern matches the rules.
 * The current spec allows only for one input log per reference date (per
 virtual plus physical host).
 * Log lines for a particular log day could be spread over two successive
 log files (as defined in the current spec).
 * Implicit cue: all log lines are available for a certain reference date
 when the log for the reference date and its successor are available.  This
 also means a log for a day without an immediate successor is not complete,
 i.e. won't be processed.  The cue in form of the successor could be given
 as an empty successor log file.  This cue has to be supplied from outside
 and cannot be determined from the implementation.


 Related is another question from #22428 comment:36

 > Here's another, related question: what happens if a web server rotates
 logs more often than once per day? At least that's something that we write
 in the specification. I'm not sure how this would work with file names, so
 maybe we in fact require that logs are rotated exactly once per day, and
 we just didn't write that in the specification yet. However, it seems
 rather restrictive to prescribe exact log rotation intervals in order to
 sanitize logs subsequently. Maybe we should be less restrictive here.

 It doesn't really matter, if the log lines for a certain day are spread
 over two or more input files.  Currently, only one input file per
 reference date is possible (the first wins).
 More input files could be supplied by extending the input log name pattern
 with a dash followed by an integer, i.e., `scrubbed.torproject.org-
 access.log-20171006-77.gz`.  In such a case it should be required that
 * counting starts with one (arbitrary).
 * there are no gaps, i.e., if there is a file with 3, there have to be
 files with 2 and 1 for the same virtual, physical host, and date
 combination.

 Again, a cue is needed for when the log day is complete.  As above this
 could be the input file for the immediate successor by reference date with
 number 1. And, this cue could be an empty file.

 Remarks:
 The way the cue is given is arbitrary, but the current implementation
 suggestion already works with the method described above.
 The naming pattern is just an arbitrary suggestion.  So improvements are
 welcome.

--
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] #12990 [Core Tor/Tor]: route certificate errors

2017-10-23 Thread Tor Bug Tracker & Wiki 
#12990: route certificate errors
--+--
 Reporter:  saint |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-client|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * milestone:   => Tor: unspecified


Comment:

 That looks very much like an MITM attempt, possibly by a captive portal.
 In particular, the key digest matches the authority key id here:
 
https://censys.io/certificates/e2a86707f84d27fc76f972275d85248d22595e8e71aadb434626832000d2d805/table
 and there's more about it here:
 
https://certificatedetails.com/4279541b61cd552b3e63d53c4857f59ffb45ce4a/31113/wtc.hntb.com

 saint, do you happen to remember what kind of horrible internet you were
 on when you saw this error?

--
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] #23486 [Applications/Tor Launcher]: nice icons for the progress bar

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23486: nice icons for the progress bar
---+---
 Reporter:  isabela|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201710  |  Actual Points:
Parent ID:  #23262 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by linda):

 Antonela, thanks for looking into the icons. We can talk about it during
 the ticket triage meeting tomorrow!

--
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] #23486 [Applications/Tor Launcher]: nice icons for the progress bar

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23486: nice icons for the progress bar
---+---
 Reporter:  isabela|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201710  |  Actual Points:
Parent ID:  #23262 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by antonela):

 Hi all, I have been working on the icon set for the progress bar.
 I put together some options using pre-existent OSS icons sets.

 https://trac.torproject.org/projects/tor/attachment/ticket/23486/TTB-
 Icons.png

 I'd like to mockup these icons in the real interface to check consistency
 between the existing ones and this new one.

 What do you think?

--
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] #23486 [Applications/Tor Launcher]: nice icons for the progress bar

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23486: nice icons for the progress bar
---+---
 Reporter:  isabela|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201710  |  Actual Points:
Parent ID:  #23262 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by antonela):

 * Attachment "TTB-Icons.png" added.

 v0

--
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] #23952 [Core Tor/Tor]: LOG_PROTOCOL_WARN can call get_options() during an options transition.

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23952: LOG_PROTOCOL_WARN can call get_options() during an options transition.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_review => merge_ready
 * reviewer:   => dgoulet


Comment:

 lgtm.

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

Re: [tor-bugs] #17521 [Core Tor/Tor]: Support capsicum(4) on FreeBSD

2017-10-23 Thread Tor Bug Tracker & Wiki 
#17521: Support capsicum(4) on FreeBSD
-+-
 Reporter:  yawning  |  Owner:
 |  shawn.webb
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security, sandboxing, |  Actual Points:
  BSD, capsicum  |
Parent ID:   | Points:
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by ahf):

 * reviewer:   => ahf


--
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] #23957 [Obfuscation/BridgeDB]: Add support for bridge-distribution descriptor lines in BridgeDB

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23957: Add support for bridge-distribution descriptor lines in BridgeDB
--+--
 Reporter:  isis  |  Owner:  isis
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal|   Keywords:  bridgedb-parsers
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:  SponsorM  |
--+--
 BridgeDB should be capable of allowing operators to choose if/how to
 distribute their bridges, which is possible after #18329. Already #21177
 is in Stem, so we just need to update BridgeDB to the latest Stem master
 and add some handling in the descriptor parsing and distribution 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] #23785 [Core Tor/Tor]: [HELP!] 7.5a5's(IIRC) Tor cause DNS disruption!

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23785: [HELP!] 7.5a5's(IIRC) Tor cause DNS disruption!
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  task  | Status:  needs_information
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * priority:  Very High => High
 * milestone:   => Tor: 0.3.2.x-final


Comment:

 Can you identify the last version that works for you, and the first
 version that breaks?  It would also be helpful to see what is in your logs
 around when the warning occurs, as cypherpunks notes above.

 For what it's worth: DNS lookup over DNSPort works for me with the current
 alpha, so it's not trivial to track this down.

--
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] #23956 [Applications/Tor Browser Sandbox]: Sandbox unusable after update (Debian) (was: Tor unusable after update (Debian))

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23956: Sandbox unusable after update (Debian)
--+
 Reporter:  helpful_guy   |  Owner:  yawning
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:  Tor:
  |  0.3.1.7
 Severity:  Major | Resolution:
 Keywords:  prctl |  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] #23899 [Applications/Tor Browser]: The incremental mar files script does not have an option to select the tmp dir

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23899: The incremental mar files script does not have an option to select the 
tmp
dir
+--
 Reporter:  boklm   |  Owner:  tbb-team
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201710R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by boklm):

 * keywords:  tbb-rbm, TorBrowserTeam201710 => tbb-rbm,
   TorBrowserTeam201710R
 * status:  new => needs_review


Comment:

 I created a patch to fix that in branch `bug_23899`:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_23899=c64f614475954951619856f58e06f7890ff9fef2

--
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] [Tor Bug Tracker & Wiki] Batch modify: #12600, #21205, #22355, #22745

2017-10-23 Thread Tor Bug Tracker & Wiki 
Batch modification to #12600, #21205, #22355, #22745 by nickm:
milestone to Tor: 0.3.3.x-final

--
Tickets 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] #23956 [Applications/Tor Browser Sandbox]: Tor unusable after update (Debian)

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23956: Tor unusable after update (Debian)
-+-
 Reporter:  helpful_guy  |  Owner:  yawning
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:  Tor:
  Sandbox|  0.3.1.7
 Severity:  Major|   Keywords:  prctl
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 After the update to 7.0.7, I get:
 {{{
 2017/10/23 10:09:04 firefox: Sandbox: prctl(PR_SET_NO_NEW_PRIVS) failed:
 Function not implemented
 }}}
 The result is no site can be visited, and all new tabs crash with the
 firefox "Gah" message. The fuller context is below.

 On load the tor log messages are normal, but firefox says:
 {{{
 2017/10/23 10:09:03 firefox: 1508778543200
 addons.webextension.{73a6fe31-595d-460b-a920-fcc0f8843232}WARN
 Loading extension '{73a6fe31-595d-460b-a920-fcc0f8843232}': Reading
 manifest: Error processing permissions.1: Unknown permission "privacy"
 2017/10/23 10:09:03 firefox: 1508778543200
 addons.webextension.{73a6fe31-595d-460b-a920-fcc0f8843232}WARN
 Loading extension '{73a6fe31-595d-460b-a920-fcc0f8843232}': Reading
 manifest: Error processing permissions.4: Unknown permission
 "unlimitedStorage"
 2017/10/23 10:09:03 firefox: 1508778543300addons.webextension
 .https-everywhere-...@eff.orgWARNLoading extension 'https-
 everywhere-...@eff.org': Reading manifest: Error processing devtools_page:
 An unexpected property was found in the WebExtension manifest.
 2017/10/23 10:09:03 firefox: 1508778543400addons.webextension
 .https-everywhere-...@eff.orgWARNPlease specify whether
 you want browser_style or not in your browser_action options.
 }}}
 Firefox does open, but any attempt to visit a URL produces this set of
 messages:

 {{{
 2017/10/23 10:09:04 firefox: Sandbox: prctl(PR_SET_NO_NEW_PRIVS) failed:
 Function not implemented
 2017/10/23 10:09:04 firefox: [Parent 3] WARNING: pipe error (59):
 Connection reset by peer: file /home/debian/build/tor-
 browser/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 322
 2017/10/23 10:09:04 firefox: [Parent 3] WARNING: pipe error (57):
 Connection reset by peer: file /home/debian/build/tor-
 browser/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 322
 2017/10/23 10:09:04 firefox: ###!!! [Parent][MessageChannel] Error:
 (msgtype=0x2C0086,name=PBrowser::Msg_Destroy) Channel error: cannot
 send/recv
 }}}

--
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] #23955 [Applications/Tor Browser]: Set "ConnectionPadding 1" by default to unify padding behavior for Tor Browser users

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23955: Set "ConnectionPadding 1" by default to unify padding behavior for Tor
Browser users
--+--
 Reporter:  cypherpunks   |  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:|
--+--
 Netflow padding was implemented by Mike Perry and merged for Tor 0.3.1.x,
 however by default it is only enabled with relays that have version bigger
 or equal to 0.3.1.x.

 https://www.torproject.org/docs/tor-manual.html.en#ConnectionPadding

 As a result, since Tor version distribution for guard nodes is
 significantly different it means that some Tor Browser users will have
 different network fingerprint.

 Of course even if they have it's not really _that_ harmful but enabling it
 by default _may_ not prove harmful either.

--
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] #22428 [Metrics/CollecTor]: Add webstats module

2017-10-23 Thread Tor Bug Tracker & Wiki 
#22428: Add webstats module
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_revision
 Priority:  High   |  Milestone:  CollecTor 1.5.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-2017   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Replying to [comment:36 karsten]:
 > Alright, I finished an initial review of commit 086e904 in your
 task-22428-4 branch. I have several trivial or minor findings, but I'd
 like to postpone them until we have resolved one that I consider major:

 Good, it's better to address the small stuff at the very end :-)

 >
 > I'm unclear whether the sibling approach is robust enough to cover all
 cases and edge cases. Maybe even worse, I'm unclear whether we'd notice if
 we'd be running into an uncovered edge case or if we'd silently not
 process and therefore lose data.

 This is not the siblings approach question, but the general question: When
 is the log for a certain day done?
 I'll address this in more detail on #23243, because this is a
 specification issue and this ticket here should only be concerned with
 implementation, imo.

 >
 > For example, what happens if we sanitize logs from a server that
 receives ''very'' few requests, maybe only a few requests per week?
 Consider these original log files (where I scrubbed the virtual host
 name):
 >  - `scrubbed.torproject.org-access.log-20171001.gz` contains requests
 from 2017-09-30 and 2017-10-01.
 >  - `scrubbed.torproject.org-access.log-20171002.gz` contains requests
 from 2017-10-01 only.
 >  - `scrubbed.torproject.org-access.log-20171004.gz` contains requests
 from 2017-10-03 only.
 >  - `scrubbed.torproject.org-access.log-20171006.gz` contains requests
 from 2017-10-05 and 2017-10-06.
 >
 > Would the existing code produce logs for 2017-10-01, -03, -05, and -06
 with exactly the sanitized log lines from these original log files? (I
 didn't run it, I only read the code and am unclear about this.)

 The result does not depend on the contents of an input log.  The above
 files would lead to a single sanitized log for 2017-10-01.  The
 implementation relies on having the sibling, which could be provided by a
 simple `touch scrubbed.torproject.org-access.log-20171003` command.  The
 application needs an outside cue.  I'm stating this here for completeness.
 As there is more to this (including the below questions), let's move the
 discussion to the spec ticket.

 >
 > Here's another, related question: what happens if a web server rotates
 logs more often than once per day? At least that's something that we write
 in the specification. I'm not sure how this would work with file names, so
 maybe we in fact require that logs are rotated exactly once per day, and
 we just didn't write that in the specification yet. However, it seems
 rather restrictive to prescribe exact log rotation intervals in order to
 sanitize logs subsequently. Maybe we should be less restrictive here.
 >
 > Is there a way to make this approach more robust? And is there a way to
 ensure that we'll learn about any broken assumptions as early as possible?

 Will move all these questions and possible answers to on #23243.

 >
 > Ah, and do you mind doing another round of JavaDoc editing and variable
 renaming towards finding a middle ground between 2-characters-is-almost-
 verbose and 80-characters-can-fit-in-a-line-so-let-us-not-use-more-
 than-79? As a fixup/squash commit without rebasing, please. :) Thank you!

 I'll take another look, no problem ;-)

--
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] #5190 [Core Tor/Tor]: Collect Rob's patch for throttling flows at guards

2017-10-23 Thread Tor Bug Tracker & Wiki 
#5190: Collect Rob's patch for throttling flows at guards
-+-
 Reporter:  arma |  Owner:
 |  robgjansen
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  performance, scheduling, SponsorZ,   |  Actual Points:
  tor-relay, review-group-18 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Great!  Thanks, Rob!  And sorry for my confusion.

--
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] #23954 [Core Tor/Tor]: Race condition in LOG_PROTOCOL_WARN

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23954: Race condition in LOG_PROTOCOL_WARN
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 LOG_PROTOCOL_WARN currently calls get_options().  After #23952 is merged,
 it will call get_protocol_warning_severity_level().  The trouble is, both
 of these functions access a global variable without acquiring a lock...
 and LOG_PROTOCOL_WARN can be invoked from outside the main thread.

 Let's fix this once #23952 and #23953 are merged.

--
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] #23953 [Core Tor/Tor]: Use stdatomic counters where available

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23953: Use stdatomic counters where available
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 See branch `ticket23953_033`

--
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] #23953 [Core Tor/Tor]: Use stdatomic counters where available

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23953: Use stdatomic counters where available
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 C11 has built-in atomics; we may as well use them to implement
 atomic_counter_t and speed up a little.

--
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] #23952 [Core Tor/Tor]: LOG_PROTOCOL_WARN can call get_options() during an options transition.

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23952: LOG_PROTOCOL_WARN can call get_options() during an options transition.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  assigned => needs_review
 * cc: toralf (added)


Comment:

 See fix in my branch `bug23952_032`.

--
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] #23479 [Core Tor/Tor]: Bug: ../src/or/config.c:785: get_options_mutable: Non-fatal assertion ! in_option_validation failed

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23479: Bug: ../src/or/config.c:785: get_options_mutable: Non-fatal assertion !
in_option_validation failed
+
 Reporter:  gk  |  Owner:  nickm
 Type:  defect  | Status:  closed
 Priority:  High|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tor-config, tor-client  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by nickm):

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


Comment:

 Opened #23952 to track the onion_skin_TAP_server_handshake 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] #23952 [Core Tor/Tor]: LOG_PROTOCOL_WARN can call get_options() during an options transition.

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23952: LOG_PROTOCOL_WARN can call get_options() during an options transition.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 See comments on #23479.

--
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] #5190 [Core Tor/Tor]: Collect Rob's patch for throttling flows at guards

2017-10-23 Thread Tor Bug Tracker & Wiki 
#5190: Collect Rob's patch for throttling flows at guards
-+-
 Reporter:  arma |  Owner:
 |  robgjansen
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  performance, scheduling, SponsorZ,   |  Actual Points:
  tor-relay, review-group-18 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by robgjansen):

 I believe that my patches have been public since I talked to Roger and he
 made this ticket. (See
 [https://trac.torproject.org/projects/tor/ticket/5190#comment:5 my comment
 above].)

 The code currently publicly exists on https://github.com/robgjansen/tor in
 these branches:
   * research/throttling/bitsplit
   * research/throttling/flag
   * research/throttling/threshold

 AIUI, Tor doesn't generally "archive" research code. Perhaps this case was
 different because of the potential positive impact that throttling could
 have on general Tor usage? In any case, I don't plan on removing my code
 from my GitHub Tor clone linked above, but do feel free to "collect" it in
 some way if that is desirable.

 I think we can close this ticket.  If we indeed want to further pursue it,
 deciding if throttling should actually be done and how should probably be
 a new ticket.

--
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] #23479 [Core Tor/Tor]: Bug: ../src/or/config.c:785: get_options_mutable: Non-fatal assertion ! in_option_validation failed

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23479: Bug: ../src/or/config.c:785: get_options_mutable: Non-fatal assertion !
in_option_validation failed
+
 Reporter:  gk  |  Owner:  nickm
 Type:  defect  | Status:  accepted
 Priority:  High|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-config, tor-client  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by nickm):

 Oh, darnit.  It's LOG_PROTOCOL_WARN.

--
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] #23929 [Metrics/Bot]: Don't tweet statistics from Onionoo when Onionoo is down

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23929: Don't tweet statistics from Onionoo when Onionoo is down
-+--
 Reporter:  irl  |  Owner:  irl
 Type:  defect   | Status:  accepted
 Priority:  Very High|  Milestone:
Component:  Metrics/Bot  |Version:
 Severity:  Critical | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by irl):

 I'm not sure I can actually even do this with the HC fluent API. I think I
 need to use the full HTTP client API instead. This probably will allow me
 to pull out the IP address after receiving the response, and I need to do
 this anyway to take advantage of caching.

--
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] #17193 [Core Tor/Tor]: Don't print bridge IPs/fingerprints in WARN/NOTICE log messages

2017-10-23 Thread Tor Bug Tracker & Wiki 
#17193: Don't print bridge IPs/fingerprints in WARN/NOTICE log messages
--+
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:
 Keywords:  tor-bridge|  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:  SponsorM
--+
Changes (by nickm):

 * severity:  Blocker => Major


--
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] #23929 [Metrics/Bot]: Don't tweet statistics from Onionoo when Onionoo is down

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23929: Don't tweet statistics from Onionoo when Onionoo is down
-+--
 Reporter:  irl  |  Owner:  irl
 Type:  defect   | Status:  accepted
 Priority:  Very High|  Milestone:
Component:  Metrics/Bot  |Version:
 Severity:  Critical | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by irl):

 The remote IP address isn't in the Headers afaics.

 {{{
 HTTP/1.1 200 OK
 Date: Mon, 23 Oct 2017 15:49:36 GMT
 Last-Modified: Mon, 23 Oct 2017 14:52:23 GMT
 Access-Control-Allow-Origin: *
 Content-Type: application/json; charset=UTF-8
 Cache-Control: public, max-age=300
 Content-Length: 1045
 X-Varnish: 606629251
 Via: 1.1 varnish (Varnish/5.0)
 X-Varnish: 789232853
 Age: 0
 Via: 1.1 varnish (Varnish/5.0)
 Accept-Ranges: bytes
 Strict-Transport-Security: max-age=15768000; preload
 }}}

 I can get the headers out when I get the response, but there's nothing to
 log.

--
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] #23858 [Core Tor/Tor]: Create a local tool that provides detailed statistics for relay operators

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23858: Create a local tool that provides detailed statistics for relay 
operators
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-relay |  Actual Points:
Parent ID:| Points:  5
 Reviewer:|Sponsor:  SponsorQ-can
--+
Changes (by nickm):

 * sponsor:   => SponsorQ-can


--
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] #23677 [Core Tor/Tor]: Tor should log what it thinks the time is sometime(s)

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23677: Tor should log what it thinks the time is sometime(s)
-+
 Reporter:  pastly   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bootstrap clock-skew ux  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor8-can
-+
Changes (by nickm):

 * sponsor:   => Sponsor8-can


--
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] #23573 [Core Tor/Tor]: Do we want to close all connections when tor closes?

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23573: Do we want to close all connections when tor closes?
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  shutdown, privcount, correctness,|  Actual Points:
  chutney-wants, review-group-24 |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by nickm):

 * sponsor:   => Sponsor8


Comment:

 Calling this sponsor8 because of #23847

--
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] #23523 [Core Tor/Tor]: Handle extreme values better in add_laplace_noise()

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23523: Handle extreme values better in add_laplace_noise()
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.6.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, privcount, review-|  Actual Points:
  group-24   |
Parent ID:  #23061   | Points:  0.5
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-
Changes (by nickm):

 * sponsor:   => SponsorQ


--
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] #23521 [Core Tor/Tor]: detect if clock skew is probably really time zone misconfiguration

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23521: detect if clock skew is probably really time zone misconfiguration
-+
 Reporter:  catalyst |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bootstrap clock-skew ux  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor8
-+
Changes (by nickm):

 * sponsor:   => Sponsor8


--
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] #23501 [Core Tor/Tor]: Refactor rep_hist_format_hs_stats() to add noise when counters are initialised

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23501: Refactor rep_hist_format_hs_stats() to add noise when counters are
initialised
+--
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.2.2.14-alpha
 Severity:  Normal  | Resolution:
 Keywords:  tor-relay, privcount, refactor  |  Actual Points:
Parent ID:  #23061  | Points:  0.5
 Reviewer:  |Sponsor:  SponsorQ-can
+--
Changes (by nickm):

 * sponsor:   => SponsorQ-can


--
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] #23512 [Core Tor/Tor]: Bandwidth stats watermark can be induced using OOM killer

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23512: Bandwidth stats watermark can be induced using OOM killer
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bug-bounty, congestion-attack,   |  Actual Points:
  research, watermark, tor-stats, guard- |
  discovery  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-
Changes (by nickm):

 * sponsor:   => SponsorQ


--
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] #23416 [Core Tor/Tor]: Document the precision and limits of sample_laplace_distribution()

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23416: Document the precision and limits of sample_laplace_distribution()
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-relay, privcount  |  Actual Points:
Parent ID:  #23061| Points:  1
 Reviewer:|Sponsor:  SponsorQ-can
--+
Changes (by nickm):

 * sponsor:   => SponsorQ-can


--
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] #23415 [Core Tor/Tor]: sample_laplace_distribution() should take multiple random inputs

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23415: sample_laplace_distribution() should take multiple random inputs
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, security-low, privcount,  |  Actual Points:
  031-backport, 030-backport, 029-backport, 028  |
  -backport-maybe, 026-backport-maybe|
Parent ID:  #23061   | Points:  0.5
 Reviewer:   |Sponsor:
 |  SponsorQ-can
-+-
Changes (by nickm):

 * sponsor:   => SponsorQ-can


--
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] #23406 [Core Tor/Tor]: Sampled guards are not re-weighted when a new consensus arrives

2017-10-23 Thread Tor Bug Tracker & Wiki 
#23406: Sampled guards are not re-weighted when a new consensus arrives
---+---
 Reporter:  teor   |  Owner:  nickm
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.1-alpha
 Severity:  Normal | Resolution:
 Keywords:  path-selection, tor-guard  |  Actual Points:
Parent ID:  #23318 | Points:  1
 Reviewer: |Sponsor:  SponsorV-can
---+---
Changes (by nickm):

 * sponsor:   => SponsorV-can


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

  1   2   3   >