[tor-bugs] #22048 [Applications/Tor Browser]: Find search phrase is preserved between sessions

[Tor Bug Tracker & Wiki]

#22048: Find search phrase is preserved between sessions
--+--
 Reporter:  bugreporter69 |  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:|
--+--


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

Re: [tor-bugs] #21273 [Applications/Tor Launcher]: Proxy settings unecessarily limit guard selection process

[Tor Bug Tracker & Wiki]

#21273: Proxy settings unecessarily limit guard selection process
---+---
 Reporter:  pastly |  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by pastly):

 Update:

 Today approx. 40% of guards (by number) have an ORPort of 443 or 80 today.
 That's about 44% by consensus weight.

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

Re: [tor-bugs] #22047 [Metrics/Atlas]: Remove usage of the data-original-title attribute

[Tor Bug Tracker & Wiki]

#22047: Remove usage of the data-original-title attribute
---+--
 Reporter:  cypherpunks|  Owner:  irl
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cypherpunks):

 * 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

[tor-bugs] #22047 [Metrics/Atlas]: Remove usage of the data-original-title attribute

[Tor Bug Tracker & Wiki]

#22047: Remove usage of the data-original-title attribute
---+-
 Reporter:  cypherpunks|  Owner:  irl
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 The HTML in Atlas uses the data-original-title attribute which serves no
 purpose other than to clutter up the code. FWICT this is left over code
 from when Atlas used the Bootstrap Popover plugin which was removed in
 commit
 
[https://gitweb.torproject.org/atlas.git/commit/?id=7a0ee0c7e69b10c33d671395f17c9cf8664bd2f9
 7a0ee0c7e69b10c33d671395f17c9cf8664bd2f9].

 The Bootstrap Tooltip plugin overwrites the data-original-title attribute
 when the title attribute is specified in the
 [https://gitweb.torproject.org/atlas.git/tree/js/libs/bootstrap/bootstrap-
 tooltip.js?id=a2b3f23f0212a16ae410d513749b535fdbe6bc5a#n191 fixTitle
 function]. In the current code base all elements that use the data-
 original-title attribute also specify the title attribute so the former
 serves no purpose.

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

Re: [tor-bugs] #21932 [Metrics/metrics-lib]: Stop relying on the platform's default charset

[Tor Bug Tracker & Wiki]

#21932: Stop relying on the platform's default charset
-+---
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 Good points!

 Can you give an example (or maybe even a complete list) of places where
 metrics-lib writes US-ASCII files?

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

Re: [tor-bugs] #6140 [Metrics/Censorship analysis]: Kazakhstan uses DPI to block Tor

[Tor Bug Tracker & Wiki]

#6140: Kazakhstan uses DPI to block Tor
-+--
 Reporter:  runa |  Owner:
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Metrics/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  dpi censorship block kz  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by dcf):

 * keywords:  dpi => dpi censorship block kz


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

Re: [tor-bugs] #21890 [Metrics/metrics-lib]: Don't skip unrecognized lines in certain cases

[Tor Bug Tracker & Wiki]

#21890: Don't skip unrecognized lines in certain cases
-+---
 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:

 Thanks for reviewing!  Merged and pushed to master.  Closing.

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

Re: [tor-bugs] #21587 [Metrics/Metrics website]: Improve running bridges statistic by skipping statuses without any running bridges

[Tor Bug Tracker & Wiki]

#21587: Improve running bridges statistic by skipping statuses without any 
running
bridges
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

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


Comment:

 I looked into logging a warning in this case, but we're re-processing all
 known bridge statuses twice per day, and we'd see that warning dozens or
 hundreds of time in each execution.  I think even on level finer it would
 be too noisy.  That's why I left out the log message.

 Cherry-picked and pushed to master.  Thanks for looking!  Closing.

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

Re: [tor-bugs] #21578 [Metrics/Metrics website]: Resolve deprecation warnings after upgrading to metrics-lib 1.6.0

[Tor Bug Tracker & Wiki]

#21578: Resolve deprecation warnings after upgrading to metrics-lib 1.6.0
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

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


Comment:

 Cherry-picked and pushed to master.  Thanks for looking!  Closing.

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

Re: [tor-bugs] #21366 [Metrics/Atlas]: support whitespace in search term (as does onionoo)

[Tor Bug Tracker & Wiki]

#21366: support whitespace in search term (as does onionoo)
---+-
 Reporter:  cypherpunks|  Owner:  irl
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by nusenu):

 Since the stop-gap solution does not work, is there any other way how I
 can build a single atlas URL to find a list of relays with a given contact
 string (I also know their fingerprint)?

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

Re: [tor-bugs] #21366 [Metrics/Atlas]: support whitespace in search term (as does onionoo)

[Tor Bug Tracker & Wiki]

#21366: support whitespace in search term (as does onionoo)
---+-
 Reporter:  cypherpunks|  Owner:  irl
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by nusenu):

 https://lists.torproject.org/pipermail/metrics-
 team/2017-April/000323.html:

 (trying to find a stop-gap solution for
 https://trac.torproject.org/projects/tor/ticket/21366)

 from onionoo.tpo:
 > search
 >
 > Return only (1) relays with the parameter value matching (part of a)
 > nickname, (possibly $-prefixed) [...]
 > If multiple search terms are given, separated by spaces, the
 > **intersection** of all relays and bridges matching all search terms
 > will be returned.


 Karsten wrote
 (https://trac.torproject.org/projects/tor/ticket/21366#comment:4)
 > You could approximate the second example by using
 > search=contact:Neel%20contact:Chauhan, but that will also return all
 > relays that have those **two** strings somewhere in the contact line,
 > rather than just Neel Chauhan.


 So I would assume that
 https://atlas.torproject.org/#search/contact:Neel%20contact:Chauhan
 (backend:
 https://onionoo.torproject.org/summary?search=contact:Neel%20contact:Chauhan)

 should only return relays where the contact field contains "Neel"
 **and** "Chauhan" but it also returns relays that have only "Neel" (and
 no "Chauhan"), so I would deduce that search terms are OR connected.

 example contact result:
 " 0xBBC1514B34CFB0F10231280F2FC36F0EF7887127"

 If search terms are OR connected (not the "intersection")
 then I would simply list all the fingerprints to get a list of all
 relevant relays, but that does not work either (no results)
 example (2 fingerprints separated by a single space):
 
https://atlas.torproject.org/#search/D5B8C38539C509380767D4DE20DE84CF84EE8299%201602E42D1DE3C7B3EF042F357F906DE55FA6C7C6
 Also tried:
 
"lookup:D5B8C38539C509380767D4DE20DE84CF84EE8299%20lookup:1602E42D1DE3C7B3EF042F357F906DE55FA6C7C6"

 In this search, the search terms are AND connected:

 https://onionoo.torproject.org/summary?search=contact:Neel%20D46175487C3

 So I'm not sure
 - if the current behavior works as documented and intended
 - How to get a stop-gap solution without false-positives/false-negative
 search results

 Is this a bug or am I misunderstanding something?
 (or does the AND/OR mode depend on whether search qualifiers are used?)

 -

 https://lists.torproject.org/pipermail/metrics-
 team/2017-April/000324.html:
 Hi nusenu,

 > (trying to find a stop-gap solution for
 > https://trac.torproject.org/projects/tor/ticket/21366)

 We should probably discuss this on the ticket, not here.  Quick response
 below though.

 > from onionoo.tpo:
 >> search
 >>
 >> Return only (1) relays with the parameter value matching (part of a)
 >> nickname, (possibly $-prefixed) [...]
 >> If multiple search terms are given, separated by spaces, the
 >> **intersection** of all relays and bridges matching all search terms
 >> will be returned.
 >
 >
 > Karsten wrote
 > (https://trac.torproject.org/projects/tor/ticket/21366#comment:4)
 >> You could approximate the second example by using
 >> search=contact:Neel%20contact:Chauhan, but that will also return all
 >> relays that have those **two** strings somewhere in the contact line,
 >> rather than just Neel Chauhan.
 >
 >
 > So I would assume that
 > https://atlas.torproject.org/#search/contact:Neel%20contact:Chauhan
 > (backend:
 >
 https://onionoo.torproject.org/summary?search=contact:Neel%20contact:Chauhan)
 >
 > should only return relays where the contact field contains "Neel"
 > **and** "Chauhan" but it also returns relays that have only "Neel" (and
 > no "Chauhan"), so I would deduce that search terms are OR connected.
 >
 > example contact result:
 > " 0xBBC1514B34CFB0F10231280F2FC36F0EF7887127"

 Hmm, looks like my suggestion was misleading.  The two qualified search
 terms are not OR-connected, but the second search term is simply
 discarded.  Try swapping the two and see how that changes the result.

 The spec says: "If the same parameter is specified more than once, only
 the first parameter value is considered."

 Now, the search term is only given once, but the qualified search terms
 are treated as if the user passed values to keys matching search
 qualifiers.  And the second contact parameter is simply dropped.

 This is expected behavior that we might be able to document better.

 All the best,
 Karsten

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online

Re: [tor-bugs] #13450 [Metrics/Torflow]: BwAuth is leaving ~10% of relays unmeasured

[Tor Bug Tracker & Wiki]

#13450: BwAuth is leaving ~10% of relays unmeasured
-+
 Reporter:  cypherpunks  |  Owner:  aagbsn
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Metrics/Torflow  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  performance  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by tyseom):

 * cc: tyseom (removed)
 * severity:   => Normal


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

Re: [tor-bugs] #9814 [Metrics/Atlas]: Atlas should make clear when relay details come from outdated consensus

[Tor Bug Tracker & Wiki]

#9814: Atlas should make clear when relay details come from outdated consensus
---+--
 Reporter:  wfn|  Owner:  metrics-team
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 I don't think the entire column should be removed, just remove the value
 for relays that are not running (instead of displaying a stricked through
 uptime).

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

Re: [tor-bugs] #9814 [Metrics/Atlas]: Atlas should make clear when relay details come from outdated consensus

[Tor Bug Tracker & Wiki]

#9814: Atlas should make clear when relay details come from outdated consensus
---+--
 Reporter:  wfn|  Owner:  metrics-team
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cypherpunks):

 * owner:  phw => metrics-team
 * status:  reopened => assigned


Comment:

 phw is not the maintainer of atlas anymore, irl 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] #22046 [Metrics/Atlas]: Remove cruft

[Tor Bug Tracker & Wiki]

#22046: Remove cruft
---+--
 Reporter:  cypherpunks|  Owner:  irl
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cypherpunks):

 * 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

[tor-bugs] #22046 [Metrics/Atlas]: Remove cruft

[Tor Bug Tracker & Wiki]

#22046: Remove cruft
---+-
 Reporter:  cypherpunks|  Owner:  irl
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 The Atlas repository contains several files which are duplicate, from the
 Tor Status era, or unused.

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

Re: [tor-bugs] #9814 [Metrics/Atlas]: Atlas should make clear when relay details come from outdated consensus

[Tor Bug Tracker & Wiki]

#9814: Atlas should make clear when relay details come from outdated consensus
---+--
 Reporter:  wfn|  Owner:  phw
 Type:  defect | Status:  reopened
 Priority:  High   |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 The uptime column on the search page is confusing. For both running and
 non-running relays the uptime is shown which makes no sense for the later.
 IMO the strike through isn't enough to clear up that confusion.
 Furthermore, the uptime of non-running relays is only shown on the search
 page (with the strike through) while the details page shows the downtime
 (which is better IMO). Finally, the online/offline dot in the first column
 better communicates the status of the relays than the strike through.
 Because of these reasons i think the uptime column should be removed from
 the search page.

 Now on to the details pages. When a relay is running it shows the uptime
 which is based on the `last_restarted` field from Onionoo according to
 
[https://gitweb.torproject.org/atlas.git/tree/js/models/relay.js?id=a2b3f23f0212a16ae410d513749b535fdbe6bc5a#n180
 js/models/relay.js:180]. The `last_restarted` field is also shown in its
 unparsed state further down the properties column. This is duplicate
 information (relative versus absolute) so i'm in favor of removing the
 `Last Restarted` field on the details page.

 When a relay is non-running it shows the downtime and the last seen
 timestamp. The downtime is based on the `last_seen` field from Onionoo
 according to
 
[https://gitweb.torproject.org/atlas.git/tree/js/models/relay.js?id=a2b3f23f0212a16ae410d513749b535fdbe6bc5a#n187
 js/models/relay.js:187]. This is duplicate information (relative versus
 absolute) so i'm in favor of removing the `Last Seen` field on the details
 page.

 I'd be happy to create a patch for these changes if they are approved.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-guard |  Actual Points:
Parent ID:| Points:  1.5
 Reviewer:|Sponsor:  SponsorU
--+

Comment (by s7r):

 Right. I am getting it every 2 days or so. The server is 1gbps at an ISP
 datacenter, so it's out of the question if it's on a slow connection
 network.

 I am running `0.3.1.0-alpha-dev (git-b1c7e5d8c0a648b1+f7afd80)` with
 default guard  context (no bridges).

 This Tor instance hosts a hidden service, and when this happens it can no
 longer build new rend circuits. However, let's think about it from another
 perspective maybe the bug is actually fixed in terms of logic of requested
 descriptors, but it's a race condition in how they are processed after
 being downloaded / refreshed. I am saying this because, based on the
 timestamp, at exactly the same time or immediately after (~1 second) it
 complains that it is missing descriptors for some of our primary entry
 guards, it comes back to reality and says We now have enough directory
 information to build circuits. And after more time (minutes - is this
 normal?) it confirms that it successfully opened a circuit. This is logged
 two times, every time, with the very same timestamp (is this also normal?)

 Check timestamps in these last events:

 {{{
 Apr 12 04:26:10 vm16 Tor[978]: Our directory information is no longer up-
 to-date enough to build circuits: We're missing descriptors for some of
 our primary entry guards
 Apr 12 04:26:10 vm16 Tor[978]: I learned some more directory information,
 but not enough to build a circuit: We're missing descriptors for some of
 our primary entry guards
 Apr 12 04:26:10 vm16 Tor[978]: We now have enough directory information to
 build circuits.
 Apr 12 04:27:19 vm16 Tor[978]: Tor has successfully opened a circuit.
 Looks like client functionality is working.
 Apr 12 04:27:19 vm16 Tor[978]: Tor has successfully opened a circuit.
 Looks like client functionality is working.
 }}}

 {{{
 Apr 17 12:04:16 vm16 Tor[978]: Our directory information is no longer up-
 to-date enough to build circuits: We're missing descriptors for some of
 our primary entry guards
 Apr 17 12:04:16 vm16 Tor[978]: I learned some more directory information,
 but not enough to build a circuit: We're missing descriptors for some of
 our primary entry guards
 Apr 17 12:04:16 vm16 Tor[978]: We now have enough directory information to
 build circuits.
 Apr 17 12:05:24 vm16 Tor[978]: Tor has successfully opened a circuit.
 Looks like client functionality is working.
 Apr 17 12:05:24 vm16 Tor[978]: Tor has successfully opened a circuit.
 Looks like client functionality is working.
 }}}

 {{{
 Apr 19 05:38:18 vm16 Tor[978]: Our directory information is no longer up-
 to-date enough to build circuits: We're missing descriptors for some of
 our primary entry guards
 Apr 19 05:38:18 vm16 Tor[978]: I learned some more directory information,
 but not enough to build a circuit: We're missing descriptors for some of
 our primary entry guards
 Apr 19 05:38:18 vm16 Tor[978]: We now have enough directory information to
 build circuits.
 Apr 19 05:42:12 vm16 Tor[978]: Tor has successfully opened a circuit.
 Looks like client functionality is working.
 Apr 19 05:42:12 vm16 Tor[978]: Tor has successfully opened a circuit.
 Looks like client functionality is working.
 }}}

 {{{
 Apr 21 00:48:20 vm16 Tor[978]: Our directory information is no longer up-
 to-date enough to build circuits: We're missing descriptors for some of
 our primary entry guards
 Apr 21 00:48:20 vm16 Tor[978]: I learned some more directory information,
 but not enough to build a circuit: We're missing descriptors for some of
 our primary entry guards
 Apr 21 00:48:21 vm16 Tor[978]: We now have enough directory information to
 build circuits.
 Apr 21 00:49:26 vm16 Tor[978]: Tor has successfully opened a circuit.
 Looks like client functionality is working.
 Apr 21 00:49:26 vm16 Tor[978]: Tor has successfully opened a circuit.
 Looks like client functionality is working.
 }}}

 asn should we allow a time period for Tor to process new descriptors upon
 refresh? In terms of seconds, so slower computers or computers on slower
 connections don't get these warnings? During that time, previous
 descriptors can be used. This also requires to ensure we try to refresh
 descriptors for guards with N minutes before the ones we already have
 expire, so we have this time period to handle it.

--
Ticket URL: 
Tor Bug Tracker & Wiki