Re: [tor-bugs] #17945 [Core Tor/Tor]: Stop single hop client connections to Single Onion Services (was: Stop single hop client connecting to (Rendezvous) Single Onion Services)

[Tor Bug Tracker & Wiki]

#17945: Stop single hop client connections to Single Onion Services
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor2web, tor-hs, 029-proposed, 029   |  Actual Points:  0.4
  -teor-no, needs-design, needs-proposal-maybe,  |
  single-onion, review-group-33, |
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #24962   | Points:  5
 Reviewer:  asn, teor|Sponsor:
-+-
Description changed by teor:

Old description:

> Tor2Web clients make a one-hop connection to the rendezvous point.
> Rendezvous Single Onion Services also make a one-hop connection to the
> rendezvous point. (Single Onion Services expect a client to make an
> extend request to the Single Onion Service at the end of a 3-hop path.)
>
> This uses Tor as a one-hop proxy (in this case, to a single onion
> service), which we try to avoid, because it enables certain attacks.
>
> For Rendezvous Single Onion Services, I don't know how to prevent this
> happening. (Should the rendezvous point intervene? Should we add
> something to the RSOS descriptor?)
>
> For Single Onion Services, we can modify the Tor2Web client code so it
> doesn't make the SOS extend request, but falls back to rendezvous mode.

New description:

 Tor2Web clients make a one-hop connection to HSDirs, intro points, and
 rend points. Single Onion Services also make a one-hop connection to the
 rendezvous point.

 This uses Tor as a one-hop proxy (in this case, to a single onion
 service), which we try to avoid, because it enables certain attacks. We
 also try to avoid single hop connections in the onion service protocol,
 because they give IP addresses to middle relays.

 See the child tickets for details.

--

--
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] #22689 [Core Tor/Tor]: hs: Stop intro points being used as single hop proxies

[Tor Bug Tracker & Wiki]

#22689: hs: Stop intro points being used as single hop proxies
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  relay-safety, 033-triage-20180320,   |  Actual Points:
  033-removed-20180320   |
Parent ID:  #17945   | Points:  0.5
 Reviewer:  teor |Sponsor:
-+-
Description changed by teor:

Old description:

> This prevents them knowing both the service and client IP addresses, and
> therefore being targets for network traffic logging, sybil, or hacking
> attacks.
>
> We need to implement the following checks:
> * if the introduction point was made using a direct connection (single
> onion services), refuse direct client connections,
> * ~~if the rend point was made using a direct connection (custom client,
> no tor2web for HSv3), refuse direct service connections (single onion
> services).~~
>
> See #22688 for how this is done for HSDir3s using channel_is_client().
> The comments in that patch explain why it works.
>
> We could even refactor the common code out of
> connection_dir_is_anonymous() into connection_is_anonymous(), and avoid
> including channel[tls].h into directory.c.
>
> I'm not sure if I will get time to do this, so please feel free to take
> this ticket.

New description:

 This prevents them knowing both the service and client IP addresses, and
 therefore being targets for network traffic logging, sybil, or hacking
 attacks.

 We need to implement the following checks:
 * if an introduction point was made using a direct connection (single
 onion services), refuse direct client connections,
 * for v3 intro points, always refuse direct client connections
 * for v2 intro points, refuse direct client connections based on a
 consensus parameter
 * ~~if the rend point was made using a direct connection (custom client,
 no tor2web for HSv3), refuse direct service connections (single onion
 services).~~

 See #22688 for how this is done for HSDir3s using channel_is_client(). The
 comments in that patch explain why it works.

 We could even refactor the common code out of
 connection_dir_is_anonymous() into connection_is_anonymous(), and avoid
 including channel[tls].h into directory.c.

 I'm not sure if I will get time to do this, so please feel free to take
 this 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] #22688 [Core Tor/Tor]: hs: stop HSDirs being used as single-hop "proxies"

[Tor Bug Tracker & Wiki]

#22688: hs: stop HSDirs being used as single-hop "proxies"
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, relay-safety,|  Actual Points:  0.3
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #17945   | Points:  0.3
 Reviewer:   |Sponsor:
-+-
Description changed by teor:

Old description:

> handle_post_hs_descriptor and handle_get_hs_descriptor_v3 should check
> that the connection is:
> * encrypted, and
> * not from a client (channel_is_client in 0.3.1.1-alpha and later
> correctly identifies unauthenticated peers, which are clients and
> bridges).
>
> For extra safety, we can check if the circuit is from a relay.

New description:

 handle_post_hs_descriptor and handle_get_hs_descriptor_v3 should check
 that the connection is:
 * encrypted, and
 * not from a client (channel_is_client in 0.3.1.1-alpha and later
 correctly identifies unauthenticated peers, which are clients and
 bridges).

 For HSv2, we should allow direct Tor2web client connections by default,
 but have a consensus parameter to turn them off. Direct service
 connections should always be refused,

--

--
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] #22689 [Core Tor/Tor]: hs: Stop intro points being used as single hop proxies

[Tor Bug Tracker & Wiki]

#22689: hs: Stop intro points being used as single hop proxies
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  relay-safety, 033-triage-20180320,   |  Actual Points:
  033-removed-20180320   |
Parent ID:  #17945   | Points:  0.5
 Reviewer:  teor |Sponsor:
-+-
Description changed by teor:

Old description:

> This prevents them knowing both the service and client IP addresses, and
> therefore being targets for network traffic logging, sybil, or hacking
> attacks.
>
> We need to implement the following checks:
> * if the introduction point was made using a direct connection (single
> onion services), refuse direct client connections,
> * if the rend point was made using a direct connection (custom client, no
> tor2web for HSv3), refuse direct service connections (single onion
> services).
>
> See #22688 for how this is done for HSDir3s using channel_is_client().
> The comments in that patch explain why it works.
>
> We could even refactor the common code out of
> connection_dir_is_anonymous() into connection_is_anonymous(), and avoid
> including channel[tls].h into directory.c.
>
> I'm not sure if I will get time to do this, so please feel free to take
> this ticket.

New description:

 This prevents them knowing both the service and client IP addresses, and
 therefore being targets for network traffic logging, sybil, or hacking
 attacks.

 We need to implement the following checks:
 * if the introduction point was made using a direct connection (single
 onion services), refuse direct client connections,
 * ~~if the rend point was made using a direct connection (custom client,
 no tor2web for HSv3), refuse direct service connections (single onion
 services).~~

 See #22688 for how this is done for HSDir3s using channel_is_client(). The
 comments in that patch explain why it works.

 We could even refactor the common code out of
 connection_dir_is_anonymous() into connection_is_anonymous(), and avoid
 including channel[tls].h into directory.c.

 I'm not sure if I will get time to do this, so please feel free to take
 this 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] #22688 [Core Tor/Tor]: hs: stop HSDirs being used as single-hop "proxies" (was: hs: Make sure HSDir never know service, client, or bridge IP addresses)

[Tor Bug Tracker & Wiki]

#22688: hs: stop HSDirs being used as single-hop "proxies"
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, relay-safety,|  Actual Points:  0.3
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #17945   | Points:  0.3
 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] #17945 [Core Tor/Tor]: Stop single hop client connecting to (Rendezvous) Single Onion Services

[Tor Bug Tracker & Wiki]

#17945: Stop single hop client connecting to (Rendezvous) Single Onion Services
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor2web, tor-hs, 029-proposed, 029   |  Actual Points:  0.4
  -teor-no, needs-design, needs-proposal-maybe,  |
  single-onion, review-group-33, |
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #24962   | Points:  5
 Reviewer:  asn, teor|Sponsor:
-+-

Comment (by teor):

 Replying to [comment:58 arma]:
 > Am I missing something here, or did the #24902 change, where relays by
 default now try to tarpit establish-rendezvous requests that come directly
 from clients, accomplish the goals of this ticket? Or were the goals
 broader?

 There aren't any onion service single-hop proxies any more. And no onion
 service relay knows both the client and service address.

 But Tor2web still gives away client IP addresses by connecting directly to
 HSDirs and intro points. Maybe we want a consensus parameter to block this
 insecure behaviour if it causes trouble in future?

 * #22689 is for into points, which still get direct connections from
 Tor2web clients, but all services and other clients always use 3-hop
 connections
 * #22688 is for HSDirs, which still get direct connections from Tor2web
 clients, but all services and other clients always use 3-hop connections

--
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] #22689 [Core Tor/Tor]: hs: Stop intro points being used as single hop proxies (was: hs: Stop rend and intro points being used as single hop proxies)

[Tor Bug Tracker & Wiki]

#22689: hs: Stop intro points being used as single hop proxies
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  relay-safety, 033-triage-20180320,   |  Actual Points:
  033-removed-20180320   |
Parent ID:  #17945   | Points:  0.5
 Reviewer:  teor |Sponsor:
-+-

Comment (by teor):

 #24902 stops rend points being used as single hop proxies, but we still
 need to fix intro points (and HSDirs).

--
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] #26581 [Applications/Tor Browser]: Import "Healthy Onions" to Tor Browser

[Tor Bug Tracker & Wiki]

#26581: Import "Healthy Onions" to Tor Browser
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


Comment:

 > I can list 101 reasons

 Where?

--
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] #21200 [Applications/Tor Browser]: Move all TB Mozilla service calls to .onions

[Tor Bug Tracker & Wiki]

#21200: Move all TB Mozilla service calls to .onions
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by tom):

 Replying to [comment:8 arma]:
 > Is there any new thinking here? Is somebody waiting for v3 onion
 services to be a thing? Would they want to set them up with some sort of
 onionbalance framework, for robustness? It would be nice to have a
 checklist of desired features/steps, so we can work to check them off, and
 so we can notice when the list has become empty.

 There is no new thinking, and we are not waiting on any features from Tor
 on this. It's simply not been something the services team at Mozilla has
 added to their target list yet.

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

Re: [tor-bugs] #21200 [Applications/Tor Browser]: Move all TB Mozilla service calls to .onions

[Tor Bug Tracker & Wiki]

#21200: Move all TB Mozilla service calls to .onions
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arma):

 * cc: dgoulet (added)


Comment:

 cc'ing dgoulet since last i checked he is the keeper of the "what do we
 need to do before v3 onion services are at feature parity" list.

--
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] #21200 [Applications/Tor Browser]: Move all TB Mozilla service calls to .onions

[Tor Bug Tracker & Wiki]

#21200: Move all TB Mozilla service calls to .onions
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 An onion service for addons.mozilla.org would be *awesome*, because
 addons.m.o keeps being the center of attention in various "what if they
 can mess with the cert" attacks.

 Is there any new thinking here? Is somebody waiting for v3 onion services
 to be a thing? Would they want to set them up with some sort of
 onionbalance framework, for robustness? It would be nice to have a
 checklist of desired features/steps, so we can work to check them off, and
 so we can notice when the list has become empty.

--
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] #24299 [Core Tor/Tor]: Allow onion services to distinguish clients from each other

[Tor Bug Tracker & Wiki]

#24299: Allow onion services to distinguish clients from each other
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, tor-dos,|  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #24298   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 See also the work being done in #4700, which could be the same work as
 this ticket wants.

--
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] #4700 [Core Tor/Tor]: Tor should provide a mechanism for hidden services to differentiate authorized clients and circuits

[Tor Bug Tracker & Wiki]

#4700: Tor should provide a mechanism for hidden services to differentiate
authorized clients and circuits
-+-
 Reporter:  katmagic |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-control, needs-proposal, tor-hs  |  Actual Points:
  needs-design, 035-proposed |
Parent ID:   | Points:  10
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 ahf, do I remember that you had a patch for this one? Is it nearly-ready-
 but-sitting-in-a-mailbox-somewhere?

--
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] #4700 [Core Tor/Tor]: Tor should provide a mechanism for hidden services to differentiate authorized clients and circuits

[Tor Bug Tracker & Wiki]

#4700: Tor should provide a mechanism for hidden services to differentiate
authorized clients and circuits
-+-
 Reporter:  katmagic |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-control, needs-proposal, tor-hs  |  Actual Points:
  needs-design, 035-proposed |
Parent ID:   | Points:  10
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 See also #24299 which looks very related.

--
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] #17945 [Core Tor/Tor]: Stop single hop client connecting to (Rendezvous) Single Onion Services

[Tor Bug Tracker & Wiki]

#17945: Stop single hop client connecting to (Rendezvous) Single Onion Services
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor2web, tor-hs, 029-proposed, 029   |  Actual Points:  0.4
  -teor-no, needs-design, needs-proposal-maybe,  |
  single-onion, review-group-33, |
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #24962   | Points:  5
 Reviewer:  asn, teor|Sponsor:
-+-

Comment (by arma):

 Am I missing something here, or did the #24902 change, where relays by
 default now try to tarpit establish-rendezvous requests that come directly
 from clients, accomplish the goals of this ticket? Or were the goals
 broader?

--
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] #26590 [Applications/Tor Browser]: SVG isn't blocked in Safest security setting with 8.0a9

[Tor Bug Tracker & Wiki]

#26590: SVG isn't blocked in Safest security setting with 8.0a9
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by mcs):

 Replying to [comment:1 cypherpunks]:
 > Looking at `about:support` one does find
 >
 > `svg.in-content.enabled   false`

 Looking at https://bugzilla.mozilla.org/show_bug.cgi?id=1216893, it looks
 like the correct pref name is now `svg.disabled`. Does the incorrect
 behavior you observed disappear if you use about:config to set that pref
 to false?

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

Re: [tor-bugs] #24104 [Core Tor/Tor]: Delay descriptor bandwidth reporting on established relays (was: Delay descriptor bandwidth reporting on large relays)

[Tor Bug Tracker & Wiki]

#24104: Delay descriptor bandwidth reporting on established relays
-+-
 Reporter:  teor |  Owner:  juga
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  034-backport-maybe, 033-backport-|  Actual Points:
  maybe, 032-backport-maybe, 031-backport-   |
  maybe, 029-backport-maybe, security-low,   |
  guard-discovery-stats, chutney-wants, bwauth-  |
  wants, 034-triage-20180328,|
  034-removed-20180328, tor-bwauth   |
Parent ID:  #25925   | Points:  1
 Reviewer:  ahf  |Sponsor:
-+-

Comment (by arma):

 (changing ticket title to reflect the new plan)

--
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] #24104 [Core Tor/Tor]: Delay descriptor bandwidth reporting on large relays

[Tor Bug Tracker & Wiki]

#24104: Delay descriptor bandwidth reporting on large relays
-+-
 Reporter:  teor |  Owner:  juga
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  034-backport-maybe, 033-backport-|  Actual Points:
  maybe, 032-backport-maybe, 031-backport-   |
  maybe, 029-backport-maybe, security-low,   |
  guard-discovery-stats, chutney-wants, bwauth-  |
  wants, 034-triage-20180328,|
  034-removed-20180328, tor-bwauth   |
Parent ID:  #25925   | Points:  1
 Reviewer:  ahf  |Sponsor:
-+-

Comment (by arma):

 Replying to [comment:31 arma]:
 > So I resume liking the "proceed if we_are_hibernating()" idea as the
 simplest fix.

 To be clear (and to save you time), I was thinking something like
 {{{
 diff --git a/src/or/router.c b/src/or/router.c
 index 4afba65..f1a9936 100644
 --- a/src/or/router.c
 +++ b/src/or/router.c
 @@ -2440,17 +2440,18 @@ check_descriptor_bandwidth_changed(time_t now)
  {
static time_t last_changed = 0;
uint64_t prev, cur;
 +  int hibernating = we_are_hibernating();

/* If the relay uptime is bigger than MAX_UPTIME_BANDWIDTH_CHANGE,
 * the next regularly scheduled descriptor update (18h) will be enough
 */
 -  if (get_uptime() > MAX_UPTIME_BANDWIDTH_CHANGE)
 +  if (get_uptime() > MAX_UPTIME_BANDWIDTH_CHANGE && !hibernating)
  return;

if (!router_get_my_routerinfo())
  return;

prev = router_get_my_routerinfo()->bandwidthcapacity;
 -  cur = we_are_hibernating() ? 0 : rep_hist_bandwidth_assess();
 +  cur = hibernating ? 0 : rep_hist_bandwidth_assess();
if ((prev != cur && (!prev || !cur)) ||
cur > (prev * BANDWIDTH_CHANGE_FACTOR) ||
cur < (prev / BANDWIDTH_CHANGE_FACTOR) ) {
 }}}

 And then don't forget to open the ticket for the follow-on (but can be
 handled separately) work. :)

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

Re: [tor-bugs] #24104 [Core Tor/Tor]: Delay descriptor bandwidth reporting on large relays

[Tor Bug Tracker & Wiki]

#24104: Delay descriptor bandwidth reporting on large relays
-+-
 Reporter:  teor |  Owner:  juga
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  034-backport-maybe, 033-backport-|  Actual Points:
  maybe, 032-backport-maybe, 031-backport-   |
  maybe, 029-backport-maybe, security-low,   |
  guard-discovery-stats, chutney-wants, bwauth-  |
  wants, 034-triage-20180328,|
  034-removed-20180328, tor-bwauth   |
Parent ID:  #25925   | Points:  1
 Reviewer:  ahf  |Sponsor:
-+-

Comment (by arma):

 I continue to like the general idea of this patch.

 Some code review suggestions:

 In the changes file, it says "bigger than 24h" but I think we mean
 "smaller than 24h".

 Juga, you might want to add a config line to your editor that complains to
 you about lines with trailing whitespace. There are some in test_router.c.

 This is a lot of fixups (which is fine), so somebody might want to squash
 it before the merge.

 The change as done here will mean we stop publishing a new descriptor when
 we go hibernating (see how check_descriptor_bandwidth_changed() checks
 we_are_hibernating() and sets cur to 0 if so). One simple fix would be for
 the function to still proceed if we_are_hibernating(), so we still let
 everybody know when we start hibernating. But another fix that I like a
 bit more would be to add a separate mark_my_descriptor_dirty() call when
 we decide to start hibernating... on more thought though, that should be a
 separate fix ("publish a new descriptor explicitly when we begin/end
 hibernating") that can be done separately from this fix and shouldn't
 delay it. So I resume liking the "proceed if we_are_hibernating()" idea as
 the simplest fix.

 Speaking of hibernating, I also checked if this change makes us not
 publish a descriptor when we wake up from hibernating. I think it's ok,
 because see how hibernate_end() calls reset_uptime(), so now
 check_descriptor_bandwidth_changed() will be willing to proceed. All the
 more reason to open the "explicitly mark descriptor dirty when
 beginning/ending hibernation, rather than implicitly doing it as part of
 the bandwidth check" ticket.

 We also reset_uptime(), and thus become willing to publish descriptors
 more readily for bandwidth changes, when our external IP address changes.
 I think that's ok, since it should not be an easy thing for an attacker to
 induce.

--
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] #25786 [Core Tor/Tor]: Policies for HTTPTunnelPort

[Tor Bug Tracker & Wiki]

#25786: Policies for HTTPTunnelPort
--+--
 Reporter:  pyhedgehog|  Owner:  neel
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by neel):

 * status:  assigned => new


--
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] #3723 [Core Tor/Tor]: Report version of bwscanners in votes

[Tor Bug Tracker & Wiki]

#3723: Report version of bwscanners in votes
--+
 Reporter:  mikeperry |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bwauth|  Actual Points:
Parent ID:  #25925| Points:
 Reviewer:  teor  |Sponsor:
--+

Comment (by teor):

 Replying to [comment:26 juga]:
 > Rebased to master and continuing on
 ​https://github.com/torproject/tor/pull/195.

 When I'm reviewing, I find rebases and new pull requests really confusing.
 I lose all my past GitHub comments, and I have to switch between the old
 and new pull requests. (Some people like new pull requests, I've just
 found out that I don't..)

 So can we leave any more rebases until the patch is complete?

--
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] #26590 [Applications/Tor Browser]: SVG isn't blocked in Safest security setting with 8.0a9

[Tor Bug Tracker & Wiki]

#26590: SVG isn't blocked in Safest security setting with 8.0a9
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 Replying to [comment:2 gk]:
 > Replying to [ticket:26590 cypherpunks]:
 > > SVG doesn't seem to be blocked in Safest security setting with 8.0a9
 (Linux)
 >
 > What makes you believe so? Do you have an example that is blocked in Tor
 Browser stable but not in the alpha?
 I just noticed that quickly while going into my Github account and trying
 to report an issue and I saw that the "edit" button icon was present when
 normally it wasn't with the stable series [I may be wrong though if Github
 added a png fallback, so very sorry in that case for my misleading report]
 (as well as the non-presence of the canvas anti-fp notification on first
 visit to Github, though that may be a fix in Firefox?)

--
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] #26594 [Core Tor/Tor]: Tor becomes unresponsive after configuration handling on Windows

[Tor Bug Tracker & Wiki]

#26594: Tor becomes unresponsive after configuration handling on Windows
--+--
 Reporter:  ahf   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by ahf):

 Hello71 on #tor-dev says that the issue is reproducible in Wine as well.

--
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] #23359 [Applications/Tor Browser]: WebExtensions icons are not shown on first start but on restart

[Tor Bug Tracker & Wiki]

#23359: WebExtensions icons are not shown on first start but on restart
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff60-esr, AffectsTails|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * priority:  Medium => High


--
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] #26517 [Applications/Tor Browser]: When I have security setting set to "Safest" and I open NoScrip's preferences and click reset, TorBrowser still says Security setting "Safest" even th

[Tor Bug Tracker & Wiki]

#26517: When I have security setting set to "Safest" and I open NoScrip's
preferences and click reset, TorBrowser still says Security setting
"Safest" even though many sites are now whitelisted
---+--
 Reporter:  Dbryrtfbcbhgf  |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Major  | Resolution:
 Keywords:  ff60-esr, tbb-security-slider  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

 * keywords:   => ff60-esr, tbb-security-slider


Old description:

> When I have security setting set to "Safest" and I open NoScrip's
> preferences and click reset, TorBrowser still says Security setting
> "Safest" even though many sites are now whitelisted. I attached a video
> showing the bug. TorBrowser 8a9

New description:

 When I have security setting set to "Safest" and I open NoScript's
 preferences and click reset, TorBrowser still says Security setting
 "Safest" even though many sites are now whitelisted. I attached a video
 showing the bug. TorBrowser 8a9

--

--
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] #26579 [Applications/Tor Browser]: about:tor very slow to load

[Tor Bug Tracker & Wiki]

#26579: about:tor very slow to load
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #23073| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * parent:   => #23073


Comment:

 I actually think that's due to selfrando. Because when new content
 processes are created the randomization gets launched and it takes while
 until this is finished. I noticed that in the esr52-based alpha series,
 too, although I have to agree that it got worse when switching to esr60,
 probably due to increased binary size.

 I could be wrong, though. But let's tag it as a selfrando bug barring
 further investigation.

--
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] #26590 [Applications/Tor Browser]: SVG isn't blocked in Safest security setting with 8.0a9

[Tor Bug Tracker & Wiki]

#26590: SVG isn't blocked in Safest security setting with 8.0a9
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information


Comment:

 Replying to [ticket:26590 cypherpunks]:
 > SVG doesn't seem to be blocked in Safest security setting with 8.0a9
 (Linux)

 What makes you believe so? Do you have an example that is blocked in Tor
 Browser stable but not in the alpha?

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

Re: [tor-bugs] #26582 [Applications/Tor Browser]: Disable DNT for all Tor Browser users.

[Tor Bug Tracker & Wiki]

#26582: Disable DNT for all Tor Browser users.
--+
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

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


Comment:

 `privacy.donottrackheader.enabled` is set to `false` in my Tor Browser.
 Thus, it seems you messed with your settings and have it enabled now.

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

Re: [tor-bugs] #26594 [Core Tor/Tor]: Tor becomes unresponsive after configuration handling on Windows

[Tor Bug Tracker & Wiki]

#26594: Tor becomes unresponsive after configuration handling on Windows
--+--
 Reporter:  ahf   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by ahf):

 Just a short note after some confusion in #tor-dev. I only *compile* Tor
 in WSL, but we run it *outside* of WSL in the normal Windows environment.
 Building Tor where the target is a "native" Linux binary runs fine via WSL
 (and isn't interesting for this 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

Re: [tor-bugs] #25485 [Applications/Tor Browser]: Browser/TorBrowser/Tor/libstdc++.so.6: version `CXXABI_1.3.11' not found (required by /usr/lib/x86_64-linux-gnu/libmirclient.so.9)

[Tor Bug Tracker & Wiki]

#25485: Browser/TorBrowser/Tor/libstdc++.so.6: version `CXXABI_1.3.11' not found
(required by /usr/lib/x86_64-linux-gnu/libmirclient.so.9)
+--
 Reporter:  cypherpunks |  Owner:  tbb-team
 Type:  defect  | Status:  reopened
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201806  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

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


Comment:

 Ugh, wrong 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] #25485 [Applications/Tor Browser]: Browser/TorBrowser/Tor/libstdc++.so.6: version `CXXABI_1.3.11' not found (required by /usr/lib/x86_64-linux-gnu/libmirclient.so.9)

[Tor Bug Tracker & Wiki]

#25485: Browser/TorBrowser/Tor/libstdc++.so.6: version `CXXABI_1.3.11' not found
(required by /usr/lib/x86_64-linux-gnu/libmirclient.so.9)
+
 Reporter:  cypherpunks |  Owner:  tbb-team
 Type:  defect  | Status:  closed
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  worksforme
 Keywords:  ff60-esr, TorBrowserTeam201806  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by gk):

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


Comment:

 `privacy.donottrackheader.enabled` is set to `false` in my Tor Browser.
 Thus, it seems you messed with your settings and have it enabled now.

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

Re: [tor-bugs] #26589 [Applications/Tor Browser]: Tor Browser 8.0a9 will not start on Ubuntu 17.10.

[Tor Bug Tracker & Wiki]

#26589: Tor Browser 8.0a9 will not start on Ubuntu 17.10.
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  ff60-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Duplicate of #25485.

--
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] #25485 [Applications/Tor Browser]: Browser/TorBrowser/Tor/libstdc++.so.6: version `CXXABI_1.3.11' not found (required by /usr/lib/x86_64-linux-gnu/libmirclient.so.9)

[Tor Bug Tracker & Wiki]

#25485: Browser/TorBrowser/Tor/libstdc++.so.6: version `CXXABI_1.3.11' not found
(required by /usr/lib/x86_64-linux-gnu/libmirclient.so.9)
+--
 Reporter:  cypherpunks |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201806  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * keywords:  ff60-esr => ff60-esr, TorBrowserTeam201806
 * priority:  High => Very High


Comment:

 #26589 is 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

[tor-bugs] #26594 [Core Tor/Tor]: Tor becomes unresponsive after configuration handling on Windows

[Tor Bug Tracker & Wiki]

#26594: Tor becomes unresponsive after configuration handling on Windows
--+--
 Reporter:  ahf   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 When trying to start Tor from master (as of commit
 `adcd1d8b9ac09f3abc11e2e3187fe363ad3df2fd`), Tor will never progress from
 the initial configuration handling that is happening before we bootstrap.

 When starting Tor the following output will appear:

 {{{
 PS
 
C:\Users\ahf\AppData\Local\Packages\TheDebianProject.DebianGNULinux_76v4gfsz19hv4\LocalState\rootfs\home\ahf\src\github.com\ahf
 \tor-win32\src\tor> .\src\or\tor.exe
 Jul 01 20:58:33.065 [notice] Tor 0.3.5.0-alpha-dev (git-adcd1d8b9ac09f3a)
 running on Windows 8 with Libevent 2.1.8-stable, OpenSSL 1.0.2n, Zlib
 1.2.11, Liblzma N/A, and Libzstd N/A.
 Jul 01 20:58:33.068 [notice] Tor can't help you if you use it wrong! Learn
 how to be safe at https://www.torproject.org/download/download#warning
 Jul 01 20:58:33.069 [notice] This version is not a stable Tor release.
 Expect more bugs than usual.
 Jul 01 20:58:33.084 [notice] Configuration file
 "C:\Users\ahf\AppData\Roaming\tor\torrc" not present, using reasonable
 defaults.
 Jul 01 20:58:33.086 [warn] Path for GeoIPFile () is relative and
 will resolve to
 
C:\Users\ahf\AppData\Local\Packages\TheDebianProject.DebianGNULinux_76v4gfsz19hv4\LocalState\rootfs\home\ahf\src\github.com\ahf
 \tor-win32\src\tor\. Is this what you wanted?
 Jul 01 20:58:33.086 [warn] Path for GeoIPv6File () is relative
 and will resolve to
 
C:\Users\ahf\AppData\Local\Packages\TheDebianProject.DebianGNULinux_76v4gfsz19hv4\LocalState\rootfs\home\ahf\src\github.com\ahf
 \tor-win32\src\tor\. Is this what you wanted?
 }}}

 After this the process becomes unresponsive. The "Scheduler type KISTLite
 has been enabled." NOTICE log message is expected here, but is never
 shown.

 === Bisecting the issue ===

 I tried to bisect the issue and it looks like the issue began to show up
 after commit `696f6f15697260255146d634e1529202cc4c2b77` (the commit itself
 doesn't compile on Windows, but the following couple of commits are
 related fixes to that patch). The first commit that I can compile where
 this issue appears is `0b7452eeb2f2dee7acefee2d3ca2cb402a877ea1`.


 === Analysis ===

 I managed to track the issue down to a call to `strcasecmp()` in
 `config_lines_eq()` in `src/lib/encoding/confline.c`. I added the
 following debug output to get a slightly better understanding of what was
 going on (since gdb wasn't of much help here):

 {{{
 diff --git a/src/lib/encoding/confline.c b/src/lib/encoding/confline.c
 index 7f535b321..4544465d3 100644
 --- a/src/lib/encoding/confline.c
 +++ b/src/lib/encoding/confline.c
 @@ -14,6 +14,9 @@
  #include "lib/string/util_string.h"

  #include 
 +#include 
 +
 +#define AHF_DEBUG(...) do { printf(__VA_ARGS__); fflush(stdout); } while
 (0)

  /** Helper: allocate a new configuration option mapping 'key' to 'val',
   * append it to *lst. */
 @@ -232,8 +235,26 @@ int
  config_lines_eq(config_line_t *a, config_line_t *b)
  {
while (a && b) {
 +AHF_DEBUG("a: %p\n", a);
 +AHF_DEBUG("b: %p\n", b);
 +
 +AHF_DEBUG("a->key:   %p\n", a->key);
 +AHF_DEBUG("a->value: %p\n", a->value);
 +AHF_DEBUG("a->next:  %p\n\n", a->next);
 +
 +AHF_DEBUG("b->key:   %p\n", b->key);
 +AHF_DEBUG("b->value: %p\n", b->value);
 +AHF_DEBUG("b->next:  %p\n\n", b->next);
 +
 +AHF_DEBUG("a->key: '%s'\n", a->key);
 +AHF_DEBUG("a->value: '%s'\n", a->value);
 +
 +AHF_DEBUG("b->key: '%s'\n", b->key);
 +AHF_DEBUG("b->value: '%s'\n", b->value);
 +
  if (strcasecmp(a->key, b->key) || strcmp(a->value, b->value))
return 0;
  a = a->next;
  b = b->next;
}
 }}}

 Tor would now output the following when started:

 {{{
 $ ./src/or/tor.exe
 Jul 01 21:24:47.029 [notice] Tor 0.3.5.0-alpha-dev (git-0b7452eeb2f2dee7)
 running on Very recent version of Windows [major=10,minor=0] with Libevent
 2.1.8-stable, OpenSSL 1.0.2o, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd N/A.
 Jul 01 21:24:47.029 [notice] Tor can't help you if you use it wrong! Learn
 how to be safe at https://www.torproject.org/download/download#warning
 Jul 01 21:24:47.029 [notice] This version is not a stable Tor release.
 Expect more bugs than usual.
 Jul 01 21:24:47.039 [notice] Configuration file
 "C:\Users\ahf\AppData\Roaming\tor\torrc" not present, using reasonable
 defaults.
 Jul 01 21:24:47.041 [warn] Path for GeoIPFile () is relative and
 will resolve to C:\msys64\home\ahf\src\github.com\ahf\tor\. Is
 this what you wanted?
 Jul 01 

Re: [tor-bugs] #26593 [Core Tor/Tor]: Split even more things out of or.h

[Tor Bug Tracker & Wiki]

#26593: Split even more things out of or.h
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:  Sponsor3-can
--+
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 PR at https://github.com/torproject/tor/pull/196 for a branch called
 "split_or_h_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

[tor-bugs] #26593 [Core Tor/Tor]: Split even more things out of or.h

[Tor Bug Tracker & Wiki]

#26593: Split even more things out of or.h
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:  dgoulet
  Sponsor:  Sponsor3-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] #3723 [Core Tor/Tor]: Report version of bwscanners in votes

[Tor Bug Tracker & Wiki]

#3723: Report version of bwscanners in votes
--+
 Reporter:  mikeperry |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bwauth|  Actual Points:
Parent ID:  #25925| Points:
 Reviewer:  teor  |Sponsor:
--+
Changes (by juga):

 * status:  needs_revision => needs_review


Comment:

 Rebased to master and continuing on
 ​https://github.com/torproject/tor/pull/195.

--
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] #26454 [Internal Services/Tor Sysadmin Team]: Please create email alias/forwarding and LDAP for Shane

[Tor Bug Tracker & Wiki]

#26454: Please create email alias/forwarding and LDAP for Shane
-+
 Reporter:  ewyatt   |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  High |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by qbi):

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


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

Re: [tor-bugs] #25774 [Metrics/Ideas]: Record latency measurements using OnionPerf

[Tor Bug Tracker & Wiki]

#25774: Record latency measurements using OnionPerf
---+
 Reporter:  irl|  Owner:  metrics-team
 Type:  project| Status:  needs_revision
 Priority:  Medium |  Milestone:
Component:  Metrics/Ideas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer:  irl|Sponsor:
---+
Changes (by irl):

 * status:  needs_review => needs_revision
 * reviewer:   => irl


Comment:

 Replying to [comment:1 karsten]:
 > If we were to put this on Tor Metrics, we'd probably make the source
 configurable and display either all sources at once or just a single one
 of them. And we'd probably stack the three graphs for the hops vertically,
 rather than horizontally, or alternatively use three colors for the three
 hops.

 This sounds good. This is not how I was expecting the graphs to look, the
 2nd hop seems to happen faster than the 1st hop. Perhaps there are some
 overheads we incur on the 1st hop that regular clients wouldn't have
 because we don't use guards. (I don't think we can fix this, it's just
 something we should work out and document.)

 It looks like there is overlap in the ranges for the 2nd and 3rd hops, so
 I think having separate plots is necessary and putting the 3 on the same
 plot with different colours wouldn't be readable.

 The plots that share the same row are easier to compare than those that
 share the same column, so we should consider what users may want to
 compare.

 For parameters, the current parameters for the existing performance graphs
 are all applicable except that it probably does not make sense to have
 this for the onion measurements.

 > I think this already addesses the "circuit build latency" part in the
 ticket description. What exactly is meant by "end-to-end latency" there?
 Maybe there's data for that, too.

 End-to-end latency is the latency to send data across the circuit. From
 looking at the TorPerf spec, this would be the difference between
 DATAREQUEST and DATARESPONSE divided by 2.

--
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] #23359 [Applications/Tor Browser]: WebExtensions icons are not shown on first start but on restart

[Tor Bug Tracker & Wiki]

#23359: WebExtensions icons are not shown on first start but on restart
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff60-esr, AffectsTails|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by intrigeri):

 * keywords:  ff60-esr => ff60-esr, AffectsTails


Comment:

 Might this be related to the code guarded by
 `extensions.torbutton.inserted_button` in
 `src/chrome/content/torbutton.js`?

 We've had workarounds for similar issues in Tails forever and they're not
 working anymore in 8.0 so I've dropped them and I'm now very interested in
 seeing this fixed for real in 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] #26554 [Applications/Tor Browser]: Clean-up the toolbar in Tor Browser based on ESR60

[Tor Bug Tracker & Wiki]

#26554: Clean-up the toolbar in Tor Browser based on ESR60
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201806  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by intrigeri):

 * cc: intrigeri (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] #23359 [Applications/Tor Browser]: WebExtensions icons are not shown on first start but on restart

[Tor Bug Tracker & Wiki]

#23359: WebExtensions icons are not shown on first start but on restart
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff60-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by intrigeri):

 * cc: intrigeri (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] #26553 [Applications/Tor Browser]: Sign our own extensions in Tor Browser

[Tor Bug Tracker & Wiki]

#26553: Sign our own extensions in Tor Browser
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, tbb-security,  |  Actual Points:
  TorBrowserTeam201806, GeorgKoppen201806|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by intrigeri):

 * cc: intrigeri (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] #26520 [Applications/Tor Browser]: NoScript is broken with TOR_SKIP_LAUNCH=1 in ESR 60-based Tor Browser

[Tor Bug Tracker & Wiki]

#26520: NoScript is broken with TOR_SKIP_LAUNCH=1 in ESR 60-based Tor Browser
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201806  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by intrigeri):

 * cc: intrigeri (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] #22582 [Applications/Tor Browser]: www.nexusmods.com not working properly in TOR

[Tor Bug Tracker & Wiki]

#22582: www.nexusmods.com not working properly in TOR
---+--
 Reporter:  WalrusInAnus   |  Owner:  tbb-team
 Type:  defect | Status:  reopened
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-usability-website, cloudflare  |  Actual Points:
Parent ID:  #18361 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by WalrusInAnus):

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


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

Re: [tor-bugs] #22582 [Applications/Tor Browser]: www.nexusmods.com not working properly in TOR

[Tor Bug Tracker & Wiki]

#22582: www.nexusmods.com not working properly in TOR
---+---
 Reporter:  WalrusInAnus   |  Owner:  tbb-team
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
   |  worksforme
 Keywords:  tbb-usability-website, cloudflare  |  Actual Points:
Parent ID:  #18361 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by WalrusInAnus):

 Replying to [comment:25 cypherpunks]:
 > works for me

 Which part of "Again, please don't close random bugs. This is still an
 issue." did you not understand? Are you an idiot?

 The horizontal tabs (Description, Files, Images,...) no longer display E
 instead of content, but no matter which one you click on, the contents are
 the same.

--
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] #26580 [Core Tor/Torsocks]: torsocks complains about unknown system call #417 on FreeBSD

[Tor Bug Tracker & Wiki]

#26580: torsocks complains about unknown system call #417 on FreeBSD
---+-
 Reporter:  yurivict271|  Owner:  dgoulet
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Torsocks  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by yurivict271):

 All unknown system calls should be passed, because they have nothing to do
 with socket operations. This would be a correct fix of 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] #26585 [Metrics/Onionoo]: improve AS number and name coverage (switch maxmind to RIPE Stat)

[Tor Bug Tracker & Wiki]

#26585: improve AS number and name coverage (switch maxmind to RIPE Stat)
-+--
 Reporter:  nusenu   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by cypherpunks):

 * keywords:  metrics-geoip =>


Comment:

 Replying to [comment:1 irl]:
 > For country codes

 This ticket is about AS data (number and name).

 (RIPEstat uses maxmind itself, so it does not make much sense to use
 RIPEstat for geolocation
 to replace maxmind?)
 https://stat.ripe.net/docs/data_api#Geoloc


 > 2 relays for which RIPEstat did not return an AS number

 when posting numbers, please include specific APIs used and with what
 parameters (as some RIPEstat APIs filter prefixes with low visibility by
 default)


 > It is not clear to me what our threshold on agreement should be. As the
 MaxMind database is distributed to users and can be used, for example, to
 disable/prefer the use of exit relays in specific countries,

 onionoo data is not directly used by tor client daemons in any way (or to
 disable specific exits)


 > We should conduct an analysis of the different databases and feeds
 available to us, to determine which best fits our requirements.

 what are the specific onionoo requirements?


 > As for querying RIPEstat, I have [[https://github.com/britram/canid|a
 tool]] which I have used in the above analysis

 Note, that canid does not use the specific APIs listed in the first post
 of this ticket according to their README on github.


 > I don't believe we should consider outright replacing MaxMind with
 RIPEstat for the reason that we distribute this to end clients

 what is a 'end client' in the onionoo context? is RS an end client?


 > to make it clear to users where the information has come from if that is
 important to them.

 transparency is always positive

 This ticket is the preparation to add BGP ROA enums in the future.

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

Re: [tor-bugs] #22203 [Core Tor/Tor]: Should a hup reload the geoip files?

[Tor Bug Tracker & Wiki]

#22203: Should a hup reload the geoip files?
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  intro tor-client tor-relay geoip |  Actual Points:
  hup configuration reload metrics-geoip |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by irl):

 * keywords:  intro tor-client tor-relay geoip  hup configuration reload =>
 intro tor-client tor-relay geoip  hup configuration reload metrics-
 geoip


--
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] #26592 [Community/Tor Support]: Can load cnn but not fox news

[Tor Bug Tracker & Wiki]

#26592: Can load cnn but not fox news
---+---
 Reporter:  friardave  |  Owner:  phoul
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:  not a bug
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by cypherpunks):

 Try to contact foxnews to tell them to allow Tor users.

--
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: #2506, #21909, #25542, #26240, ...

[Tor Bug Tracker & Wiki]

Batch modification to #2506, #21909, #25542, #26240, #26585 by irl:


--
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] [Tor Bug Tracker & Wiki] Batch modify: #21909, #25542, #26585

[Tor Bug Tracker & Wiki]

Batch modification to #21909, #25542, #26585 by irl:


--
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] [Tor Bug Tracker & Wiki] Batch modify: #21515, #21909, #25542, #2966

[Tor Bug Tracker & Wiki]

Batch modification to #21515, #21909, #25542, #2966 by irl:


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

Re: [tor-bugs] #26518 [Metrics/Relay Search]: The fourth most popular AS in the Tor network is "(distinct)"?

[Tor Bug Tracker & Wiki]

#26518: The fourth most popular AS in the Tor network is "(distinct)"?
--+--
 Reporter:  arma  |  Owner:  irl
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:  metrics-geoip |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by irl):

 * keywords:   => metrics-geoip


--
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] #26585 [Metrics/Onionoo]: improve AS number and name coverage (switch maxmind to RIPE Stat)

[Tor Bug Tracker & Wiki]

#26585: improve AS number and name coverage (switch maxmind to RIPE Stat)
-+--
 Reporter:  nusenu   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-geoip|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

 * keywords:   => metrics-geoip


--
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] #24104 [Core Tor/Tor]: Delay descriptor bandwidth reporting on large relays

[Tor Bug Tracker & Wiki]

#24104: Delay descriptor bandwidth reporting on large relays
-+-
 Reporter:  teor |  Owner:  juga
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  034-backport-maybe, 033-backport-|  Actual Points:
  maybe, 032-backport-maybe, 031-backport-   |
  maybe, 029-backport-maybe, security-low,   |
  guard-discovery-stats, chutney-wants, bwauth-  |
  wants, 034-triage-20180328,|
  034-removed-20180328, tor-bwauth   |
Parent ID:  #25925   | Points:  1
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by nickm):

 * status:  merge_ready => needs_revision
 * cc: arma (added)


Comment:

 One issue I spotted: the router tests won't actually run, since they
 aren't in the big list at the end of tests.c.

 I'd also like Roger to look at this before we merge: this is a good idea,
 but it reduces the frequency with which we upload descriptors, and that
 has historically caused weird issues.

--
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] #26592 [Community/Tor Support]: Can load cnn but not fox news

[Tor Bug Tracker & Wiki]

#26592: Can load cnn but not fox news
---+---
 Reporter:  friardave  |  Owner:  phoul
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:  not a bug
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * status:  new => closed
 * resolution:   => not a bug
 * component:  Webpages => Community/Tor Support
 * owner:  (none) => phoul


Comment:

 It looks like https://www.foxnews.com/ uses a content delivery network,
 and they block Tor exits. Perhaps they don't know, or they don't care
 about their users' anonymity.

 It looks like https://www.cnn.com/ doesn't block Tor exits. Maybe they've
 though about their users' anonymity, or maybe they also don't care, and
 just happened to choose a different content delivery network.

 We regularly publish blog posts about different kinds of censorship, like
 this one about Internet provider censorship:
 https://blog.torproject.org/siti-networks-india-wants-me-pay-unblock-tor

 But there's not much we can do to help, sorry!

--
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] #26541 [Core Tor/Tor]: Fix minor mistakes in the bandwidth-file dir-spec entry

[Tor Bug Tracker & Wiki]

#26541: Fix minor mistakes in the bandwidth-file dir-spec entry
-+
 Reporter:  teor |  Owner:  juga
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-bwauth, torspec  |  Actual Points:
Parent ID:  #3723| Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

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


Comment:

 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] #26270 [Core Tor/Tor]: Move dirauth module code from src/or/dirauth to src/dirauth

[Tor Bug Tracker & Wiki]

#26270: Move dirauth module code from src/or/dirauth to src/dirauth
-+-
 Reporter:  ahf  |  Owner:  ahf
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  tor-dirauth, modularization, |  Actual Points:
  refactor   |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor8
-+-
Changes (by nickm):

 * status:  merge_ready => closed
 * resolution:   => wontfix


Comment:

 I think we should wontfix this -- it will conflict with the planned code
 movement into src/feature/dirauth/.

--
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] #26580 [Core Tor/Torsocks]: torsocks complains about unknown system call #417 on FreeBSD

[Tor Bug Tracker & Wiki]

#26580: torsocks complains about unknown system call #417 on FreeBSD
---+-
 Reporter:  yurivict271|  Owner:  dgoulet
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Torsocks  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by nickm):

 * owner:  (none) => dgoulet
 * component:  - Select a component => Core Tor/Torsocks


--
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] #26592 [Webpages]: Can load cnn but not fox news

[Tor Bug Tracker & Wiki]

#26592: Can load cnn but not fox news
---+
 Reporter:  friardave  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages   |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by friardave):

 I forgot to say that I cannot access foxnews.com on tor.Replying to
 [ticket:26592 friardave]:
 > My homepage on other browsers is www.foxnews.com. I can access cnn on
 tor. Why is that?

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

[tor-bugs] #26592 [Webpages]: Can load cnn but not fox news

[Tor Bug Tracker & Wiki]

#26592: Can load cnn but not fox news
---+
 Reporter:  friardave  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages   |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 My homepage on other browsers is www.foxnews.com. I can access cnn on tor.
 Why is 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] #20532 [Core Tor/Tor]: Make sure directory_initiate_request handles pluggable transports correctly

[Tor Bug Tracker & Wiki]

#20532: Make sure directory_initiate_request handles pluggable transports 
correctly
-+-
 Reporter:  teor |  Owner:
 |  catalyst
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  bridge-client, bridge-bypass,|  Actual Points:
  031-backport   |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
 |  SponsorM
-+-
Changes (by teor):

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


Comment:

 If we don't think we need to merge this to 0.2.9, it should be closed. I
 un-parented the child 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] #24020 [Core Tor/Tor]: Can authorities use multihop circuits rather than direct connections to detect running routers?

[Tor Bug Tracker & Wiki]

#24020: Can authorities use multihop circuits rather than direct connections to
detect running routers?
+--
 Reporter:  nickm   |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  durauth, bridge-bypass  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 We can't rely on other relays to build circuits for authorities, unless
 the network has better load balancing. At the moment, high-weight relays
 fail a lot of circuits.

--
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] #24020 [Core Tor/Tor]: Can authorities use multihop circuits rather than direct connections to detect running routers?

[Tor Bug Tracker & Wiki]

#24020: Can authorities use multihop circuits rather than direct connections to
detect running routers?
+--
 Reporter:  nickm   |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  durauth, bridge-bypass  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by teor):

 * parent:  #20532 =>


Comment:

 Un-parenting to close the parent 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] #26585 [Metrics/Onionoo]: improve AS number and name coverage (switch maxmind to RIPE Stat)

[Tor Bug Tracker & Wiki]

#26585: improve AS number and name coverage (switch maxmind to RIPE Stat)
-+--
 Reporter:  nusenu   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

 * Attachment "comparison.csv" added.

 MaxMind and RIPEstat Comparison CSV

--
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] #26585 [Metrics/Onionoo]: improve AS number and name coverage (switch maxmind to RIPE Stat)

[Tor Bug Tracker & Wiki]

#26585: improve AS number and name coverage (switch maxmind to RIPE Stat)
-+--
 Reporter:  nusenu   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by irl):

 For country codes, there are 321 relays where there are disagreement and
 7837 in agreement (κ = 0.959 excluding relays for which MaxMind had no
 country code). There were no relays for which RIPEstat did not return a
 country code, but there were 21 relays for which MaxMind was missing a
 country code. This leaves 300 relays for which both MaxMind and RIPEstat
 had a country code but there was disagreement.

 RIPEstat does return 7 relays with the country code "eu" and 1 relay with
 the country code "ap" for Europe and Asia/Pacific respectively.
 [[https://dev.maxmind.com/geoip/legacy/codes/iso3166/|MaxMind have
 documentation]] indicating that they also use these codes, but did not
 return any results with these codes. In all of these cases, MaxMind did
 not have a country code.

 Without ground truth to compare to, it is not possible to say whether
 MaxMind or RIPEstat are correct in the cases where there were
 disagreement. It is also possible that MaxMind and RIPEstat agree on a
 country code that is incorrect.

 For AS numbers, there are 269 relays where there are disagreement and 7889
 in agreement (κ = 0.979 excluding relays for which either MaxMind or
 RIPEstat had no AS number). There were 101 relays for which MaxMind did
 not return an AS number and 2 relays for which RIPEstat did not return an
 AS number. Both of the relays for which RIPEstat did not return an AS
 number were in the 1.0.0.0/8 BGP prefix which has the "cn" country code
 for RIPEstat, but the "au" country code from MaxMind. MaxMind placed these
 relays in AS 4804.

 It is not clear to me what our threshold on agreement should be. As the
 MaxMind database is distributed to users and can be used, for example, to
 disable/prefer the use of exit relays in specific countries, it may be
 dangerous to users if they get mixed information about the country code
 assigned to relays. It may be equally dangerous to incorrectly assign
 country codes, but without ground truth to compare to it is not possible
 to say whether a switch would improve that situation or not.

 We should conduct an analysis of the different databases and feeds
 available to us, to determine which best fits our requirements. As for
 querying RIPEstat, I have [[https://github.com/britram/canid|a tool]]
 which I have used in the above analysis and would make it easier to
 integrate this into Onionoo if we were to choose to integrate data from
 RIPEstat.

 I don't believe we should consider outright replacing MaxMind with
 RIPEstat for the reason that we distribute this to end clients and we need
 a database that we can do this with, but I can see that having additional
 information when MaxMind does not have any information, and also to add
 the BGP prefix information (finer grained topology information than just
 AS) would be valuable to some users.

 What do you think about the addition of two new fields: 'country_source'
 and 'as_source' to indicate the source of country/as information? We could
 then supplement the MaxMind data with data from RIPEstat where MaxMind
 does not have the information while being able to make it clear to users
 where the information has come from if that is important to them.

 We could also additionally add a 'bgp_prefix' field with prefix data from
 RIPEstat.

--
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] #26523 [Core Tor/Tor]: HSPOST command doesn't parse HSADDRESS argument

[Tor Bug Tracker & Wiki]

#26523: HSPOST command doesn't parse HSADDRESS argument
-+
 Reporter:  akwizgran|  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.4.3-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, tor-control  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+
Changes (by nickm):

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


Comment:

 lgtm too; merged to 0.3.3 and forward.

--
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] #26578 [Core Tor/Tor]: Do clients request new consensus documents more often than we expect?

[Tor Bug Tracker & Wiki]

#26578: Do clients request new consensus documents more often than we expect?
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Some more thoughts:

 If we make the validity until time later, then we split the anonymity set
 for clients:
 * With the current schedule, most clients have one of two possible non-
 fresh but valid consensuses.
 * If we lengthened the valid-but-not-fresh interval to n, they would have
 1 of n possible consensuses.

 Perhaps we could double (or scale up) all the times?
 * Then clients would have one of two possible consensuses, but those
 consensuses would have a larger delta.

--
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] #26578 [Core Tor/Tor]: Do clients request new consensus documents more often than we expect?

[Tor Bug Tracker & Wiki]

#26578: Do clients request new consensus documents more often than we expect?
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [ticket:26578 arma]:
 > In our user count estimates, we used the reasoning that clients fetch a
 new consensus document every 2 to 4 hours, or on average 3 hours, so that
 represents 8 fetches per day on average.

 That calculation is intuitively wrong: if consensuses are only valid for 3
 hours, then clients can't wait 4 hours to get a new one. As a first
 approximation, clients wait between 1 and 2 hours, and therefore they
 retry every 90 minutes.

 dir-spec gives a precise example:
 [For example, if a client has a consensus that became valid at 1:00,
 and is fresh until 2:00, and expires at 4:00, that client will fetch
 a new consensus at a random time between 2:45 and 3:50, since 3/4
 of the one-hour interval is 45 minutes, and 7/8 of the remaining 75
 minutes is 65 minutes.]
 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n3552

 But that's not enough to tell us how long clients wait *between*
 consensuses.

 The consensus that the cache has is also relevant:
 [For example, if a cache has a consensus that became valid at 1:00,
 and is fresh until 2:00, that cache will fetch a new consensus at
 a random time between 2:00 and 2:30.]
 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n3367

 So here are the details of a steady-state operation:
 * from 02:00 to 03:00, all directory authorities have a consensus that
 became valid at 02:00, and this pattern continues every hour
   * so directory authorities always have a fresh consensus
 * any directory cache that has a consensus that became valid at 01:00, and
 is fresh until 02:00, will fetch a consensus that is fresh until 03:00
 sometime between 02:00 and 02:30, and this pattern continues every hour
   * so between 02:00 and 02:30, all caches either have an 01:00 or an
 02:00 consensus, and from 02:30 to 03:00 they have an 02:00 consensus
 * any client that has a consensus that became valid at 01:00, fresh until
 02:00, and valid until 04:00, will fetch a new consensus between 02:45 and
 03:50, and this pattern continues differently depending on exactly which
 consensus they fetch
   * here are the cases:
 * clients (15/65) that fetch between 02:45 and 03:00 get an 02:00
 consensus
 * half (15/65) the clients that fetch between 03:00 and 03:30 get an
 02:00 consensus, and half (15/65) get an 03:00 consensus, with the earlier
 clients more likely to get an 02:00 consensus
 * clients (20/65) that fetch between 03:30 and 03:50 get an 03:00
 consensus
   * so about half the clients:
 * fetch between 02:45 and 03:30, and get an 02:00 consensus, and retry
 between 3:45 and 4:50, a 15 minute to 125 minute interval, skewed towards
 125 minutes
 * fetch between 03:00 and 03:50 and get an 03:00 consensus, and retry
 between 4:45 and 5:50, a 55 minute to 170 minute interval, skewed towards
 55 minutes
   * overall, that's approximately 93 minutes between client attempts (due
 to the skew away from the extremes, and the larger number of clients in
 the later interval)

 > But in reality, it seems that clients fetch consensus documents way more
 frequently than that: looking at just my local Tor client, I see
 >
 > Jun 28 21:11:52.190 [info] update_consensus_networkstatus_downloads():
 Launching microdesc standard networkstatus consensus download.
 > Jun 28 22:43:52.355 [info] update_consensus_networkstatus_downloads():
 Launching microdesc standard networkstatus consensus download.
 92
 > Jun 28 23:59:52.417 [info] update_consensus_networkstatus_downloads():
 Launching microdesc standard networkstatus consensus download.
 76
 > Jun 29 01:42:52.501 [info] update_consensus_networkstatus_downloads():
 Launching microdesc standard networkstatus consensus download.
 103
 > Jun 29 03:33:52.601 [info] update_consensus_networkstatus_downloads():
 Launching microdesc standard networkstatus consensus download.
 111
 > Jun 29 05:09:52.699 [info] update_consensus_networkstatus_downloads():
 Launching microdesc standard networkstatus consensus download.
 96
 > Jun 29 06:04:52.754 [info] update_consensus_networkstatus_downloads():
 Launching microdesc standard networkstatus consensus download.
 115
 > Jun 29 07:54:52.874 [info] update_consensus_networkstatus_downloads():
 Launching microdesc standard networkstatus consensus download.
 110
 > Jun 29 08:56:52.946 [info] update_consensus_networkstatus_downloads():
 Launching microdesc 

Re: [tor-bugs] #23816 [Core Tor/Tor]: Use exponential backoff with jitter and/or tune its parameters

[Tor Bug Tracker & Wiki]

#23816: Use exponential backoff with jitter and/or tune its parameters
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  031-backport-maybe, 029-backport-|  Actual Points:
  maybe  |
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
 |  SponsorV
-+-
Changes (by nickm):

 * status:  merge_ready => closed
 * resolution:   => fixed
 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.2.x-final


Comment:

 No backport, per reasons discussed above.

--
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] #23790 [Core Tor/Tor]: rend_service_prune_list_impl_() doesn't copy over desc_is_dirty when copying intro points

[Tor Bug Tracker & Wiki]

#23790: rend_service_prune_list_impl_() doesn't copy over desc_is_dirty when
copying intro points
+--
 Reporter:  jl  |  Owner:  dgoulet
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.2.9.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.1.7
 Severity:  Normal  | Resolution:
 Keywords:  029-backport, 031-backport  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * milestone:  Tor: 0.3.1.x-final => Tor: 0.2.9.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] #23681 [Core Tor/Tor]: prop224: Clients mark intro circs as timed-out within seconds

[Tor Bug Tracker & Wiki]

#23681: prop224: Clients mark intro circs as timed-out within seconds
-+-
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, 031-backport, 029   |  Actual Points:
  -backport-maybe|
Parent ID:   | Points:
 Reviewer:  mikeperry|Sponsor:
-+-
Changes (by nickm):

 * milestone:  Tor: 0.3.1.x-final => Tor: 0.2.9.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] #20532 [Core Tor/Tor]: Make sure directory_initiate_request handles pluggable transports correctly

[Tor Bug Tracker & Wiki]

#20532: Make sure directory_initiate_request handles pluggable transports 
correctly
-+-
 Reporter:  teor |  Owner:
 |  catalyst
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bridge-client, bridge-bypass,|  Actual Points:
  031-backport   |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
 |  SponsorM
-+-
Changes (by nickm):

 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.2.x-final


Comment:

 0.3.1 is now EOL. No further backport.

--
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] #26591 [Core Tor/Tor]: doc/ missing in build directory for out-of-tree builds

[Tor Bug Tracker & Wiki]

#26591: doc/ missing in build directory for out-of-tree builds
-+-
 Reporter:  kn   |  Owner:  (none)
 Type:   | Status:  new
  enhancement|
 Priority:  Low  |  Milestone:  Tor: unspecified
Component:  Core |Version:  Tor: unspecified
  Tor/Tor|
 Severity:  Trivial  |   Keywords:  source build doc autoconf packaging
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 **autoconf** allows building tor outside the source directory using
 {{{--srcdir=DIR}}}.
 In that case, ''doc/'' is not copied or symlinked from source to build
 directory, causing pages to be unnesseccarily regenerated using
 **rst2man**.

 Would it be possible to adjust the ''configure'' stage to account for
 this?

 Specifically, this would allow complete out-of-tree builds at least on
 OpenBSD, where where the following quirk is required after ''configure''
 and before ''build'' stage to enable separation without **py-docutils** as
 additional build dependency:

 {{{
 pre-build:
 ln -sf ${WRKSRC}/doc/ ${WRKBUILD}/
 }}}

--
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] #26518 [Metrics/Relay Search]: The fourth most popular AS in the Tor network is "(distinct)"?

[Tor Bug Tracker & Wiki]

#26518: The fourth most popular AS in the Tor network is "(distinct)"?
--+--
 Reporter:  arma  |  Owner:  irl
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by irl):

 * status:  new => accepted
 * owner:  metrics-team => irl


Comment:

 Replying to [comment:1 nusenu]:
 > This is where onionoo does not provide any AS level data to Relay Search
 to aggregate on.

 Indeed this is the case. It should be more obvious that this is happening
 though. There is meant to be a mapping to "Unknown" in this case. (Also
 for countries, there should be a mapping to "Unknown").

--
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] #26590 [Applications/Tor Browser]: SVG isn't blocked in Safest security setting with 8.0a9

[Tor Bug Tracker & Wiki]

#26590: SVG isn't blocked in Safest security setting with 8.0a9
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Looking at `about:support` one does find

 `svg.in-content.enabled false`

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

[tor-bugs] #26590 [Applications/Tor Browser]: SVG isn't blocked in Safest security setting with 8.0a9

[Tor Bug Tracker & Wiki]

#26590: SVG isn't blocked in Safest security setting with 8.0a9
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 SVG doesn't seem to be blocked in Safest security setting with 8.0a9
 (Linux)

--
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] #26589 [Applications/Tor Browser]: Tor Browser 8.0a9 will not start on Ubuntu 17.10.

[Tor Bug Tracker & Wiki]

#26589: Tor Browser 8.0a9 will not start on Ubuntu 17.10.
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff60-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * status:  needs_information => new


--
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] #22040 [Applications/Tor Browser]: DocShell is null for every tab during New Identity on Win 7

[Tor Bug Tracker & Wiki]

#22040: DocShell is null for every tab during New Identity on Win 7
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-newnym, tbb-e10s,  |  Actual Points:
  tbb-7.0-issues, tbb-regression |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 ff60-esr added:
 {{{
 10:01:27.312 Error: _initWorker called too early! Please read the session
 file from disk first. 1 SessionFile.jsm:337:15
 Webconsole context has changed
 10:01:30.087 TypeError: win.gBrowser is undefined 1
 ProcessHangMonitor.jsm:412:9
 }}}

--
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] #26589 [Applications/Tor Browser]: Tor Browser 8.0a9 will not start on Ubuntu 17.10.

[Tor Bug Tracker & Wiki]

#26589: Tor Browser 8.0a9 will not start on Ubuntu 17.10.
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff60-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 {{{
 Launching './Browser/start-tor-browser --detach --debug'...
 XPCOMGlueLoad error for file /home/user/tor-browser_en-
 US/Browser/libmozgtk.so:
 /home/user/tor-browser_en-US/Browser/TorBrowser/Tor/libstdc++.so.6:
 version `CXXABI_1.3.11' not found (required by /usr/lib/x86_64-linux-
 gnu/libmirclient.so.9)
 Couldn't load XPCOM.
 }}}

--
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] #26589 [Applications/Tor Browser]: Tor Browser 8.0a9 will not start on Ubuntu 17.10.

[Tor Bug Tracker & Wiki]

#26589: Tor Browser 8.0a9 will not start on Ubuntu 17.10.
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff60-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * owner:  (none) => tbb-team
 * status:  new => needs_information
 * component:  - Select a component => Applications/Tor Browser


Comment:

 What error message do you get if you start Tor Browser in your terminal
 with `./start-tor-browser.desktop --debug` (after you changed into your
 tor-browser_$LANG directory)

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

[tor-bugs] #26589 [- Select a component]: Tor Browser 8.0a9 will not start on Ubuntu 17.10.

[Tor Bug Tracker & Wiki]

#26589: Tor Browser 8.0a9 will not start on Ubuntu 17.10.
--+--
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:  ff60-esr
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Beginning with version 8.0a9 when attempting to launch Tor Browser on
 Ubuntu 17.10 Tor Browser will exit immediately without displaying any
 error messages.

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