Re: [tor-bugs] #24826 [Core Tor/Tor]: LZMA-compressed consensus diffs stall Tor Browser launch for at least 20s or break it entirely

[Tor Bug Tracker & Wiki]

#24826: LZMA-compressed consensus diffs stall Tor Browser launch for at least 
20s
or break it entirely
--+
 Reporter:  gk|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 Replying to [comment:3 gk]:
 > Replying to [comment:2 cypherpunks]:
 > > 7.0.11 sometimes gives
 > > {{{
 > > [01-09 05:25:15] Torbutton NOTE: Exception on control port
 [Exception... "Component returned failure code: 0x804b000e
 (NS_ERROR_NET_TIMEOUT) [nsIBinaryInputStream.readBytes]"  nsresult:
 "0x804b000e (NS_ERROR_NET_TIMEOUT)"  location: "JS frame ::
 chrome://torbutton/content/torbutton.js :: torbutton_socket_readline ::
 line 824"  data: no]
 > > }}}
 > > on a slow Windows machine (didn't you forget to set the compression
 thread's priority below normal?).
 >
 > That's a different issue. There is no released Tor Browser that supports
 LZMA compression at the moment.
 Not so different as you think. Without LZMA it stalls for ~15 sec there
 and breaks Torbutton when more. And it's not funny that Tor periodically
 causes glitches in all other programs (check with 1 CPU VM). BTW,
 shouldn't Tor respond to Tor Launcher even when it's parsing diffs in the
 background? (Is timeout set to 15 sec as your logs show?)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24826 [Core Tor/Tor]: LZMA-compressed consensus diffs stall Tor Browser launch for at least 20s or break it entirely

[Tor Bug Tracker & Wiki]

#24826: LZMA-compressed consensus diffs stall Tor Browser launch for at least 
20s
or break it entirely
--+
 Reporter:  gk|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by gk):

 Replying to [comment:2 cypherpunks]:
 > 7.0.11 sometimes gives
 > {{{
 > [01-09 05:25:15] Torbutton NOTE: Exception on control port [Exception...
 "Component returned failure code: 0x804b000e (NS_ERROR_NET_TIMEOUT)
 [nsIBinaryInputStream.readBytes]"  nsresult: "0x804b000e
 (NS_ERROR_NET_TIMEOUT)"  location: "JS frame ::
 chrome://torbutton/content/torbutton.js :: torbutton_socket_readline ::
 line 824"  data: no]
 > }}}
 > on a slow Windows machine (didn't you forget to set the compression
 thread's priority below normal?).

 That#s a different issue. There is no released Tor Browser that supports
 LZMA compression at the moment.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24840 [Core Tor/Tor]: Hidden service xxx exceeded launch limit with 10 intro points in the last 35 seconds. Intro circuit launches are limited to 10 per 300 seconds

[Tor Bug Tracker & Wiki]

#24840: Hidden service xxx exceeded launch limit with 10 intro points in the 
last
35 seconds. Intro circuit launches are limited to 10 per 300 seconds
--+
 Reporter:  sx5486510 |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.6-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by sx5486510):

 Replying to [comment:2 Dbryrtfbcbhgf]:
 > Replying to [comment:1 sx5486510]:
 > > I build a new version: Tor version 0.3.3.0-alpha-dev.
 > > The same issue
 > >
 > >
 > > When i clean the files at
 c:\users\administrator\AppData\Roaming\Tor,the warning disappear and works
 > Try https://dist.torproject.org/tor-0.3.2.8-rc.tar.gz and see if that
 fixes the issue.

 Thanks
 I need to wait a few days until the warning come back

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24840 [Core Tor/Tor]: Hidden service xxx exceeded launch limit with 10 intro points in the last 35 seconds. Intro circuit launches are limited to 10 per 300 seconds

[Tor Bug Tracker & Wiki]

#24840: Hidden service xxx exceeded launch limit with 10 intro points in the 
last
35 seconds. Intro circuit launches are limited to 10 per 300 seconds
--+
 Reporter:  sx5486510 |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.6-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Dbryrtfbcbhgf):

 Replying to [comment:1 sx5486510]:
 > I build a new version: Tor version 0.3.3.0-alpha-dev.
 > The same issue
 >
 >
 > When i clean the files at c:\users\administrator\AppData\Roaming\Tor,the
 warning disappear and works
 Try https://dist.torproject.org/tor-0.3.2.8-rc.tar.gz and see if that
 fixes the issue.

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

Re: [tor-bugs] #24834 [Metrics/Relay Search]: Map consensus weight vs bandwidth for each bandwidth authority's votes

[Tor Bug Tracker & Wiki]

#24834: Map consensus weight vs bandwidth for each bandwidth authority's votes
--+--
 Reporter:  teor  |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bwauth-needs  |  Actual Points:
Parent ID:  #24674| Points:
 Reviewer:|Sponsor:
--+--

Comment (by irl):

 Ok, good to know we have a ticket for adding the data. I couldn't remember
 if we did or not.

 As a quick and rather horrible hack:
 https://people.torproject.org/~irl/volatile/rsvotes/

 This uses screen scraping of consensus health to generate some JSON that
 can be consumed by Relay Search, and needs to be manually updated. The
 data was based on the consensus published 2018-01-09 04:00:00.

 If consensus health could write out the JSON, then these maps could in
 theory be integrated into Relay Search but proper caching would be needed
 to avoid repeatedly fetching large documents.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23101 [Core Tor/Tor]: Predict and build specific HS purpose circuits (rather than GENERAL)

[Tor Bug Tracker & Wiki]

#23101: Predict and build specific HS purpose circuits (rather than GENERAL)
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-guard, guard-discovery-  |  Actual Points:
  prop247-controller, review-group-27|
Parent ID:  #13837   | Points:
 Reviewer:  asn  |Sponsor:
-+-

Comment (by mikeperry):

 Replying to [comment:19 asn]:
 > Yo yo, I'm back and took some time to look into this again.
 >
 > I suggested a potential fix for the #13837 issue in gitlab, and noted
 another issue found using the vanguards script.
 >
 > I also noticed that there is no #23101 in your `bug23101-squashed`
 branch, so I couldn't really test that one. I'll wait till the commit pops
 up to continue testing!

 Ok, I replied to your remaining outstanding comments on the 23101 commit
 with fixup commits. Everything is sitting in
 https://oniongit.eu/mikeperry/tor/commits/bug23101-squashed now. If you
 like the fixups, I will squash it all down and open a new merge request
 while we both test with vanguards.py.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24826 [Core Tor/Tor]: LZMA-compressed consensus diffs stall Tor Browser launch for at least 20s or break it entirely

[Tor Bug Tracker & Wiki]

#24826: LZMA-compressed consensus diffs stall Tor Browser launch for at least 
20s
or break it entirely
--+
 Reporter:  gk|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 7.0.11 sometimes gives
 {{{
 [01-09 05:25:15] Torbutton NOTE: Exception on control port [Exception...
 "Component returned failure code: 0x804b000e (NS_ERROR_NET_TIMEOUT)
 [nsIBinaryInputStream.readBytes]"  nsresult: "0x804b000e
 (NS_ERROR_NET_TIMEOUT)"  location: "JS frame ::
 chrome://torbutton/content/torbutton.js :: torbutton_socket_readline ::
 line 824"  data: no]
 }}}
 on a slow Windows machine (didn't you forget to set the compression
 thread's priority below 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] #13837 [Core Tor/Tor]: Mitigate guard discovery by pinning middle node

[Tor Bug Tracker & Wiki]

#13837: Mitigate guard discovery by pinning middle node
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-guard, guard-discovery-  |  Actual Points:
  prop247-controller |
Parent ID:  #9001| Points:
 Reviewer:  asn  |Sponsor:
 |  SponsorV-can
-+-

Comment (by mikeperry):

 Ok, two fixups so that we don't blame the entry guard, and emit a log
 message for some cases of this:
 
https://oniongit.eu/mikeperry/tor/commit/e9c4aa7823d1396fe2f34173d25f6aa602e9c0ef
 
https://oniongit.eu/mikeperry/tor/commit/cb1595040bbf4521f25548f00e93860f08aed683

 If you like those, and the stuff I am posting in response to your
 remaining comments on
 
https://oniongit.eu/mikeperry/tor/commit/2829a5fe4a093e27083b4a865380964c94420320,
 then I will rebase and squash all of this stuff down, and mark it as needs
 review with a new merge request.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24840 [Core Tor/Tor]: Hidden service xxx exceeded launch limit with 10 intro points in the last 35 seconds. Intro circuit launches are limited to 10 per 300 seconds

[Tor Bug Tracker & Wiki]

#24840: Hidden service xxx exceeded launch limit with 10 intro points in the 
last
35 seconds. Intro circuit launches are limited to 10 per 300 seconds
--+
 Reporter:  sx5486510 |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.6-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by sx5486510):

 I build a new version: Tor version 0.3.3.0-alpha-dev.
 The same issue

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

Re: [tor-bugs] #13837 [Core Tor/Tor]: Mitigate guard discovery by pinning middle node

[Tor Bug Tracker & Wiki]

#13837: Mitigate guard discovery by pinning middle node
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-guard, guard-discovery-  |  Actual Points:
  prop247-controller |
Parent ID:  #9001| Points:
 Reviewer:  asn  |Sponsor:
 |  SponsorV-can
-+-

Comment (by mikeperry):

 Replying to [comment:30 mikeperry]:
 > Replying to [comment:28 asn]:
 > > I encountered some annoying failures during testing this which I
 reported here:
 
https://oniongit.eu/mikeperry/tor/commit/7e962536f2d89ab0e2b8dd8821503ed66bd115ac#note_1804
 >
 > I am pretty sure this is two separate bugs that are orthogonal to this
 code:
 >
 > First, we are failing to find a second or third hop for the path because
 you specified an IP network mask  in HSLayer2Guards and HSLayer3Guards. It
 seems that routersets have a bug/quirk in their network mask handling. See
 routerset_contains(). They only return "true" for address range checks if
 the match REJECTED the specified address. If I change that
 routerset_contains() check to return true if the match is ACCEPTED, the
 very same netmasks suddenly work. However, if I just patch that
 routerset_contains function, disparate things that use routersets like
 excludenodes and exitpolicies suddenly break (in fact, about 12 unittests
 fail when I change this).

 Phew, it is not this complicated. routerset_contains() is just written
 confusingly. It turns out that the /16 restriction is still in effect, so
 when you specified the same /16 for Layer2 and Layer3 guards, that was
 actually invalid. I will just work on fixups to make sure we don't blame
 the entry guard for 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] #24839 [Core Tor/Tor]: Add a torrc option and descriptor line to opt-in as a FallbackDir

[Tor Bug Tracker & Wiki]

#24839: Add a torrc option and descriptor line to opt-in as a FallbackDir
+--
 Reporter:  teor|  Owner:  (none)
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  needs-proposal, fallback, tor-spec  |  Actual Points:
Parent ID:  #24786  | Points:  3
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 We should check if the fallbacks have a DirPort and ContactInfo.
 A ContactInfo should be required on the relay and by the selection script.
 No DirPort should result in a warning on the relay.
 A DirPort should be required by the selection script until #19129 is
 implemented.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24756 [Applications/Tor Browser]: New default bridge: bridge-01.noisetor.net

[Tor Bug Tracker & Wiki]

#24756: New default bridge: bridge-01.noisetor.net
+--
 Reporter:  patrickod   |  Owner:  tbb-team
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-bridges, TorBrowserTeam201801R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by dcf):

 We usually ask the default bridges to block their ORPort (9001 in this
 case) so that you won't get any vanilla-Tor connections.

 I did a port scan and found ports 22 (SSH), 9001 (ORPort), 9101 (?), and
 46089 (obfs4) open. You might want to firewall all but 22 and 46089.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24834 [Metrics/Relay Search]: Map consensus weight vs bandwidth for each bandwidth authority's votes

[Tor Bug Tracker & Wiki]

#24834: Map consensus weight vs bandwidth for each bandwidth authority's votes
--+--
 Reporter:  teor  |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bwauth-needs  |  Actual Points:
Parent ID:  #24674| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Replying to [comment:2 irl]:
 > This would require information that is not in Onionoo.

 Yes, that's ticket #16843.

 > I don't know if the consensus contains this information or if it would
 only come from votes (I know consensus-health displays it in the consensus
 column, but is that synthentic?). Onionoo doesn't have votes yet.

 consensus-health gets bandwidths from the votes and the consensus. The
 only synthetic flag is the deciding bwauth(s), which is calculated by
 matching the consensus bandwidth with the vote bandwidths.


 (Consensus-health doesn't load descriptors.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #16843 [Metrics/Onionoo]: Add all bwauth measurements (from votes)

[Tor Bug Tracker & Wiki]

#16843: Add all bwauth measurements (from votes)
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Metrics/Onionoo   |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bwauth-needs  |  Actual Points:
Parent ID:  #24834| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * keywords:   => tor-bwauth-needs
 * parent:   => #24834


Comment:

 There are a few tickets that want this feature, #24834 is one of them.
 We would really like this feature so we can map bwauth bias.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22026 [Metrics/Ideas]: Create new service to retrieve raw documents

[Tor Bug Tracker & Wiki]

#22026: Create new service to retrieve raw documents
---+--
 Reporter:  irl|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Ideas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by teor):

 Here's a stop-gap measure:
 * when a relay on Relay Search has a DirPort, provide links to
 http://dirport/tor/server/authority and
 http://dirport/tor/extrainfo/fp/

 This makes the current descriptor available for some relays on Relay
 Search.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24840 [Core Tor/Tor]: Hidden service xxx exceeded launch limit with 10 intro points in the last 35 seconds. Intro circuit launches are limited to 10 per 300 seconds

[Tor Bug Tracker & Wiki]

#24840: Hidden service xxx exceeded launch limit with 10 intro points in the 
last
35 seconds. Intro circuit launches are limited to 10 per 300 seconds
--+
 Reporter:  sx5486510 |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.6-alpha
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I've checked this ticket:
 https://trac.torproject.org/projects/tor/ticket/22159
 It marked fixed at branch 0.3.1, My tor version is 0.3.2.6-alpha-dev.
 It looks like there's still a problem.

 This the log:
 Jan 09 10:51:21.015 [notice] Tor 0.3.2.6-alpha-dev running on Windows 7
 [server] with Libevent 2.1.5-beta, OpenSSL 1.0.1s, Zlib 1.2.8, Liblzma
 N/A, and Libzstd N/A.
 ...
 Jan 09 10:51:21.031 [notice] Opening Socks listener on 127.0.0.1:9050
 Jan 09 10:51:21.000 [notice] We were built to run on a 64-bit CPU, with
 OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently
 lacks accelerated support for the NIST P-224 and P-256 groups. Building
 openssl with such support (using the enable-ec_nistp_64_gcc_128 option
 when configuring it) would make ECDH much faster.
 Jan 09 10:51:22.000 [notice] Bootstrapped 0%: Starting
 Jan 09 10:51:24.000 [notice] Starting with guard context "default"
 Jan 09 10:51:24.000 [notice] Bootstrapped 80%: Connecting to the Tor
 network
 Jan 09 10:51:28.000 [notice] Bootstrapped 85%: Finishing handshake with
 first hop
 Jan 09 10:51:30.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
 Jan 09 10:51:30.000 [warn] Your Guard radia4 ($) is failing an
 extremely large amount of circuits. This could indicate a route
 manipulation attack, extreme network overload, or a bug. Success counts
 are 37/297. Use counts are 76/83. 250 circuits completed, 1 were unusable,
 213 collapsed, and 2 timed out. For reference, your timeout cutoff is 60
 seconds.
 Jan 09 10:51:31.000 [notice] Tor has successfully opened a circuit. Looks
 like client functionality is working.
 Jan 09 10:51:31.000 [notice] Bootstrapped 100%: Done
 Jan 09 10:51:56.000 [warn] Hidden service xxx exceeded launch limit
 with 10 intro points in the last 35 seconds. Intro circuit launches are
 limited to 10 per 300 seconds.
 Jan 09 10:51:56.000 [warn] Service configured in "D:\\x\\Data":
 Jan 09 10:51:56.000 [warn]   Intro point 0 at [scrubbed]: circuit is open
 Jan 09 10:51:56.000 [warn]   Intro point 1 at [scrubbed]: circuit is
 connecting to server
 Jan 09 10:51:56.000 [warn]   Intro point 2 at [scrubbed]: circuit is
 connecting to server

 I can't run for a long time on the same server?

 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] #21994 [Metrics/Consensus Health]: Consensus Health: what is the distribution of a bandwidth authority's measurements?

[Tor Bug Tracker & Wiki]

#21994: Consensus Health: what is the distribution of a bandwidth authority's
measurements?
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  new
 Priority:  Very Low  |  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by teor):

 I opened #24834 as a follow-up to map the consensus weight vs bandwidth
 per bandwidth authority.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24818 [Core Tor/Tor]: Make the hard-coded authorities into a separate include file with a standard format

[Tor Bug Tracker & Wiki]

#24818: Make the hard-coded authorities into a separate include file with a
standard format
---+
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  torspec, tor-auth  |  Actual Points:
Parent ID:  #24786 | Points:  1
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * parent:   => #24786


Comment:

 Parenting to #24786, because this affects the fallback file format as
 well.

 Here's what we need to do here:
 * specify the unified authority and fallback formats
   * move each field to its own line
   * reorder fields so the files are as similar as possible
 * create a script that generates the authority format from the authorities
 in the current consensus
   * apply address overrides
   * make sure the details match the current list
   * check that all supported Tor versions can parse the list (existing
 unit tests)
 * update the fallback script to generate the new format, and increment the
 version
   * modify the structure of the current list, but not the content
   * check that all supported Tor versions (0.2.9 and later) can parse the
 list (existing unit tests)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #8742 [Core Tor/Tor]: Byte history leaks information about local usage/hidden services

[Tor Bug Tracker & Wiki]

#8742: Byte history leaks information about local usage/hidden services
-+-
 Reporter:  alphawolf|  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.2.8.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Blocker  | Resolution:  fixed
 Keywords:  byte-history, stats, tor-hs, |  Actual Points:
  privacy, tor-relay, 026-triaged-1, |
  027-triaged-1-in, PostFreeze027|
Parent ID:   | Points:  medium
 Reviewer:   |Sponsor:
 |  SponsorR
-+-
Changes (by 43901348):

 * severity:   => Blocker


Comment:

 '''PLEASE '''reopen this. Having "fixed" the issue by only adding a
 startup warning is inaccurate and insufficient:

  * Some admins will never see the warning
  * Some admins will see the warning, come to this link, see the issue is
 fixed and conclude the warning is out of date
  * The list of proposed solutions in the issue summary does not include
 "just add a startup warning, but don't address the issue itself"

 This can easily lead to misunderstandings. Please keep the issue open, or
 if you don't think it's worth fixing, please then mark it as WONTFIX.

 Anything but what you have now would be a good start, but a more robust
 solution would be to ensure that administrators see this warning, and
 ideally have to acknowledge that they know what they are doing by setting
 a configuration switch in torrc to allow a relay and HS to be run in the
 same instance.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24839 [Core Tor/Tor]: Add a torrc option and descriptor line to opt-in as a FallbackDir

[Tor Bug Tracker & Wiki]

#24839: Add a torrc option and descriptor line to opt-in as a FallbackDir
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core  |Version:
  Tor/Tor |
 Severity:  Normal|   Keywords:  needs-proposal, fallback, tor-spec
Actual Points:|  Parent ID:  #24786
   Points:  3 |   Reviewer:
  Sponsor:|
--+
 This needs:
 * a proposal and a design
 * a patch to dir-spec.txt
 * a patch to the tor man page
 * a tor code patch
 * an updateFallbackDirs.py code patch
 * a wiki update to [[doc/UpdatingFallbackDirectoryMirrors]]

 Here's a quick sketch of a design:

 1. Relay operators set `OfferFallbackDirServer 1` to offer their relay as
 a potential FallbackDir.
 2. Relays with this option set put `offer-fallback-dir-server` in their
 descriptors
 3. updateFallbackDirs.py loads relay fingerprints with `offer-fallback-
 dir-server`, and from the legacy whitelist (#24838 will make this easier)
 4. updateFallbackDirs.py applies the blacklist, does stability checks, and
 generates the fallback list

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

Re: [tor-bugs] #24806 [Core Tor/Tor]: LTS branch leaks memory continuously under stress/attack, requires back-port of 0.3.2.8-rc fixes to remain viable

[Tor Bug Tracker & Wiki]

#24806: LTS branch leaks memory continuously under stress/attack, requires back-
port of 0.3.2.8-rc fixes to remain viable
--+
 Reporter:  starlight |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by starlight):

 migrating to SLAB memory allocation is worth considering

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22760 [Core Tor/Tor]: Fix extra-info flags on fallbacks

[Tor Bug Tracker & Wiki]

#22760: Fix extra-info flags on fallbacks
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Low   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.1-alpha
 Severity:  Minor | Resolution:
 Keywords:  fallback  |  Actual Points:
Parent ID:  #24786| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * priority:  Medium => Low
 * severity:  Normal => Minor


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19129 [Core Tor/Fallback Scripts]: Allow Fallback Directories with no DirPort

[Tor Bug Tracker & Wiki]

#19129: Allow Fallback Directories with no DirPort
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Fallback Scripts|Version:
 Severity:  Minor| Resolution:
 Keywords:  tor-client fallback-directory|  Actual Points:
  needs-design reachability bootstrap|
Parent ID:  #24786   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * priority:  Medium => Low
 * severity:  Normal => Minor


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24838 [Core Tor/Fallback Scripts]: Just have relay fingerprints in the fallback whitelist

[Tor Bug Tracker & Wiki]

#24838: Just have relay fingerprints in the fallback whitelist
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:
Parent ID:  #24786 | Points:  1
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 We'll still need to check and warn if fallbacks don't have a DirPort. At
 least until stem gets ORPort support (#18856), and we modify Tor and the
 script to accept relays without DirPorts (#19129).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #19129 [Core Tor/Fallback Scripts]: Allow Fallback Directories with no DirPort

[Tor Bug Tracker & Wiki]

#19129: Allow Fallback Directories with no DirPort
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Fallback Scripts|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client fallback-directory|  Actual Points:
  needs-design reachability bootstrap|
Parent ID:  #24786   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * component:  Core Tor/Tor => Core Tor/Fallback Scripts
 * parent:  #7798 => #24786
 * milestone:  Tor: unspecified => Tor: 0.3.4.x-final


Comment:

 We might do this in 0.3.4 if stem implements ORPort support by then. See
 #18856.
 This will require a fallback script change, and a Tor change.

 And we will have to think about whether we want to backport the tor
 change.
 (We could backport a minimal change that ignores fallbacks with no
 DirPort.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22760 [Core Tor/Tor]: Fix extra-info flags on fallbacks

[Tor Bug Tracker & Wiki]

#22760: Fix extra-info flags on fallbacks
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  fallback  |  Actual Points:
Parent ID:  #24786| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * owner:  teor => (none)
 * parent:   => #24786
 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.4.x-final


Comment:

 We could do this as part of the next fallback rebuild if we wanted to.
 I won't get time to do it in 0.3.3.

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

Re: [tor-bugs] #24838 [Core Tor/Fallback Scripts]: Just have relay fingerprints in the fallback whitelist (was: Just have relay fingerprints in the whitelist)

[Tor Bug Tracker & Wiki]

#24838: Just have relay fingerprints in the fallback whitelist
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:
Parent ID:  #24786 | Points:  1
 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

[tor-bugs] #24838 [Core Tor/Fallback Scripts]: Just have relay fingerprints in the whitelist

[Tor Bug Tracker & Wiki]

#24838: Just have relay fingerprints in the whitelist
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal |   Keywords:  fallback
Actual Points: |  Parent ID:  #24786
   Points:  1  |   Reviewer:
  Sponsor: |
---+---
 We can rely on Onionoo to tell us when relay addresses change, so we don't
 need to record or check them.

 This simplifies maintaining the fallback whitelist, and also simplifies
 the script.

 We should probably still put the full details in the blacklist, but that's
 rare. We can use generateFallbackDirLine.py for that.

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

Re: [tor-bugs] #24834 [Metrics/Relay Search]: Map consensus weight vs bandwidth for each bandwidth authority's votes

[Tor Bug Tracker & Wiki]

#24834: Map consensus weight vs bandwidth for each bandwidth authority's votes
--+--
 Reporter:  teor  |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bwauth-needs  |  Actual Points:
Parent ID:  #24674| Points:
 Reviewer:|Sponsor:
--+--

Comment (by irl):

 This would require information that is not in Onionoo. I don't know if the
 consensus contains this information or if it would only come from votes (I
 know consensus-health displays it in the consensus column, but is that
 synthentic?). Onionoo doesn't have votes yet.

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

Re: [tor-bugs] #24716 [Core Tor/DirAuth]: Try cranking up cbttestfreq consensus param, to see if it helps the current overload

[Tor Bug Tracker & Wiki]

#24716: Try cranking up cbttestfreq consensus param, to see if it helps the 
current
overload
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 I think the changes had a clear effect on my relays, that varied by their
 proximity to the new clients at OVH. But it could have been a coincidence.

 I've tried tuning a lot of things since then, here's my update:
 https://trac.torproject.org/projects/tor/ticket/24782#comment:6

 My next step is to DROP all traffic from these IP addresses so I can get
 decent data for our privacy preserving stats research. That means I won't
 be able to do comparisons.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24837 [Metrics/Onionoo]: Allow Relay Searches for Additional Flags

[Tor Bug Tracker & Wiki]

#24837: Allow Relay Searches for Additional Flags
-+--
 Reporter:  teor |  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:
-+--
Changes (by irl):

 * component:  Metrics/Relay Search => Metrics/Onionoo


Comment:

 Currently these are generated by Relay Search. We should move these into
 Onionoo so that other clients can benefit from them (e.g. metrics-bot) and
 so that searching works 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] #9186 [Webpages/Website]: Document how to report security vulnerabilities

[Tor Bug Tracker & Wiki]

#9186: Document how to report security vulnerabilities
--+--
 Reporter:  lunar |  Owner:  kat5
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Blocker   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 The key fingerprint for tor-security is 8B90 4624 C5A2 8654 E453  9BC2
 E135 A8B4 1A7B F184.
 dgoulet can confirm.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22271 [Core Tor/Fallback Scripts]: Regenerate fallback list for 0.3.2 or 0.3.3

[Tor Bug Tracker & Wiki]

#22271: Regenerate fallback list for 0.3.2 or 0.3.3
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  fallback   |  Actual Points:  2
Parent ID: | Points:  3
 Reviewer: |Sponsor:
---+---
Changes (by teor):

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


Comment:

 This is done.
 Thanks all!

 https://lists.torproject.org/pipermail/tor-relays/2018-January/014080.html

 #24786 is the master task for the next rebuild. Relay opt-ins and updates
 go to #24805.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-ddos  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+
Changes (by teor):

 * status:  assigned => needs_information


Comment:

 Ok, so do we want to hold off on this change?
 Or do we want to try 0.4*Total RAM?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24837 [Metrics/Relay Search]: Allow Relay Searches for Additional Flags

[Tor Bug Tracker & Wiki]

#24837: Allow Relay Searches for Additional Flags
--+--
 Reporter:  teor  |  Owner:  metrics-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 I just tried to search for all the FallbackDirs on Relay Search to find
 out if they had been updated.

 But I didn't get any results with a simple search: "flag:FallbackDir".
 And the Advanced Search doesn't have the additional flags as options.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24836 [Metrics/Consensus Health]: Shared Random reveal count is "None" on consensus health

[Tor Bug Tracker & Wiki]

#24836: Shared Random reveal count is "None" on consensus health
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 For:
 {{{
 Consensus was published 2018-01-08 21:00:00.
 }}}

 I see that all the votes match, but the consensus does not:
 {{{
 faravahar
 Previous9 kYn3dCExUHkh8vfX0h666Y0mNlZVS6zq4WYNzCvVMcg=
 Current 9 JLjoTNxC95QU/o45hb5i9WttluHxt1argqitjW1iqlY=
 ...
 consensus
 PreviousNone kYn3dCExUHkh8vfX0h666Y0mNlZVS6zq4WYNzCvVMcg=
 Current None JLjoTNxC95QU/o45hb5i9WttluHxt1argqitjW1iqlY=
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24805 [Core Tor/Fallback Scripts]: Update fallback whitelist and blacklist

[Tor Bug Tracker & Wiki]

#24805: Update fallback whitelist and blacklist
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:
Parent ID:  #24786 | Points:  2
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 Three operators sent emails to tor-relays:

 https://lists.torproject.org/pipermail/tor-relays/2018-January/014063.html

 92412EA1B9AA887D462B51D816777002F4D58907
 360CBA08D1E24F513162047BDB54A1015E531534

 https://lists.torproject.org/pipermail/tor-relays/2018-January/014064.html

 A2A6616723B511D8E068BB71705191763191F6B2

 https://lists.torproject.org/pipermail/tor-relays/2018-January/014069.html

 E51620B90DCB310138ED89EDEDD0A5C361AAE24E

 And one sent an email to me directly, saying their relay's details had
 changed to:

 BC7ACFAC04854C77167C7D66B7E471314ED8C410
 144.76.75.184:9001
 [2a01:4f8:191:93a2::4]:9001

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #13837 [Core Tor/Tor]: Mitigate guard discovery by pinning middle node

[Tor Bug Tracker & Wiki]

#13837: Mitigate guard discovery by pinning middle node
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-guard, guard-discovery-  |  Actual Points:
  prop247-controller |
Parent ID:  #9001| Points:
 Reviewer:  asn  |Sponsor:
 |  SponsorV-can
-+-

Comment (by mikeperry):

 Replying to [comment:28 asn]:
 > I encountered some annoying failures during testing this which I
 reported here:
 
https://oniongit.eu/mikeperry/tor/commit/7e962536f2d89ab0e2b8dd8821503ed66bd115ac#note_1804

 I am pretty sure this is two separate bugs that are orthogonal to this
 code:

 First, we are failing to find a second or third hop for the path because
 you specified an IP network mask  in HSLayer2Guards and HSLayer3Guards. It
 seems that routersets have a bug/quirk in their network mask handling. See
 routerset_contains(). They only return "true" for address range checks if
 the match REJECTED the specified address. If I change that
 routerset_contains() check to return true if the match is ACCEPTED, the
 very same netmasks suddenly work. However, if I just patch that
 routerset_contains function, disparate things that use routersets like
 excludenodes and exitpolicies suddenly break (in fact, about 12 unittests
 fail when I change this).

 Since we don't need network masks for our usecase, one option is to simply
 forbid their use for these options. I worry that if we try to do anything
 complicated than we absolutely need here, we will miss the 0.3.3 merge
 deadline. Is there something easier/saner we could do here?

 Second, I don't think that changing circuit_build_failed() to ignore guard
 failures if circ->n_chan is NULL is correct. If you can't connect to a
 guard at all in other circumstances, that should still count as a failure.
 One thing we could do, though, is add a special check in
 circuit_build_failed() to not fault the guard node if vanguards are in use
 *and* we know that the vanguard failed because none of the specified
 vanguards are available. I can try to do this in a fixup, at least.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24470 [Metrics/Analysis]: Distinguish point events from ongoing events in metrics timeline

[Tor Bug Tracker & Wiki]

#24470: Distinguish point events from ongoing events in metrics timeline
--+--
 Reporter:  dcf   |  Owner:  metrics-team
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Metrics/Analysis  |Version:
 Severity:  Normal| Resolution:
 Keywords:  metrics-timeline  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * status:  new => needs_review


Comment:

 In [[doc/MetricsTimeline?action=diff&version=215]] I went with Idea 2;
 that is, point events have a blank end date, and ongoing events have an
 end date of "ongoing".

 I initially intended to implement Idea 1 (mark the point events instead of
 the ongoing events). In fact I had it all implemented and then I changed
 my mind. The main reason was that almost all the entries, whose end date
 is blank, are point events and not ongoing events. I went through the
 whole timeline and only at most 10 were ongoing. One of the things we're
 going to have to do is periodically check which ongoing events have ended,
 and it's easier to ctrl-F for "ongoing" than it is to search for the
 absence of a mark. In fact some of the entries I marked "ongoing" I
 suspect have already ended. The "ongoing" marker therefore serves as a
 todo of sorts.

 The necessary code changes were, for me, pretty small. Here is the diff
 from the `tidy` script in metrics-timeline-tools:
 {{{
 #!diff
 @@ -28,20 +28,22 @@ class Entry(object):
  def __init__(self):
  self.start_date = None
  self.start_date_approx = None
  self.end_date = None
  self.end_date_approx = False
 +self.is_ongoing = False
  self.places = set()
  self.protocols = set()
  self.description = None
  self.links = []

  @staticmethod
  def from_table_row(row):
  entry = Entry()
  entry.start_date, entry.start_date_approx =
 parse_datetime(row.start_date)
  entry.end_date, entry.end_date_approx =
 parse_datetime(row.end_date)
 +entry.is_ongoing = row.end_date == "ongoing"
  entry.places = set(row.places.split())
  entry.protocols = set(row.protocols.split())
  entry.description = parse_wikitext(row.description)
  entry.links = parse_links(row.links)
  return entry
 @@ -57,20 +59,20 @@ class Entry(object):
  )

  def to_wikitext_row(self):
  cells = (
  format_datetime_approx(self.start_date,
 self.start_date_approx),
 -format_datetime_approx(self.end_date, self.end_date_approx),
 +self.is_ongoing and "ongoing" or
 format_datetime_approx(self.end_date, self.end_date_approx),
  " ".join(sorted(self.places)),
  " ".join(sorted(self.protocols)),
  self.description.to_wikitext(),
  " ".join(link.to_wikitext() for link in self.links),
  )
  return format_table_row(cells)

  def parse_datetime(s):
 -if s == "":
 +if s == "" or s == "ongoing":
  return None, False

  approx = False
  if s.startswith("~"):
  approx = True
 }}}

 And in my [https://people.torproject.org/~dcf/metrics-country.html
 metrics-country.html] page, I treat ongoing entries as having an infinite
 end date for the purpose of filtering, and treat them specially when
 formatting the date field:
 {{{
 #!diff
 @@ -6789,7 +6789,7 @@ function accept_entry(entry, start, end, country) {
 return false;
 }
 if (entry.start_date && !entry.end_date && entry.start_date <
 start) {
 -   return false;
 +   return entry.is_ongoing;
 }
 if (entry.end_date && !entry.start_date && entry.end_date > end) {
 return false;
 @@ -6891,7 +6891,11 @@ function format_timeline_entry_dates(entry) {
 if (entry.start_date && entry.end_date) {
 return format_date(entry.start_date,
 entry.start_date_approx) + " – " + format_date(entry.end_date,
 entry.end_date_approx);
 } else if (entry.start_date) {
 -   return format_date(entry.start_date,
 entry.start_date_approx);
 +   if (entry.is_ongoing) {
 +   return format_date(entry.start_date,
 entry.start_date_approx) + " – present";
 +   } else {
 +   return format_date(entry.start_date,
 entry.start_date_approx);
 +   }
 } else if (entry.end_date) {
 return "? – " + format_date(entry.end_date,
 entry.end_date_approx);
 } else {
 }}}

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

Re: [tor-bugs] #24716 [Core Tor/DirAuth]: Try cranking up cbttestfreq consensus param, to see if it helps the current overload

[Tor Bug Tracker & Wiki]

#24716: Try cranking up cbttestfreq consensus param, to see if it helps the 
current
overload
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 I have changed moria1, and the dirauth-git, to no longer vote about
 cbtmintimeout. It will be some time (hours? days?) until enough dir auths
 update for the change to actually happen.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24835 [Applications/Tor Browser]: Tor Browser 7.0.11 still claims that Mozilla will match my gift

[Tor Bug Tracker & Wiki]

#24835: Tor Browser 7.0.11 still claims that Mozilla will match my gift
--+--
 Reporter:  teor  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 As far as I understand it, the Mozilla matching expired on 31 December
 2017. Maybe we should make the notice date-limited next time?

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

Re: [tor-bugs] #24716 [Core Tor/DirAuth]: Try cranking up cbttestfreq consensus param, to see if it helps the current overload

[Tor Bug Tracker & Wiki]

#24716: Try cranking up cbttestfreq consensus param, to see if it helps the 
current
overload
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 I think we should back out these changes, and see if there's any effect.
 Call it one last experiment.

 Mike suggests backing out the cbtmintimeout change first, since he thinks
 it shouldn't be affecting anything.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24716 [Core Tor/DirAuth]: Try cranking up cbttestfreq consensus param, to see if it helps the current overload

[Tor Bug Tracker & Wiki]

#24716: Try cranking up cbttestfreq consensus param, to see if it helps the 
current
overload
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 My ntor load has varied but lately it is crazy high.

 Here are the lines since the last ones I pasted:
 {{{
 Dec 30 18:38:00.502 [notice] Circuit handshake stats since last time:
 455344/455344 TAP, 28975792/28975813 NTor.
 Dec 31 00:38:00.536 [notice] Circuit handshake stats since last time:
 699334/699334 TAP, 27973797/27973843 NTor.
 Dec 31 06:38:00.542 [notice] Circuit handshake stats since last time:
 853782/853786 TAP, 29181912/29181969 NTor.
 Dec 31 12:38:00.536 [notice] Circuit handshake stats since last time:
 826675/826677 TAP, 27429591/27429629 NTor.
 Dec 31 18:38:00.573 [notice] Circuit handshake stats since last time:
 691791/691799 TAP, 41866424/41866586 NTor.
 Jan 01 00:38:00.549 [notice] Circuit handshake stats since last time:
 755275/755293 TAP, 38457671/38457826 NTor.
 Jan 01 06:38:00.569 [notice] Circuit handshake stats since last time:
 622897/622923 TAP, 23214801/23214813 NTor.
 Jan 01 12:38:00.552 [notice] Circuit handshake stats since last time:
 552771/552771 TAP, 21665861/21665865 NTor.
 Jan 01 18:38:00.554 [notice] Circuit handshake stats since last time:
 627477/627604 TAP, 35923014/35923158 NTor.
 Jan 02 00:38:00.555 [notice] Circuit handshake stats since last time:
 604364/604365 TAP, 30375781/30375796 NTor.
 Jan 02 06:38:00.555 [notice] Circuit handshake stats since last time:
 691533/691547 TAP, 33685459/33685478 NTor.
 Jan 02 12:38:00.553 [notice] Circuit handshake stats since last time:
 738342/738351 TAP, 33851359/33851421 NTor.
 Jan 02 18:38:00.567 [notice] Circuit handshake stats since last time:
 455824/455825 TAP, 31640360/31640429 NTor.
 Jan 03 00:38:00.568 [notice] Circuit handshake stats since last time:
 680932/681281 TAP, 28213577/28215385 NTor.
 Jan 03 06:38:00.577 [notice] Circuit handshake stats since last time:
 684922/684922 TAP, 30468494/30468518 NTor.
 Jan 03 12:38:00.584 [notice] Circuit handshake stats since last time:
 706932/706936 TAP, 32047162/32047204 NTor.
 Jan 03 18:38:00.586 [notice] Circuit handshake stats since last time:
 717007/717007 TAP, 33859568/33859589 NTor.
 Jan 04 00:38:00.586 [notice] Circuit handshake stats since last time:
 254597/254597 TAP, 39652360/39652429 NTor.
 Jan 04 12:35:31.607 [notice] Circuit handshake stats since last time:
 370544/370544 TAP, 43227111/43227209 NTor.
 Jan 04 18:35:31.651 [notice] Circuit handshake stats since last time:
 419505/463538 TAP, 57708012/57718125 NTor.
 Jan 05 00:35:31.667 [notice] Circuit handshake stats since last time:
 323241/328550 TAP, 61154041/61154849 NTor.
 Jan 05 06:35:31.677 [notice] Circuit handshake stats since last time:
 320161/321177 TAP, 56381809/56382464 NTor.
 Jan 05 12:35:31.703 [notice] Circuit handshake stats since last time:
 461325/465544 TAP, 56769051/56769766 NTor.
 Jan 05 18:35:31.706 [notice] Circuit handshake stats since last time:
 511351/652657 TAP, 62709365/62749635 NTor.
 Jan 06 10:24:49.143 [notice] Circuit handshake stats since last time:
 261450/261450 TAP, 38935974/38937202 NTor.
 Jan 06 23:14:22.057 [notice] Circuit handshake stats since last time:
 473587/473589 TAP, 46681363/46681447 NTor.
 Jan 07 05:14:22.102 [notice] Circuit handshake stats since last time:
 486614/486615 TAP, 46743956/46744012 NTor.
 Jan 07 11:14:22.144 [notice] Circuit handshake stats since last time:
 496896/496896 TAP, 48832445/48832552 NTor.
 Jan 07 17:14:22.176 [notice] Circuit handshake stats since last time:
 477255/503942 TAP, 47588565/47592247 NTor.
 Jan 07 23:14:22.201 [notice] Circuit handshake stats since last time:
 492865/493968 TAP, 50934071/50936320 NTor.
 Jan 08 05:14:22.231 [notice] Circuit handshake stats since last time:
 426030/426035 TAP, 45163497/45163547 NTor.
 Jan 08 11:14:22.204 [notice] Circuit handshake stats since last time:
 452647/457412 TAP, 38736117/38754463 NTor.
 Jan 08 17:14:22.232 [notice] Circuit handshake stats since last time:
 510958/511346 TAP, 46547845/46548062 NTor.
 }}}

 So maybe the circuit overload is still here because of #24769, or maybe
 this experiment was overall a failure.

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

Re: [tor-bugs] #24816 [Applications/Tor Browser]: Tor Browser is not your privacy browser, Non-goal: PRIVACY

[Tor Bug Tracker & Wiki]

#24816: Tor Browser is not your privacy browser, Non-goal: PRIVACY
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:  #24351| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:8 cypherpunks]:
 > Also, in Tor Browser context, this penalizes HTTPS websites (even if
 they're behind Cloudflare and don't have Cloudflare's full SSL(TM)
 support) and puts them in the same rank as HTTP ones, which is--to say the
 least--unfair (the first one is at least resilient to exit node plaintext
 sniffing whereas the second isn't).

 CLoudflare *is* exit node. Not unfair because Tor node and coudflare can
 read your data

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24816 [Applications/Tor Browser]: Tor Browser is not your privacy browser, Non-goal: PRIVACY

[Tor Bug Tracker & Wiki]

#24816: Tor Browser is not your privacy browser, Non-goal: PRIVACY
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:  #24351| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:6 cypherpunks]:
 > Replying to [comment:5 cypherpunks]:
 > > Replying to [comment:4 cypherpunks]:
 > > > Replying to [comment:3 cypherpunks]:
 > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1426618
 > > > '''RESOLVED WONTFIX''', but yeah, I support your initiative even if
 I don't think there's a chance that Mozilla will listen...
 > >
 > > Only David Keeler is replying to this report. Other Mozilla employee
 didn't answer to this at this moment. He clearly closed this report
 without reading anything.
 > Your wording wasn't clear on that you sought to only suggest an option
 for labeling as insecure Cloudflare traffic ''that has been tempered'' and
 not their full-SSL offers.

 I didn't write that. Besides I never create an account on Mozilla because
 I hate it after Looking Glass incident. Why don't you write it to bugzilla
 yourself?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24816 [Applications/Tor Browser]: Tor Browser is not your privacy browser, Non-goal: PRIVACY

[Tor Bug Tracker & Wiki]

#24816: Tor Browser is not your privacy browser, Non-goal: PRIVACY
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:  #24351| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:7 cypherpunks]:
 > LOL if I go to https://kproxy.com to visit https://github.com, should
 the browser inform me that my connection is insecure because kproxy is
 essentially MiTM? Of course not! So why should it do exactly that for
 sites behind kproxy, uh, I mean Cloudflare?

 You do realize you're connecting to KPROXY.COM right? Going beyond that
 isn't MITM because you do know your destination server is KPROXY.COM.

 You  KPROXY.COM

 The problem is Cloudflare websites. You never notice you are connecting to
 Cloudflare.

 Expected result:
 You  WTF.COM

 Actual result:
 You =CF:)=== WTF.COM

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24834 [Metrics/Relay Search]: Map consensus weight vs bandwidth for each bandwidth authority's votes

[Tor Bug Tracker & Wiki]

#24834: Map consensus weight vs bandwidth for each bandwidth authority's votes
--+--
 Reporter:  teor  |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-bwauth-needs  |  Actual Points:
Parent ID:  #24674| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Maybe we also want to map consensus weight for each authority while we're
 doing 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] #24768 [Core Tor/DirAuth]: Increase nf_conntimeout_clients to 5 hours

[Tor Bug Tracker & Wiki]

#24768: Increase nf_conntimeout_clients to 5 hours
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #24716| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 The theory is that these new clients are building a lot of circuits, then
 closing them immediately, so we should make them wait longer. But you're
 right, increasing this parameter won't help with that.

 Do you think we should reduce it to try and free up more circuit RAM?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24834 [Metrics/Relay Search]: Map consensus weight vs bandwidth for each bandwidth authority's votes

[Tor Bug Tracker & Wiki]

#24834: Map consensus weight vs bandwidth for each bandwidth authority's votes
--+--
 Reporter:  teor  |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal|   Keywords:  tor-bwauth-needs
Actual Points:|  Parent ID:  #24674
   Points:|   Reviewer:
  Sponsor:|
--+--
 The new map on Relay Search is great!
 The consensus weight versus bandwidth map has been really helpful for
 analysing bandwidth authority behaviour.
 We now know that the measurements are biased towards the north of the
 northern hemisphere. (We don't know why yet: maybe the Internet is better,
 maybe the relays are all there, or maybe the bandwidth authorities are all
 there.)

 I can look at the bias for the Guard and Exit flags by doing an aggregate
 search, then mapping it.

 But I'd also like to see the bias for each bandwidth authority, using the
 bandwidth figures in their votes.
 Is this possible in Relay Search?

 Having this map on a country level would help us when we start
 experimenting with moving the servers around, or pooling them, or using a
 CDN.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24768 [Core Tor/DirAuth]: Increase nf_conntimeout_clients to 5 hours

[Tor Bug Tracker & Wiki]

#24768: Increase nf_conntimeout_clients to 5 hours
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #24716| Points:
 Reviewer:|Sponsor:
--+

Comment (by mikeperry):

 What is the theory that makes you think this is a good idea? Raising this
 value to 5 hours will mean that clients keep otherwise unused circuits
 opened for 5 hours, which means more memory use at relays for these open
 circuits. Additionally, it means that the OR connections to the relays
 will also be held open and padded for 5 hours, resulting in bandwidth
 overhead and higher overall connection counts. As I see it, this could
 make things much, much worse.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24814 [Core Tor/Tor]: Tor relay killing UPC Connect Box

[Tor Bug Tracker & Wiki]

#24814: Tor relay killing UPC Connect Box
--+
 Reporter:  pato  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [comment:5 pato]:
 > I've stopped now the DirPort functionality by setting it to 0. Let's see
 if that will help.

 For recent Tors, that won't actually turn off offering dir info (via
 begindir on your ORPort). You'll want to set "DirCache 0" in your torrc if
 you want to opt out of directory server 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] #24814 [Core Tor/Tor]: Tor relay killing UPC Connect Box

[Tor Bug Tracker & Wiki]

#24814: Tor relay killing UPC Connect Box
--+
 Reporter:  pato  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:7 pato]:
 > I run it solely for other people, so I think it's better to use a relay
 instead of bridge?

 Bridges send their details to the bridge authority, and these details are
 given out to censored users.
 So you would be helping other people.

 > As far as I understand the LimitNOFILE, it's system wide and could cause
 various other issues. I fear I rather have to shutdown my relay.

 If you use a systemd drop-in for the tor service, it only applies to the
 tor process.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24798 [Core Tor/Tor]: Enforce ipv4 + ipv6 capable exit

[Tor Bug Tracker & Wiki]

#24798: Enforce ipv4 + ipv6 capable exit
--+
 Reporter:  Zakhar|  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.11
 Severity:  Normal| Resolution:  worksforme
 Keywords:  tor-client, ipv6  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Please post the new ticket number in this ticket once you have opened it.

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

Re: [tor-bugs] #24833 [- Select a component]: DNS not reliably returning AAAA records

[Tor Bug Tracker & Wiki]

#24833: DNS not reliably returning  records
--+---
 Reporter:  Zakhar|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:  Tor: 0.2.9.14
 Severity:  Normal| Resolution:
 Keywords:  DNS   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by Zakhar):

 Addition:

 '''DNS over ipv6 reliably returns both A and  records:'''

 `$ head /etc/tor/torrc`
 `DNSPort [fe80::10%vnet0]:9053`
 `TransPort [fe80::10%vnet0]:9040`

 (the rest is identical)

 `$ curl -g -H 'Host: ifconfig.co'  http://[2001:470:28:840::cafe:d00d];
 echo "dig"; dig ifconfig.co A ifconfig.co  +short;`
 `2a02:c207:3002:267::1`
 `dig`
 `188.113.88.193`
 `2001:470:28:840::cafe:d00d`

 `$ !!`
 `2001:67c:2608::1`
 `dig`
 `188.113.88.193`
 `2001:470:28:840::cafe:d00d`

 `$ !!`
 `2a00:1dc0:caff:8b::5b9a`
 `dig`
 `188.113.88.193`
 `2001:470:28:840::cafe:d00d`

 `$ !!`
 `ifconfig.co  +short;`
 `2001:bc8:4700:2300::1:a07`
 `dig`
 `188.113.88.193`
 `2001:470:28:840::cafe:d00d`


 ... of course the command does not show our external ipv4 address since we
 don't have the ipv4 stack anymore.

 Unfortunately, the workaround to run DNS over ipv6 in my dual stack is not
 possible right now due to some limitations in my configuration tools...
 because indeed that would make things more reliable!

 I have also noticed that DNS over ipv6 with tor seems faster... probably
 it is select newer/faster exit nodes!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24833 [- Select a component]: DNS not reliably returning AAAA records

[Tor Bug Tracker & Wiki]

#24833: DNS not reliably returning  records
--+---
 Reporter:  Zakhar|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:  Tor: 0.2.9.14
 Severity:  Normal|   Keywords:  DNS 
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 '''[Enhancement Request]'''

 (Cleaner explanation than closed ticket #24798)

 I have a Tor Router set with dual stack.
 DNS is done in ipv4 through (it should not matter since an ipv4 DNS can
 still respond to  queries)

 '''I can't find a setting to make DNS reliably returning  records''':
 it is sort of "random", probably depending on the exit node.

 `$ uname -a`
 `Linux user-pc 4.4.0-104-generic #127-Ubuntu SMP Mon Dec 11 12:16:42 UTC
 2017 x86_64 x86_64 x86_64 GNU/Linux`
 `$ tor --version`
 `Tor version 0.2.9.11 (git-aa8950022562be76).`

 (I will test 0.3.1, as recommended, next week when we have Bionic Beaver
 Alpha 1... to avoid having to compile with Ubuntu chaintool I'm not so
 familiar with... and because it has dependencies that are not in 16.04
 -already tried!)

 Here is the relevant tor snippet

 `$ head /etc/tor/torrc`

 `DNSPort 172.16.0.1:9053 IPv6Traffic`
 `TransPort 172.16.0.1:9040`
 `TransPort [fe80::10%vnet0]:9040`
 `ClientUseIPv6 1`
 `ClientPreferIPv6ORPort 1`
 `ClientPreferIPv6DirPort 1`

 Here is what I get from a machine connected to the router:

 `$ curl 'http://ipv4.whatismyip.akamai.com'; echo; curl -g -H 'Host:
 ifconfig.co'  http://[2001:470:28:840::cafe:d00d]; echo "dig"; dig
 ifconfig.co A ifconfig.co  +short;`
 `46.182.19.15`
 `2607:5300:120:312::1:1`
 `dig`
 `188.113.88.193`

 `$ !!`
 `199.87.154.255`
 `2a00:fc00:e000:b001::f4ee`
 `dig`
 `188.113.88.193`

 `$ !!`
 `5.254.112.154`
 `2620:18c:0:1001::102`
 `dig`
 `188.113.88.193`
 `2001:470:28:840::cafe:d00d`

 `$ !!`
 `197.231.221.211`
 `2620:18c:0:1001::102`
 `dig`
 `188.113.88.193`

 `$ !!`
 `192.42.116.16`
 `2604:8b40:1:3::1`
 `dig`
 `188.113.88.193`

 `$ !!`
 `185.220.101.16`
 `2a03:f85:8::7`
 `dig`
 `188.113.88.193`
 `2001:470:28:840::cafe:d00d`

 ''(changing exit between each repetition with a NEWNYM command)''

 So, as you can see, both the ipv4 an the ipv6 stack work (first 2 curls of
 the command line), no issue with that fortunately!

 For ipv6 I have to force the ipv6 address since the DNS query not always
 returns  responses.

 Depending on the exit host, we get  responses... or not!

 '''Question:''' how to make  responses reliable?

 ''P.S.: from teor's response in my initial ill-worded ticket, I don't
 think it is relevant to add 'IPv6Traffic' to TransPort. Indeed, when you
 bind the TransPort to an ipv4 address you can't sen ipv6 there, and when
 you bind to an ipv6 address, it is already for ipv6.
 Even more, you can't do that: tor-0.2.9 rightfully complaining when you
 add that to TransPort, whereas it is pleased (but has no effect!) when you
 specify the option for DNSPort''

 ''P.S.2: You might have noticed the [fe80::10%vnet0] in my torrc, this is
 not a bug, I am using my patched version that accepts binding to link-
 local ipv6 addresses. #23819''

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24814 [Core Tor/Tor]: Tor relay killing UPC Connect Box

[Tor Bug Tracker & Wiki]

#24814: Tor relay killing UPC Connect Box
--+
 Reporter:  pato  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by pato):

 I run it solely for other people, so I think it's better to use a relay
 instead of bridge?
 As far as I understand the LimitNOFILE, it's system wide and could cause
 various other issues. I fear I rather have to shutdown my relay.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-ddos  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+

Comment (by dgoulet):

 Replying to [comment:6 teor]:
 > Replying to [comment:5 dgoulet]:
 > > We could also explore the possibility for that value to be a moving
 target at runtime. It is a bit more dicy and complicated but because Tor
 at startup looks at the "Total memory" instead of the "Available memory"
 to estimate that value, things can go badly quickly if 4/16 GB of RAM are
 available which will make Tor use 12GB as a limit... and even with a
 fairly good amount of swap, this is likely to be killed by the OOM of the
 OS at some point.
 > >
 > > On the flip side, a fast relay stuck with an estimation of 1GB or 2GB
 of RAM that Tor can use at startup won't be "fast" for much long before
 the OOM kicks in and start killing old circuits.
 >
 > This is not what I have observed. I have some fast Guards. Under normal
 load they don't ever use much more than 1 - 2 GB total RAM.

 Oh that was in the context of the ongoing "DDoS" on the network. I also
 usually never go above 1.2GB for a ~12MB/s relay but right now I'm at ~3GB
 so an estimation at 1GB of RAM would just decrease my relay capabilities.

 > If the fastest relay can do 1 Gbps, then that's 125 MB per second. 12 GB
 of RAM is 100 seconds of traffic. Is it really useful to buffer 100
 seconds of traffic? (Or, under the current load, tens of thousands of
 useless circuits?)
 >
 > So I'm not sure if using more RAM for queues actually helps. In my
 experience, it just increases the number of active connections and CPU
 usage. I don't know how to measure if this benefits or hurts clients. (I
 guess I could tweak my guard and test running a client through it?)

 I think this could come down to lots of traffic being queued because the
 next hops are overloaded so if you relay is very big, Tor is happy to keep
 it while waiting to relay the cells to the much slower next hop. However,
 I'm seriously uncertain about this and if it is even really what is
 happening... Need more investigation on my part.

 [snip]

 Yeah the rest of your response is good knowledge and I'm honestly also
 uncertain of what to do for now either.

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

Re: [tor-bugs] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-ddos  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+

Comment (by yawning):

 Replying to [comment:6 teor]:
 > > I do believe right now that the network is still fairly usable because
 we have big Guards able to use 5, 10, 12GB of RAM right now... Unclear to
 me if firing up the OOM more frequently would improve the situation but we
 should be very careful at not making every relays using a "too low amount
 of ram" :S.
 >
 > If the fastest relay can do 1 Gbps, then that's 125 MB per second. 12 GB
 of RAM is 100 seconds of traffic. Is it really useful to buffer 100
 seconds of traffic? (Or, under the current load, tens of thousands of
 useless circuits?)

 No, but you don't have a choice because you can't drop cells except if
 things are going catastrophically wrong and you're willing to tear down
 the circuit.

 http://yuba.stanford.edu/~nickm/papers/sigcomm2004.pdf

 However as the paper says:
 > It is a little difficult to persuade the operator of a
 > functioning, profitable network to take the risk and remove
 > 99% of their buffers. But that has to be the next step, and
 > we see the results presented in this paper as a first step
 > towards persuading an operator to try it.

 (The CoDel work also supports their hypothesis.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24798 [Core Tor/Tor]: Enforce ipv4 + ipv6 capable exit

[Tor Bug Tracker & Wiki]

#24798: Enforce ipv4 + ipv6 capable exit
--+
 Reporter:  Zakhar|  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.11
 Severity:  Normal| Resolution:  worksforme
 Keywords:  tor-client, ipv6  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Zakhar):

 Indeed, this ticket is not explaining correct.

 I am opening a new one, sorry for the disturbance!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24759 [Core Tor/Tor]: (Sandbox) Caught a bad syscall attempt (syscall socket)

[Tor Bug Tracker & Wiki]

#24759: (Sandbox) Caught a bad syscall attempt (syscall socket)
--+
 Reporter:  mig5  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.9
 Severity:  Normal| Resolution:
 Keywords:  sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by yawning):

 That should be fine, if you want to debug it further, I'd suggest trying
 to figure out what args are passed to `socket()` when it fails.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24759 [Core Tor/Tor]: (Sandbox) Caught a bad syscall attempt (syscall socket)

[Tor Bug Tracker & Wiki]

#24759: (Sandbox) Caught a bad syscall attempt (syscall socket)
--+
 Reporter:  mig5  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.9
 Severity:  Normal| Resolution:
 Keywords:  sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by mig5):

 Hi yawning,

 bash-4.4# ldd --version
 ldd (GNU libc) 2.25


 This is a Fedora 26 virtual machine running within QubesOS (which may or
 may not complicate the fact).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-ddos  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+

Comment (by teor):

 Replying to [comment:5 dgoulet]:
 > We could also explore the possibility for that value to be a moving
 target at runtime. It is a bit more dicy and complicated but because Tor
 at startup looks at the "Total memory" instead of the "Available memory"
 to estimate that value, things can go badly quickly if 4/16 GB of RAM are
 available which will make Tor use 12GB as a limit... and even with a
 fairly good amount of swap, this is likely to be killed by the OOM of the
 OS at some point.
 >
 > On the flip side, a fast relay stuck with an estimation of 1GB or 2GB of
 RAM that Tor can use at startup won't be "fast" for much long before the
 OOM kicks in and start killing old circuits.

 This is not what I have observed. I have some fast Guards. Under normal
 load they don't ever use much more than 1 - 2 GB total RAM.

 > It is difficult to tell what a normal fast relay will endure in terms of
 RAM for Tor overtime but so far of what I can tell with my relays, between
 1 and 2 GB is usually what I see (in non-DoS condition and non-Exit).

 I usually see 1-2 GB for non-exits, and closer to 2 GB for exits.

 > I do believe right now that the network is still fairly usable because
 we have big Guards able to use 5, 10, 12GB of RAM right now... Unclear to
 me if firing up the OOM more frequently would improve the situation but we
 should be very careful at not making every relays using a "too low amount
 of ram" :S.

 If the fastest relay can do 1 Gbps, then that's 125 MB per second. 12 GB
 of RAM is 100 seconds of traffic. Is it really useful to buffer 100
 seconds of traffic? (Or, under the current load, tens of thousands of
 useless circuits?)

 So I'm not sure if using more RAM for queues actually helps. In my
 experience, it just increases the number of active connections and CPU
 usage. I don't know how to measure if this benefits or hurts clients. (I
 guess I could tweak my guard and test running a client through it?)

 Here's what happened when I followed my own advice in this thread:
 https://lists.torproject.org/pipermail/tor-relays/2018-January/014021.html

 I have a few big guards that are very close to a lot of the new clients.
 They were using 150% CPU, 4-8 GB RAM, and 15000 connections each. But they
 were not actually carrying much useful traffic.

 I tried reducing MaxMemInQueues to 2 GB and 1 GB, and they started using
 3-7 GB RAM. This is on 0.3.0 with the destroy cell fix. (But on my slower
 Guards and my Exit, MaxMemInQueues worked really well, reducing the RAM
 usage to 0.5 - 1.5 GB, without reducing the consensus weight.)

 I tried reducing the number of file descriptors, that reduced the CPU to
 around 110%, because the new connections were closed earlier. It pushed a
 lot of the sockets into the kernel TIME_WAIT state, about 10,000 on top of
 the regular 10,000. (Maybe these new Tor clients didn't do exponential
 backoff?)

 I tried DisableOOSCheck 0, and it didn't seem to make much difference to
 RAM or CPU, but it made a small difference to sockets (and it makes sure
 that I don't lose important sockets, like new control port sockets, so I
 left it on).

 I already set RelayBandwidthRate, but now I also set
 MaxAdvertisedBandwidth to about half the RelayBandwidthRate. Hopefully
 this will make the clients go elsewhere. But this isn't really a solution
 for the network.

 So I'm out of options to try and regulate traffic on these guards. And I
 need to have them working in about a week or so, because I need to run
 safe stats collections on them.

 I think my only remaining option is to drop connections when the number of
 connections per IP goes above some limit. From the tor-relays posts, it
 seems like up to 10 connections per IP is normal, but these clients will
 make hundreds of connections at once. I think I should DROP rather than
 RST, because that forces the client to timeout, rather than immediately
 making another connection.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21518 [Applications/Orbot]: Pluggable transports for zero-rated services

[Tor Bug Tracker & Wiki]

#21518: Pluggable transports for zero-rated services
-+-
 Reporter:  cypherpunks  |  Owner:
 |  cypherpunks
 Type:  project  | Status:
 |  accepted
 Priority:  High |  Milestone:
Component:  Applications/Orbot   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  PT pluggable transport WhatsApp  |  Actual Points:
  poverty|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by atagar):

 * component:  Core Tor/DocTor => Applications/Orbot


Comment:

 I'm not sure what this ticket is about. Sending this over to Orbot since
 you mention that and mobile.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24815 [Core Tor/Tor]: Validate shared random state dates before each voting period

[Tor Bug Tracker & Wiki]

#24815: Validate shared random state dates before each voting period
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-sr, tor-ddos  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:1 dgoulet]:
 > I suppose you are talking about the log on Jan 7th but the upcoming
 round on Jan 6th:
 >
 > {{{
 > Jan 07 09:48:14.984 [info] sr_state_update: SR: State prepared for
 upcoming voting period (2018-01-06 23:00:00). Upcoming phase is reveal
 (counters: 0 commit & 1 reveal rounds).
 > }}}
 >
 > That time (`2018-01-06 23:00:00`) is the `valid_after` from the
 consensus and the SR subsystem only uses the time from the consensus to
 take every timing decision. It updates the state when loading from disk
 (at bootup) or when a new consensus has just been computed.
 >
 > In this case, it is when booting up (`sr_init()`) I presume?

 No, waking from sleep.

 > So it takes the consensus from disk (very old), and tries to vote with
 that information. Ultimately it will fail but then once your dirauth gets
 the latest consensus, it should sync up again with the whole dance at the
 next voting round.
 >
 > Do you see that or I'm misunderstanding the issue or ?

 There are times when it never syncs up.
 Sometimes it will be out of sync for hours, and other times it won't get
 back in sync until I restart the Tor process.

 I need to do some debugging to find out why it produces a different
 consensus to everyone else.
 I assumed it was shared random because of these warning messages.

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

Re: [tor-bugs] #24820 [Core Tor/Nyx]: nyx crashes on startup

[Tor Bug Tracker & Wiki]

#24820: nyx crashes on startup
---+
 Reporter:  monochromec|  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Core Tor/Nyx   |Version:
 Severity:  Critical   | Resolution:
 Keywords:  nyx crash startup  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Ick, thanks for the report! Juggling a few things right now but I very
 much appreciate the report. Certainly odd this differs between 3.5 and
 3.6...

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24832 [Core Tor/Nyx]: Drop 'measured' bandwidth from nyx

[Tor Bug Tracker & Wiki]

#24832: Drop 'measured' bandwidth from nyx
--+
 Reporter:  atagar|  Owner:  atagar
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Including the 'measured: x' value was silly of me. That's the Bandwidth
 Authority metric which is unitless. Understandably this causes
 confusion...

 https://lists.torproject.org/pipermail/tor-relays/2018-January/014065.html

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22343 [Applications/Tor Browser]: Save as... in the context menu results in using the catch-all circuit

[Tor Bug Tracker & Wiki]

#22343: Save as... in the context menu results in using the catch-all circuit
-+-
 Reporter:  gk   |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-linkability, ff52-esr,   |  Actual Points:
  tbb-7.0-must, tbb-7.0-issues, tbb-regression,  |
  tbb-7.0-frequent, TorBrowserTeam201801R|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:
 tbb-linkability, ff52-esr, tbb-7.0-must, tbb-7.0-issues, tbb-
 regression, tbb-7.0-frequent, TorBrowserTeam201712
 =>
 tbb-linkability, ff52-esr, tbb-7.0-must, tbb-7.0-issues, tbb-
 regression, tbb-7.0-frequent, TorBrowserTeam201801R


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24756 [Applications/Tor Browser]: New default bridge: bridge-01.noisetor.net

[Tor Bug Tracker & Wiki]

#24756: New default bridge: bridge-01.noisetor.net
+--
 Reporter:  patrickod   |  Owner:  tbb-team
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-bridges, TorBrowserTeam201801R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * keywords:  tbb-bridges => tbb-bridges, TorBrowserTeam201801R


Comment:

 patrickod: Do you want to write a proper patch for including the new
 bridge into Tor Browser or should we turn the data in comment:description
 into a proper one (I am fine either way)? I assume the latter and put it
 onto our review radar nevertheless.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24197 [Applications/Tor Browser]: Building Windows 64 firefox with the sandbox enabled fails

[Tor Bug Tracker & Wiki]

#24197: Building Windows 64 firefox with the sandbox enabled fails
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201801,   |  Actual Points:
  GeorgKoppen201801  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-rbm => tbb-rbm, TorBrowserTeam201801, GeorgKoppen201801


Comment:

 Replying to [comment:4 boklm]:
 > Those patches are fixing the build, however it seems it is not enough to
 get the sandbox working on Windows 64. After starting the browser the
 `about:page` tab stays blank. When trying to load a web page in a new tab,
 the tab also stays blank. After changing `security.sandbox.content.level`
 from `1` to `0` in `about:config` and restarting, the browser is working
 correctly.
 >
 > To try to debug this I tried setting `security.sandbox.windows.log` and
 `security.sandbox.logging.enabled` to `true`, but didn't see anything
 related to sandbox in the browser console.

 Hm. Maybe I did not fix all the issues in #16010 then? Let me look closer
 at that...

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

Re: [tor-bugs] #15897 [Applications/Tor Browser]: Circuit information is not displayed on Tor Browser new/error pages

[Tor Bug Tracker & Wiki]

#15897: Circuit information is not displayed on Tor Browser new/error pages
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton, tbb-circuit-display,  |  worksforme
  tbb-usability  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Replying to [comment:20 cypherpunks]:
 > Doesn't work for me in 7.5a10 on new tabs.

 New tabs don't have domains in their URL bar. Thus, that behavior is
 expected.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24793 [Obfuscation/Obfsproxy]: obfs4 breaks http proxy with basic auth (was: tor brower proxy auth basic)

[Tor Bug Tracker & Wiki]

#24793: obfs4 breaks http proxy with basic auth
---+--
 Reporter:  gilcu3 |  Owner:  (none)
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Obfsproxy  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

 * owner:  tbb-team => (none)
 * status:  new => assigned
 * version:  Tor: 0.3.1.9 =>


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

Re: [tor-bugs] #24793 [Obfuscation/Obfsproxy]: tor brower proxy auth basic

[Tor Bug Tracker & Wiki]

#24793: tor brower proxy auth basic
---+--
 Reporter:  gilcu3 |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Obfsproxy  |Version:  Tor: 0.3.1.9
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gilcu3):

 * status:  needs_information => new
 * component:  Applications/Tor Browser => Obfuscation/Obfsproxy


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24200 [Applications/Tor Launcher]: improve bridge and proxy help text

[Tor Bug Tracker & Wiki]

#24200: improve bridge and proxy help text
---+
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID:  #21951 | Points:
 Reviewer: |Sponsor:
---+
Changes (by isabela):

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


Comment:

 We will release the new UI with the copy suggested by Linda on this ticket
 (which is also the same one we are using right  now at our implementation
 on alpha).

 The UX team will test all this with our users and based on that we will
 see how to continue to improve this copy. So I am closing this ticket.

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

Re: [tor-bugs] #24793 [Applications/Tor Browser]: tor brower proxy auth basic

[Tor Bug Tracker & Wiki]

#24793: tor brower proxy auth basic
--+---
 Reporter:  gilcu3|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:  Tor: 0.3.1.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by yawning):

 Replying to [comment:8 gilcu3]:
 > yes exactly, obfs4 is the selected option in Tor Browser, so that line
 in code is correct or not?

 I mean, it's an obfs4proxy bug.

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

Re: [tor-bugs] #24759 [Core Tor/Tor]: (Sandbox) Caught a bad syscall attempt (syscall socket)

[Tor Bug Tracker & Wiki]

#24759: (Sandbox) Caught a bad syscall attempt (syscall socket)
--+
 Reporter:  mig5  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.9
 Severity:  Normal| Resolution:
 Keywords:  sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by yawning):

 What libc (implementation and version) are you using?

 The sandbox rules have a special case for how glibc implements the
 interface lookup, though I'm not sure how much glibc has changed over
 time.

 {{{
h->fd = __socket (PF_NETLINK, SOCK_RAW | SOCK_CLOEXEC, NETLINK_ROUTE);
 }}}
 
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/ifaddrs.c;h=32381f54e4e0e10c42c47aed0ebeb1df03bf19af;hb=HEAD#l258

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24738 [Core Tor]: Abort trap: 6 after installation Mac OS 10.13.1

[Tor Bug Tracker & Wiki]

#24738: Abort trap: 6 after installation Mac OS 10.13.1
-+---
 Reporter:  lL__ |  Owner:  (none)
 Type:  defect   | Status:  needs_information
 Priority:  Very High|  Milestone:  Tor: unspecified
Component:  Core Tor |Version:  Tor: unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor, error, abort, trap  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by nickm):

 * status:  new => needs_information


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24793 [Applications/Tor Browser]: tor brower proxy auth basic

[Tor Bug Tracker & Wiki]

#24793: tor brower proxy auth basic
--+---
 Reporter:  gilcu3|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:  Tor: 0.3.1.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gilcu3):

 yes exactly, obfs4 is the selected option in Tor Browser, so that line in
 code is correct or not?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24793 [Applications/Tor Browser]: tor brower proxy auth basic

[Tor Bug Tracker & Wiki]

#24793: tor brower proxy auth basic
--+---
 Reporter:  gilcu3|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:  Tor: 0.3.1.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by yawning):

 I assume the failure case involves obfs4proxy.

 https://gitweb.torproject.org/pluggable-
 transports/obfs4.git/tree/obfs4proxy/proxy_http.go#n92

 https://github.com/golang/go/blob/master/src/net/http/request.go#L881
 {{{
 func (r *Request) SetBasicAuth(username, password string) {
 r.Header.Set("Authorization", "Basic "+basicAuth(username,
 password))
 }
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #15897 [Applications/Tor Browser]: Circuit information is not displayed on Tor Browser new/error pages

[Tor Bug Tracker & Wiki]

#15897: Circuit information is not displayed on Tor Browser new/error pages
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton, tbb-circuit-display,  |  Actual Points:
  tbb-usability  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

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


Comment:

 Doesn't work for me in 7.5a10 on new tabs.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24197 [Applications/Tor Browser]: Building Windows 64 firefox with the sandbox enabled fails

[Tor Bug Tracker & Wiki]

#24197: Building Windows 64 firefox with the sandbox enabled fails
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 Those patches are fixing the build, however it seems it is not enough to
 get the sandbox working on Windows 64. After starting the browser the
 `about:page` tab stays blank. When trying to load a web page in a new tab,
 the tab also stays blank. After changing `security.sandbox.content.level`
 from `1` to `0` in `about:config` and restarting, the browser is working
 correctly.

 To try to debug this I tried setting `security.sandbox.windows.log` and
 `security.sandbox.logging.enabled` to `true`, but didn't see anything
 related to sandbox in the browser console.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22343 [Applications/Tor Browser]: Save as... in the context menu results in using the catch-all circuit

[Tor Bug Tracker & Wiki]

#22343: Save as... in the context menu results in using the catch-all circuit
-+-
 Reporter:  gk   |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-linkability, ff52-esr,   |  Actual Points:
  tbb-7.0-must, tbb-7.0-issues, tbb-regression,  |
  tbb-7.0-frequent, TorBrowserTeam201712 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * status:  needs_revision => needs_review


Comment:

 Here's a new version of the patch for review. I believe I have fixed the
 errors gk found in comment:30 and cleaned up some of the code.

 https://github.com/arthuredelstein/tor-browser/commit/22343+8

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

Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

[Tor Bug Tracker & Wiki]

#23881: Implement a way to utilise tor's logging system from Rust code
---+---
 Reporter:  isis   |  Owner:
   |  chelseakomlo
 Type:  enhancement| Status:
   |  needs_review
 Priority:  High   |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  rust, rust-pilot, review-group-28  |  Actual Points:
Parent ID: | Points:  3
 Reviewer:  nickm  |Sponsor:
---+---
Changes (by nickm):

 * reviewer:   => nickm


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22079 [Community]: Community governance documents

[Tor Bug Tracker & Wiki]

#22079: Community governance documents
---+
 Reporter:  alison |  Owner:  alison
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Community  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by alison):

 what happens when a councilmember resigns?

 the current policy says we can:
 * continue with a 4 person council until terms end on March 31
  (our policy lets us have a 3, 4 or 5 member council)
 * hold community council elections early
  (we need 5 people to ask for this)

 maybe instead we should revise the CC guidelines to have a countback,
 which means filling vacancies with the person who received the next
 highest votes.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24831 [Metrics/Onionoo]: Consider providing more/less fine grained graphs where currently they are not

[Tor Bug Tracker & Wiki]

#24831: Consider providing more/less fine grained graphs where currently they 
are
not
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #24155
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 In relay search, if a graph is not available it shows a "No Data
 Available" image. As the data is present anyway, perhaps these graphs can
 be shown with only the last X data points from a later graph with the
 interval then increased to be that of the later graph.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24733 [Core Tor/Tor]: Loading ifc.ifc_buf using the new tor_free() causes undefined behaviour on x86_64 macOS

[Tor Bug Tracker & Wiki]

#24733: Loading ifc.ifc_buf using the new tor_free() causes undefined behaviour 
on
x86_64 macOS
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  address-sanitizer, unexpected-   |  Actual Points:  0.1
  consequences, review-group-28  |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-

Comment (by catalyst):

 Replying to [comment:11 teor]:

 > I think refactoring my patch to do this in a separate function is a good
 solution.
 >
 > And then a separate ticket for evaluate-once, if it is even possible.

 Sounds good to me.

 We might also want to comment the implementation of `tor_free()` to warn
 about this issue possibly arising elsewhere in the future when packed
 structures are involved.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24830 [Metrics/Ideas]: Mashup GoodBadISPs with Onionoo to give indications of which providers are oversubscribed

[Tor Bug Tracker & Wiki]

#24830: Mashup GoodBadISPs with Onionoo to give indications of which providers 
are
oversubscribed
---+--
 Reporter:  irl|  Owner:  metrics-team
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Ideas  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 The [[doc/GoodBadISPs]] page contains a lot of useful information for
 relay operators about which providers are willing to host middle or exit
 relays, but doesn't give any indication of which providers already host a
 large number of relays or which would be the best provider to choose to
 help diversity.

 By giving more structure to that page or by moving the page into
 JSON/XML/database and then mashing it up with Onionoo data (bandwidth,
 consensus weights, middle vs. exits) it would be clearer to see what
 operators would help to improve diversity in the network.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24716 [Core Tor/DirAuth]: Try cranking up cbttestfreq consensus param, to see if it helps the current overload

[Tor Bug Tracker & Wiki]

#24716: Try cranking up cbttestfreq consensus param, to see if it helps the 
current
overload
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 My fast relay (`Truie`) got from Dec 28th to Jan 5th a pretty important
 load on NTor. From 500k to 1M depending on the time of day.

 {{{
 Jan 03 22:51:02.262 [notice] Circuit handshake stats since last time:
 397262/397262 TAP, 910632/910632 NTor.
 }}}

 Everything started to go down on Jan 5th past 20:00:00 UTC. For now, the
 traffic going through it is almost double what it used to see but the
 connections are stable with:

 {{{
 Jan 08 15:21:02.670 [notice] Circuit handshake stats since last time:
 23591/23597 TAP, 334149/334368 NTor.
 Jan 08 15:51:02.709 [notice] Circuit handshake stats since last time:
 12063/12063 TAP, 341922/341922 NTor.
 Jan 08 16:21:02.718 [notice] Circuit handshake stats since last time:
 23751/23751 TAP, 335790/335790 NTor.
 Jan 08 16:51:02.478 [notice] Circuit handshake stats since last time:
 21637/21637 TAP, 357263/357263 NTor.
 Jan 08 17:21:02.557 [notice] Circuit handshake stats since last time:
 57312/57312 TAP, 343390/343390 NTor.
 }}}

 Not only NTor connections went down but TAP also went down considerably.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24829 [Metrics/Relay Search]: Consider which time periods to show for graphs

[Tor Bug Tracker & Wiki]

#24829: Consider which time periods to show for graphs
--+--
 Reporter:  irl   |  Owner:  metrics-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #24155
   Points:|   Reviewer:
  Sponsor:|
--+--
 While the bandwidth reporting intervals have decreased, consensus weight
 graphs for 1 week are still available and for older relays, they even have
 bandwidth graphs available for 1 week.

 We should consider which time periods should be supported. In the last
 change, 3 days and 1 week were both removed from Relay Search and so even
 if the data exists it's not possible to display these anymore.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24828 [Metrics/Relay Search]: Remove tabs when no data is available for graphs

[Tor Bug Tracker & Wiki]

#24828: Remove tabs when no data is available for graphs
--+--
 Reporter:  irl   |  Owner:  irl
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #24155| Points:
 Reviewer:|Sponsor:
--+--
Changes (by irl):

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


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24828 [Metrics/Relay Search]: Remove tabs when no data is available for graphs

[Tor Bug Tracker & Wiki]

#24828: Remove tabs when no data is available for graphs
--+--
 Reporter:  irl   |  Owner:  metrics-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 When no data is available for graphs, currently a no data available image
 is displayed. If no data is available for both graphs, the tab should be
 hidden.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24816 [Applications/Tor Browser]: Tor Browser is not your privacy browser, Non-goal: PRIVACY

[Tor Bug Tracker & Wiki]

#24816: Tor Browser is not your privacy browser, Non-goal: PRIVACY
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:  #24351| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Also, in Tor Browser context, this penalizes HTTPS websites (even if
 they're behind Cloudflare and don't have Cloudflare's full SSL(TM)
 support) and puts them in the same rank as HTTP ones, which is--to say the
 least--unfair.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24770 [Core Tor/Tor]: Change the circuit build time defaults to reduce network load

[Tor Bug Tracker & Wiki]

#24770: Change the circuit build time defaults to reduce network load
+--
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.3.1.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  dos-resistance, tor-client  |  Actual Points:
Parent ID:  #24716  | Points:  1
 Reviewer:  |Sponsor:
+--
Changes (by dgoulet):

 * cc: mikeperry (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] #24782 [Core Tor/Tor]: Set a lower default MaxMemInQueues value

[Tor Bug Tracker & Wiki]

#24782: Set a lower default MaxMemInQueues value
-+
 Reporter:  teor |  Owner:  ahf
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-ddos  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+

Comment (by dgoulet):

 We could also explore the possibility for that value to be a moving target
 at runtime. It is a bit more dicy and complicated but because Tor at
 startup looks at the "Total memory" instead of the "Available memory" to
 estimate that value, things can go badly quickly if 4/16 GB of RAM are
 available which will make Tor use 12GB as a limit... and even with a
 fairly good amount of swap, this is likely to be killed by the OOM of the
 OS at some point.

 On the flip side, a fast relay stuck with an estimation of 1GB or 2GB of
 RAM that Tor can use at startup won't be "fast" for much long before the
 OOM kicks in and start killing old circuits. It is difficult to tell what
 a normal fast relay will endure in terms of RAM for Tor overtime but so
 far of what I can tell with my relays, between 1 and 2 GB is usually what
 I see (in non-DoS condition and non-Exit).

 I do believe right now that the network is still fairly usable because we
 have big Guards able to use 5, 10, 12GB of RAM right now... Unclear to me
 if firing up the OOM more frequently would improve the situation but we
 should be very careful at not making every relays using a "too low amount
 of ram" :S.

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

Re: [tor-bugs] #24769 [Core Tor/Tor]: Increase client idle and connection timeouts to reduce network load

[Tor Bug Tracker & Wiki]

#24769: Increase client idle and connection timeouts to reduce network load
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, dos-resistance,  |  Actual Points:
  032-backport, 031-backport, 029-backport, 025  |
  -backport-maybe|
Parent ID:  #24716   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * cc: mikeperry (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] #24821 [Core Tor/Tor]: Relay publishing malformed dirreq-v3-tunneled-dl

[Tor Bug Tracker & Wiki]

#24821: Relay publishing malformed dirreq-v3-tunneled-dl
---+
 Reporter:  atagar |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Major  | Resolution:
 Keywords:  tor-relay, extra-info  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dgoulet):

 * keywords:   => tor-relay, extra-info
 * milestone:   => Tor: 0.3.3.x-final


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

Re: [tor-bugs] #24816 [Applications/Tor Browser]: Tor Browser is not your privacy browser, Non-goal: PRIVACY

[Tor Bug Tracker & Wiki]

#24816: Tor Browser is not your privacy browser, Non-goal: PRIVACY
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:  #24351| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 LOL if I go to https://kproxy.com to visit https://github.com, should the
 browser inform me that my connection is insecure because kproxy is
 essentially MiTM? Of course not! So why should it do exactly that for
 sites behind kproxy, uh, I mean Cloudflare?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24826 [Core Tor/Tor]: LZMA-compressed consensus diffs stall Tor Browser launch for at least 20s or break it entirely

[Tor Bug Tracker & Wiki]

#24826: LZMA-compressed consensus diffs stall Tor Browser launch for at least 
20s
or break it entirely
--+
 Reporter:  gk|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

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


Comment:

 I've observed such load on my relays. Depending on the available CPU, this
 can take quite a bit of time, I've seen more than a minute on a very
 loaded machine.

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

Re: [tor-bugs] #24815 [Core Tor/Tor]: Validate shared random state dates before each voting period

[Tor Bug Tracker & Wiki]

#24815: Validate shared random state dates before each voting period
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-sr, tor-ddos  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  new => needs_information


Comment:

 I suppose you are talking about the log on Jan 7th but the upcoming round
 on Jan 6th:

 {{{
 Jan 07 09:48:14.984 [info] sr_state_update: SR: State prepared for
 upcoming voting period (2018-01-06 23:00:00). Upcoming phase is reveal
 (counters: 0 commit & 1 reveal rounds).
 }}}

 That time (`2018-01-06 23:00:00`) is the `valid_after` from the consensus
 and the SR subsystem only uses the time from the consensus to take every
 timing decision. It updates the state when loading from disk (at bootup)
 or when a new consensus has just been computed.

 In this case, it is when booting up (`sr_init()`) I presume? So it takes
 the consensus from disk (very old), and tries to vote with that
 information. Ultimately it will fail but then once your dirauth gets the
 latest consensus, it should sync up again with the whole dance at the next
 voting round.

 Do you see that or I'm misunderstanding the issue or ?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24816 [Applications/Tor Browser]: Tor Browser is not your privacy browser, Non-goal: PRIVACY

[Tor Bug Tracker & Wiki]

#24816: Tor Browser is not your privacy browser, Non-goal: PRIVACY
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:  #24351| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:5 cypherpunks]:
 > Replying to [comment:4 cypherpunks]:
 > > Replying to [comment:3 cypherpunks]:
 > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1426618
 > > '''RESOLVED WONTFIX''', but yeah, I support your initiative even if I
 don't think there's a chance that Mozilla will listen...
 >
 > Only David Keeler is replying to this report. Other Mozilla employee
 didn't answer to this at this moment. He clearly closed this report
 without reading anything.
 Your wording wasn't clear on that you sought to only suggest an option for
 labeling as insecure Cloudflare traffic ''that has been tempered'' and not
 their full-SSL offers.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24759 [Core Tor/Tor]: (Sandbox) Caught a bad syscall attempt (syscall socket)

[Tor Bug Tracker & Wiki]

#24759: (Sandbox) Caught a bad syscall attempt (syscall socket)
--+
 Reporter:  mig5  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.9
 Severity:  Normal| Resolution:
 Keywords:  sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

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


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