Re: [tor-bugs] #21642 [Core Tor/Tor]: Prop275: Eliminate "published" times from microdescriptor consensus

[Tor Bug Tracker & Wiki]

#21642: Prop275: Eliminate "published" times from microdescriptor consensus
+--
 Reporter:  nickm   |  Owner:  nickm
 Type:  enhancement | Status:
|  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, review-group-17  |  Actual Points:  .5
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by arma):

 Another option for hack1 is to just change the hack to "if you are missing
 from the consensus, decide that the authorities forgot about you so now's
 a good time to republish". The problem with that option though is that
 each time we hit whatever bugs there are, there's a several-hour gap where
 the relay isn't used by clients. That's not ideal, but maybe it's good
 enough? Yuck.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22211 [Core Tor/Tor]: mistaken comment in routerstatus_parse_entry_from_string()

[Tor Bug Tracker & Wiki]

#22211: mistaken comment in routerstatus_parse_entry_from_string()
--+-
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 {{{
   } else if (flav == FLAV_MICRODESC) {
 offset = -1; /* There is no identity digest */
   }
 }}}

 I *think* it means to say "There is no descriptor digest" here -- since
 there is an identity digest in both kinds of consensus flavors.

 (I am making a ticket, rather than just fixing it, so a second person can
 look at it and either agree or tell me why I'm mistaken.)

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

Re: [tor-bugs] #22211 [Core Tor/Tor]: mistaken comment in routerstatus_parse_entry_from_string()

[Tor Bug Tracker & Wiki]

#22211: mistaken comment in routerstatus_parse_entry_from_string()
--+--
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arma):

 * status:  new => needs_review


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

Re: [tor-bugs] #21642 [Core Tor/Tor]: Prop275: Eliminate "published" times from microdescriptor consensus

[Tor Bug Tracker & Wiki]

#21642: Prop275: Eliminate "published" times from microdescriptor consensus
+--
 Reporter:  nickm   |  Owner:  nickm
 Type:  enhancement | Status:
|  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, review-group-17  |  Actual Points:  .5
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by arma):

 * cc: arma (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] #21642 [Core Tor/Tor]: Prop275: Eliminate "published" times from microdescriptor consensus

[Tor Bug Tracker & Wiki]

#21642: Prop275: Eliminate "published" times from microdescriptor consensus
+--
 Reporter:  nickm   |  Owner:  nickm
 Type:  enhancement | Status:
|  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, review-group-17  |  Actual Points:  .5
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by arma):

 Replying to [comment:16 arma]:
 > So I have resumed thinking that if we set published_on to always 2037,
 we will be disabling this hack. :(

 If we want to re-enable the hack (assuming that when we do the
 published_on change, we do it only in the microdescriptor consensus, and
 not in the vanilla consensus), here is code that would do that:

 {{{
 diff --git a/src/or/networkstatus.c b/src/or/networkstatus.c
 index 2d39c90..3fde2a2 100644
 --- a/src/or/networkstatus.c
 +++ b/src/or/networkstatus.c
 @@ -811,6 +811,35 @@ we_want_to_fetch_flavor(const or_options_t *options,
 int f
 lavor)
return flavor == usable_consensus_flavor();
  }

 +/** Helper function: return 1 if consensus c is non-null and from
 + * within the time bounds of [valid_after, valid_until]. Else return 0.
 */
 +static int
 +consensus_is_valid(networkstatus_t *c, time_t now)
 +{
 +  if (c && c->valid_after <= now && now <= c->valid_until)
 +return 1;
 +  return 0;
 +}
 +
 +/** Return a valid consensus with the preferred flavor flavor if
 + * possible, else return any valid consensus if possible. */
 +networkstatus_t *
 +networkstatus_find_consensus_with_preferred_flavor(int flavor, time_t
 now)
 +{
 +  networkstatus_t *c;
 +
 +  /* One: If we fetch the preferred flavor type, great, use it. Else,
 switch
 +   * to one that we do fetch. */
 +  if (!we_want_to_fetch_flavor(get_options(), flavor))
 +flavor = usable_consensus_flavor();
 +
 +  /* Two: See if we've got it, and if it's valid. */
 +  c = networkstatus_get_latest_consensus_by_flavor(flavor);
 +  if (!consensus_is_valid(c, now))
 +return NULL;
 +  return c;
 +}
 +
  /** How long will we hang onto a possibly live consensus for which we're
   * fetching certs before we check whether there is a better one? */
  #define DELAY_WHILE_FETCHING_CERTS (20*60)
 diff --git a/src/or/networkstatus.h b/src/or/networkstatus.h
 index 71f36b6..c980da3 100644
 --- a/src/or/networkstatus.h
 +++ b/src/or/networkstatus.h
 @@ -66,6 +66,8 @@ const routerstatus_t
 *router_get_consensus_status_by_nickname(
 int warn_if_unnamed);
  const char *networkstatus_get_router_digest_by_nickname(const char
 *nickname);
  int networkstatus_nickname_is_unnamed(const char *nickname);
 +networkstatus_t *networkstatus_find_consensus_with_preferred_flavor(
 +   int flavor, time_t now);
  void networkstatus_consensus_download_failed(int status_code,
   const char *flavname);
  void update_consensus_networkstatus_fetch_time(time_t now);
 diff --git a/src/or/router.c b/src/or/router.c
 index 6d3a32a..e9378d8 100644
 --- a/src/or/router.c
 +++ b/src/or/router.c
 @@ -2391,11 +2391,17 @@ mark_my_descriptor_dirty_if_too_old(time_t now)
  mark_my_descriptor_dirty("time for new descriptor");
  return;
}
 +
 +  /* Find a live consensus, so we can use it below to check if our entry
 +   * is up-to-date. We prefer the vanilla consensus flavor, because at
 some
 +   * point in the future we might stop listing useful published_on
 entries
 +   * in the microdescriptor consensus. */
 +  ns = networkstatus_find_consensus_with_preferred_flavor(FLAV_NS, now);
 +
/* Now we see whether we want to be retrying frequently or no.  The
 * rule here is that we'll retry frequently if we aren't listed in the
 * live consensus we have, or if the publication time of the
 * descriptor listed for us in the consensus is very old. */
 -  ns = networkstatus_get_live_consensus(now);
if (ns) {
  rs = networkstatus_vote_find_entry(ns, server_identitykey_digest);
  if (rs == NULL)
 }}}

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

Re: [tor-bugs] #21642 [Core Tor/Tor]: Prop275: Eliminate "published" times from microdescriptor consensus

[Tor Bug Tracker & Wiki]

#21642: Prop275: Eliminate "published" times from microdescriptor consensus
+--
 Reporter:  nickm   |  Owner:  nickm
 Type:  enhancement | Status:
|  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, review-group-17  |  Actual Points:  .5
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by arma):

 Thoughts:

 A) I think the patch in prop275_minimal_029 is safe and fine.

 B) Check out in mark_my_descriptor_dirty_if_too_old() how we decide to
 republish our descriptor if our consensus entry says our descriptor is
 more than 18 hours old (#3327):
 {{{
 else if (rs->published_on < slow_cutoff)
   retry_fast_reason = "version listed in consensus is quite old";
 }}}
 So if we do the next step, which would be setting the timestamp to 2037 or
 whatever, we will disable this hack. Are we still using the hack much? I
 think we added it because we have a bunch of subtle bugs where relays
 forget to republish, or where relays *do* republish but the dir auths drop
 their newly published descriptor because it's too similar to the last one.
 I don't think we found or fixed those bugs.

 At first I thought "hey, no problem, relays cache both flavors of
 consensus, because directory_caches_dir_info is so lenient." But then I
 realized that in the above code snippet, the rs is gotten from
 networkstatus_get_latest_consensus(), which will be the microdesc
 consensus. So I have resumed thinking that if we set published_on to
 always 2037, we will be disabling this hack. :(

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22210 [Core Tor/Tor]: circuit_is_acceptable is slow due to IP and fingerprint parsing

[Tor Bug Tracker & Wiki]

#22210: circuit_is_acceptable is slow due to IP and fingerprint parsing
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.12
 Severity:  Normal|   Keywords:  tor-hs
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+
 (I received this bug report from special. Please feel free to contact me
 (teor) with questions.)

 Using Tor version 0.3.1.0-alpha-dev (git-04f1ddaa2a33194b), also applies
 to at least all 0.2.8.x and above.

 Testcase is a ricochet client with a very large number of contacts.
 Effectively, it’s a client that attempts to build circuits to >100 <500
 hidden services almost simultaneously, and retries over time with
 increasing delays.

 This tor client will constantly use 100% of a CPU core for >15 minutes
 after start. There’s a variety of buggy behavior going on, and a lot of
 circuits, so it’s not entirely surprising to see some high load. More
 interesting is where that load actually comes from.

 The vast majority of CPU time — 2.1 minutes out of a 3 minute trace — is
 spent under `circuit_is_acceptable`, as called from
 `connection_ap_attach_pending` (via `circuit_get_open_circ_or_launch` and
 `circuit_get_best`). The breakdown from there is:

 2.10 min  100.0%6.26 scircuit_is_acceptable

 58.93 s   46.7% 1.05 s tor_addr_parse
 56.34 s   44.7% 1.84 s  tor_inet_pton
 52.53 s   41.7% 1.68 s   tor_inet_aton
 50.71 s   40.2% 914.00 ms tor_sscanf
 49.74 s   39.4% 13.78 stor_vsscanf
 29.30 s   23.2% 20.11 s scan_unsigned
 5.29 s4.2%  5.29 s  TOR_ISDIGIT
 1.13 s0.8%  1.13 s  digit_to_num

 43.76 s   34.7% 1.30 s connection_ap_can_use_exit
 39.51 s   31.3% 574.00 ms   node_get_by_nickname
 38.93 s   30.9% 764.00 msnode_get_by_hex_id
 23.82 s   18.9% 869.00 ms hex_digest_nickname_decode
 21.61 s   17.1% 10.95 sbase16_decode
 10.07 s7.9% 10.07 s hex_decode_digit_
 14.32 s   11.3% 156.00 ms node_get_by_id

 16.39 s   13.0% 1.47 s build_state_get_exit_node
 14.93 s   11.8% 119.00 ms   node_get_by_id

 That is super hard to read in this format, but essentially a majority of
 time is spent on:

 1. Parsing IP addresses from strings out of node descriptors
 2. Looking up nodes by ID
 3. Decoding hex digests to get node IDs

 This implies to me that these could be cached in a much more useful way in
 the node struct, the algorithmic complexity of some of the circuit
 selection functions is out of control, and I’m also guessing that the
 circuit attach functions are being called __way__ too often.

 Without circuit_is_acceptable being considered, the hottest path is under
 choose_good_middle_server for node selection, which seems much more
 reasonable.

 The profile quoted here had —enable-expensive-hardening (including ASAN)
 and slightly older tor, but I’ve rerun with 04f1ddaa and without hardening
 with the same conclusions, including 2 out of 3 minutes of CPU time being
 spent under `circuit_is_acceptable`.

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

Re: [tor-bugs] #21969 [Core Tor/Tor]: We're missing descriptors for some of our primary entry guards

[Tor Bug Tracker & Wiki]

#21969: We're missing descriptors for some of our primary entry guards
---+
 Reporter:  asn|  Owner:
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-guard, tor-bridge  |  Actual Points:
Parent ID: | Points:  1.5
 Reviewer: |Sponsor:  SponsorU
---+

Comment (by teor):

 Replying to [comment:6 catalyst]:
 > ...
 > I attached a log of a failed bootstrap with obfs4.  (Tor Browser 7.0a3
 with defaults obfs4 bridge configuration)  It appears to have gotten stuck
 because none of the selected guards was reachable when trying to download
 the consensus.

 IMO, the right fix here is to fall back to a fallback directory mirror.
 It's what they are there for.

 > ...
 > Note that two of the guards have the same fingerprint
 (`A832D176ECD5C7C6B58825AE22FC4C90FA249637`), and seem to be multiple
 ports on the same IP according to the TBB-generated torrc.  Maybe we
 should prevent this during guard selection?

 Unless, of course, you are using a restricted guard set or bridges, where
 we should... just try another guard?

 Also, maybe we want tor to try an IPv4 and an IPv6 address for your bridge
 if you only have one dual-stack bridge?

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

Re: [tor-bugs] #21903 [Core Tor/Chutney]: Disable DNS in chutney by default, and add an option to enable it

[Tor Bug Tracker & Wiki]

#21903: Disable DNS in chutney by default, and add an option to enable it
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #19573| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_information => needs_revision


Comment:

 I want DNS to work by default in chutney, and I want offline use to work
 even on macOS (and other OSs that have no resolv.conf).

 I think a good way to fix this is to do the thing that will work once
 #21900 is fixed in tor.

 So we should make working DNS the default, and have an --offline option.
 (Or, even better, we could check if the ServerDNSResolvConfFile exists,
 and if it doesn't, we should apply a workaround, which can be switched
 off.)

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

Re: [tor-bugs] #21900 [Core Tor/Tor]: evdns fails when resolv.conf is missing, but succeeds when resolv.conf is empty

[Tor Bug Tracker & Wiki]

#21900: evdns fails when resolv.conf is missing, but succeeds when resolv.conf 
is
empty
-+-
 Reporter:  teor |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt, dns, crash, tor- |  Actual Points:
  relay, macos   |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Sounds like the fix is to treat a missing resolv.conf as being the same as
 an empty resolv.conf?

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

Re: [tor-bugs] #22152 [Core Tor/Tor]: make-test-network-all fails hidden service tests

[Tor Bug Tracker & Wiki]

#22152: make-test-network-all fails hidden service tests
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Another open related bug is #18564.

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

Re: [tor-bugs] #22152 [Core Tor/Tor]: make-test-network-all fails hidden service tests

[Tor Bug Tracker & Wiki]

#22152: make-test-network-all fails hidden service tests
--+
 Reporter:  teor  |  Owner:
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 This is like #15937. Again.

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

Re: [tor-bugs] #4998 [Core Tor/Tor]: MyFamily as a list

[Tor Bug Tracker & Wiki]

#4998: MyFamily as a list
+--
 Reporter:  weasel  |  Owner:  Jigsaw52
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.2.3.11-alpha
 Severity:  Normal  | Resolution:
 Keywords:  tor-relay lorax easy intro  |  Actual Points:
Parent ID:  #15060  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by Jigsaw52):

 Thanks for the explanation.
 I checked out out your branch and tested it and everything seems fine.

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

Re: [tor-bugs] #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:
 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 dgoulet):

 * milestone:   => Tor: unspecified


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

Re: [tor-bugs] #20319 [Internal Services/Tor Sysadmin Team]: set HPKP headers on onionoo

[Tor Bug Tracker & Wiki]

#20319: set HPKP headers on onionoo
-+-
 Reporter:  weasel   |  Owner:  tpa
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sainslie):

 Replying to [comment:3 weasel]:
 > Thanks for trying to help, sainslie, but apache is not anywhere in that
 stack.
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 I rebuilt it using Varnish Configuration Language.
 -BEGIN PGP SIGNATURE-

 iQIcBAEBCgAGBQJZEiv4AAoJEM18vpeSzTzCEtcP/0mqLYFErb1wSTYCSt/Jp6GU
 c3jzlDUZGgHr+CbnX2aEq835ZCpwYY8lIClFMagBrMMGRk2iveupflfmMzUTzSOd
 x98y5J+0DcPEG3pw9wcBNUbzXmHZRL0845vXTYSTI2x94hTO6x/S7NwDEOFVxeaX
 ++w3BodCUJq8q0CBqD/fbEgTNJTm33PW2/tVh1f2hNJZGySh1YcyEznrn/5etQ/o
 OPce0kl4icsvd5dtJuShaDry1dtx1JUQlLWQ0jCj1gg/D9OWGjHyE7ETpE+/J98f
 40tDCc5w6xw4G2mBMzJsdmTqPWPfm6W3VkpiW26BtqAfpZ+LiSrs1YEFrZ7dOWWp
 xJw+bT/ieAEriU2dYAH7unK+++x2Eo4USF0DEwIHQM6Q9vALrKn5PZQRG74v+BsC
 p2kp069K/er7QJGSesCLacexFE4wekdjH47VAzHC9OLn4WW2sV/oI3Spug0HfgDq
 eHijK/OUoU0guiwS8YgLYVUVn7Hl5qqUxz9UiN/CDCqtT+k4PkJWH1LlaQF5zOFW
 UzB46jx/fY39NpwDJicVPlEdfswRrBJXomdzDrB4Qdfb3w6hA0vf3iHxptFD/Jm9
 KdjdtZRevtNmzflJHDrWIZqG2KT/Ssi2C3b2nI9IjOlCtMoXtrwD9xEr9E0dABri
 alTZ3FfoUXa4W6OLMHuD
 =CT4N
 -END PGP SIGNATURE-

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

Re: [tor-bugs] #16337 [Applications/Tor Browser]: Investigate whether Animations(Player) API provides new high resolution timestamp

[Tor Bug Tracker & Wiki]

#16337: Investigate whether Animations(Player) API provides new high resolution
timestamp
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-fingerprinting-time-   |  Actual Points:
  highres, tbb-7.0-must-alpha,   |
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by mcs):

 r=brade, r=mcs
 This looks good to us too.

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

Re: [tor-bugs] #22044 [Applications/Tor Browser]: When I use the search box in the upper right it defaults to using youtube (on macOS)

[Tor Bug Tracker & Wiki]

#22044: When I use the search box in the upper right it defaults to using 
youtube
(on macOS)
-+-
 Reporter:  Dbryrtfbcbhgf|  Owner:  mcs
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must-alpha,|  Actual Points:
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * status:  assigned => needs_review
 * keywords:  ff52-esr, tbb-7.0-must-alpha, TorBrowserTeam201705 =>
 ff52-esr, tbb-7.0-must-alpha, TorBrowserTeam201705R


Comment:

 The difference on OSX is due to
 https://bugzilla.mozilla.org/show_bug.cgi?id=1126722.
 But the real problem is that we are not setting the default search engine
 correctly: `browser.search.defaultenginename` needs to contain an URL.
 This is because the getter for `originalDefaultEngine`, which is defined
 in `browser/app/profile/000-tor-browser.js`, uses
 `nsIPrefBranch.getComplexValue()` to retrieve the pref value. The solution
 is to use a data: URL for the value (Mozilla
 defines`browser.search.defaultenginename.US` that way). Here is a patch:
 https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug22044-01=a6a714a4541b3821267558c8c0a5ef725a91331a

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

Re: [tor-bugs] #21621 [Core Tor/Tor]: Intro points can get stuck in CIRCUIT_PURPOSE_S_ESTABLISH_INTRO

[Tor Bug Tracker & Wiki]

#21621: Intro points can get stuck in CIRCUIT_PURPOSE_S_ESTABLISH_INTRO
--+
 Reporter:  teor  |  Owner:  dgoulet
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.7.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:  #21446| Points:  1
 Reviewer:|Sponsor:  SponsorR-can
--+
Changes (by dgoulet):

 * status:  accepted => needs_information


Comment:

 So I was studying carefully this ticket for the service implementation of
 prop224 (#20657) in order to implement this feature. However, I *think*
 the service intro circuit do expire normally and don't have a super long
 expiration like a rendezvous circuit has.

 Looking at `circuit_expire_building()` (which actually looks at open
 circuits contrary to its comment), the timeout cutoff is "normal" that is
 not super long:

 `SET_CUTOFF(s_intro_cutoff, get_circuit_build_timeout_ms() * (9/6.0) +
 1000);`

 And then later, there is the `if (victim->state == CIRCUIT_STATE_OPEN) {`
 condition that just breaks if we have a
 `CIRCUIT_PURPOSE_S_ESTABLISH_INTRO` and ultimately close it with timeout
 reason.

 So, I believe tor "naturally" closes too old intro circuit that *are*
 established but then nothing happens on them. By design, they are suppose
 to be short live so this seems already integrated?

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

Re: [tor-bugs] #22044 [Applications/Tor Browser]: When I use the search box in the upper right it defaults to using youtube (on macOS)

[Tor Bug Tracker & Wiki]

#22044: When I use the search box in the upper right it defaults to using 
youtube
(on macOS)
-+-
 Reporter:  Dbryrtfbcbhgf|  Owner:  mcs
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must-alpha,|  Actual Points:
  TorBrowserTeam201705   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * cc: arthuredelstein, gk (added)
 * keywords:  ff52-esr, tbb-7.0-must-alpha => ff52-esr, tbb-7.0-must-alpha,
 TorBrowserTeam201705
 * owner:  tbb-team => mcs


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

Re: [tor-bugs] #22063 [Metrics/Onionoo]: Document that only the first qualified search term applies

[Tor Bug Tracker & Wiki]

#22063: Document that only the first qualified search term applies
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  task | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  new => needs_review


Comment:

 How's
 
[https://gitweb.torproject.org/user/karsten/onionoo.git/commit/?h=task-22063=ee71d4e35d9576a5b8f8131fb5b25b9ea65b10e1
 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] #22062 [Metrics/Onionoo]: Bad requests do not add the Access-Control-Allow-Origin header

[Tor Bug Tracker & Wiki]

#22062: Bad requests do not add the Access-Control-Allow-Origin header
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Before I try out whether this works and what it might break in unexpected
 ways: what's the use case for including these headers in responses to bad
 requests?

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

Re: [tor-bugs] #19607 [Metrics/metrics-lib]: avoid repeated keyword strings

[Tor Bug Tracker & Wiki]

#19607: avoid repeated keyword strings
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Looks good!

 Just one question/suggestion: what do you think about moving
 `serverAtMostOnce` and other parts that are only relevant for parsing
 server descriptors to `ServerDescriptorImpl`?

 Other than that, I'm not entirely sure what you mean by "additional lines
 will go away" in your comment above.  Which lines do you mean?

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

Re: [tor-bugs] #22209 [Core Tor/Tor]: Channelpadding tests fail on kevent-based systems

[Tor Bug Tracker & Wiki]

#22209: Channelpadding tests fail on kevent-based systems
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 mike -- could you look at the stack trace?  I'll do the event_reinit()
 thing, since it's backend stuff.

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

Re: [tor-bugs] #22209 [Core Tor/Tor]: Channelpadding tests fail on kevent-based systems

[Tor Bug Tracker & Wiki]

#22209: Channelpadding tests fail on kevent-based systems
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Perhaps we need an event_reinit call in here somewhere?  See
 
http://www.wangafu.net/~nickm/libevent-2.0/doxygen/html/event_8h.html#a7409499a79a59842955928af446fe03d

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22209 [Core Tor/Tor]: Channelpadding tests fail on kevent-based systems

[Tor Bug Tracker & Wiki]

#22209: Channelpadding tests fail on kevent-based systems
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 First observed on freebsd, reproduced on osx:
 {{{
 [532]$ ./src/test/test channelpadding/..
 channelpadding/channelpadding_decide_to_pad_channel: [forking] [warn]
 kevent: Bad file descriptor

   FAIL src/test/test_channelpadding.c:759: assert(tried_to_write_cell
 OP_EQ 1): 0 vs 1May 09 13:07:08.604 [err] tor_assertion_failed_: Bug:
 src/or/scheduler.c:398: scheduler_release_channel__real: Assertion
 channels_pending failed; aborting. (on Tor 0.3.1.0-alpha-dev
 9f5b71a7cafbaf14)
 May 09 13:07:08.612 [err] Bug: Assertion channels_pending failed in
 scheduler_release_channel__real at src/or/scheduler.c:398. Stack trace:
 (on Tor 0.3.1.0-alpha-dev 9f5b71a7cafbaf14)
 May 09 13:07:08.612 [err] Bug: 0   test
 0x00010f350f49 log_backtrace + 73 (on Tor 0.3.1.0-alpha-dev
 9f5b71a7cafbaf14)
 May 09 13:07:08.612 [err] Bug: 1   test
 0x00010f3b600e tor_assertion_failed_ + 318 (on Tor 0.3.1.0-alpha-dev
 9f5b71a7cafbaf14)
 May 09 13:07:08.612 [err] Bug: 2   test
 0x00010f2de166 scheduler_release_channel__real + 310 (on Tor 0.3.1.0
 -alpha-dev 9f5b71a7cafbaf14)
 May 09 13:07:08.612 [err] Bug: 3   test
 0x00010ee2b4bc channel_change_state + 1180 (on Tor 0.3.1.0-alpha-dev
 9f5b71a7cafbaf14)
 May 09 13:07:08.612 [err] Bug: 4   test
 0x00010ee2ac52 channel_mark_for_close + 386 (on Tor 0.3.1.0-alpha-dev
 9f5b71a7cafbaf14)
 May 09 13:07:08.612 [err] Bug: 5   test
 0x00010ee3b0e4 channel_free_list + 2308 (on Tor 0.3.1.0-alpha-dev
 9f5b71a7cafbaf14)
 May 09 13:07:08.612 [err] Bug: 6   test
 0x00010ee3a4ef channel_free_all + 223 (on Tor 0.3.1.0-alpha-dev
 9f5b71a7cafbaf14)
 May 09 13:07:08.612 [err] Bug: 7   test
 0x00010ea8a673 test_channelpadding_decide_to_pad_channel + 1283 (on
 Tor 0.3.1.0-alpha-dev 9f5b71a7cafbaf14)
 May 09 13:07:08.612 [err] Bug: 8   test
 0x00010edf25d9 testcase_run_bare_ + 329 (on Tor 0.3.1.0-alpha-dev
 9f5b71a7cafbaf14)
 May 09 13:07:08.612 [err] Bug: 9   test
 0x00010edf2374 testcase_run_one + 2932 (on Tor 0.3.1.0-alpha-dev
 9f5b71a7cafbaf14)
 May 09 13:07:08.612 [err] Bug: 10  test
 0x00010edf3861 tinytest_main + 1553 (on Tor 0.3.1.0-alpha-dev
 9f5b71a7cafbaf14)
 May 09 13:07:08.612 [err] Bug: 11  test
 0x00010edf0397 main + 1703 (on Tor 0.3.1.0-alpha-dev 9f5b71a7cafbaf14)
 May 09 13:07:08.612 [err] Bug: 12  libdyld.dylib
 0x7fffa1660235 start + 1 (on Tor 0.3.1.0-alpha-dev 9f5b71a7cafbaf14)
 May 09 13:07:08.612 [err] Bug: 13  ???
 0x0002 0x0 + 2 (on Tor 0.3.1.0-alpha-dev 9f5b71a7cafbaf14)
 [Lost connection!]
   [channelpadding_decide_to_pad_channel FAILED]
 channelpadding/channelpadding_negotiation: [forking] OK
 channelpadding/channelpadding_consensus: [forking] [warn] kevent: Bad file
 descriptor

   FAIL src/test/test_channelpadding.c:398: assert(tried_to_write_cell
 OP_EQ 1): 0 vs 1
   [channelpadding_consensus FAILED]
 channelpadding/channelpadding_timers: [forking] [warn] kevent: Bad file
 descriptor

   FAIL src/test/test_channelpadding.c:324: assert(tried_to_write_cell
 OP_EQ CHANNELS_TO_TEST): 0 vs 100
   [channelpadding_timers FAILED]
 3/4 TESTS FAILED. (0 skipped)
 }}}

 The problem might be because of the "kevent: bad file descriptor" thing;
 there might be a libevent mainloop that is not surviving across fork(), or
 is getting closed 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] #16225 [Metrics/metrics-lib]: Unify exception/error handling in metrics-lib

[Tor Bug Tracker & Wiki]

#16225: Unify exception/error handling in metrics-lib
-+---
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Replying to [comment:10 iwakeh]:
 > Replying to [comment:8 karsten]:
 > > ...
 > > > From this scenario, I would conclude that methods like
 readDescriptors, parseDescriptors, collectDescriptors don't throw
 DescriptorParseExceptions, but simply process as much as possible and
 provide a list of problematic descriptors at the end, which the API using
 program can choose to ignore or process.
 > > > Does this sound like the right use-case description?
 > >
 > > It does sound like the right use-case description!
 >
 > Maybe, add that to the javadoc somewhere :-)

 Yes, we should, once we fully support that use case.  Right now, if
 `DescriptorParser` is tasked with parsing a given file and runs into
 something it cannot parse, it just throws that exception and calls it a
 day (see #22139).

 >
 > >
 > > The part that needs more thoughts is when and how we should provide
 problematic descriptors and related error cases.  Providing them at the
 end can easily lead to out-of-memory situations, because we might have to
 keep more and more problematic descriptors in memory until we're finally
 done parsing.  Maybe we can include problematic descriptors in line with
 non-problematic ones.
 > >
 > > How about this: whenever we can't parse a descriptor, we include a
 `Descriptor` instance with the raw contents we cannot parse in the
 descriptor queue.  And we include a new method `Descriptor#getException()`
 that returns the `DescriptorParseException` that we ran into, or `null` if
 we didn't run into an exception while parsing.
 > >
 > > Similarly, if we run into an exception while downloading files from a
 remote server or while reading files from the file system, so before
 splitting contents into descriptor-sized chunks and attempting to parse
 those, we include a `Descriptor` instance without descriptor contents and
 with just the exception.
 >
 > If we were using java8, I'd suggest using
 java.util.Optional.

 It seems like we won't have Java 8 in the near future (see #19622), but
 can you elaborate how that would help here?

 > Actually your suggestions goes in that direction, too.
 > Maybe, a new descriptor class InvalidDescriptor could be useful here?
 It would be accessible via the instanceof-method and have limited
 information: at least the Exception and maybe also its origin (url, path),
 in case of a file also bytes.

 I briefly thought about such a new type for this case, too.  But the only
 reason I found was that there wouldn't be a method
 `Descriptor#getException()` that sometimes returns `null`.  However,
 adding such a type would mean that whoever is interested in
 exceptions/errors would have to do another `instanceof` check and
 downcast.  Are there other aspects?

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

Re: [tor-bugs] #21859 [Core Tor/Tor]: prop224: Rendezvous circuit e2e crypto

[Tor Bug Tracker & Wiki]

#21859: prop224: Rendezvous circuit e2e crypto
-+
 Reporter:  dgoulet  |  Owner:  asn
 Type:  enhancement  | Status:  needs_revision
 Priority:  Very High|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #21888   | Points:  9
 Reviewer:  dgoulet  |Sponsor:  SponsorR-must
-+
Changes (by dgoulet):

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


Comment:

 I commented. Nothing major, mostly naming and comments. Good stuff!!!

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

Re: [tor-bugs] #21934 [Metrics/metrics-lib]: Allow extra arguments in lines containing comma-separated key-value lists

[Tor Bug Tracker & Wiki]

#21934: Allow extra arguments in lines containing comma-separated key-value 
lists
-+---
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

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


Comment:

 Replying to [comment:5 iwakeh]:
 > This fix prevents a parsing failure for valid descriptors, which is an
 improvement.  Maybe open a new ticket for discussing the possibilities for
 providing the unrecognized parts?
 > Currently, at least the bytes of the entire descriptor are available for
 further processing.

 Good idea.  Added as #22208.

 > The patch looks fine, all checks and tests pass. merge ready!

 Great, merged to master.  Thanks for reviewing!  Closing.

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

[tor-bugs] #22208 [Metrics/metrics-lib]: Provide lines containing extra, unrecognized arguments

[Tor Bug Tracker & Wiki]

#22208: Provide lines containing extra, unrecognized arguments
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 This question came up when implementing
 [https://trac.torproject.org/projects/tor/ticket/21934#comment:4 #21934]:
 do we need to include lines with extra arguments in
 `Descriptor#getUnrecognizedLines()`?  Or do we need another method
 `Descriptor#getPartiallyUnrecognizedLines()`?  Or can we safely drop those
 extra arguments on the floor?  See also
 `TorperfResults#getUnrecognizedKeys()` which is somewhat related here, but
 not exactly the same.

 This is not super urgent, because at least the bytes of the entire
 descriptor are available for further processing.

 The fix is also not trivial to write, because we'll have manually go
 through all places where extra arguments are permitted and ignored and add
 those lines to a list of partially unrecognized lines.

 The result could be that doing nothing is the way to go.  Needs more
 thoughts.

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

Re: [tor-bugs] #21886 [Applications/Tor Browser]: Downloading of binary files stalls at 0/0 bytes in Tor Browser based on ESR52 with e10s off

[Tor Bug Tracker & Wiki]

#21886: Downloading of binary files stalls at 0/0 bytes in Tor Browser based on
ESR52 with e10s off
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-7.0-must-alpha,   |  Actual Points:
  ff52-esr, TorBrowserTeam201705,|
  GeorgKoppen201705  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by gk):

 I uploaded testbuilds to people-tpo. I ran the Linux builds on three
 different systems and the Windows build on a Windows 7 machine. Everything
 worked fine. I had no chance to test macOS yet.

 https://people.torproject.org/~gk/testbuilds/21886/ has the bundles.

 I am still trying to understand why the fix is working and what the
 underlying issue of this ticket is.

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

Re: [tor-bugs] #21934 [Metrics/metrics-lib]: Allow extra arguments in lines containing comma-separated key-value lists

[Tor Bug Tracker & Wiki]

#21934: Allow extra arguments in lines containing comma-separated key-value 
lists
-+---
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * status:  needs_review => merge_ready


Comment:

 This fix prevents a parsing failure for valid descriptors, which is an
 improvement.  Maybe open a new ticket for discussing the possibilities for
 providing the unrecognized parts?
 Currently, at least the bytes of the entire descriptor are available for
 further processing.

 The patch looks fine, all checks and tests pass. merge ready!

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

Re: [tor-bugs] #22112 [Metrics/Metrics website]: Replace torperf.csv with onionperf.csv

[Tor Bug Tracker & Wiki]

#22112: Replace torperf.csv with onionperf.csv
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:2 iwakeh]:
 > Committed to master means 'productive', but the current onionperf.csv
 links on metrics.tp.o lead to 404; is that intended?

 Ah, no, that's an oversight.  Fixed!  (Just not yet deployed.)

 > init-onionperf.sql:  The last "group by" on the second to the last line
 contains a `3`, which seems to refer to `source`, but `source` in this
 select is set to `''`.  What is intended here?

 The intention was to aggregate over all sources and to include `''` in
 every resulting row, so that there's the same number and type of columns
 as in the `SELECT` above.  That third column, `'' AS source`, is not an
 aggregate function, so I included it in the `GROUP BY`.  But I just tried
 out to simply drop that column from the `GROUP BY`, which worked just
 fine.  Changed.

 > Why are there columns in the measurements table that are not used later
 on (mostly the unrecognized key lines))?  Shouldn't these be omitted?
 > Here it seems as if only 'endpointremote' is used to determine the
 content of column 'server'.  If just that is needed it ought to be filled
 by the java code initially.  But, I might have overlooked something?

 I tried to make the schema as complete as possible, so that we can write
 different views in the future more easily.  In fact, I only left out path
 information and build times, because I wanted to avoid making the schema
 too complex while not using the data at all.  But I could see how we're
 adding those parts, too.  Regarding your question why we included
 unrecognized keys, they will all be recognized in the next metrics-lib
 version, in which case we'll update this code.

 > In some other module we used constants for column-names in Java.  As the
 db redesign will be future work, is this intentionally left to be improved
 then?

 Well, I'm not a big fan of how we used string constants there, because
 they give a false sense of code robustness by protecting against typos,
 but they cannot be used in prepared statements and also don't provide any
 type safety.  And at least during development I ran much more often into
 the latter two issues than into typos.  But maybe you're right and string
 constants are better than nothing.  Changed.

 Please find [https://gitweb.torproject.org/karsten/metrics-
 web.git/log/?h=task-22112 my task-22112 branch] with the fixes.  What do
 you think?  Ready to remove the beta label and call this done? :)

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

Re: [tor-bugs] #22060 [Core Tor/Tor]: Remove deprecated options from 0.2.9.2-alpha

[Tor Bug Tracker & Wiki]

#22060: Remove deprecated options from 0.2.9.2-alpha
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  config|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:  nickm |Sponsor:
--+
Changes (by nickm):

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


Comment:

 squashed and merged; thank you!

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

Re: [tor-bugs] #16225 [Metrics/metrics-lib]: Unify exception/error handling in metrics-lib

[Tor Bug Tracker & Wiki]

#16225: Unify exception/error handling in metrics-lib
-+---
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 Replying to [comment:8 karsten]:
 > ...
 > > From this scenario, I would conclude that methods like
 readDescriptors, parseDescriptors, collectDescriptors don't throw
 DescriptorParseExceptions, but simply process as much as possible and
 provide a list of problematic descriptors at the end, which the API using
 program can choose to ignore or process.
 > > Does this sound like the right use-case description?
 >
 > It does sound like the right use-case description!

 Maybe, add that to the javadoc somewhere :-)

 >
 > The part that needs more thoughts is when and how we should provide
 problematic descriptors and related error cases.  Providing them at the
 end can easily lead to out-of-memory situations, because we might have to
 keep more and more problematic descriptors in memory until we're finally
 done parsing.  Maybe we can include problematic descriptors in line with
 non-problematic ones.
 >
 > How about this: whenever we can't parse a descriptor, we include a
 `Descriptor` instance with the raw contents we cannot parse in the
 descriptor queue.  And we include a new method `Descriptor#getException()`
 that returns the `DescriptorParseException` that we ran into, or `null` if
 we didn't run into an exception while parsing.
 >
 > Similarly, if we run into an exception while downloading files from a
 remote server or while reading files from the file system, so before
 splitting contents into descriptor-sized chunks and attempting to parse
 those, we include a `Descriptor` instance without descriptor contents and
 with just the exception.

 If we were using java8, I'd suggest using java.util.Optional.
 Actually your suggestions goes in that direction, too.
 Maybe, a new descriptor class InvalidDescriptor could be useful here?  It
 would be accessible via the instanceof-method and have limited
 information: at least the Exception and maybe also its origin (url, path),
 in case of a file also bytes.

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

Re: [tor-bugs] #22060 [Core Tor/Tor]: Remove deprecated options from 0.2.9.2-alpha

[Tor Bug Tracker & Wiki]

#22060: Remove deprecated options from 0.2.9.2-alpha
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  config|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:  nickm |Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 Actually probably better in `merge_ready` since nickm was the reviewer
 here.

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

Re: [tor-bugs] #21871 [Core Tor/Tor]: prop224: Change descriptor format for legacy encryption key

[Tor Bug Tracker & Wiki]

#21871: prop224: Change descriptor format for legacy encryption key
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #21888   | Points:  3
 Reviewer:  asn  |Sponsor:  SponsorR-must
-+
Changes (by dgoulet):

 * status:  needs_information => merge_ready
 * reviewer:   => asn


Comment:

 Ok, extra fixup commit pushed to address the last comment about the
 certificate expiry lifetime check. This is ready for merge.

 Branch: `ticket21871_031_02`
 Rebased on master and fixup squashed branch: `ticket21871_031_03`
 Spec: `ticket21871_01`

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

Re: [tor-bugs] #20270 [Core Tor/Tor]: "Descriptor is missing an ntor curve25519 onion key" message too noisy?

[Tor Bug Tracker & Wiki]

#20270: "Descriptor is missing an ntor curve25519 onion key" message too noisy?
-+-
 Reporter:  arma |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  easy, triage-out-030-201612  |  Actual Points:  .1
  TorCoreTeam201705 029-backport 030-backport|
Parent ID:   | Points:  .2
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  easy, triage-out-030-201612 =>
 easy, triage-out-030-201612 TorCoreTeam201705 029-backport
 030-backport
 * status:  accepted => needs_review
 * actualpoints:   => .1


Comment:

 Okay.  My branch `bug20270_029` does that.

 I suggest that we don't backport it any farther than 0.3.0, since
 authorities usually stay up-to-date with the latest stable, if not even
 more up-to-date.

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

Re: [tor-bugs] #22060 [Core Tor/Tor]: Remove deprecated options from 0.2.9.2-alpha

[Tor Bug Tracker & Wiki]

#22060: Remove deprecated options from 0.2.9.2-alpha
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  config|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:  nickm |Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_revision => needs_review


Comment:

 Last fixup commits fixing the comment about AllowSingleHop situation.

 Branch: `ticket22060_031_01`
 Spec: `ticket22060_01`

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

Re: [tor-bugs] #21642 [Core Tor/Tor]: Prop275: Eliminate "published" times from microdescriptor consensus

[Tor Bug Tracker & Wiki]

#21642: Prop275: Eliminate "published" times from microdescriptor consensus
+--
 Reporter:  nickm   |  Owner:  nickm
 Type:  enhancement | Status:
|  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, review-group-17  |  Actual Points:  .5
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 lgtm!

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

Re: [tor-bugs] #21642 [Core Tor/Tor]: Prop275: Eliminate "published" times from microdescriptor consensus

[Tor Bug Tracker & Wiki]

#21642: Prop275: Eliminate "published" times from microdescriptor consensus
+--
 Reporter:  nickm   |  Owner:  nickm
 Type:  enhancement | Status:
|  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, review-group-17  |  Actual Points:  .5
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 We can't use an assertion there -- we also set it for the
 routerstatus_format_entry() call in   networkstatus_compute_consensus().
 I've added one comment and clarified another.

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

Re: [tor-bugs] #22149 [Core Tor/Tor]: prop140: Update dir-spec with prop140 protocols

[Tor Bug Tracker & Wiki]

#22149: prop140: Update dir-spec with prop140 protocols
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201705  |  Actual Points:  .3
Parent ID:  #13339 | Points:  .3
 Reviewer: |Sponsor:  Sponsor4
---+
Changes (by nickm):

 * status:  accepted => needs_review
 * keywords:   => TorCoreTeam201705
 * actualpoints:   => .3


Comment:

 See my dirspec branch `prop140_completed`

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

Re: [tor-bugs] #21642 [Core Tor/Tor]: Prop275: Eliminate "published" times from microdescriptor consensus

[Tor Bug Tracker & Wiki]

#21642: Prop275: Eliminate "published" times from microdescriptor consensus
+--
 Reporter:  nickm   |  Owner:  nickm
 Type:  enhancement | Status:
|  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, review-group-17  |  Actual Points:  .5
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 lgtm; One quick comment:

 In `routerstatus_format_entry()`, this is used if not vote status is
 present:

 {{{
 format_iso_time(published, rs->published_on_to_format);
 }}}

 This matches the commit description which is that `published_on_to_format`
 is only used has an output for the control port. However, I think we
 should add a strong validation of that and possibly a `tor_assert(format
 == NS_CONTROL_PORT)` in that if? If not, at least add a comment on how
 that is used for that function and what the caller should expect?

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

Re: [tor-bugs] #1922 [Core Tor/Tor]: torrc.d-style configuration directories

[Tor Bug Tracker & Wiki]

#1922: torrc.d-style configuration directories
-+-
 Reporter:  aa138346 |  Owner:
 |  Jigsaw52
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, intro,   |  Actual Points:
  tor-03-unspecified-201612  |
Parent ID:   | Points:  medium
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


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

Re: [tor-bugs] #1922 [Core Tor/Tor]: torrc.d-style configuration directories

[Tor Bug Tracker & Wiki]

#1922: torrc.d-style configuration directories
-+-
 Reporter:  aa138346 |  Owner:
 |  Jigsaw52
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, intro,   |  Actual Points:
  tor-03-unspecified-201612  |
Parent ID:   | Points:  medium
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 7. For consistency, let's sort the output of tor_listdir().

 8. Maybe we shouldn't automatically detect directory vs file: instead, we
 should only load the configuration files in a directory if the string ends
 with /*

 9. Do we support quoted paths here? Maybe we should.

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

Re: [tor-bugs] #1922 [Core Tor/Tor]: torrc.d-style configuration directories

[Tor Bug Tracker & Wiki]

#1922: torrc.d-style configuration directories
-+-
 Reporter:  aa138346 |  Owner:
 |  Jigsaw52
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, intro,   |  Actual Points:
  tor-03-unspecified-201612  |
Parent ID:   | Points:  medium
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Looks like good solid work!  A few comments:

 1.
 {{{
 +  if (!list) {
 +list = included_list;
 +list_last = included_list_last;
 +  } else if (included_list) {
 +list_last->next = included_list;
 +list_last = included_list_last;
 +  }
 }}}

 This conditional isn't necessary -- look what we were doing with the
 "next" pointer in the old code.

 2. Can the code in the `if (!strcmp(k, "%include")) {` block be extracted
 into a new function?  It makes the config_get_lines_aux function huge, and
 it's logically fairly separate.

 3. There should probably be a flag to enable %include on specific files:
 we use config_get_lines() all over the place, and we don't necessarily
 want to allow includes in all of them.

 4. Maybe there should be two wrappers for config_get_lines_aux: one
 presenting the old API, and one presenting one the new API that allows
 includes and reports whether they have happened?  That way we could avoid
 changing all 22 places that call config_get_lines().

 5. This could be much shorter and safer with tor_asprintf.
 {{{
 +  size_t fullname_len = (size_t) (strlen(path) + strlen(f) + 2);
 +  char *fullname = tor_malloc_zero(fullname_len);
 +  strlcat(fullname, path, fullname_len);
 +  strlcat(fullname, PATH_SEPARATOR, fullname_len);
 +  strlcat(fullname, f, fullname_len);
 +  tor_free(f);
 }}}

 6. This could use a changes file; see doc/HACKING/CodingStandards.md for
 more info on those.

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

Re: [tor-bugs] #22101 [Core Tor/Tor]: Can't have relative DataDirectory with CookieAuthentication enabled

[Tor Bug Tracker & Wiki]

#22101: Can't have relative DataDirectory with CookieAuthentication enabled
--+
 Reporter:  pastly|  Owner:  Jigsaw52
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Huh, I'm not sure whether or not that's behavior people would have
 expected.  What do you think, Roger?  Should everything be relative to the
 datadirectory, the cwd, or what?

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

Re: [tor-bugs] #21744 [Core Tor/Tor]: Build out glossary in torspec

[Tor Bug Tracker & Wiki]

#21744: Build out glossary in torspec
--+
 Reporter:  chelseakomlo  |  Owner:  chelseakomlo
 Type:  project   | Status:  closed
 Priority:  Low   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:  implemented
 Keywords:  torspec   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Merged, and made some corrections in
 21caa46a1f2064d60755df3aebf4447edf2189fb.  Watch out -- my fixes may
 themselves need fixes :)

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

Re: [tor-bugs] #4998 [Core Tor/Tor]: MyFamily as a list

[Tor Bug Tracker & Wiki]

#4998: MyFamily as a list
+--
 Reporter:  weasel  |  Owner:  Jigsaw52
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.2.3.11-alpha
 Severity:  Normal  | Resolution:
 Keywords:  tor-relay lorax easy intro  |  Actual Points:
Parent ID:  #15060  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 Oh, I see what you did.  Yes, you're correct there.  The code looks like
 it should work.

 One thing that we try not to do any more, though: we try not to rewrite
 values that could get written back into the torrc by a SAVECONF command.
 What we usually do instead now is, when we want to normalize a
 configuration value, normalize it into a separate field of or_options_t.
 What do you think of the patch I've made on top of your branch, in `my-
 family-list-fix-4498` in my public repository?  The URL is

 https://gitweb.torproject.org/nickm/tor.git/log/?h=my-family-list-fix-4498

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

Re: [tor-bugs] #21952 [User Experience]: Increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Increasing the use of onion services through automatic redirects and
aliasing
-+---
 Reporter:  linda|  Owner:  linda
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by mcs):

 * cc: brade, mcs (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] #22204 [Core Tor/Tor]: I can't list a relay in my EntryNodes if it doesn't have the Guard flag

[Tor Bug Tracker & Wiki]

#22204: I can't list a relay in my EntryNodes if it doesn't have the Guard flag
-+
 Reporter:  arma |  Owner:
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  030-backport regression  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

 * keywords:   => 030-backport regression
 * milestone:   => Tor: 0.3.1.x-final


Comment:

 Not intentional, but wow, that's not the greatest idea.

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

Re: [tor-bugs] #22206 [Core Tor/Tor]: Fetching compressed consensus gives it uncompressed if Accept-Encoding header is specified

[Tor Bug Tracker & Wiki]

#22206: Fetching compressed consensus gives it uncompressed if Accept-Encoding
header is specified
--+
 Reporter:  Sebastian |  Owner:  ahf
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * keywords:   => regression


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

Re: [tor-bugs] #22206 [Core Tor/Tor]: Fetching compressed consensus gives it uncompressed if Accept-Encoding header is specified

[Tor Bug Tracker & Wiki]

#22206: Fetching compressed consensus gives it uncompressed if Accept-Encoding
header is specified
--+
 Reporter:  Sebastian |  Owner:  ahf
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ahf):

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


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

Re: [tor-bugs] #19607 [Metrics/metrics-lib]: avoid repeated keyword strings

[Tor Bug Tracker & Wiki]

#19607: avoid repeated keyword strings
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 Please see this [https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/commit/?h=task-19607-2 example-branch] using enums.  The
 additional lines will go away when the currently deprecated methods in
 DescriptorImpl are removed.  (I wanted everything to pass tests and checks
 in this example.)

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

Re: [tor-bugs] #22122 [Metrics/metrics-lib]: Add support for six new key-value pairs added by OnionPerf

[Tor Bug Tracker & Wiki]

#22122: Add support for six new key-value pairs added by OnionPerf
-+---
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 I think there should be an OnionperfResult class that also supports the
 old torperf format.

 Eventually, there might be more use cases for the additional data in
 onionperf measurements.
 And, onionperf already adds many keys that are not part of the torperf
 format.

 So, all 'torperf' should become 'onionperf' soon.

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

Re: [tor-bugs] #22112 [Metrics/Metrics website]: Replace torperf.csv with onionperf.csv

[Tor Bug Tracker & Wiki]

#22112: Replace torperf.csv with onionperf.csv
-+
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by iwakeh):

 * status:  needs_review => needs_revision


Comment:

 Committed to master means 'productive', but the current onionperf.csv
 links on metrics.tp.o lead to 404; is that intended?

 init-onionperf.sql:  The last "group by" on the second to the last line
 contains a `3`, which seems to refer to `source`, but `source` in this
 select is set to `''`.  What is intended here?

 Why are there columns in the measurements table that are not used later on
 (mostly the unrecognized key lines))?  Shouldn't these be omitted?
 Here it seems as if only 'endpointremote' is used to determine the content
 of column 'server'.  If just that is needed it ought to be filled by the
 java code initially.  But, I might have overlooked something?

 In some other module we used constants for column-names in Java.  As the
 db redesign will be future work, is this intentionally left to be improved
 then?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22207 [Metrics/CollecTor]: Add bridge authority fingerprint to sanitized bridge network statuses

[Tor Bug Tracker & Wiki]

#22207: Add bridge authority fingerprint to sanitized bridge network statuses
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 When I looked through existing code that uses methods from
 `DescriptorFile` other than `DescriptorFile#getDescriptors()` for #22141,
 I spotted [https://gitweb.torproject.org/metrics-
 
web.git/tree/modules/legacy/src/main/java/org/torproject/ernie/cron/network/ConsensusStatsFileHandler.java#n205
 this code in metrics-web]:

 {{{
   if (descriptorFile.getFileName().contains(
   "4A0CCD2DDC7995083D73F5D667100C8A5831F16D")) {
 authority = "Tonga";
   } else if (descriptorFile.getFileName().contains(
   "1D8F3A91C37C5D1C4C19B1AD1D0CFBE8BF72D8E1")) {
 authority = "Bifroest";
   }
 }}}

 Not beautiful, I know, but that's not the point.  The point is that we
 need to parse the bridge authority fingerprint from the file name, because
 it's not contained in the descriptor itself.  That seems bad, and
 relatively easy to fix.

 Right now, the header of a sanitized bridge network status looks like
 this:

 {{{
 @type bridge-network-status 1.1
 published 2017-05-09 07:57:32
 flag-thresholds stable-uptime=1075980 stable-mtbf=2384868 fast-speed=21000
 guard-wfu=98.000% guard-tk=691200 guard-bw-inc-exits=318000 guard-bw-exc-
 exits=318000 enough-mtbf=1 ignoring-advertised-bws=0
 }}}

 We could easily include a "fingerprint" line there, like this:

 {{{
 @type bridge-network-status 1.2
 published 2017-05-09 07:57:32
 flag-thresholds stable-uptime=1075980 stable-mtbf=2384868 fast-speed=21000
 guard-wfu=98.000% guard-tk=691200 guard-bw-inc-exits=318000 guard-bw-exc-
 exits=318000 enough-mtbf=1 ignoring-advertised-bws=0
 fingerprint 1D8F3A91C37C5D1C4C19B1AD1D0CFBE8BF72D8E1
 }}}

 Ideally, we'd modify the bridge authority code to include this line, too,
 and then go through archived bridge network statuses and retroactively put
 it in.

 This is somewhat related to #12951 when we added a `"published"` line to
 bridge network statuses in a similar way.

 I'm copying isis to hear what they think about putting in a
 `"fingerprint"` line.

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

Re: [tor-bugs] #22141 [Metrics/metrics-lib]: Deprecate `DescriptorFile` and add relevant information to `Descriptor`

[Tor Bug Tracker & Wiki]

#22141: Deprecate `DescriptorFile` and add relevant information to `Descriptor`
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 See also some related thoughts on handling I/O exceptions in
 [https://trac.torproject.org/projects/tor/ticket/16225#comment:8 this
 ticket].

 Also note that `DescriptorParser#parseDescriptors()` needs to be changed,
 too, and return `Iterator` rather than `List`.
 There may be even more.

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

Re: [tor-bugs] #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:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by karsten):

 * cc: karsten (added)


Comment:

 I'm not arguing against fixing bugs or writing better tests.

 But what's the practical value of being able to reload the geoip files?
 We only ship new geoip files in new releases, and people will need to
 restart their tor process in order to upgrade to those anyway.  I'd guess
 that only a tiny fraction of operators would want to put in newer geoip
 files manually and reload their tor process.  And those statistics are
 hardly statistically relevant.

 So, I was curious how old the geoip files used by relays and bridges are,
 which is very likely related to how old the tor versions running in the
 network are.  Relays and bridges contain `geoip-db-digest` lines with
 SHA-1 digests of their geoip file, and we can extract those digests from
 tor's Git repo.  Here are some statistics on the age of geoip files
 mentioned in descriptors published between January 1, 2017 and May 4,
 2017:

 {{{
 # Relays
 Min.  1st Qu.   Median Mean  3rd Qu.
 Max.
 "2009-06-03" "2015-03-03" "2015-12-01" "2016-02-15" "2017-01-04"
 "2017-04-04"

 # Bridges
 Min.  1st Qu.   Median Mean  3rd Qu.
 Max.
 "2009-06-03" "2016-11-03" "2016-12-07" "2016-11-04" "2017-02-08"
 "2017-04-04"
 }}}

 These statistics say that the geoip files used by relays are more than 1
 year old on average and those used by bridges a couple of months.  (No
 idea why the difference between the two is so big.)

 But anyway, it seems like improving support for manually reloading geoip
 files won't make much of a difference.

 What we should consider instead is support for downloading signed geoip
 files from the directory authorities.  That will be much more effective.
 But it's also a lot of work and requires looking into licenses.

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

Re: [tor-bugs] #21886 [Applications/Tor Browser]: Downloading of binary files stalls at 0/0 bytes in Tor Browser based on ESR52 with e10s off

[Tor Bug Tracker & Wiki]

#21886: Downloading of binary files stalls at 0/0 bytes in Tor Browser based on
ESR52 with e10s off
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-7.0-must-alpha,   |  Actual Points:
  ff52-esr, TorBrowserTeam201705,|
  GeorgKoppen201705  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by gk):

 Replying to [comment:22 mcs]:
 > Replying to [comment:21 gk]:
 > > Well, that's not the same as in the attachment which is why I was
 asking.
 >
 > Ah. I forgot that we posted a patch in an attachment (work in progress)
 and then later we posted a pointer to what we thought was a better patch.
 The main difference between the two patches is where our hook is added
 (`nsExternalHelperAppService::DoContent()` vs.
 `nsExternalAppHandler::OnStartRequest()`). But you probably already knew
 that...
 >
 > Do you know if the patch we posted in the attachment fixes this bug on
 Linux? We did not try it because we were hoping to find a fix for #21766
 as well, on all platforms.

 Yes, it works for me on Linux with a custom build. And your patch in the
 attachment makes the difference between a working and broken download (all
 other things are equal). And, probably of equal importance, it stops the
 "http channel Listener OnDataAvailable contract violation" message in the
 console as well. So, I am slightly optimistic for this ticket... I am
 doing some nightlies right now for better testing, having your fix on top
 of `tor-browser-52.1.0esr-7.0-2-build1`.

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

Re: [tor-bugs] #22192 [User Experience/Website]: Update tor-mirrors.csv / mirror site

[Tor Bug Tracker & Wiki]

#22192: Update tor-mirrors.csv / mirror site
-+---
 Reporter:  Samdney  |  Owner:  Sebastian
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by arma):

 I added those entries, and did another mirror run, and pushed the result:

 https://lists.torproject.org/pipermail/tor-commits/2017-May/122508.html

 Please close the ticket if we're all set, or let me know if anything
 broke. Thanks!

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

Re: [tor-bugs] #22206 [Core Tor/Tor]: Fetching compressed consensus gives it uncompressed if Accept-Encoding header is specified (was: Fetching compressed consensus behaves unpredictably strange)

[Tor Bug Tracker & Wiki]

#22206: Fetching compressed consensus gives it uncompressed if Accept-Encoding
header is specified
--+
 Reporter:  Sebastian |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

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