[tor-bugs] #28641 [Core Tor/Tor]: conn_close_if_marked: Non-fatal assertion !(connection_is_reading(conn)) failed

[Tor Bug Tracker & Wiki]

#28641: conn_close_if_marked: Non-fatal assertion !(connection_is_reading(conn))
failed
--+--
 Reporter:  TheBoegl  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Component:  Core Tor/Tor
  Version:  Tor: 0.3.4.9  |   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 I got the following log entry on Ubuntu 18.04.1 LTS:

 {{{
 Nov 27 21:36:40 server Tor-samaadams[14901]: tor_bug_occurred_(): Bug:
 ../src/or/main.c:1047: conn_close_if_marked: Non-fatal assertion
 !(connection_is_reading(conn)) failed. (on Tor 0.3.4.9 )
 Nov 27 21:36:40 server Tor-samaadams[14901]: Bug: Non-fatal assertion
 !(connection_is_reading(conn)) failed in conn_close_if_marked at
 ../src/or/main.c:1047. Stack trace: (on Tor 0.3.4.9 )
 Nov 27 21:36:40 server Tor-samaadams[14901]: Bug:
 /usr/bin/tor(log_backtrace+0x43) [0x55feb610d2a3] (on Tor 0.3.4.9 )
 Nov 27 21:36:40 server Tor-samaadams[14901]: Bug:
 /usr/bin/tor(tor_bug_occurred_+0xb9) [0x55feb61282d9] (on Tor 0.3.4.9 )
 Nov 27 21:36:40 server Tor-samaadams[14901]: Bug:
 /usr/bin/tor(+0x54631) [0x55feb5fd9631] (on Tor 0.3.4.9 )
 Nov 27 21:36:40 server Tor-samaadams[14901]: Bug:
 /usr/bin/tor(+0x54a9e) [0x55feb5fd9a9e] (on Tor 0.3.4.9 )
 Nov 27 21:36:40 server Tor-samaadams[14901]: Bug: /usr/lib/x86_64
 -linux-gnu/libevent-2.1.so.6(+0x1ea11) [0x7f1727e99a11] (on Tor 0.3.4.9 )
 Nov 27 21:36:40 server Tor-samaadams[14901]: Bug: /usr/lib/x86_64
 -linux-gnu/libevent-2.1.so.6(event_base_loop+0x53f) [0x7f1727e9a33f] (on
 Tor 0.3.4.9 )
 Nov 27 21:36:40 server Tor-samaadams[14901]: Bug:
 /usr/bin/tor(do_main_loop+0x212) [0x55feb5fdbca2] (on Tor 0.3.4.9 )
 Nov 27 21:36:40 server Tor-samaadams[14901]: Bug:
 /usr/bin/tor(tor_run_main+0x11a5) [0x55feb5fde4a5] (on Tor 0.3.4.9 )
 Nov 27 21:36:40 server Tor-samaadams[14901]: Bug:
 /usr/bin/tor(tor_main+0x3a) [0x55feb5fd625a] (on Tor 0.3.4.9 )
 Nov 27 21:36:40 server Tor-samaadams[14901]: Bug:
 /usr/bin/tor(main+0x19) [0x55feb5fd5fe9] (on Tor 0.3.4.9 )
 Nov 27 21:36:40 server Tor-samaadams[14901]: Bug: /lib/x86_64-linux-
 gnu/libc.so.6(__libc_start_main+0xe7) [0x7f172663ab97] (on Tor 0.3.4.9 )
 Nov 27 21:36:40 server Tor-samaadams[14901]: Bug:
 /usr/bin/tor(_start+0x2a) [0x55feb5fd603a] (on Tor 0.3.4.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] #28353 [Metrics/Website]: Use Guard & Exit, Guard only, Exit only, and Middle only on all bandwidth by flag graphs

[Tor Bug Tracker & Wiki]

#28353: Use Guard & Exit, Guard only, Exit only, and Middle only on all 
bandwidth
by flag graphs
-+--
 Reporter:  teor |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #28328   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * Attachment "bandwidth-flags-2018-11-28.png" 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] #28353 [Metrics/Website]: Use Guard & Exit, Guard only, Exit only, and Middle only on all bandwidth by flag graphs

[Tor Bug Tracker & Wiki]

#28353: Use Guard & Exit, Guard only, Exit only, and Middle only on all 
bandwidth
by flag graphs
-+--
 Reporter:  teor |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #28328   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Replying to [comment:9 antonela]:
 > Hi! The contrast between the pink and the red colors are not strong
 enough. I would suggest having a shade of green (aroundish #12bc00).

 Hi antonela!

 Hmm, I see how green would have a stronger contrast. But green doesn't
 convey the special meaning of the second color as a mix of the first and
 the third color: the first color stands for relays with the Exit flag, the
 third color for relays with the Guard flag, and the color in between for
 relays with ''both'' Guard and Exit flags. That's why the middle color was
 supposed to be a blend of the other two colors, which is not the case with
 green.

 How's this: magenta for Exit, cyan for Guard, and blue for Guard and Exit?

 [[Image(bandwidth-flags-2018-11-28.png, 700px)]]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28584 [Metrics]: Give up on signing jars

[Tor Bug Tracker & Wiki]

#28584: Give up on signing jars
-+-
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by karsten):

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


Comment:

 Okay, cool. Merged to metrics-base and patched the other five dependent
 code bases. Closing. 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] #28554 [Core Tor/Tor]: Fix memory leaks and missing unmocks in test_entry_guard_outdated_dirserver_exclusion

[Tor Bug Tracker & Wiki]

#28554: Fix memory leaks and missing unmocks in
test_entry_guard_outdated_dirserver_exclusion
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  bootstrap, clock-skew,   |  Actual Points:  0.1
  s8-bootstrap, 033-backport-maybe, 034  |
  -backport-maybe, 035-backport  |
Parent ID:  #24661   | Points:  0.1
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8-can
-+-
Changes (by teor):

 * status:  needs_information => needs_review


Comment:

 master is the default, and I wasn't paying attention.

 Here's a pull request for 0.3.3:
 https://github.com/torproject/tor/pull/550

 Here's a pull request for master, because 0.3.4 and later have Windows
 tests:
 https://github.com/torproject/tor/pull/534

 I think we've fixed all the outstanding CI issues, so everything should
 pass.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28639 [Core Tor/sbws]: After several days, most of the circuits timeout

[Tor Bug Tracker & Wiki]

#28639: After several days, most of the circuits timeout
--+
 Reporter:  juga  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  sbws:
  |  1.0.x-final
Component:  Core Tor/sbws |Version:
 Severity:  Normal| Resolution:
 Keywords:  sbws-1.0-must-moved-20181128  |  Actual Points:
Parent ID:  #25925| Points:
 Reviewer:|Sponsor:
--+

Comment (by juga):

 Replying to [comment:1 teor]:
 > What does tor say in its logs?

 The main repeated part:

 {{{
 Oct 28 05:43:00.000 [notice] Heartbeat: Tor's uptime is 2 days 17:59
 hours, with 7 circuits open. I've sent 15.08 GB and received 482.17 GB.
 Oct 28 05:43:00.000 [notice] Average packaged cell fullness: 43.617%. TLS
 write overhead: 4%
 Oct 28 05:50:28.000 [notice] Have tried resolving or connecting to address
 '[scrubbed]' at 3 different places. Giving up.
 Oct 28 05:57:49.000 [notice] No circuits are opened. Relaxed timeout for
 circuit 40835 (a General-purpose client 2-hop circuit in state doing
 handshakes with channel state open) to 1ms. However, it appears the
 circuit has timed out anyway. 0 guards are live. [53 similar message(s)
 suppressed in last 3600 seconds]
 }}}

 I can't figure out reasons with that, but maybe you do.

 There are also some of the type:
 {{{
 Oct 26 23:33:59.000 [warn] Tried connecting to router at REDACTED, but
 identity key was not as expected: wanted REDACTED but got REDACTED.
 }}}

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28639#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
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] #28554 [Core Tor/Tor]: Fix memory leaks and missing unmocks in test_entry_guard_outdated_dirserver_exclusion

[Tor Bug Tracker & Wiki]

#28554: Fix memory leaks and missing unmocks in
test_entry_guard_outdated_dirserver_exclusion
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  bootstrap, clock-skew,   |  Actual Points:  0.1
  s8-bootstrap, 033-backport-maybe, 034  |
  -backport-maybe, 035-backport  |
Parent ID:  #24661   | Points:  0.1
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8-can
-+-

Comment (by teor):

 Oh, hang on, the 0.3.3 pull request CI points to master for some reason. I
 think GitHub's CI API is broken, or it's broken on the Travis/Appveyor
 side.

 Here's the 0.3.3 branch CI from my repository:
 https://travis-ci.org/teor2345/tor/builds/458279337

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28615 [Metrics/Library]: Additional @type annotation

[Tor Bug Tracker & Wiki]

#28615: Additional @type annotation
-+--
 Reporter:  atagar   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Adding a `@type` annotation for detached signatures sounds reasonable.

 But I'm less clear about the other three. A status entry is not a
 descriptor. It is ''part'' of another descriptor. In Metrics Library we
 have `NetworkStatusEntry` for status entry, but it's explicitly marked as
 not being a descriptor type of its own.

 Wouldn't it be sufficient to pass the `@type` annotation of the network
 status containing the status entry to Stem?

 Asked differently, if we make the status entry a descriptor type of its
 own, why would we not do the same with `dir-source` entries
 (`DirSourceEntry` in Metrics Library), `directory-signature` entries
 (`DirectorySignature` in Metrics Library)? (I'm not suggesting we do this,
 but what would we tell somebody suggesting this after defining descriptor
 types for the various status entries?)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28642 [Applications/Tor Browser]: Tor browser cannot connect to SOCKS server if it is not specified by IP address

[Tor Bug Tracker & Wiki]

#28642: Tor browser cannot connect to SOCKS server if it is not specified by IP
address
+--
 Reporter:  wagon   |  Owner:  tbb-team
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Component:  Applications/Tor Browser
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 I have tor running at another host with IP 10.0.0.1. It is accessible by
 tor-browser running on 10.0.0.2 via network connection. In TBB 8.0.3, if I
 put in `/path/to/Browser/TorBrowser/Data/Browser/profile.default/user.js`
 an option
 {{{
 user_pref("network.proxy.socks", "10.0.0.1");
 }}}
 it works fine. However, if I put
 {{{
 user_pref("network.proxy.socks", "myproxy");
 }}}
 where `myproxy` is added to `/etc/hosts` as `10.0.0.1 myproxy`, tor-
 browser cannot connect. Original firefox 60.3.0 (8.0.3 is based on this
 version) works fine if proxy is specified as `myproxy`. Is it a feature or
 bug? Do we have some workaround 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

[tor-bugs] #28643 [Internal Services/Service - github tpo]: New github team for manual and support

[Tor Bug Tracker & Wiki]

#28643: New github team for manual and support
+--
 Reporter:  teor|  Owner:  hiro
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Internal Services/Service - github tpo  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+--
 emmapeel asked me to give her write access to the manual and support
 repositories on https://github.com/torproject , so she can close pull
 requests.

 We give access to github/torproject using github teams.

 People with write access can close pull requests, and push to branches.

 Here's what I need to know:

 Write access team:
 Which repositories should the team have access to?
 What should the team be called?
 Who should be in the team?
 What are their github usernames?

 Do you need a team with admin access as well?
 People with admin access can modify permissions, and delete or rename the
 repository. (A few of us already have admin access to all repositories.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28642 [Applications/Tor Browser]: Tor browser cannot connect to SOCKS server if it is not specified by IP address

[Tor Bug Tracker & Wiki]

#28642: Tor browser cannot connect to SOCKS server if it is not specified by IP
address
--+--
 Reporter:  wagon |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 I guess it's related to a feature which has prevented numerous proxy
 bypasses for DNS requests. We do
 {{{
 +PRNetAddr tempAddr;
 +if (mDisableDNS) {
 +// Allow IP lookups through, but nothing else.
 +if (PR_StringToNetAddr(aHostname.BeginReading(), &tempAddr) !=
 PR_SUCCESS) {
 +return NS_ERROR_UNKNOWN_PROXY_HOST; // XXX:
 NS_ERROR_NOT_IMPLEMENTED?
 +}
 +}
 }}}
 `network.proxy.socks_remote_dns` is the preference which might help you.
 Assuming I am right then this a WONTFIX. Please reopen otherwise.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28642 [Applications/Tor Browser]: Tor browser cannot connect to SOCKS server if it is not specified by IP address

[Tor Bug Tracker & Wiki]

#28642: Tor browser cannot connect to SOCKS server if it is not specified by IP
address
--+--
 Reporter:  wagon |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by wagon):

 I see the same problem with `torsocks`, but `torsocks` documented it as
 not yet implemented (`man torsocks.conf`):

 > TorAddress ip_addr
 >  The IP address of the Tor SOCKS server (e.g "server = 10.1.4.253").
 Only one server may be  specified.
 >  Currently, **torsocks does NOT support hostname**.  (default:
 127.0.0.1)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28625 [Applications/Tor Browser]: Tor Browser gets stuck

[Tor Bug Tracker & Wiki]

#28625: Tor Browser gets stuck
--+---
 Reporter:  kanda |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by kanda):

 I am using Arch Linux with LTS kernel 64 bit. But the problem was already
 there, when i used the non LTS kernel.

 Yep, I reseted the Tor browser, but the problem remains.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28494 [Core Tor/Stem]: Please provide an equivalent for UnparseableDescriptor from metrics-lib

[Tor Bug Tracker & Wiki]

#28494: Please provide an equivalent for UnparseableDescriptor from metrics-lib
---+
 Reporter:  irl|  Owner:  atagar
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  worksforme
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by irl):

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


Comment:

 Ok. In this case I think this can be closed. If I do find that there are
 cases where it's not working, I'll reopen or file a new 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] #27947 [Core Tor/Chutney]: Chutney's owning controller process code compares strings with ints

[Tor Bug Tracker & Wiki]

#27947: Chutney's owning controller process code compares strings with ints
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 opara, did you still want to write this patch?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #10538 [Applications/Tor Browser]: Think of PTTBB's pluggable transport interface

[Tor Bug Tracker & Wiki]

#10538: Think of PTTBB's pluggable transport interface
--+--
 Reporter:  asn   |  Owner:  tbb-team
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Closing as dcf intended to do (I agree with that).

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

[tor-bugs] #28644 [Internal Services/Service - git]: please delete branch tb8_updates in support.git

[Tor Bug Tracker & Wiki]

#28644: please delete branch tb8_updates in support.git
-+
 Reporter:  emmapeel |  Owner:  tor-gitadm
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 This branch has inadvertently been uploaded to the repo. We have merged it
 in master already.

 plz delete  branch tb8_updates from

 https://git.torproject.org/project/web/support.git

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28642 [Applications/Tor Browser]: Tor browser cannot connect to SOCKS server if it is not specified by IP address

[Tor Bug Tracker & Wiki]

#28642: Tor browser cannot connect to SOCKS server if it is not specified by IP
address
--+--
 Reporter:  wagon |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by wagon):

 > `network.proxy.socks_remote_dns` is the preference which might help you.
 You are right. If it is false, it works. However, it is strange that value
 of this option in `user.js` is ignored. I have to change it from browser
 in `about:config` manually. Why? I found that in `/path/to/profile.meek-
 http-helper` it is written
 {{{
 // Make sure DNS is also blackholed. network.proxy.socks_remote_dns is
 // overridden by meek-http-helper at startup.
 }}}
 but I don't use transports.

 From anonymity point of view using tor as DNS service is not good, as
 different exit nodes will be used for DNS resolving and for data transfer,
 which makes tor usage pattern unique. For this task, some intermediate
 local transparent proxy, which maps `myproxy` to another IP, is probably
 better.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28643 [Internal Services/Service - github tpo]: New github team for manual and support

[Tor Bug Tracker & Wiki]

#28643: New github team for manual and support
+--
 Reporter:  teor|  Owner:  hiro
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Internal Services/Service - github tpo  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by hiro):

 emmapeel should be able to push to torgit and then the git hooks we have
 should push to github and automagically close the pull request.

 We give read access to github/torproject teams so that when a PR is opened
 people can receive an email on that repository (because they are in the
 team). Then I only give write access to the pusher, which is only an
 account we use to sync between torgit and github.

 I am going to check why this PR isn't being closed automatically.
 Sometimes github is slow in syncing PR, the only important thing is that
 once something is merged the commits can be seen on github.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26698 [Core Tor/Tor]: Authorities should put a hash of the bandwidth file in their votes

[Tor Bug Tracker & Wiki]

#26698: Authorities should put a hash of the bandwidth file in their votes
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:
   |  needs_review
 Priority:  Low|  Milestone:  Tor:
   |  0.4.0.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-crypto tor-dirauth tor-bwauth  |  Actual Points:
Parent ID:  #27047 | Points:
 Reviewer:  mikeperry  |Sponsor:
---+---
Changes (by teor):

 * milestone:  Tor: unspecified => Tor: 0.4.0.x-final


Comment:

 Putting this in 0.4.0, because it's a feature with code.

 Hey mikeperry, do you have time to review this ticket this week?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28501 [Webpages/Support]: lektor plugins: please add lektor-markdown-header-anchors

[Tor Bug Tracker & Wiki]

#28501: lektor plugins: please add lektor-markdown-header-anchors
--+
 Reporter:  emmapeel  |  Owner:  hiro
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Support  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by emmapeel):

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


Comment:

 it is working now

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

Re: [tor-bugs] #28644 [Internal Services/Service - git]: please delete branch tb8_updates in support.git

[Tor Bug Tracker & Wiki]

#28644: please delete branch tb8_updates in support.git
-+-
 Reporter:  emmapeel |  Owner:  tor-gitadm
 Type:  task | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by irl):

 * status:  new => needs_information


Comment:

 Please GPG sign descriptions for tickets that ask for the deletion of
 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] #28644 [Internal Services/Service - git]: please delete branch tb8_updates in support.git

[Tor Bug Tracker & Wiki]

#28644: please delete branch tb8_updates in support.git
-+
 Reporter:  emmapeel |  Owner:  tor-gitadm
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by irl):

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


Comment:

 I confirmed this was merged, so I guess no data is being deleted, but
 still in future make sure to sign the description so I can do less work.

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

[tor-bugs] #28645 [Core Tor/sbws]: Add debugging options to sbws torrc

[Tor Bug Tracker & Wiki]

#28645: Add debugging options to sbws torrc
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #28639
   Points: |   Reviewer:
  Sponsor: |
---+---
 We should set the following torrc options for better logs:
 {{{
 # useful logging options for clients that don't care about anonymity
 'SafeLogging': 0,
 'LogTimeGranularity': 1,
 'ProtocolWarnings': 1,
 }}}


 I also mentioned some of these options in:
 https://github.com/torproject/sbws/issues/146
 But they never made it into the pull 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] #28640 [Applications/Tor Browser]: System addon does not override app-profile addon

[Tor Bug Tracker & Wiki]

#28640: System addon does not override app-profile addon
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201811  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * cc: mcs, brade (added)
 * keywords:  tbb-mobile => tbb-mobile, TorBrowserTeam201811
 * status:  needs_information => new


Comment:

 Replying to [comment:2 sysrqb]:
 > I think it is intentional that the app profile extensions override the
 system addon: [https://gitweb.torproject.org/tor-
 browser.git/tree/toolkit/mozapps/extensions/internal/XPIProvider.jsm#n2105
 in XPIProvider] - at least this is how I am reading it.

 That's actually okay I think. The bug here is that the there is an
 integral extension, which we don't ship anymore compared to the previous
 bundle, still available after the update and not deleted.

 For Linux/Windows we get that essentially for free as the profile is
 included inside of the bundle and the logic determining which items to
 remove/replace is running across the profiles on those platforms as well.

 For macOS the case is different as we needed to get the profile outside of
 the bundle directory for code signing purposes (see: #13252, and note that
 we plan to do so for Linux and Windows, too, as there are a bunch of bugs
 with our current way of doing things on those platforms, see: #18367 and
 #18369). We solved that problem but I currently can't find the details,
 mcs/brade might know. That in turn might help to find a good solution for
 Android case and/or might help thinking through whether desktop platforms
 would be affected the same once we transition to a built-in Torbutton for
 them, too.

 > I wonder if we should do something slightly hacky. In the
 `PostUpdateHandler`, when the system extensions are copied into the
 `features/` dir, we check if the same addon is already installed in the
 profile, and we uninstall it if it is found.

 Sounds fine with me if we don't fine a better plan.

 > (I don't know how to initiate an uninstall of an addon from Java -
 [https://gitweb.torproject.org/tor-
 browser.git/tree/mobile/android/chrome/content/aboutAddons.js#n344 the
 javascript is context sensitive] - plus it requires another restart before
 it is it fully uninstalled, but that's another problem).

 Yeah, le't not go that route.

 > The third problem is preferences.json isn't copied from the apk into the
 app's data directory. I think this is because the the app
 [https://gitweb.torproject.org/tor-
 
browser.git/tree/mobile/android/base/java/org/mozilla/gecko/distribution/Distribution.java#n520
 sets a preference] (`distribution_state`) when initialization completes,
 and then it [https://gitweb.torproject.org/tor-
 
browser.git/tree/mobile/android/base/java/org/mozilla/gecko/distribution/Distribution.java#n491
 never copies new files] from newer APKs during an update.

 That's annoying. I think we should make exceptions for the files we care
 about. Or we could just put some logic in the `PostUpdateHandler` here as
 well.

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

[tor-bugs] #28646 [Core Tor/sbws]: Disable adaptive circuit timeouts

[Tor Bug Tracker & Wiki]

#28646: Disable adaptive circuit timeouts
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #28639
   Points: |   Reviewer:
  Sponsor: |
---+---
 sbws sets its own timeouts, so it should tell tor not to use adaptive
 timeouts:
 {{{
 'LearnCircuitBuildTimeout': 0,  # Disable adaptive circuit timeouts.
 }}}

 This was implemented in 0.3.0:
 https://github.com/torproject/sbws/issues/146
 https://github.com/torproject/sbws/pull/147

 But reverted in 0.4.0 by mistake:
 https://github.com/torproject/sbws/issues/151

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28639 [Core Tor/sbws]: After several days, most of the circuits timeout

[Tor Bug Tracker & Wiki]

#28639: After several days, most of the circuits timeout
--+
 Reporter:  juga  |  Owner:  (none)
 Type:  defect| Status:
  |  needs_information
 Priority:  Medium|  Milestone:  sbws:
  |  1.0.x-final
Component:  Core Tor/sbws |Version:
 Severity:  Normal| Resolution:
 Keywords:  sbws-1.0-must-moved-20181128  |  Actual Points:
Parent ID:  #25925| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  new => needs_information


--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28639#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
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] #28639 [Core Tor/sbws]: After several days, most of the circuits timeout

[Tor Bug Tracker & Wiki]

#28639: After several days, most of the circuits timeout
--+
 Reporter:  juga  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  sbws:
  |  1.0.x-final
Component:  Core Tor/sbws |Version:
 Severity:  Normal| Resolution:
 Keywords:  sbws-1.0-must-moved-20181128  |  Actual Points:
Parent ID:  #25925| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:6 juga]:
 > Replying to [comment:1 teor]:
 > > What does tor say in its logs?
 >
 > The main repeated part:
 >
 > {{{
 > Oct 28 05:43:00.000 [notice] Heartbeat: Tor's uptime is 2 days 17:59
 hours, with 7 circuits open. I've sent 15.08 GB and received 482.17 GB.
 > Oct 28 05:43:00.000 [notice] Average packaged cell fullness: 43.617%.
 TLS write overhead: 4%
 > Oct 28 05:50:28.000 [notice] Have tried resolving or connecting to
 address '[scrubbed]' at 3 different places. Giving up.
 > Oct 28 05:57:49.000 [notice] No circuits are opened. Relaxed timeout for
 circuit 40835 (a General-purpose client 2-hop circuit in state doing
 handshakes with channel state open) to 1ms. However, it appears the
 circuit has timed out anyway. 0 guards are live. [53 similar message(s)
 suppressed in last 3600 seconds]
 > }}}

 The key parts of this message are:
 {{{
 No circuits are opened. Relaxed timeout for circuit
 }}}

 I think we can fix this bug by disabling adaptive timeouts in tor. See
 #28646.

 {{{
 0 guards are live.
 }}}

 > I can't figure out reasons with that, but maybe you do.

 sbws sets `UseEntryGuards 0`, so it should never have any guards:
 https://github.com/torproject/sbws/blob/master/sbws/globals.py#L19

 I need better logs to debug this issue, please implement #28645.

 > There are also some of the type:
 > {{{
 > Oct 26 23:33:59.000 [warn] Tried connecting to router at REDACTED, but
 identity key was not as expected: wanted REDACTED but got REDACTED.
 > }}}

 It is safe to paste these logs without redacting them. sbws just contacts
 relays at random, so there is no need to protect anyone's privacy.

 Once you've done #28645 and #28646, please paste the un-redacted logs in
 this ticket.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28639#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
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] #28647 [Core Tor/sbws]: Update DEPLOY.rst based on Torflow's documentation

[Tor Bug Tracker & Wiki]

#28647: Update DEPLOY.rst based on Torflow's documentation
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+---
 Are these things required for sbws:
 * 500Mbit-1Gbit of upstream
 * a fixed IP address
 * SSL is needed to avoid HTTP content caches at the various exit nodes
 * Self-signed certs are OK
 * The server will consume around 12-15Gbytes/day
 * A script to create the file

 See Torflow's docs at:
 
https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/README.BwAuthorities#n157

 This documentation needs to be updated in 1.0, before we give the
 instructions to more authority operators.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28648 [Core Tor/sbws]: Broken links in DEPLOY.rst

[Tor Bug Tracker & Wiki]

#28648: Broken links in DEPLOY.rst
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+---
 These links are broken on GitHub:

 {{{
 To configure destinations, create a configuration file according to
 ./docs/source/man_sbws.ini.rst (or /docs/source/man_sbws.ini.rst or
 :doc:`man_sbws.ini` or man sbws.ini)
 }}}

 https://github.com/torproject/sbws/blob/master/DEPLOY.rst#scanner-setup

 We should fix this before sbws is deployed by more operators.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28648 [Core Tor/sbws]: Broken links in DEPLOY.rst

[Tor Bug Tracker & Wiki]

#28648: Broken links in DEPLOY.rst
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 Is there an automatic link-checking tool you can use when building sbws in
 CI?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28649 [Core Tor/sbws]: Provide an example destination URL

[Tor Bug Tracker & Wiki]

#28649: Provide an example destination URL
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+---
 When I tried to work out how to configure a sbws destination, I looked at:
 * DEPLOY.rst, but the links were broken (#28648)
 * config.default.ini, but the [destinations] section didn't tell me what I
 needed to add
 * man_sbws.ini.rst , but I couldn't work out what needs to go in the
 minimal sbws.ini
 * an example config.ini, but there isn't one

 Please:
 * add an example URL to config.default.ini, or
 * add a config.ini with an example URL

 Please also:
 * clearly document the minimal sbws.ini in DEPLOY.rst, and
 * clearly document the minimal sbws.ini at the top of man_sbws.ini.rst
 * tell me I shouldn't change the other options listed in man_sbws.ini.rst

 This ticket is required for sbws setup, so it should go in sbws 1.0.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28643 [Internal Services/Service - github tpo]: New github team for manual and support

[Tor Bug Tracker & Wiki]

#28643: New github team for manual and support
+--
 Reporter:  teor|  Owner:  hiro
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Internal Services/Service - github tpo  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 Replying to [comment:1 hiro]:
 > emmapeel should be able to push to torgit and then the git hooks we have
 should push to github and automagically close the pull request.

 Auto-closing only works when the pushed commits match the pull request.

 > We give read access to github/torproject teams so that when a PR is
 opened people can receive an email on that repository (because they are in
 the team). Then I only give write access to the pusher, which is only an
 account we use to sync between torgit and github.

 The network team has write access to some repositories, because we need it
 to close pull requests, and rebuild CI on Travis and Appveyor.

 A few people have admin access, because we need it to modify the Travis
 and Appveyor CI configs.

 > I am going to check why this PR isn't being closed automatically.
 Sometimes github is slow in syncing PR, the only important thing is that
 once something is merged the commits can be seen on github.

 The commits from github.com were squashed before pushing to
 torproject.org. So GitHub didn't close the pull request, because the
 commits did not match.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28650 [Core Tor/Tor]: hi

[Tor Bug Tracker & Wiki]

#28650: hi
-+--
 Reporter:  srikanth kurra   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  Core Tor/Tor
  Version:   |   Severity:  Normal
 Keywords:  tor-hs, tor-control  |  Actual Points:
Parent ID:  #28269   | Points:
 Reviewer:   |Sponsor:
-+--


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

Re: [tor-bugs] #28650 [Core Tor/Tor]: hi

[Tor Bug Tracker & Wiki]

#28650: hi
-+
 Reporter:  srikanth kurra   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-control  |  Actual Points:
Parent ID:  #28269   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by teor):

 This is a bug tracker for problems with Tor.
 Do you have a problem with Tor?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28641 [Core Tor/Tor]: conn_close_if_marked: Non-fatal assertion !(connection_is_reading(conn)) failed

[Tor Bug Tracker & Wiki]

#28641: conn_close_if_marked: Non-fatal assertion !(connection_is_reading(conn))
failed
--+--
 Reporter:  TheBoegl  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nickm):

 Hi!  Thanks for reporting this! It looks like a duplicate of #27750.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28616 [Core Tor/Tor]: TLS internal error running Tor 0.3.4.9 on Debian Buster (OpenSSL 1.1.1a)

[Tor Bug Tracker & Wiki]

#28616: TLS internal error running Tor 0.3.4.9 on Debian Buster (OpenSSL 1.1.1a)
--+
 Reporter:  filippo   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by gvanem):

 I had the same issue. I reported it to Tor-talk at 13-October:
   https://lists.torproject.org/pipermail/tor-talk/2018-October/044547.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] #28466 [Applications/rbm]: rbm does not correctly apply git submodule URL changes

[Tor Bug Tracker & Wiki]

#28466: rbm does not correctly apply git submodule URL changes
+
 Reporter:  boklm   |  Owner:  boklm
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/rbm|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tbb-rbm, TorBrowserTeam201811R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by gk):

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


Comment:

 Looks good! Applied to `rbm`'s `master` branch (commit
 eb500fa9467fb4d7229c9ca87f202ef18603d023) and updated `tor-browser-
 build`'s `master` subsequently (commit
 3378261a8cce3a8e1d908c8b73ee448ec572bec4).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28521 [Obfuscation/FTE]: fte is not working using default tor browser bridges

[Tor Bug Tracker & Wiki]

#28521: fte is not working using default tor browser bridges
-+---
 Reporter:  boklm|  Owner:  kpdyer
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/FTE  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by gk):

 Replying to [comment:2 kpdyer]:
 > Yep, I'm the owner for these.
 >
 >  - 128.105.214.161 had a hardware failure and is permanently offline.

 We can delete it from Tor Browser then?

 >  - 128.105.214.162/128.105.214.163 are experiencing some sort of
 transient failure but I'm not physically located near these machines. I've
 asked someone to look into it and I should have an answer soon.

 Okay, sounds good. Let us know what we should do (if anything, like
 removing them, too).

 >  - 131.252.210.150 was in a bad state but I was able to resolve it
 remotely. Can you confirm it's working for you too?

 Hm. Tor Browser does not seem to like it for some reason. I'll look closer
 at it why that's the case.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28641 [Core Tor/Tor]: conn_close_if_marked: Non-fatal assertion !(connection_is_reading(conn)) failed

[Tor Bug Tracker & Wiki]

#28641: conn_close_if_marked: Non-fatal assertion !(connection_is_reading(conn))
failed
--+--
 Reporter:  TheBoegl  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

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


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

Re: [tor-bugs] #28628 [Applications/Tor Browser]: Introduce New Security Settings to users

[Tor Bug Tracker & Wiki]

#28628: Introduce New Security Settings to users
---+--
 Reporter:  antonela   |  Owner:  dunqan
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201811  |  Actual Points:
Parent ID:  #25658 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by antonela):

 * owner:  antonela => dunqan


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28640 [Applications/Tor Browser]: System addon does not override app-profile addon

[Tor Bug Tracker & Wiki]

#28640: System addon does not override app-profile addon
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201811  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 Replying to [comment:4 gk]:
 > For macOS the case is different as we needed to get the profile outside
 of the bundle directory for code signing purposes (see: #13252, and note
 that we plan to do so for Linux and Windows, too, as there are a bunch of
 bugs with our current way of doing things on those platforms, see: #18367
 and #18369). We solved that problem but I currently can't find the
 details, mcs/brade might know. That in turn might help to find a good
 solution for Android case and/or might help thinking through whether
 desktop platforms would be affected the same once we transition to a
 built-in Torbutton for them, too.

 On macOS, when we transitioned from "profile embedded within the app" to
 the "side-by-side" TorBrowser-Data approach, the normal update mechanism
 took care of removing all of the extensions from the embedded browser
 profile. Here is the current #13252 patch for reference:
 https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-
 browser-60.3.0esr-8.5-1&id=86e3b0eabbd3b1f02d755399074e511eb5784aa2

 The patch does include some migration code which moves the browser profile
 over to TorBrowser-Data, but I don't think that code needs to do anything
 special for the extensions (since they will be removed when the MAR-based
 update has been applied, and that occurs before the profile migration code
 runs). If you want to see the migration code, start by looking at
 `migrateOneTorBrowserDataDir()` inside `toolkit/xre/nsAppRunner.cpp`.

 We also added some code to help with preferences overrides. From the
 commit message:
  All .js files in distribution/preferences (on Mac OS,
 Contents/Resources/distribution/preferences) will be copied to the
 preferences directory within the user's browser profile when the profile
 is created and each time Tor Browser is updated.
 I don't think we rely on that code any longer due to changes made for
 Firefox ESR 60, but you can see the relevant code by looking at the
 changes to `toolkit/mozapps/extensions/internal/XPIProvider.jsm` as part
 of the #13252 patch.

 One crazy idea that might work as a quick-and-dirty solution would be to
 blocklist the old Torbutton. Using that approach would require using a new
 extension ID for the system add-on... which is inconvenient. I am sure we
 will encounter this same issue for desktop (at least on macOS), and we
 will probably need to add code to
 `toolkit/mozapps/extensions/internal/XPIProvider.jsm` that removes all
 traces of the old profile-based extension.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28051 [Applications/Tor Browser]: Build Orbot into TBA

[Tor Bug Tracker & Wiki]

#28051: Build Orbot into TBA
-+-
 Reporter:  sysrqb   |  Owner:  sysrqb
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tba-a2,  |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by gk):

 Replying to [comment:37 sysrqb]:
 > Okay. I have two new branches, one for tor-browser and another for
 orbot.
 >
 > The orbot branch (`28051_orbot_4`) includes the changes in comment:31.
 It also includes a new proguard rule for keeping
 `org.torproject.android.settings.Languages.setup(Class,int)` that it was
 stipping due to it not being used. Unfortunately, this method is called by
 the Application when the app starts, so I added it in GeckoApplication in
 Fennec.
 >
 > I have mixed feelings about adding this, because on the one hand this is
 needed for opening Orbot's Settings menu - otherwise Orbot crashes and
 we're left with Tor Browser without Tor. However, on the other hand, we'll
 likely never use Orbot's settings menu. But, we're already renaming the
 preferences layout xml so it doesn't conflict with Fennec, so if we do
 that then I think it makes sense that we prevent this crash.

 I think that's okay and I agree with that.

 > The new tor-browser branch adds the necessary initialization calls -
 `28051_6`.

 Okay, both branches look good to me. I'll commit the `tor-browser` patches
 once we are good with all the other 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] #28624 [Core Tor/Tor]: Should we remember dormant state on restart?

[Tor Bug Tracker & Wiki]

#28624: Should we remember dormant state on restart?
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+
Changes (by mcs):

 * cc: brade, mcs (added)


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

Re: [tor-bugs] #28642 [Applications/Tor Browser]: Tor browser cannot connect to SOCKS server if it is not specified by IP address

[Tor Bug Tracker & Wiki]

#28642: Tor browser cannot connect to SOCKS server if it is not specified by IP
address
--+--
 Reporter:  wagon |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by targetSdkVersion):

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


Comment:

 Replying to [comment:1 gk]:
 > I guess it's related to a feature which has prevented numerous proxy
 bypasses for DNS requests. We do
 > {{{
 > +PRNetAddr tempAddr;
 > +if (mDisableDNS) {
 > +// Allow IP lookups through, but nothing else.
 > +if (PR_StringToNetAddr(aHostname.BeginReading(), &tempAddr) !=
 PR_SUCCESS) {
 > +return NS_ERROR_UNKNOWN_PROXY_HOST; // XXX:
 NS_ERROR_NOT_IMPLEMENTED?
 > +}
 > +}
 > }}}
 > `network.proxy.socks_remote_dns` is the preference which might help you.
 Assuming I am right then this a WONTFIX. Please reopen otherwise.
 No, that's not for the address of SOCKS proxy for Firefox. See #17991,
 #17953, #17949, #17901 for why you can't use hard-coded `127.0.0.1`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28424 [Core Tor/Tor]: Refactor hs_service_callback() to no longer need to run once per second?

[Tor Bug Tracker & Wiki]

#28424: Refactor hs_service_callback() to no longer need to run once per second?
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+

Comment (by akwizgran):

 I updated the simulation to consider the probability of lookup failure as
 a function of time, and to use the same HSDirs in both hashrings. The new
 code is attached, along with graphs showing the mean and first percentile
 of the lookup success rate over 1000 independent runs.

 The first percentile gives an idea of the experience of an unlucky hidden
 service. The success rate for an unlucky service falls below 90% after 5
 hours, showing that the assessment in my last comment, based on mean time
 until possible failure, was too optimistic. Services do need to republish
 their descriptors frequently or there's a significant risk of lookup
 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/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28424 [Core Tor/Tor]: Refactor hs_service_callback() to no longer need to run once per second?

[Tor Bug Tracker & Wiki]

#28424: Refactor hs_service_callback() to no longer need to run once per second?
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+
Changes (by akwizgran):

 * Attachment "ChurnSim.2.java" added.

 Updated simulation code

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

Re: [tor-bugs] #28424 [Core Tor/Tor]: Refactor hs_service_callback() to no longer need to run once per second?

[Tor Bug Tracker & Wiki]

#28424: Refactor hs_service_callback() to no longer need to run once per second?
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+
Changes (by akwizgran):

 * Attachment "hsdir-reachability-first-percentile.png" added.

 First percentile lookup success rate

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28424 [Core Tor/Tor]: Refactor hs_service_callback() to no longer need to run once per second?

[Tor Bug Tracker & Wiki]

#28424: Refactor hs_service_callback() to no longer need to run once per second?
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+
Changes (by akwizgran):

 * Attachment "hsdir-reachability-mean.png" added.

 Mean lookup success rate

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27828 [Applications/Tor Browser]: "Check for Tor Browser update" doesn't seem to do anything

[Tor Bug Tracker & Wiki]

#27828: "Check for Tor Browser update" doesn't seem to do anything
-+-
 Reporter:  arma |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-8.0-issues, tbb-regression,  |  Actual Points:
  TorBrowserTeam201811R  |
Parent ID:  #25694   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * keywords:  tbb-8.0-issues, tbb-regression => tbb-8.0-issues, tbb-
 regression, TorBrowserTeam201811R
 * status:  new => needs_review


Comment:

 Here is a fix for review:
 https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug27828-01&id=a79c1cdea0e1e73cae8ebafc27b3423828fa1816

 Changes to the Firefox code between ESR 52 and 60 caused the update
 "wizard" window to not be opened if the update had already been downloaded
 (updater state == pending), but Torbutton relies on the old behavior. Our
 patch works around the problem, although in the long run I expect Mozilla
 to remove the XUL-based update window entirely (as well as the
 `app.update.doorhanger` pref). For reference, here is the Torbutton code
 that calls the `showUpdateDownloaded()` function:
 
https://gitweb.torproject.org/torbutton.git/tree/src/chrome/content/torbutton.js?h=maint-2.0#n595

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28305 [Metrics/Statistics]: Include client numbers even if we think we got reports from more than 100% of all relays

[Tor Bug Tracker & Wiki]

#28305: Include client numbers even if we think we got reports from more than 
100%
of all relays
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:  SponsorV-can
+--
Changes (by karsten):

 * Attachment "frac-raw-2018-11-28.png" 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] #28305 [Metrics/Statistics]: Include client numbers even if we think we got reports from more than 100% of all relays

[Tor Bug Tracker & Wiki]

#28305: Include client numbers even if we think we got reports from more than 
100%
of all relays
+--
 Reporter:  karsten |  Owner:  karsten
 Type:  defect  | Status:  accepted
 Priority:  High|  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:  SponsorV-can
+--
Changes (by karsten):

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


Comment:

 I think I now know what's going on: some relays report written directory
 byte statistics for times when they were hardly listed in consensuses.

 Here's a graph with all variables going into the `frac` formula, plus
 intermediate products, and finally the `frac` value:

 [[Image(frac-raw-2018-11-28.png, 500px)]]

 Note the red arrow. At this point `n(H)` grows larger than `n(N)`. That's
 an issue. By definition, a relay cannot report written directory bytes
 statistics for a longer time than it's online.

 I also looked at random relay `002B024E24A30F113982FCB17DFE05B6F38C0C79`
 that had a larger `n(H)` value than `n(N)` value on 2018-10-28:

  - This relay was listed in 3 out of 24 consensuses on 2018-10-28 (19:00,
 20:00, and 21:00). As a result, we count this relay with `n(N) = 10800`
 (we're using seconds internally, not hours).
  - The same relay published an extra-info descriptor on 2018-10-31 at
 09:28:04 with the following line: `dirreq-write-history 2018-10-30
 08:04:04 (86400 s) 0,0`. We count this as `n(H) = 57356` on 2018-10-28.

 A possible mitigation (other than the one I suggested above) could be to
 replace `n(H)` with `n(N^H)` in the `frac` formula. This would mean that
 we'd cap the amount of time for which a relay reported written directory
 bytes to the amount of time it was listed in the consensus.

 I'm currently dumping and downloading the database to try this out at
 home. However, I'm afraid that deploying this fix is going to be much more
 expensive than making the simple fix suggested above. I'll report here
 what I find out.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28640 [Applications/Tor Browser]: System addon does not override app-profile addon

[Tor Bug Tracker & Wiki]

#28640: System addon does not override app-profile addon
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201811  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sysrqb):

 Replying to [comment:5 mcs]:
 > Replying to [comment:4 gk]:
 > > For macOS the case is different as we needed to get the profile
 outside of the bundle directory for code signing purposes (see: #13252,
 and note that we plan to do so for Linux and Windows, too, as there are a
 bunch of bugs with our current way of doing things on those platforms,
 see: #18367 and #18369). We solved that problem but I currently can't find
 the details, mcs/brade might know. That in turn might help to find a good
 solution for Android case and/or might help thinking through whether
 desktop platforms would be affected the same once we transition to a
 built-in Torbutton for them, too.
 >
 > On macOS, when we transitioned from "profile embedded within the app" to
 the "side-by-side" TorBrowser-Data approach, the normal update mechanism
 took care of removing all of the extensions from the embedded browser
 profile. Here is the current #13252 patch for reference:
 > https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-
 browser-60.3.0esr-8.5-1&id=86e3b0eabbd3b1f02d755399074e511eb5784aa2
 >
 > The patch does include some migration code which moves the browser
 profile over to TorBrowser-Data, but I don't think that code needs to do
 anything special for the extensions (since they will be removed when the
 MAR-based update has been applied, and that occurs before the profile
 migration code runs). If you want to see the migration code, start by
 looking at `migrateOneTorBrowserDataDir()` inside
 `toolkit/xre/nsAppRunner.cpp`.
 >
 > We also added some code to help with preferences overrides. From the
 commit message:
 >  All .js files in distribution/preferences (on Mac OS,
 Contents/Resources/distribution/preferences) will be copied to the
 preferences directory within the user's browser profile when the profile
 is created and each time Tor Browser is updated.
 > I don't think we rely on that code any longer due to changes made for
 Firefox ESR 60, but you can see the relevant code by looking at the
 changes to `toolkit/mozapps/extensions/internal/XPIProvider.jsm` as part
 of the #13252 patch.

 Thanks! Part of the problem we're having on Android is the update
 mechanism is completely different than on desktop - so we don't benefit
 from the same MAR logic. I do think, and I agree, the torbutton transition
 should affect Mac OS the say way it affects Android, though.

 >
 > One crazy idea that might work as a quick-and-dirty solution would be to
 blocklist the old Torbutton. Using that approach would require using a new
 extension ID for the system add-on... which is inconvenient. I am sure we
 will encounter this same issue for desktop (at least on macOS), and we
 will probably need to add code to
 `toolkit/mozapps/extensions/internal/XPIProvider.jsm` that removes all
 traces of the old profile-based extension.

 Interesting idea, and I don't think it's too crazy. One other idea I have
 is we can conditionally ignore a `torbut...@torproject.org` xpi during
 startup if it's not a system addon:

 https://gitweb.torproject.org/tor-
 browser.git/tree/toolkit/mozapps/extensions/internal/XPIProvider.jsm?h
 =tor-browser-60.3.0esr-8.5-1#n1600

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28424 [Core Tor/Tor]: Refactor hs_service_callback() to no longer need to run once per second?

[Tor Bug Tracker & Wiki]

#28424: Refactor hs_service_callback() to no longer need to run once per second?
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+

Comment (by akwizgran):

 At the risk of going off-topic, I just wanted to mention one other thing I
 noticed when running the simulations. The lookup success rate can be
 improved by changing the parameters without storing more copies of
 descriptors.

 Reducing `hsdir_spread_fetch`, without changing the other parameters,
 improves the mean lookup success rate. Intuitively, if a replica is stored
 on dirs d_1...d_n at positions 1...n, churn is less likely to displace d_i
 from its position than d_{i+1} because there's less hashring distance into
 which churn could insert a new dir. Thus a client is more likely to find
 the descriptor at position i than position i+1 after churn. Reducing
 `hsdir_spread_fetch` concentrates more of the client's lookups on
 positions that are more likely to hold the descriptor.

 However, while the mean lookup success rate is improved, the effect on the
 first percentile is more nuanced. The success rate remains at 100% for
 longer, but then falls faster. I think this is because each lookup chooses
 from a smaller set of positions to query, so there's a smaller set of
 possible outcomes. When `hsdir_spread_fetch == 1`, all lookups query the
 same positions.

 This is relevant in the real world if clients can retry failed lookups. We
 might accept a lower mean success rate if clients can have another chance
 at success by retrying.

 Another interesting possibility is to trade a larger `hsdir_n_replicas`
 for a smaller `hsdir_spread_store`. In other words, use more replicas and
 store fewer copies at each replica. This improves the lookup success rate
 (both mean and first percentile), without increasing the number of copies
 of the descriptor that are stored.

 However, I'm not sure how increasing `hsdir_n_replicas` would affect query
 bandwidth. Do clients try replicas in parallel or series? If parallel,
 increasing `hsdir_n_replicas` would increase bandwidth for all queries. If
 series, the worst-case bandwidth would increase (a query would visit more
 replicas before failing).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28642 [Applications/Tor Browser]: Tor browser cannot connect to SOCKS server if it is not specified by IP address

[Tor Bug Tracker & Wiki]

#28642: Tor browser cannot connect to SOCKS server if it is not specified by IP
address
--+--
 Reporter:  wagon |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by wagon):

 > For this task, some intermediate local transparent proxy, which maps
 myproxy to another IP, is probably better.
 There is a very simple solution which requires neither `myproxy` nor any
 additional proxy for this steup. It is enough to specify 127.0.0.1 as
 SOCKS proxy in tor-browser and then redirect tor-browser to Tor's IP:port
 using only [[https://serverfault.com/a/907324|iptables rules]]. It may be
 [[https://serverfault.com/a/364137|not an accurate solution from viewpoint
 of standards]] but it is neat, simple, and works fine.


 > See #17991, #17953, #17949, #17901 for why you can't use hard-coded
 127.0.0.1.
 I think it is a different problem. Tor-browser works fine with any IP of
 SocksPort, it is not needed to be hard-coded. This ticket is about using
 some hostname instead of IP.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28051 [Applications/Tor Browser]: Build Orbot into TBA

[Tor Bug Tracker & Wiki]

#28051: Build Orbot into TBA
-+-
 Reporter:  sysrqb   |  Owner:  sysrqb
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tba-a2,  |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by sysrqb):

 Replying to [comment:40 gk]:
 > Replying to [comment:37 sysrqb]:
 > > The new tor-browser branch adds the necessary initialization calls -
 `28051_6`.
 >
 > Okay, both branches look good to me. I'll commit the `tor-browser`
 patches once we are good with all the other stuff.

 Great. I pushed a new orbot branch - `28051_orbot_5`. This only changes
 the commit "Change Orbot's behavior for Tor Browser" and calls "finish()"
 in the Activity when Tor's bootstrapping reaches 100%. This returns the
 user to Fennec automatically. This should only happen when first starts
 TBA. If the user opens our Orbot using the notification message, then
 Orbot remains open until they hit the back button or select Exit from
 Orbot's menu.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28051 [Applications/Tor Browser]: Build Orbot into TBA

[Tor Bug Tracker & Wiki]

#28051: Build Orbot into TBA
-+-
 Reporter:  sysrqb   |  Owner:  sysrqb
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tba-a2,  |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by sysrqb):

 Replying to [comment:41 sysrqb]:
 >  If the user opens our Orbot using the notification message, then Orbot
 remains open until they hit the back button or select Exit from Orbot's
 menu.

 Hrm. Yeah, selecting Exit is actually bad. Now Exit actually exits and
 kills orbot, so the user is provided a Tor Browser without a Tor. I think
 we should change this, 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] #28628 [Applications/Tor Browser]: Introduce New Security Settings to users

[Tor Bug Tracker & Wiki]

#28628: Introduce New Security Settings to users
---+--
 Reporter:  antonela   |  Owner:  dunqan
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201811  |  Actual Points:
Parent ID:  #25658 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dunqan):

 Hi everyone!

 As per #25658 antonela's asked me to consider changes to the onboarding
 process to bring it in line with the new Security Preferences screen
 (replacing the existing security slider in TB).

 '''Option 1: feature tour'''

 https://sketch.cloud/s/q8JlM/bgO0ze4/play

 Following the behaviour introduced to the user in the Circuit Display
 onboarding card:

 * Hitting the purple button in the onboarding flow opens DDG in a new tab.
 * A doorhanger introduces the new shield icon and explains the various
 icon states (the first sentence could be cut and/or incorporated into the
 onboarding card itself for brevity).
 * Hitting "Next" opens the Security Level doorhanger (see the change in
 icon state) and the second and third steps of the feature tour.
 * User may hit "Advanced Security Settings" at any time to open the new
 Security Preferences screen in a new tab (still in design as per #25658).
 * Hitting "Done!" at the end of the feature tour returns the user to the
 Security card in About:Tor.

 The intention of this route is to introduce the new shield icon and
 Security Level doorhanger properly and provide more context for the
 Security Preferences screen itself.

 '''Option 2: simple fix'''

 https://sketch.cloud/s/q8JlM/QbkaV97/play

 * Hitting the purple button in the onboarding flow simply opens the new
 Security Preferences screen in a new tab, instead of the current security
 slider window.

 Full .sketch file here for reference: https://sketch.cloud/s/q8JlM

 

 On a related note I think it would be worthwhile adding an icon or other
 device to the purple buttons in the onboarding flow, to differentiate
 between the two button behaviours:

 a) Button progresses to the next card
 b) Button opens an external link/feature tour

 But perhaps that should be a new 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] #28642 [Applications/Tor Browser]: Tor browser cannot connect to SOCKS server if it is not specified by IP address

[Tor Bug Tracker & Wiki]

#28642: Tor browser cannot connect to SOCKS server if it is not specified by IP
address
--+--
 Reporter:  wagon |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Replying to [comment:5 wagon]:
 > > See #17991, #17953, #17949, #17901 for why you can't use hard-coded
 127.0.0.1.
 > I think it is a different problem. Tor-browser works fine with any IP of
 SocksPort, it is not needed to be hard-coded. This ticket is about using
 some hostname instead of IP.

 I agree, closing. FWIW: not sure why `user.js` is ignored. I have not
 looked that closely at the code.

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

Re: [tor-bugs] #28051 [Applications/Tor Browser]: Build Orbot into TBA

[Tor Bug Tracker & Wiki]

#28051: Build Orbot into TBA
-+-
 Reporter:  sysrqb   |  Owner:  sysrqb
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tba-a2,  |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by sysrqb):

 Replying to [comment:42 sysrqb]:
 > Replying to [comment:41 sysrqb]:
 > >  If the user opens our Orbot using the notification message, then
 Orbot remains open until they hit the back button or select Exit from
 Orbot's menu.
 >
 > Hrm. Yeah, selecting Exit is actually bad. Now Exit actually exits and
 kills orbot, so the user is provided a Tor Browser without a Tor. I think
 we should change this, too.

 I pushed `28051_orbot_6` where the Exit menu option is renamed as "Close",
 and Orbot doesn't stop tor when Close is selected.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28424 [Core Tor/Tor]: Refactor hs_service_callback() to no longer need to run once per second?

[Tor Bug Tracker & Wiki]

#28424: Refactor hs_service_callback() to no longer need to run once per second?
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+
Changes (by grote):

 * cc: grote (added)


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

[tor-bugs] #28651 [Obfuscation/Snowflake]: Prepare all pieces of the snowflake pipeline for a second snowflake bridge

[Tor Bug Tracker & Wiki]

#28651: Prepare all pieces of the snowflake pipeline for a second snowflake 
bridge
---+
 Reporter:  arma   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 Right now there is one snowflake bridge, and its fingerprint is hard-coded
 in tor browser.

 Eventually we will have enough load, and/or want more resiliency, that we
 want to set up a second snowflake bridge.

 To be able to do that, I think we need changes at the client, changes at
 the snowflake, and changes at the broker.

 (A) At the snowflake side, the snowflake needs to tell the broker which
 bridge(s) it is willing to send traffic to. Additionally, we either want
 to declare that each snowflake sends to only one bridge, or we need to add
 a way for the client to tell the snowflake which bridge it wants to reach.

 (B) At the broker side, we need it to be able to learn from snowflakes
 which bridge(s) they use, and we need it to be able to learn from clients
 which bridge they want to use, and we need it to match clients with
 snowflakes that will reach that bridge.

 (C) At the client side, we need it to tell the broker which bridge it
 wants to use, and (depending on our design choice in A above) we might
 also need the client to be able to tell the snowflake which bridge it
 wants to use.

 (There is an alternative approach, where we assume that every snowflake is
 always running the newest javascript, so it is willing to reach every
 bridge on our master list. Then the broker doesn't need to do anything
 new, and we just need to add a way for the client to tell the snowflake
 which bridge it wants. I don't have a good handle on how realistic this
 assumption is.)

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

Re: [tor-bugs] #27977 [Applications/Tor Browser]: Build Orbot with rbm/tor-browser-build

[Tor Bug Tracker & Wiki]

#27977: Build Orbot with rbm/tor-browser-build
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201811, TBA-a2   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by gk):

 sisbell: could you provide an updated branch with the fixups and the new
 patches from #28051 to get the building going?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28624 [Core Tor/Tor]: Should we remember dormant state on restart?

[Tor Bug Tracker & Wiki]

#28624: Should we remember dormant state on restart?
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+

Comment (by arma):

 So would that mean that by default, Tor never remembers its dormant state
 across restarts? (Or more precisely, never reacts to dormancy info in the
 state file on startup.)

 That would seem to not cover the "some linux distro includes a Tor client
 package by default" use case, right? It's more oriented towards specific
 Tor installs that know they want to be special?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26690 [Applications/Tor Browser]: TBA: Port padlock states for .onion services to mobile

[Tor Bug Tracker & Wiki]

#26690: TBA: Port padlock states for .onion services to mobile
-+-
 Reporter:  igt0 |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a2,  |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:  #5709| Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by gk):

 igt0: How is it going with the updated icon? I'd like to get that patch
 into the upcoming alpha.

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

Re: [tor-bugs] #28051 [Applications/Tor Browser]: Build Orbot into TBA

[Tor Bug Tracker & Wiki]

#28051: Build Orbot into TBA
-+-
 Reporter:  sysrqb   |  Owner:  sysrqb
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tba-a2,  |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by gk):

 Replying to [comment:43 sysrqb]:
 > Replying to [comment:42 sysrqb]:
 > > Replying to [comment:41 sysrqb]:
 > > >  If the user opens our Orbot using the notification message, then
 Orbot remains open until they hit the back button or select Exit from
 Orbot's menu.
 > >
 > > Hrm. Yeah, selecting Exit is actually bad. Now Exit actually exits and
 kills orbot, so the user is provided a Tor Browser without a Tor. I think
 we should change this, too.
 >
 > I pushed `28051_orbot_6` where the Exit menu option is renamed as
 "Close", and Orbot doesn't stop tor when Close is selected.

 Looks good to me.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28305 [Metrics/Statistics]: Include client numbers even if we think we got reports from more than 100% of all relays

[Tor Bug Tracker & Wiki]

#28305: Include client numbers even if we think we got reports from more than 
100%
of all relays
+--
 Reporter:  karsten |  Owner:  karsten
 Type:  defect  | Status:  accepted
 Priority:  High|  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:  SponsorV-can
+--

Comment (by teor):

 Replying to [comment:5 karsten]:
 > I think I now know what's going on: some relays report written directory
 byte statistics for times when they were hardly listed in consensuses.
 >
 > Here's a graph ...
 >
 > Note the red arrow. At this point `n(H)` grows larger than `n(N)`.
 That's an issue. By definition, a relay cannot report written directory
 bytes statistics for a longer time than it's online.

 But relays that aren't listed in the consensus can still be acting as
 relays.

 Here are a few scenarios where that happens:
 * the relay's IPv4 address is unreachable from a majority of directory
 authorities, but some clients (with old consensuses) can still reach it:
 * the relay's IPv4 address has changed, and the authorities haven't
 checked the new address, but the relay is still reachable on the old
 address cached at some clients
 * the same scenarios with IPv6, but there are only 6/9 authorities that
 check and vote on IPv6
 * the relay is configured as a bridge by some clients, but it publishes
 descriptors as a relay

 If a relay drops in and out of the consensus every few hours, there will
 always be some clients with a consensus containing that relay.

 > I also looked at random relay `002B024E24A30F113982FCB17DFE05B6F38C0C79`
 that had a larger `n(H)` value than `n(N)` value on 2018-10-28:
 >
 >  - This relay was listed in 3 out of 24 consensuses on 2018-10-28
 (19:00, 20:00, and 21:00). As a result, we count this relay with `n(N) =
 10800` (we're using seconds internally, not hours).
 >  - The same relay published an extra-info descriptor on 2018-10-31 at
 09:28:04 with the following line: `dirreq-write-history 2018-10-30
 08:04:04 (86400 s) 0,0`. We count this as `n(H) = 57356` on 2018-10-28.
 >
 > A possible mitigation (other than the one I suggested above) could be to
 replace `n(H)` with `n(N^H)` in the `frac` formula. This would mean that
 we'd cap the amount of time for which a relay reported written directory
 bytes to the amount of time it was listed in the consensus.

 This seems like a reasonable approach: if the relay is listed in the
 consensus for `n(N^H)` seconds, then we should weight its bandwidth using
 that number of seconds.

 > I'm currently dumping and downloading the database to try this out at
 home. However, I'm afraid that deploying this fix is going to be much more
 expensive than making the simple fix suggested above. I'll report here
 what I find out.

 I'm not sure if it will make much of a difference long-term: relays that
 drop out of the consensus should have low bandwidth weights, and therefore
 low bandwidths. (Except when the network is unstable, or there are less
 than 3 bandwidth authorities.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28615 [Metrics/Library]: Additional @type annotation

[Tor Bug Tracker & Wiki]

#28615: Additional @type annotation
-+--
 Reporter:  atagar   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by atagar):

 > Adding a @type annotation for detached signatures sounds reasonable.

 Great! Thanks Karsten. Once the @type docs are updated please let me know
 and I'll make the related tweaks on stem's end.

 > But I'm less clear about the other three

 You're completely right that router status entries are simply entities in
 a network status document (**@type network-status-***). The trouble is
 that unlike other descriptor types router status entries are often
 provided on their own. For example, via the control port...

 {{{
 >>> GETINFO ns/name/caersidi
 250+ns/name/caersidi=
 r caersidi O7NMYwctnRDoNu5ClocT97kyX2Y 1cL1nVzDsMuGliTcNUnjIc6MAEE
 2018-11-26 17:23:54 208.113.135.162 1443 1444
 s Fast Guard HSDir Running Stable V2Dir Valid
 w Bandwidth=4820
 .
 250 OK
 }}}

 As such stem users sometimes have a desire to parse individual router
 status entries despite the fact that they're not technically valid
 descriptors on their own.

 > why would we not do the same with dir-source entries

 That's an interesting point. Is there anything that vends dir-source
 entries on their own?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27750 [Core Tor/Tor]: conn_close_if_marked: Non-fatal assertion !(connection_is_writing(conn))

[Tor Bug Tracker & Wiki]

#27750: conn_close_if_marked: Non-fatal assertion !(connection_is_writing(conn))
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.8
 Severity:  Normal   | Resolution:
 Keywords:  regression, 034-backport, 035-must,  |  Actual Points:
  035-rc-blocker?|
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
-+-

Comment (by teor):

 Another user is reporting this bug in 0.3.4, we should backport:
 https://lists.torproject.org/pipermail/tor-
 relays/2018-November/016676.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] #28647 [Core Tor/sbws]: Update INSTALL.rst and DEPLOY.rst based on Torflow's documentation (was: Update DEPLOY.rst based on Torflow's documentation)

[Tor Bug Tracker & Wiki]

#28647: Update INSTALL.rst and DEPLOY.rst based on Torflow's documentation
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Description changed by teor:

Old description:

> Are these things required for sbws:
> * 500Mbit-1Gbit of upstream
> * a fixed IP address
> * SSL is needed to avoid HTTP content caches at the various exit nodes
> * Self-signed certs are OK
> * The server will consume around 12-15Gbytes/day
> * A script to create the file
>
> See Torflow's docs at:
> https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/README.BwAuthorities#n157
>
> This documentation needs to be updated in 1.0, before we give the
> instructions to more authority operators.

New description:

 Are these things required for sbws:
 * ~~500Mbit-1Gbit of upstream~~ documented in INSTALL.rst
 * a fixed IP address
 * SSL is needed to avoid HTTP content caches at the various exit nodes
 * Self-signed certs are OK
 * The server will consume around 12-15Gbytes/day
 * A script to create the file

 See Torflow's docs at:
 
https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/README.BwAuthorities#n157

 This documentation needs to be updated in 1.0, before we give the
 instructions to more authority operators.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28546 [Applications/Tor Browser]: Rebrand Tor Browser's Window's Installer

[Tor Bug Tracker & Wiki]

#28546: Rebrand Tor Browser's Window's Installer
--+---
 Reporter:  pospeselr |  Owner:  pospeselr
 Type:  project   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #25702| Points:
 Reviewer:|Sponsor:
--+---
Changes (by pospeselr):

 * Attachment "28546_00.patch" 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] #28546 [Applications/Tor Browser]: Rebrand Tor Browser's Window's Installer

[Tor Bug Tracker & Wiki]

#28546: Rebrand Tor Browser's Window's Installer
--+---
 Reporter:  pospeselr |  Owner:  pospeselr
 Type:  project   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #25702| Points:
 Reviewer:|Sponsor:
--+---
Changes (by pospeselr):

 * Attachment "nsis-branding.png" 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] #28546 [Applications/Tor Browser]: Rebrand Tor Browser's Window's Installer

[Tor Bug Tracker & Wiki]

#28546: Rebrand Tor Browser's Window's Installer
--+--
 Reporter:  pospeselr |  Owner:  pospeselr
 Type:  project   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201811R |  Actual Points:
Parent ID:  #25702| Points:
 Reviewer:|Sponsor:
--+--
Changes (by pospeselr):

 * keywords:   => TorBrowserTeam201811R
 * cc: antonela (added)
 * status:  assigned => needs_review


Comment:

 These patches update the branding for tor-browser's windows NSIS
 installer. The new channel specific icons are used and the default install
 path and shortcuts include the channel name to allow side-by-side
 installations. The shortcut name has also been changed from 'Start Tor
 Browser' to:
  - release -> 'Tor Browser.lnk'
  - nightly -> 'Tor Browser Nightly.lnk'
  - alpha -> 'Tor Browser Alpha.lnk'

 [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/28546/nsis-branding.png)]]

 

 tbb-windows-installer patch (I don't seem to have a tbb-windows-installer
 gitweb):
 https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/28546/28546_00.patch

 tor-browser-build change:
 https://gitweb.torproject.org/user/richard/tor-browser-
 build.git/commit/?h=bug_28546

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28652 [Core Tor/sbws]: When sbws stops making progress, log a warning

[Tor Bug Tracker & Wiki]

#28652: When sbws stops making progress, log a warning
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #28547
   Points: |   Reviewer:
  Sponsor: |
---+---
 In #28639, sbws stopped making progress, but didn't log anything.

 sbws should detect when its progress rate falls beneath some minimum (for
 example, all relays measured min_result times in data_period days), and
 log a warning.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27977 [Applications/Tor Browser]: Build Orbot with rbm/tor-browser-build

[Tor Bug Tracker & Wiki]

#27977: Build Orbot with rbm/tor-browser-build
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201811, TBA-a2   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by sisbell):

 Changes (android-1128)

  * Added latest patches
  * Removed copying of non-arm native libraries
  * Added comment of reason for copying artifacts

 Patches created from branch 28051_orbot_6

 Project firefox config uses

 {{{
 git_hash: 28051_6
 git_url: https://git.torproject.org/user/sysrqb/tor-browser.git
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28554 [Core Tor/Tor]: Fix memory leaks and missing unmocks in test_entry_guard_outdated_dirserver_exclusion

[Tor Bug Tracker & Wiki]

#28554: Fix memory leaks and missing unmocks in
test_entry_guard_outdated_dirserver_exclusion
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  bootstrap, clock-skew,   |  Actual Points:  0.1
  s8-bootstrap, 033-backport-maybe, 034  |
  -backport-maybe, 035-backport  |
Parent ID:  #24661   | Points:  0.1
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8-can
-+-

Comment (by catalyst):

 Replying to [comment:8 teor]:
 > Oh, hang on, the 0.3.3 pull request CI points to master for some reason.
 I think GitHub's CI API is broken, or it's broken on the Travis/Appveyor
 side.
 >
 > Here's the 0.3.3 branch CI from my repository:
 > https://travis-ci.org/teor2345/tor/builds/458279337

 It looks like your `bug28554-033` and `teor/bug28554` branches are
 identical for some reason? At least from what I fetch from GitHub.

 {{{
 $ git rev-parse teor/bug28554-033 teor/bug28554
 ffc7b81b5dd909f0c4325e7a5b893504f76b9c77
 ffc7b81b5dd909f0c4325e7a5b893504f76b9c77
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28554 [Core Tor/Tor]: Fix memory leaks and missing unmocks in test_entry_guard_outdated_dirserver_exclusion

[Tor Bug Tracker & Wiki]

#28554: Fix memory leaks and missing unmocks in
test_entry_guard_outdated_dirserver_exclusion
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  bootstrap, clock-skew,   |  Actual Points:  0.1
  s8-bootstrap, 033-backport-maybe, 034  |
  -backport-maybe, 035-backport  |
Parent ID:  #24661   | Points:  0.1
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8-can
-+-

Comment (by teor):

 Yes, the branches are identical:

 Replying to [comment:3 teor]:
 > This branch is based on maint-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] #27490 [Core Tor/Tor]: When ClientPreferIPv6ORPort is set to auto, and a relay is being chosen for a directory or orport connection, prefer IPv4 or IPv6 at random

[Tor Bug Tracker & Wiki]

#27490: When ClientPreferIPv6ORPort is set to auto, and a relay is being chosen 
for
a directory or orport connection, prefer IPv4 or IPv6 at random
--+
 Reporter:  neel  |  Owner:  neel
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6  |  Actual Points:
Parent ID:  #17835| Points:
 Reviewer:  teor  |Sponsor:
--+

Comment (by teor):

 Hi nickm, what needs to be done before this branch is merged?

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

Re: [tor-bugs] #27647 [Core Tor/Tor]: When randomly choosing IPv4 or IPv6, set IPv6 probability based on IPv6 weight

[Tor Bug Tracker & Wiki]

#27647: When randomly choosing IPv4 or IPv6, set IPv6 probability based on IPv6
weight
-+--
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client ipv6  |  Actual Points:
Parent ID:  #17835   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by teor):

 When the consensus is received, tor parses it, and assigns bandwidth
 weights to each relay. Each relay has an IPv4 address, and an optional
 IPv6 address. Some relays can be entry nodes, depending on their flags.

 When bridges are configured, tor parses the config, and weights each
 bridge equally. Each bridge has one or two IP addresses. Each bridge is an
 entry node.

 Once the entry nodes have up-to-date weights and addresses, you can
 calculate the entry node weight for IPv4 and IPv6.

 We'll also need some documentation for this weight calculation, probably
 in dir-spec.txt.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27647 [Core Tor/Tor]: When randomly choosing IPv4 or IPv6, set IPv6 probability based on IPv6 weight

[Tor Bug Tracker & Wiki]

#27647: When randomly choosing IPv4 or IPv6, set IPv6 probability based on IPv6
weight
-+--
 Reporter:  teor |  Owner:  neel
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client ipv6  |  Actual Points:
Parent ID:  #17835   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by teor):

 * type:  defect => enhancement


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28653 [Core Tor/Tor]: Specify IPv4 and IPv6 weight calculations in dir-spec.txt

[Tor Bug Tracker & Wiki]

#28653: Specify IPv4 and IPv6 weight calculations in dir-spec.txt
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-client ipv6 tor-spec  |  Actual Points:
Parent ID:  #27647| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * type:  defect => enhancement


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28653 [Core Tor/Tor]: Specify IPv4 and IPv6 weight calculations in dir-spec.txt

[Tor Bug Tracker & Wiki]

#28653: Specify IPv4 and IPv6 weight calculations in dir-spec.txt
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-client ipv6 tor-spec
Actual Points:|  Parent ID:  #27647
   Points:|   Reviewer:
  Sponsor:|
--+--
 In #27647, we set the initial IPv6 weight based on the number of entry
 nodes that support IPv4, IPv6, or both.

 We need to specify these calculations.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27648 [Core Tor/Tor]: Stop setting the IPv6 preferred flag on nodes

[Tor Bug Tracker & Wiki]

#27648: Stop setting the IPv6 preferred flag on nodes
-+--
 Reporter:  teor |  Owner:  neel
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client ipv6  |  Actual Points:
Parent ID:  #17835   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by teor):

 * type:  defect => enhancement


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17835 [Core Tor/Tor]: Make ClientPreferIPv6ORPort smarter

[Tor Bug Tracker & Wiki]

#17835: Make ClientPreferIPv6ORPort smarter
-+
 Reporter:  teor |  Owner:  neel
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client ipv6  |  Actual Points:
Parent ID:  #17811   | Points:  medium/large
 Reviewer:   |Sponsor:
-+
Changes (by teor):

 * type:  defect => enhancement


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27492 [Core Tor/Tor]: Try IPv4 or IPv6 more often based on public or private IP addresses

[Tor Bug Tracker & Wiki]

#27492: Try IPv4 or IPv6 more often based on public or private IP addresses
--+--
 Reporter:  neel  |  Owner:  neel
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #17835| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * type:  defect => enhancement


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28057 [Core Tor/Tor]: When randomly choosing IPv4 or IPv6, log better IPv6 preference info

[Tor Bug Tracker & Wiki]

#28057: When randomly choosing IPv4 or IPv6, log better IPv6 preference info
-+
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client ipv6  |  Actual Points:
Parent ID:  #17835   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by teor):

 * type:  defect => enhancement


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28521 [Obfuscation/FTE]: fte is not working using default tor browser bridges

[Tor Bug Tracker & Wiki]

#28521: fte is not working using default tor browser bridges
-+---
 Reporter:  boklm|  Owner:  kpdyer
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/FTE  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by kpdyer):

 Replying to [comment:4 gk]:
 > Replying to [comment:2 kpdyer]:
 > > Yep, I'm the owner for these.
 > >
 > >  - 128.105.214.161 had a hardware failure and is permanently offline.
 >
 > We can delete it from Tor Browser then?

 Yep!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28654 [Core Tor/Tor]: Allow relays to serve future consensuses

[Tor Bug Tracker & Wiki]

#28654: Allow relays to serve future consensuses
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.0.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  bootstrap, clock-skew, tor-guard,
 Severity:  Normal   |  usability, ux, s8-errors, 035-roadmap-subtask,
 |  035-triaged-in-20180711, s8-bootstrap
Actual Points:   |  Parent ID:  #28591
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Like #28591 for clients, we should allow relays to serve future
 consensuses.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26783 [Obfuscation/Snowflake]: Snowflake statistics appear to be broken from something plus mid-June

[Tor Bug Tracker & Wiki]

#26783: Snowflake statistics appear to be broken from something plus mid-June
-+-
 Reporter:  TracTorProjectSucksRightNow  |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Snowflake|Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dcf):

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


Comment:

 I guess these missing days of metrics will remain a mystery.

 I've
 
[https://trac.torproject.org/projects/tor/wiki/doc/MetricsTimeline?action=diff&version=299
 noted it] on the Metrics Timeline.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28655 [Obfuscation/BridgeDB]: If a bridge supports obfs4, don't give out its other flavors

[Tor Bug Tracker & Wiki]

#28655: If a bridge supports obfs4, don't give out its other flavors
--+
 Reporter:  arma  |  Owner:  sysrqb
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor19 |
--+
 There's a FOCI 2018 paper looking at blocking of bridges inside China, and
 one of their conclusions is that China has moved from "block by IP:port"
 to "block to IP":
 https://www.usenix.org/conference/foci18/presentation/dunna

 If that is so, it means that when bridgedb gives out the vanilla ORPort of
 an obfs4 bridge, then some user will get it, try to use it from inside
 China, trigger the active probing, and get the whole IP address blocked --
 including the obfs4 port.

 The fix: when bridgedb gets a bridge that supports an active-probing
 resistant transport (right now that means obfs4), it needs to decide not
 to give out the other transports for that bridge (vanilla ORPort, obfs3,
 etc).

 (There are two caveats for this plan. First, it means we're prioritizing
 obfs4 bridges for the China context, since all of these transports will
 still be useful for countries other than China. I'm ok with that. Second,
 it assumes that the FOCI paper is actually correct in its conclusions
 about how China has changed its blocking. I recall in the Q&A at the end
 of the presentation that some folks questioned the analysis, but I didn't
 follow it enough to form a solid opinion. But even if China isn't doing
 its censorship in this new way yet, now is a great time for bridgedb to
 become able to handle 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

[tor-bugs] #28656 [Core Tor]: Bug: src/feature/nodelist/nodelist.c:2501: compute_frac_paths_available : Non-fatal assertion !(f_exit > 0.0) failed.

[Tor Bug Tracker & Wiki]

#28656: Bug: src/feature/nodelist/nodelist.c:2501: compute_frac_paths_available 
:
Non-fatal assertion !(f_exit > 0.0) failed.
--+--
 Reporter:  meejah|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  Core Tor
  Version:  Tor: unspecified  |   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 I've been running Tor master recently, and saw this. This tor client
 (should have been) mostly idle for the past several days. It would have
 been used to create a bunch of custom circuits and then left alone. I see
 this in the logs:

 {{{
 Nov 28 15:15:31.000 [warn] tor_bug_occurred_(): Bug:
 src/feature/nodelist/nodelist.c:2501: compute_frac_paths_available: Non-
 fatal assertion !(f_exit > 0.0) failed. (on Tor 0.4.0.0-alpha-dev
 469f47ef8dc8b181)
 Nov 28 15:15:31.000 [warn] Bug: Non-fatal assertion !(f_exit > 0.0) failed
 in compute_frac_paths_available at src/feature/nodelist/nodelist.c:2501.
 Stack trace: (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 15:15:31.000 [warn] Bug: ./src/app/tor(log_backtrace_impl+0x47)
 [0x55c0f4988067] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 15:15:31.000 [warn] Bug: ./src/app/tor(tor_bug_occurred_+0xc0)
 [0x55c0f4983630] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 15:15:31.000 [warn] Bug: ./src/app/tor(+0x11ca02)
 [0x55c0f48baa02] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 15:15:31.000 [warn] Bug:
 ./src/app/tor(router_have_minimum_dir_info+0x13f) [0x55c0f48bf3bf] (on Tor
 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 15:15:31.000 [warn] Bug:
 ./src/app/tor(directory_info_has_arrived+0x39) [0x55c0f4807469] (on Tor
 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 15:15:31.000 [warn] Bug:
 ./src/app/tor(connection_dir_reached_eof+0x103a) [0x55c0f487ff0a] (on Tor
 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 15:15:31.000 [warn] Bug:
 ./src/app/tor(connection_handle_read+0x841) [0x55c0f48010e1] (on Tor
 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 15:15:31.000 [warn] Bug: ./src/app/tor(+0x68fde)
 [0x55c0f4806fde] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 15:15:31.000 [warn] Bug: /usr/lib/x86_64-linux-
 gnu/libevent-2.0.so.5(event_base_loop+0x6a0) [0x7fdcfe4455a0] (on Tor
 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 15:15:31.000 [warn] Bug: ./src/app/tor(do_main_loop+0x9d)
 [0x55c0f48083ad] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 15:15:31.000 [warn] Bug: ./src/app/tor(tor_run_main+0x13b3)
 [0x55c0f47f5ae3] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 15:15:31.000 [warn] Bug: ./src/app/tor(tor_main+0x3a)
 [0x55c0f47f2f1a] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 15:15:31.000 [warn] Bug: ./src/app/tor(main+0x19)
 [0x55c0f47f2a99] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 15:15:31.000 [warn] Bug: /lib/x86_64-linux-
 gnu/libc.so.6(__libc_start_main+0xf1) [0x7fdcfd3712e1] (on Tor 0.4.0.0
 -alpha-dev 469f47ef8dc8b181)
 Nov 28 15:15:31.000 [warn] Bug: ./src/app/tor(_start+0x2a)
 [0x55c0f47f2aea] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 16:22:17.000 [notice] Heartbeat: Tor's uptime is 7 days 0:00 hours,
 with 0 circuits open. I've sent 2.66 MB and received 25.15 MB.
 }}}

 On the advice of `#tor-dev` I'm attaching the datadir.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28656 [Core Tor]: Bug: src/feature/nodelist/nodelist.c:2501: compute_frac_paths_available : Non-fatal assertion !(f_exit > 0.0) failed.

[Tor Bug Tracker & Wiki]

#28656: Bug: src/feature/nodelist/nodelist.c:2501: compute_frac_paths_available 
:
Non-fatal assertion !(f_exit > 0.0) failed.
--+--
 Reporter:  meejah|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by meejah):

 * Attachment "bug-datadir.tar.gz" added.

 datadir from the client exhibiting the 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] #28656 [Core Tor]: Bug: src/feature/nodelist/nodelist.c:2501: compute_frac_paths_available : Non-fatal assertion !(f_exit > 0.0) failed.

[Tor Bug Tracker & Wiki]

#28656: Bug: src/feature/nodelist/nodelist.c:2501: compute_frac_paths_available 
:
Non-fatal assertion !(f_exit > 0.0) failed.
--+--
 Reporter:  meejah|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by meejah):

 Some more logs:

 {{{
 Nov 28 09:52:28.000 [warn] tor_bug_occurred_(): Bug:
 src/feature/nodelist/nodelist.c:2501: compute_frac_paths_available: Non-
 fatal assertion !(f_exit > 0.0) failed. (on Tor 0.4.0.0-alpha-dev
 469f47ef8dc8b181)
 Nov 28 09:52:28.000 [warn] Bug: Non-fatal assertion !(f_exit > 0.0) failed
 in compute_frac_paths_available at src/feature/nodelist/nodelist.c:2501.
 Stack trace: (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 09:52:28.000 [warn] Bug: ./src/app/tor(log_backtrace_impl+0x47)
 [0x55c0f4988067] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 09:52:28.000 [warn] Bug: ./src/app/tor(tor_bug_occurred_+0xc0)
 [0x55c0f4983630] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 09:52:28.000 [warn] Bug: ./src/app/tor(+0x11ca02)
 [0x55c0f48baa02] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 09:52:28.000 [warn] Bug:
 ./src/app/tor(router_have_minimum_dir_info+0x13f) [0x55c0f48bf3bf] (on Tor
 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 09:52:28.000 [warn] Bug:
 ./src/app/tor(directory_info_has_arrived+0x39) [0x55c0f4807469] (on Tor
 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 09:52:28.000 [warn] Bug:
 ./src/app/tor(connection_dir_reached_eof+0x103a) [0x55c0f487ff0a] (on Tor
 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 09:52:28.000 [warn] Bug:
 ./src/app/tor(connection_handle_read+0x841) [0x55c0f48010e1] (on Tor
 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 09:52:28.000 [warn] Bug: ./src/app/tor(+0x68fde)
 [0x55c0f4806fde] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 09:52:28.000 [warn] Bug: /usr/lib/x86_64-linux-
 gnu/libevent-2.0.so.5(event_base_loop+0x6a0) [0x7fdcfe4455a0] (on Tor
 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 09:52:28.000 [warn] Bug: ./src/app/tor(do_main_loop+0x9d)
 [0x55c0f48083ad] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 09:52:28.000 [warn] Bug: ./src/app/tor(tor_run_main+0x13b3)
 [0x55c0f47f5ae3] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 09:52:28.000 [warn] Bug: ./src/app/tor(tor_main+0x3a)
 [0x55c0f47f2f1a] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 09:52:28.000 [warn] Bug: ./src/app/tor(main+0x19)
 [0x55c0f47f2a99] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 09:52:28.000 [warn] Bug: /lib/x86_64-linux-
 gnu/libc.so.6(__libc_start_main+0xf1) [0x7fdcfd3712e1] (on Tor 0.4.0.0
 -alpha-dev 469f47ef8dc8b181)
 Nov 28 09:52:28.000 [warn] Bug: ./src/app/tor(_start+0x2a)
 [0x55c0f47f2aea] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 10:22:17.000 [notice] Heartbeat: Tor's uptime is 6 days 18:00
 hours, with 0 circuits open. I've sent 2.63 MB and received 24.48 MB.
 Nov 28 10:22:17.000 [notice] Average packaged cell fullness: 55.959%. TLS
 write overhead: 6%
 Nov 28 11:44:28.000 [warn] tor_bug_occurred_(): Bug:
 src/feature/nodelist/nodelist.c:2501: compute_frac_paths_available: Non-
 fatal assertion !(f_exit > 0.0) failed. (on Tor 0.4.0.0-alpha-dev
 469f47ef8dc8b181)
 Nov 28 11:44:28.000 [warn] Bug: Non-fatal assertion !(f_exit > 0.0) failed
 in compute_frac_paths_available at src/feature/nodelist/nodelist.c:2501.
 Stack trace: (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 11:44:28.000 [warn] Bug: ./src/app/tor(log_backtrace_impl+0x47)
 [0x55c0f4988067] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 11:44:28.000 [warn] Bug: ./src/app/tor(tor_bug_occurred_+0xc0)
 [0x55c0f4983630] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 11:44:28.000 [warn] Bug: ./src/app/tor(+0x11ca02)
 [0x55c0f48baa02] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 11:44:28.000 [warn] Bug:
 ./src/app/tor(router_have_minimum_dir_info+0x13f) [0x55c0f48bf3bf] (on Tor
 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 11:44:28.000 [warn] Bug:
 ./src/app/tor(directory_info_has_arrived+0x39) [0x55c0f4807469] (on Tor
 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 11:44:28.000 [warn] Bug:
 ./src/app/tor(connection_dir_reached_eof+0x103a) [0x55c0f487ff0a] (on Tor
 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 11:44:28.000 [warn] Bug:
 ./src/app/tor(connection_handle_read+0x841) [0x55c0f48010e1] (on Tor
 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 11:44:28.000 [warn] Bug: ./src/app/tor(+0x68fde)
 [0x55c0f4806fde] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
 Nov 28 11:44:28.000 [warn] Bug: /usr/lib/x86_64-linux-
 gnu/libevent-2.0.so.5(event_base_loop+0x6a0) [0x7fdcfe44

Re: [tor-bugs] #28656 [Core Tor]: Bug: src/feature/nodelist/nodelist.c:2501: compute_frac_paths_available : Non-fatal assertion !(f_exit > 0.0) failed.

[Tor Bug Tracker & Wiki]

#28656: Bug: src/feature/nodelist/nodelist.c:2501: compute_frac_paths_available 
:
Non-fatal assertion !(f_exit > 0.0) failed.
--+--
 Reporter:  meejah|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by meejah):

 Full data-dir is here: https://share.riseup.net/#T9BgH8C522wEHEQb3CCsWQ

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28591 [Core Tor/Tor]: Accept a future consensus for bootstrap

[Tor Bug Tracker & Wiki]

#28591: Accept a future consensus for bootstrap
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bootstrap, clock-skew, tor-guard,|  Actual Points:
  usability, ux, s8-errors, 035-roadmap- |
  subtask, 035-triaged-in-20180711,  |
  s8-bootstrap   |
Parent ID:  #23605   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  assigned => needs_review


Comment:

 Here's the pull request:
 https://github.com/torproject/tor/pull/551

 The code is based on #24661 and maint-0.3.5. It also includes #28654. (I'm
 not sure if #28654 is a good idea, but it makes sense to be consistent.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28654 [Core Tor/Tor]: Allow relays to serve future consensuses

[Tor Bug Tracker & Wiki]

#28654: Allow relays to serve future consensuses
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bootstrap, clock-skew, tor-guard,|  Actual Points:
  usability, ux, s8-errors, 035-roadmap- |
  subtask, 035-triaged-in-20180711,  |
  s8-bootstrap   |
Parent ID:  #28591   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Code in #28591.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28655 [Obfuscation/BridgeDB]: If a bridge supports obfs4, don't give out its other flavors

[Tor Bug Tracker & Wiki]

#28655: If a bridge supports obfs4, don't give out its other flavors
--+---
 Reporter:  arma  |  Owner:  sysrqb
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor19
--+---

Comment (by dcf):

 Replying to [ticket:28655 arma]:
 > There's a FOCI 2018 paper looking at blocking of bridges inside China,
 and one of their conclusions is that China has moved from "block by
 IP:port" to "block to IP":
 >
 > Second, it assumes that the FOCI paper is actually correct in its
 conclusions about how China has changed its blocking. I recall in the Q&A
 at the end of the presentation that some folks questioned the analysis,
 but I didn't follow it enough to form a solid opinion. But even if China
 isn't doing its censorship in this new way yet, now is a great time for
 bridgedb to become able to handle it.)

 My, Lynn Tsai's, and Qi Zhong's monitoring of default Tor Browser bridges
 also reached this conclusion, that the GFW changed from single-port
 blocking to all-port blocking (at least for these special bridges). The
 change happened in October 2016.

 https://www.bamsoftware.com/papers/thesis/#sec:china-perport
 https://www.bamsoftware.com/papers/thesis/#sec:china-allports
 > The blocking event of October 20, 2016 was noteworthy not only because
 it occurred before a release, but also because it affected more than one
 port on some bridges. See point ⓗ in
 [https://www.bamsoftware.com/papers/thesis/#fig:proxy-probe-timelines-
 china1 Figure 5.2]. When GreenBelt:7013 was blocked, so were
 GreenBelt:5881 (which had escaped blocking in the previous batch) and
 GreenBelt:12166 (which was awaiting deployment in the next batch).
 Similarly, when MaBishomarim:7920 and JonbesheSabz:4148 were blocked, so
 were the Orbot-reserved MaBishomarim:1984 and JonbesheSabz:1984 (point ⓚ),
 ending an eight-month unblocked streak.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28651 [Obfuscation/Snowflake]: Prepare all pieces of the snowflake pipeline for a second snowflake bridge

[Tor Bug Tracker & Wiki]

#28651: Prepare all pieces of the snowflake pipeline for a second snowflake 
bridge
---+
 Reporter:  arma   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by dcf):

 You could simplify further by removing (A). Don't have every proxy keep a
 whitelist of bridges; rather let it be willing to connect to any address
 the broker gives it. How this would work is: the client sends a bridge
 fingerprint or other identifier to the broker; the broker looks up the
 fingerprint in its own whitelist mapping fingerprint to IP:port; the
 broker gives the IP:port to the proxy.

 What you would lose with this design is a measure of proxies' self-defense
 against a malicious broker. The broker could get a proxy to initiate a
 WebSocket connection to any destination.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28651 [Obfuscation/Snowflake]: Prepare all pieces of the snowflake pipeline for a second snowflake bridge

[Tor Bug Tracker & Wiki]

#28651: Prepare all pieces of the snowflake pipeline for a second snowflake 
bridge
---+
 Reporter:  arma   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by dcf):

 Another design alternative, requiring changes in core tor: let a bridge
 line describe not just a single bridge fingerprint, but a set of them. The
 client is satisfied if any fingerprint in the set matches. The broker (or
 the proxy) knows the current set of bridges, and randomly selects one
 without any control by the client.

 Adding a new bridge to the set would require pushing out new bridge lines
 to users (i.e., making a new Tor Browser release). But if new bridges are
 only needed to increase capacity, that should be a frequent enough pace.

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