Re: [tor-bugs] #9476 [Core Tor/Tor]: Completely drop support for Tor 0.2.2.x

2017-05-13 Thread Tor Bug Tracker & Wiki
#9476: Completely drop support for Tor 0.2.2.x
-+-
 Reporter:  nickm|  Owner:
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-auth, 026-triaged-1,  |  Actual Points:
  unfrozen, 027-triaged-1-out,   |
  tor-03-unspecified-201612  | Points:
Parent ID:  #15940   |  medium/large
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Replying to [comment:12 nickm]:
 > Dumping server support for 0.2.2 clients can wait till squeeze EOL.

 I hear squeeze has reached (and exceeded) eol.

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

Re: [tor-bugs] #22251 [Core Tor/Tor]: Time to retire old link versions?

2017-05-13 Thread Tor Bug Tracker & Wiki
#22251: Time to retire old link versions?
--+
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by yawning):

 Depends on #9476, though I'm not sure how much is left to do there.

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

Re: [tor-bugs] #22251 [Core Tor/Tor]: Time to retire old link versions?

2017-05-13 Thread Tor Bug Tracker & Wiki
#22251: Time to retire old link versions?
--+
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by Insolsence):

 * cc: ishbir@… (added)


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

[tor-bugs] #22251 [Core Tor/Tor]: Time to retire old link versions?

2017-05-13 Thread Tor Bug Tracker & Wiki
#22251: Time to retire old link versions?
--+
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 In our spec, we have
 {{{
All new relay implementations of the Tor protocol MUST support
backwards-compatible renegotiation
 }}}

 But the v3 link handshake came out in Tor 0.2.3.6-alpha. That's certainly
 older than any relays. Is it older than any clients that we expect to
 work?

 Step 0 in phasing out old link versions would be to admit in tor-spec that
 supporting them is not a MUST. I'd say we're ready to do this one any
 time. We could put v3 as the minimum you MUST implement, or we might pick
 v4, since it came out in 0.2.4.11-alpha, and that's pretty old now too.

 Step 1 in phasing out old link versions would be to actually remove the
 code from mainline Tor. In preparation, we should try to figure out which
 Tor client versions are still in use today, and which ones still happen to
 work with the current network, and figure out in what time frame we'll be
 ok breaking those old Tor clients.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22250 [- Select a component]: create one Tor Theme for Tor browser

2017-05-13 Thread Tor Bug Tracker & Wiki
#22250: create one Tor Theme for Tor browser
--+-
 Reporter:  nim01 |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 firefox have a default theme, and in version 53 got a two new nice compact
 themes, but maybe tor will be better with one custom theme made
 specifically for TBB.

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

Re: [tor-bugs] #22246 [Core Tor/Tor]: ASSERT failure on v0.3.0.6

2017-05-13 Thread Tor Bug Tracker & Wiki
#22246: ASSERT failure on v0.3.0.6
+
 Reporter:  tmpname0901 |  Owner:
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.0.6
 Severity:  Major   | Resolution:
 Keywords:  tor-hs prop224  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:  SponsorR-can
+
Description changed by arma:

Old description:

> May 10 12:57:20.000 [err] tor_assertion_failed_(): Bug:
> src/common/container.c:1430: digest256map_get: Assertion map failed;
> aborting. (on Tor 0.3.0.6 47d2e4f06ec26a79)
> May 10 12:57:20.000 [err] Bug: Assertion map failed in digest256map_get
> at src/common/container.c:1430. Stack trace: (on Tor 0.3.0.6
> 47d2e4f06ec26a79)
> May 10 12:57:20.000 [err] Bug: /usr/bin/tor(log_backtrace+0x42)
> [0x7f2bfbdefc12] (on Tor 0.3.0.6 47d2e4f06ec26a79)
> May 10 12:57:20.000 [err] Bug:
> /usr/bin/tor(tor_assertion_failed_+0xa3) [0x7f2bfbe07b53] (on Tor 0.3.0.6
> 47d2e4f06ec26a79)
> May 10 12:57:20.000 [err] Bug: /usr/bin/tor(digest256map_get+0x11b)
> [0x7f2bfbdf8d8b] (on Tor 0.3.0.6 47d2e4f06ec26a79)
> May 10 12:57:20.000 [err] Bug:
> /usr/bin/tor(hs_cache_lookup_as_dir+0x74) [0x7f2bfbde3714] (on Tor
> 0.3.0.6 47d2e4f06ec26a79)
> May 10 12:57:20.000 [err] Bug: /usr/bin/tor(+0x192323)
> [0x7f2bfbdb3323] (on Tor 0.3.0.6 47d2e4f06ec26a79)
> May 10 12:57:20.000 [err] Bug:
> /usr/bin/tor(connection_dir_process_inbuf+0x6a2) [0x7f2bfbdb7e42] (on Tor
> 0.3.0.6 47d2e4f06ec26a79)
> May 10 12:57:20.000 [err] Bug:
> /usr/bin/tor(connection_handle_read+0x794) [0x7f2bfbd92af4] (on Tor
> 0.3.0.6 47d2e4f06ec26a79)
> May 10 12:57:20.000 [err] Bug: /usr/bin/tor(+0xbc8a1)
> [0x7f2bfbcdd8a1] (on Tor 0.3.0.6 47d2e4f06ec26a79)
> May 10 12:57:20.000 [err] Bug: /usr/bin/tor(event_base_loop+0x804)
> [0x7f2bfbe692b4] (on Tor 0.3.0.6 47d2e4f06ec26a79)
> May 10 12:57:20.000 [err] Bug: /usr/bin/tor(do_main_loop+0x3f3)
> [0x7f2bfbcd91e3] (on Tor 0.3.0.6 47d2e4f06ec26a79)
> May 10 12:57:20.000 [err] Bug: /usr/bin/tor(tor_main+0xe75)
> [0x7f2bfbcda305] (on Tor 0.3.0.6 47d2e4f06ec26a79)
> May 10 12:57:20.000 [err] Bug: /usr/bin/tor(main+0x19)
> [0x7f2bfbcd6319] (on Tor 0.3.0.6 47d2e4f06ec26a79)
> May 10 12:57:20.000 [err] Bug:
> /lib64/libc.so.6(__libc_start_main+0xfd) [0x7f2bfadf4d1d] (on Tor 0.3.0.6
> 47d2e4f06ec26a79)
> May 10 12:57:20.000 [err] Bug: /usr/bin/tor(+0xb5229)
> [0x7f2bfbcd6229] (on Tor 0.3.0.6 47d2e4f06ec26a79)

New description:

 {{{
 May 10 12:57:20.000 [err] tor_assertion_failed_(): Bug:
 src/common/container.c:1430: digest256map_get: Assertion map failed;
 aborting. (on Tor 0.3.0.6 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug: Assertion map failed in digest256map_get at
 src/common/container.c:1430. Stack trace: (on Tor 0.3.0.6
 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug: /usr/bin/tor(log_backtrace+0x42)
 [0x7f2bfbdefc12] (on Tor 0.3.0.6 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug:
 /usr/bin/tor(tor_assertion_failed_+0xa3) [0x7f2bfbe07b53] (on Tor 0.3.0.6
 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug: /usr/bin/tor(digest256map_get+0x11b)
 [0x7f2bfbdf8d8b] (on Tor 0.3.0.6 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug:
 /usr/bin/tor(hs_cache_lookup_as_dir+0x74) [0x7f2bfbde3714] (on Tor 0.3.0.6
 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug: /usr/bin/tor(+0x192323)
 [0x7f2bfbdb3323] (on Tor 0.3.0.6 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug:
 /usr/bin/tor(connection_dir_process_inbuf+0x6a2) [0x7f2bfbdb7e42] (on Tor
 0.3.0.6 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug:
 /usr/bin/tor(connection_handle_read+0x794) [0x7f2bfbd92af4] (on Tor
 0.3.0.6 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug: /usr/bin/tor(+0xbc8a1) [0x7f2bfbcdd8a1]
 (on Tor 0.3.0.6 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug: /usr/bin/tor(event_base_loop+0x804)
 [0x7f2bfbe692b4] (on Tor 0.3.0.6 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug: /usr/bin/tor(do_main_loop+0x3f3)
 [0x7f2bfbcd91e3] (on Tor 0.3.0.6 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug: /usr/bin/tor(tor_main+0xe75)
 [0x7f2bfbcda305] (on Tor 0.3.0.6 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug: /usr/bin/tor(main+0x19)
 [0x7f2bfbcd6319] (on Tor 0.3.0.6 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug:
 /lib64/libc.so.6(__libc_start_main+0xfd) [0x7f2bfadf4d1d] (on Tor 0.3.0.6
 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug: /usr/bin/tor(+0xb5229) [0x7f2bfbcd6229]
 (on Tor 0.3.0.6 47d2e4f06ec26a79)
 }}}

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list

[tor-bugs] #22249 [Metrics/Onionoo]: Remove deprecation warnings as soon as metrics-lib 1.7.0 is released

2017-05-13 Thread Tor Bug Tracker & Wiki
#22249: Remove deprecation warnings as soon as metrics-lib 1.7.0 is released
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 Current Onionoo master does not use any deprecated metrics-lib methods,
 but as soon as we release metrics-lib 1.7.0 and update Onionoo to use that
 there will be some errors and some warnings.  I found 2 errors and 3
 warnings in the tests.  There might be more when metrics-lib 1.7.0 comes
 out.  This ticket is a placeholder to make sure that we remove these
 errors and warnings soon after they appear.

 In this context we might also want to fix the deprecation warnings related
 to `TimeFactory#getTime()`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22248 [Metrics/Metrics website]: Remove deprecation warnings as soon as metrics-lib 1.7.0 is released

2017-05-13 Thread Tor Bug Tracker & Wiki
#22248: Remove deprecation warnings as soon as metrics-lib 1.7.0 is released
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 Current metrics-web master does not use any deprecated metrics-lib
 methods, but as soon as we release metrics-lib 1.7.0 and update metrics-
 web to use that there will be some warnings.  I found 1 such warning in
 the advbwdist module and 3 warnings in the legacy module, all related to
 streamlined digest methods.  There might be more when metrics-lib 1.7.0
 comes out.  This ticket is a placeholder to make sure that we remove these
 warnings soon after they appear.

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

Re: [tor-bugs] #22247 [Metrics/CollecTor]: Remove deprecation warnings as soon as metrics-lib 1.7.0 is released

2017-05-13 Thread Tor Bug Tracker & Wiki
#22247: Remove deprecation warnings as soon as metrics-lib 1.7.0 is released
---+-
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  CollecTor 1.2.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 [https://gitweb.torproject.org/karsten/metrics-db.git/log/?h=task-22247 My
 branch task-22247] removes current deprecation warnings, but it should not
 yet be reviewed and merged, because it requires metrics-lib 1.7.0 at least
 for the last commit.  Putting it here anyway.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22247 [Metrics/CollecTor]: Remove deprecation warnings as soon as metrics-lib 1.7.0 is released

2017-05-13 Thread Tor Bug Tracker & Wiki
#22247: Remove deprecation warnings as soon as metrics-lib 1.7.0 is released
---+-
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  CollecTor 1.2.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 There are a couple of deprecation warnings when compiling CollecTor, some
 of which being introduced by preparations for metrics-lib 1.7.0.  Once
 that is released we should remove those warnings by updating to newer
 code.

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

Re: [tor-bugs] #22246 [Core Tor/Tor]: ASSERT failure on v0.3.0.6

2017-05-13 Thread Tor Bug Tracker & Wiki
#22246: ASSERT failure on v0.3.0.6
+
 Reporter:  tmpname0901 |  Owner:
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.0.6
 Severity:  Major   | Resolution:
 Keywords:  tor-hs prop224  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:  SponsorR-can
+
Changes (by asn):

 * keywords:   => tor-hs prop224
 * component:  Core Tor => Core Tor/Tor
 * sponsor:   => SponsorR-can


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

[tor-bugs] #22246 [Core Tor]: ASSERT failure on v0.3.0.6

2017-05-13 Thread Tor Bug Tracker & Wiki
#22246: ASSERT failure on v0.3.0.6
-+
 Reporter:  tmpname0901  |  Owner:
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor |Version:  Tor: 0.3.0.6
 Severity:  Major|   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 May 10 12:57:20.000 [err] tor_assertion_failed_(): Bug:
 src/common/container.c:1430: digest256map_get: Assertion map failed;
 aborting. (on Tor 0.3.0.6 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug: Assertion map failed in digest256map_get at
 src/common/container.c:1430. Stack trace: (on Tor 0.3.0.6
 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug: /usr/bin/tor(log_backtrace+0x42)
 [0x7f2bfbdefc12] (on Tor 0.3.0.6 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug:
 /usr/bin/tor(tor_assertion_failed_+0xa3) [0x7f2bfbe07b53] (on Tor 0.3.0.6
 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug: /usr/bin/tor(digest256map_get+0x11b)
 [0x7f2bfbdf8d8b] (on Tor 0.3.0.6 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug:
 /usr/bin/tor(hs_cache_lookup_as_dir+0x74) [0x7f2bfbde3714] (on Tor 0.3.0.6
 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug: /usr/bin/tor(+0x192323)
 [0x7f2bfbdb3323] (on Tor 0.3.0.6 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug:
 /usr/bin/tor(connection_dir_process_inbuf+0x6a2) [0x7f2bfbdb7e42] (on Tor
 0.3.0.6 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug:
 /usr/bin/tor(connection_handle_read+0x794) [0x7f2bfbd92af4] (on Tor
 0.3.0.6 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug: /usr/bin/tor(+0xbc8a1) [0x7f2bfbcdd8a1]
 (on Tor 0.3.0.6 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug: /usr/bin/tor(event_base_loop+0x804)
 [0x7f2bfbe692b4] (on Tor 0.3.0.6 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug: /usr/bin/tor(do_main_loop+0x3f3)
 [0x7f2bfbcd91e3] (on Tor 0.3.0.6 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug: /usr/bin/tor(tor_main+0xe75)
 [0x7f2bfbcda305] (on Tor 0.3.0.6 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug: /usr/bin/tor(main+0x19)
 [0x7f2bfbcd6319] (on Tor 0.3.0.6 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug:
 /lib64/libc.so.6(__libc_start_main+0xfd) [0x7f2bfadf4d1d] (on Tor 0.3.0.6
 47d2e4f06ec26a79)
 May 10 12:57:20.000 [err] Bug: /usr/bin/tor(+0xb5229) [0x7f2bfbcd6229]
 (on Tor 0.3.0.6 47d2e4f06ec26a79)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

2017-05-13 Thread 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 s7r):

 asn: you could be right with the second theory. Maybe the descriptors that
 need to be fetched are not even available, because the guard is not
 running in current consensus. This is based on a log analysis I just did
 now:

 On a period of ~1 hour and 15 minutes (20:40 - 21:55), it starts like this
 (this instance is using default Guard context, no bridges):

 {{{
 May 11 20:40:54 electrum Tor[7669]: Our directory information is no longer
 up-to-date enough to build circuits: We're missing descriptors for some of
 our primary entry guards
 May 11 20:40:54 electrum Tor[7669]: I learned some more directory
 information, but not enough to build a circuit: We're missing descriptors
 for some of our primary entry guards
 }}}

 Immediately after, over 500 messages like this one (with 1-3 seconds time
 between them):
 {{{
 May 11 20:41:01 electrum Tor[7669]: Giving up launching first hop of
 circuit to rendezvous point [scrubbed] for service yzgq5m227nhsi33j.
 May 11 20:41:04 electrum Tor[7669]: Giving up launching first hop of
 circuit to rendezvous point [scrubbed] for service yzgq5m227nhsi33j.
 May 11 20:41:07 electrum Tor[7669]: Giving up launching first hop of
 circuit to rendezvous point [scrubbed] for service yzgq5m227nhsi33j.
 May 11 20:41:10 electrum Tor[7669]: Giving up launching first hop of
 circuit to rendezvous point [scrubbed] for service yzgq5m227nhsi33j.
 May 11 20:41:44 electrum Tor[7669]: Giving up launching first hop of
 circuit to rendezvous point [scrubbed] for service yzgq5m227nhsi33j.
 May 11 20:41:47 electrum Tor[7669]: Giving up launching first hop of
 circuit to rendezvous point [scrubbed] for service yzgq5m227nhsi33j.
 May 11 20:41:49 electrum Tor[7669]: Giving up launching first hop of
 circuit to rendezvous point [scrubbed] for service yzgq5m227nhsi33j.
 May 11 20:41:51 electrum Tor[7669]: Giving up launching first hop of
 circuit to rendezvous point [scrubbed] for service yzgq5m227nhsi33j.
 }}}
 [...] so on so on until:
 {{{
 May 11 21:54:55 electrum Tor[7669]: Giving up launching first hop of
 circuit to rendezvous point [scrubbed] for service yzgq5m227nhsi33j.
 May 11 21:54:57 electrum Tor[7669]: Giving up launching first hop of
 circuit to rendezvous point [scrubbed] for service yzgq5m227nhsi33j.
 May 11 21:54:59 electrum Tor[7669]: Giving up launching first hop of
 circuit to rendezvous point [scrubbed] for service yzgq5m227nhsi33j.
 May 11 21:55:04 electrum Tor[7669]: Giving up launching first hop of
 circuit to rendezvous point [scrubbed] for service yzgq5m227nhsi33j.
 May 11 21:55:05 electrum Tor[7669]: Giving up launching first hop of
 circuit to rendezvous point [scrubbed] for service yzgq5m227nhsi33j.
 May 11 21:55:53 electrum Tor[7669]: We now have enough directory
 information to build circuits.
 May 11 21:55:54 electrum Tor[7669]: Tor has successfully opened a circuit.
 Looks like client functionality is working.
 May 11 21:55:54 electrum Tor[7669]: Tor has successfully opened a circuit.
 Looks like client functionality is working.
 }}}

 And it stopped complaining about failing the first hop of a rendezvous
 circuit. First hop is obviously the guard.

 There was a clear cutoff of over 1 hour in this case, just because one of
 the descriptors was missing. I don't know if the first primary guard was
 in that consensus as running or not.

 To take an informed decision, let's log some more information in a custom
 branch:
 - all primary guards in their order (first, second, etc)
 - the primary guard(s) for which we are missing descriptors only
 - the status of all primary guards in the current consensus (running / not
 running)
 - attempts to fetch the missing descriptors and status of this operation
 (success / failure).

 Maybe something else?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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

2017-05-13 Thread 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:  nickm
 Type:  defect   | Status:  accepted
 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:
-+

Comment (by acceleraTor):

 you may Want To Look into entrynodes.c @
 /**
  * Return true iff node has all the flags needed for us to consider
 it
  * a possible guard when sampling guards.
  */
 static int
 node_is_possible_guard(const node_t *node)
 {
   /* The "GUARDS" set is all nodes in the nodelist for which this
 predicate
* holds. */

   tor_assert(node);
   return (node->is_possible_guard &&
   node->is_stable &&
   node->is_fast &&
   node->is_valid &&
   node_is_dir(node));
 }

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22245 [Core Tor/Tor]: Logic error with monthly accounting

2017-05-13 Thread Tor Bug Tracker & Wiki
#22245: Logic error with monthly accounting
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Here's the code in src/or/hibernate.c:
 {{{
   /* If this is before the Nth, we want the Nth of last month. */
   if (tm.tm_mday < cfg_start_day ||
   (tm.tm_mday < cfg_start_day && before)) {
 --tm.tm_mon;
   }
 }}}
 Andrey Karpov points out in https://www.viva64.com/en/b/0507/ that the
 second clause of the if is redundant with the first clause.

 Looking at it more, I think we wanted that second clause to be
 {{{(tm.tm_mday == cfg_start_day && before)}}}.

 What are the implications of this bug for relays that do monthly
 accounting?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22244 [Core Tor/Tor]: tor_assert(strchr(cp, ':')+2) is never going to do what we want

2017-05-13 Thread Tor Bug Tracker & Wiki
#22244: tor_assert(strchr(cp, ':')+2) is never going to do what we want
--+
 Reporter:  arma  |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Here's the code in src/or/dns.c:
 {{{
 const char *err = strchr(cp, ':')+2;
 tor_assert(err);
 }}}
 Andrey Karpov points out in https://www.viva64.com/en/b/0507/ that that
 code is never going to do what we want: even if strchr returns NULL, err
 will still be 2.

 The history of that code is actually kind of exciting. It used to be
 {{{strchr(cp, ':'+2)}}}, which Veracode freaked out about:
 https://lists.torproject.org/pipermail/tor-
 commits/2008-February/008431.html
 and then mwenge noticed the underlying bug and nickm fixed it here:
 https://lists.torproject.org/pipermail/tor-
 commits/2008-February/008530.html
 but we left the tor_assert line in place.

 What's the right fix? We could simply take out the assert, because hey
 it's never been a problem. Or we could break it out into something like
 {{{
 const char *colon = strchr(cp, ':');
 tor_assert(colon);
 const char *err = colon+2;
 }}}

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