Re: [tor-bugs] #32485 [Applications/Tor Browser]: Dead obfs4 Bridges on Tor Browser Android

[Tor Bug Tracker & Wiki]

#32485: Dead obfs4 Bridges on Tor Browser Android
--+--
 Reporter:  torify|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202001  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 Hopefully useful thoughts:

 (A) It is very reasonable that one (or all) of the default obfs4 bridges
 are blocked in your country. China blocks them quickly, and periodically
 we hear reports from places like Venezuela and Peru that they've grabbed
 the list of default bridges and blocked them by IP address.

 (B) You probably want to leave UpdateBridgesFromAuthority alone. It was
 potentially a good design at the beginning, but we never finished building
 it, so it's very unlikely that it will do what you want here.

 (C) You should be sure to watch #30767, the ticket about how custom obfs4
 bridges don't work on Tor Browser Android. This could be your bug right
 here.

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

Re: [tor-bugs] #33066 [Metrics/Website]: metrics dirbytes graph has two "0 Gbit/s" labels on the y axis

[Tor Bug Tracker & Wiki]

#33066: metrics dirbytes graph has two "0 Gbit/s" labels on the y axis
-+--
 Reporter:  arma |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by arma):

 * Attachment "dirbytes-2019-10-29-2020-01-27.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] #33066 [Metrics/Website]: metrics dirbytes graph has two "0 Gbit/s" labels on the y axis

[Tor Bug Tracker & Wiki]

#33066: metrics dirbytes graph has two "0 Gbit/s" labels on the y axis
-+--
 Reporter:  arma |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by arma):

 I attached the downloadable png in case the bug is transient.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33066 [Metrics/Website]: metrics dirbytes graph has two "0 Gbit/s" labels on the y axis

[Tor Bug Tracker & Wiki]

#33066: metrics dirbytes graph has two "0 Gbit/s" labels on the y axis
-+--
 Reporter:  arma |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 https://metrics.torproject.org/dirbytes.png?start=2019-10-29=2020-01-27
 right now has three labels on the y axis: "0 Gbit/s", "0 Gbit/s", and "1
 Gbit/s". That sure is weird.

 Maybe the middle one is actually 0.5, and it gets rounded to zero?

 I guess all sorts of things are possible. :)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33018 [Core Tor/Tor]: Dir auths using an unsustainable 400+ mbit/s, need to diagnose and fix

[Tor Bug Tracker & Wiki]

#33018: Dir auths using an unsustainable 400+ mbit/s, need to diagnose and fix
---+---
 Reporter:  arma   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-health 043-should  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by arma):

 Replying to [comment:3 cypherpunks]:
 > In the Metrics the increase is not seen?
 > http://rougmnvswfsmd4dq.onion/dirbytes.html

 Thanks. I've filed #33065 to investigate.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33065 [Metrics/Website]: metrics dirbytes graph either underreports or leaves out dir auths?

[Tor Bug Tracker & Wiki]

#33065: metrics dirbytes graph either underreports or leaves out dir auths?
-+--
 Reporter:  arma |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 https://metrics.torproject.org/dirbytes.html
 shows that on average about 1gbit/s is spent serving directory
 information.

 But the investigations in #33018 show that moria1 by itself is pushing
 about 135mbit/s, and I hear gabelmoo is doing even more than that.

 The text under the graph says "directory mirrors", so maybe we are leaving
 out dir auths in this graph? In that case, it would be cool to change it
 to one of those layered graphs so you can see how much of the total is dir
 auths and how much of the total are other relays.

 Or maybe we're somehow not adding up the right things? Step zero is to
 spot-check the current data and the current graphs and become convinced
 that indeed we're presenting the right data.

 Originally reported in
 https://trac.torproject.org/projects/tor/ticket/33018#comment: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] #33029 [Core Tor/Tor]: dir-auth: Dir auths should resume sending 503's but never to relays or other dir auths

[Tor Bug Tracker & Wiki]

#33029: dir-auth: Dir auths should resume sending 503's but never to relays or
other dir auths
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth 043-should?  |  Actual Points:
Parent ID:  #33018   | Points:  0.4
 Reviewer:   |Sponsor:
-+

Comment (by arma):

 Replying to [comment:6 teor]:
 > Please check for authority IPv6 addresses. I'm just about to make relays
 use IPv6 to authorities as part of sponsor 55, so we need an IPv6 check
 when we whitelist relays.

 Thanks, teor, this is a great point.

 I actually think I have a better plan that will accomplish your goal and
 the rest of these goals better: let's make sure the dir auth addresses
 (all of them) are added to the bloom filter that
 nodelist_probably_contains_address() checks, and then just only check that
 and we're done. That is, the logic should be: "if we're a dir auth, always
 answer every question from other relays."

 It looks like the ipv6 address for relays gets added properly in
 node_add_to_address_set():
 {{{
 if (!tor_addr_is_null(>rs->ipv6_addr))
   address_set_add(the_nodelist->node_addrs, >rs->ipv6_addr);
 [...]
 if (!tor_addr_is_null(>ri->ipv6_addr))
   address_set_add(the_nodelist->node_addrs, >ri->ipv6_addr);
 [...]
 if (!tor_addr_is_null(>md->ipv6_addr))
   address_set_add(the_nodelist->node_addrs, >md->ipv6_addr);
 }}}

 So the change we would want to make is in or near
 nodelist_set_consensus(), where right after we call
 {{{
   /* Now add all the nodes we have to the address set. */
   SMARTLIST_FOREACH_BEGIN(the_nodelist->nodes, node_t *, node) {
 node_add_to_address_set(node);
   } SMARTLIST_FOREACH_END(node);
 }}}
 we call some similar thing that loops through trusted_dir_servers and
 calls address_set_add() and/or address_set_add_ipv4h() on each known dir
 auth address. That way we get the dir auth addresses in the consensus
 because they are relays, and we get the configured addresses (if
 different) with this new code.

 And then the minor worry in dgoulet's code about "if this shows up in the
 profile, we can move to have an address set instead" gets resolved too
 because it is just one thing we are checking.

 And as a tiny bonus, we handle dir auth addresses as though they are
 relays from the perspective of the DoS module, which is probably a thing
 we should have done from the beginning there anyway.

 Do you buy all of that, dgoulet and teor?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33057 [- Select a component]: Cant use TOR on my macbook catalina

[Tor Bug Tracker & Wiki]

#33057: Cant use TOR on my macbook catalina
--+
 Reporter:  SFactionx |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by SFactionx):

 PROBLEM SOLVED

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33058 [- Select a component]: cant install tor on my macbook

[Tor Bug Tracker & Wiki]

#33058: cant install tor on my macbook
--+
 Reporter:  SFactionx |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by SFactionx):

 Replying to [ticket:33058 SFactionx]:
 > diese fehlermeldung erhalte ich wenn ich den browser installiert habe
 und öffnen will.
 > ein protokoll zum copy-paste gibt es nicht. wenn ich den button unten
 rechts betätige steht im pop-up fenster dass 0 tor-protkollnachrichten
 kopiert wurden. screenshot sende ich anbei


 PROBLEM SOLVED

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32783 [Core Tor/Tor]: Investigate clusterfuzz build failures

[Tor Bug Tracker & Wiki]

#32783: Investigate clusterfuzz build failures
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  network-team-roadmap-2020Q1, |  Actual Points:  .3
  security, technical-debt, tor-ci, 043-should   |
Parent ID:   | Points:  3
 Reviewer:  [upstream]   |Sponsor:
-+-

Comment (by nickm):

 (Clusterfuzz reports that our build is passing)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33006 [Core Tor/Tor]: Fix test-stem `test_take_ownership_via_controller` failure

[Tor Bug Tracker & Wiki]

#33006: Fix test-stem `test_take_ownership_via_controller` failure
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  043-should|  Actual Points:
Parent ID:  #33039| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Can we close this now?  We've merged Taylor's fix for #33039, and Stem has
 merged my PR to fix the test failure message.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33064 [- Select a component]: Can't Play purchased YouTube video due to HTML5 error

[Tor Bug Tracker & Wiki]

#33064: Can't Play purchased YouTube video due to HTML5 error
--+
 Reporter:  maverik89 |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by maverik89):

 * Attachment "screenshot.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] #33033 [Core Tor/sbws]: sbws stuck thinking a destination is dead

[Tor Bug Tracker & Wiki]

#33033: sbws stuck thinking a destination is dead
---+
 Reporter:  tom|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by tom):

 This happened again. I'm testing a local patch that places a max on the
 time to wait and adds more logging.

 Something I have not been able to figure out though, is why I get massive
 number of log messages all on the same thread at the same second. I
 imagine this is part of the problem for why the failure cascades so
 quickly...

 {{{
 Jan 26 14:18:32 WARNING Thread-4 destination.py:245 - is_functional -
 Please, add more destinations or increment the number of maximum number of
 consecutive failures in the configuration.
 Jan 26 14:18:32 WARNING Thread-3 destination.py:244 - is_functional - The
 last 9 times the destination https://bw.bwauth.domain/1G failed.Disabled
 for 5120.0 minutes.
 Jan 26 14:18:32 WARNING Thread-3 destination.py:245 - is_functional -
 Please, add more destinations or increment the number of maximum number of
 consecutive failures in the configuration.
 Jan 26 14:18:32 WARNING Thread-4 destination.py:244 - is_functional - The
 last 9 times the destination https://bw.bwauth.domain/1G failed.Disabled
 for 5120.0 minutes.
 Jan 26 14:18:32 WARNING Thread-4 destination.py:245 - is_functional -
 Please, add more destinations or increment the number of maximum number of
 consecutive failures in the configuration.
 Jan 26 14:18:32 WARNING Thread-3 destination.py:244 - is_functional - The
 last 9 times the destination https://bw.bwauth.domain/1G failed.Disabled
 for 5120.0 minutes.
 Jan 26 14:18:32 WARNING Thread-3 destination.py:245 - is_functional -
 Please, add more destinations or increment the number of maximum number of
 consecutive failures in the configuration.
 Jan 26 14:18:32 WARNING Thread-4 destination.py:244 - is_functional - The
 last 9 times the destination https://bw.bwauth.domain/1G failed.Disabled
 for 5120.0 minutes.
 Jan 26 14:18:32 WARNING Thread-4 destination.py:245 - is_functional -
 Please, add more destinations or increment the number of maximum number of
 consecutive failures in the configuration.
 Jan 26 14:18:32 WARNING Thread-3 destination.py:244 - is_functional - The
 last 9 times the destination https://bw.bwauth.domain/1G failed.Disabled
 for 5120.0 minutes.
 Jan 26 14:18:32 WARNING Thread-3 destination.py:245 - is_functional -
 Please, add more destinations or increment the number of maximum number of
 consecutive failures in the configuration.
 Jan 26 14:18:32 WARNING Thread-4 destination.py:244 - is_functional - The
 last 9 times the destination https://bw.bwauth.domain/1G failed.Disabled
 for 5120.0 minutes.
 Jan 26 14:18:32 WARNING Thread-4 destination.py:245 - is_functional -
 Please, add more destinations or increment the number of maximum number of
 consecutive failures in the configuration.
 Jan 26 14:18:32 WARNING Thread-3 destination.py:244 - is_functional - The
 last 9 times the destination https://bw.bwauth.domain/1G failed.Disabled
 for 5120.0 minutes.
 Jan 26 14:18:32 WARNING Thread-3 destination.py:245 - is_functional -
 Please, add more destinations or increment the number of maximum number of
 consecutive failures in the configuration.
 Jan 26 14:18:32 WARNING Thread-4 destination.py:244 - is_functional - The
 last 9 times the destination https://bw.bwauth.domain/1G failed.Disabled
 for 5120.0 minutes.
 Jan 26 14:18:32 WARNING Thread-4 destination.py:245 - is_functional -
 Please, add more destinations or increment the number of maximum number of
 consecutive failures in the configuration.
 Jan 26 14:18:32 WARNING Thread-3 destination.py:244 - is_functional - The
 last 9 times the destination https://bw.bwauth.domain/1G failed.Disabled
 for 5120.0 minutes.
 Jan 26 14:18:32 WARNING Thread-3 destination.py:245 - is_functional -
 Please, add more destinations or increment the number of maximum number of
 consecutive failures in the configuration.
 Jan 26 14:18:32 WARNING Thread-4 destination.py:244 - is_functional - The
 last 9 times the destination https://bw.bwauth.domain/1G failed.Disabled
 for 5120.0 minutes.
 Jan 26 14:18:32 WARNING Thread-4 destination.py:245 - is_functional -
 Please, add more destinations or increment the number of maximum number of
 consecutive failures in the configuration.
 Jan 26 14:18:32 WARNING Thread-3 destination.py:244 - is_functional - The
 last 9 times the destination https://bw.bwauth.domain/1G failed.Disabled
 for 5120.0 minutes.
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 

[tor-bugs] #33064 [- Select a component]: Can't Play purchased YouTube video due to HTML5 error

[Tor Bug Tracker & Wiki]

#33064: Can't Play purchased YouTube video due to HTML5 error
---+--
 Reporter:  maverik89  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Component:  - Select a component
  Version: |   Severity:  Normal
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 I am on the latest Tor browser and I have a problem with playing purchased
 videos from YouTube, all other Youtube videos load fine but when trying to
 play a purchased video this message pops up

 "Your browser does not currently recognize any of the video formats
 available. Click here to visit frequently asked questions about HTML5
 video"

 So not sure what to do?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30733 [Core Tor/sbws]: sbws does not detect changes in descriptor bandwidth values

[Tor Bug Tracker & Wiki]

#30733: sbws does not detect changes in descriptor bandwidth values
-+-
 Reporter:  starlight|  Owner:  juga
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:  sbws:
 |  1.1.0
 Severity:  Critical | Resolution:
 Keywords:  sbws-majority-blocker, sbws- |  Actual Points:
  roadmap-august |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by juga):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:35 juga]:
 > When #30909 is merged, this ticket can be closed, since the remaining
 child tickets, #30747 and #30908 have been solved.

 I went through all the thread and realized there was a PR associated to
 this ticket:

 Replying to [comment:23 teor]:
 > I did a review of this pull request: the code looks good, but one of the
 comments is wrong.
 >
 > See my comment on the pull request:
 >
 
https://github.com/torproject/sbws/pull/358/commits/2b3860678595dc8a1f26ab93bc6cef54fe796a7d#r294117174

 I squashed that PR, changed comments, cherry-picked the commits created
 other PR based on `maint-1.1`:
 https://github.com/torproject/sbws/pull/362

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30727 [Core Tor/sbws]: Make sbws vote for all measured relays, even if they are not Running / not in the consensus

[Tor Bug Tracker & Wiki]

#30727: Make sbws vote for all measured relays, even if they are not Running / 
not
in the consensus
-+-
 Reporter:  teor |  Owner:  juga
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:  sbws:
 |  1.1.0
 Severity:  Critical | Resolution:
 Keywords:  must-keep-3-torflow-blocker, sbws-   |  Actual Points:
  majority-blocker   |
Parent ID:  #29710   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by juga):

 See https://github.com/torproject/sbws/pull/361

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30727 [Core Tor/sbws]: Make sbws vote for all measured relays, even if they are not Running / not in the consensus

[Tor Bug Tracker & Wiki]

#30727: Make sbws vote for all measured relays, even if they are not Running / 
not
in the consensus
-+-
 Reporter:  teor |  Owner:  juga
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:  sbws:
 |  1.1.0
 Severity:  Critical | Resolution:
 Keywords:  must-keep-3-torflow-blocker, sbws-   |  Actual Points:
  majority-blocker   |
Parent ID:  #29710   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by juga):

 * status:  assigned => needs_review


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

[tor-bugs] #33063 [Applications]: Circuit keeps changing for about 4 times after manually requesting a circuit change. Result: Can't view videos from sites that are censored in many countries

[Tor Bug Tracker & Wiki]

#33063: Circuit keeps changing for about 4 times after manually requesting a
circuit change. Result: Can't view videos from sites that are censored in
many countries
--+--
 Reporter:  oo7   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  Applications
  Version:  Tor: 0.4.2.5  |   Severity:  Normal
 Keywords:  circuit   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 Title.
 When I try to watch a video on a site that's blocked in many countries, I
 manually change the circuit until it the video loads. But the circuits
 keep changing so the video can't be played unless you're very lucky.

 How to reproduce: Establish a new circuit when viewing a website (to see
 that it keeps changing by itself for about 4 times).
 If you need it, I can tell you the website which is most affevted by it
 from my user experience. But I'm quite sure it's caused by the unwanted
 auto-changing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30909 [Core Tor/sbws]: sbws consensus timestamp updates incorrectly use the current time

[Tor Bug Tracker & Wiki]

#30909: sbws consensus timestamp updates incorrectly use the current time
+---
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws   |Version:  sbws: 1.1.0
 Severity:  Normal  | Resolution:  fixed
 Keywords:  sbws-ci-fail-sometimes  |  Actual Points:  0.2
Parent ID:  #30733  | Points:  0.2
 Reviewer:  juga|Sponsor:
+---
Changes (by juga):

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


Comment:

 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

[tor-bugs] #33062 [Internal Services/Tor Sysadmin Team]: investigate kreb's advice on DNS hijacking

[Tor Bug Tracker & Wiki]

#33062: investigate kreb's advice on DNS hijacking
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major|   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 After reviewing [https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-
 recent-widespread-dns-hijacking-attacks/ this article about recent DNS
 hijacking incidents], I think it might be worth reviewing the
 recommendations given in the article, which are basically:

  1. [x] use DNSSEC
  2. [ ] Use registration features like Registry Lock that can help protect
 domain names records from being changed
  3. [ ] Use access control lists for applications, Internet traffic and
 monitoring
  4. [ ] Use 2-factor authentication, and require it to be used by all
 relevant users and subcontractors
  5. [x] In cases where passwords are used, pick unique passwords and
 consider password managers
  6. [ ] Review accounts with registrars and other providers
  7. [ ] Monitor certificates by monitoring, for example, Certificate
 Transparency Logs

 Some of those are impractical: for example 2FA will not work for us if we
 have one shared account with a provider.

 Others have already been done: we have a good DNSSEC deployment and manage
 passwords properly.

 Mainly, I'm curious about investigating Registry lock and CT logs
 monitoring, the latter which could be added as a Nagios thing, maybe.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33061 [Metrics/CollecTor]: archived bandwidth scanner files lack explicit source attibution

[Tor Bug Tracker & Wiki]

#33061: archived bandwidth scanner files lack explicit source attibution
---+---
 Reporter:  starlight  |  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Component:  Metrics/CollecTor
  Version: |   Severity:  Normal
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
 Current files in

 https://collector.torproject.org/archive/relay-descriptors/bandwidths/
 https://collector.torproject.org/recent/relay-descriptors/bandwidths/

 lack indication of which bandwidth scanner generated them.  (files
 archived from Tom's collection are attributed)

 Collect these files here and abandoned an attempt to fill a gap due to
 this issue.  Ad-hoc logic to bin them may be possible but is not trivial.
 Can provide attribution by sha256 digest for most of them if the file
 naming is improved.

 original ticket #21378

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30733 [Core Tor/sbws]: sbws does not detect changes in descriptor bandwidth values

[Tor Bug Tracker & Wiki]

#30733: sbws does not detect changes in descriptor bandwidth values
-+-
 Reporter:  starlight|  Owner:  juga
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:  sbws:
 |  1.1.0
 Severity:  Critical | Resolution:
 Keywords:  sbws-majority-blocker, sbws- |  Actual Points:
  roadmap-august |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by juga):

 When #30909 is merged, this ticket can be closed, since the remaining
 child tickets, #30747 and #30908 have been solved.
 Other previous comments are part of other tickets, like #30067
 (#comment:31) and not this one.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30909 [Core Tor/sbws]: sbws consensus timestamp updates incorrectly use the current time

[Tor Bug Tracker & Wiki]

#30909: sbws consensus timestamp updates incorrectly use the current time
+---
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws   |Version:  sbws: 1.1.0
 Severity:  Normal  | Resolution:
 Keywords:  sbws-ci-fail-sometimes  |  Actual Points:  0.2
Parent ID:  #30733  | Points:  0.2
 Reviewer:  juga|Sponsor:
+---
Changes (by juga):

 * status:  needs_revision => merge_ready


Comment:

 Replying to [comment:3 juga]:
 > I realized about other bug, fixed in
 https://github.com/juga0/sbws/commits/bug30909_11.
 > I'm not sure which the workflow should be here, so just changing this
 ticket to needs review, but not doing PR nor assigning reviewer.

 Since this ticket is blocking #30733 and the potential bug it's not
 related to teor's patch, i've created #33060 for it and changing this one
 to merge ready.

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

Re: [tor-bugs] #33060 [Core Tor/sbws]: Check that consensus timestamp lists is initialied and has at list one item

[Tor Bug Tracker & Wiki]

#33060: Check that consensus timestamp lists is initialied and has at list one 
item
---+---
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.1.0
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:  0.1
 Reviewer: |Sponsor:
---+---

Comment (by juga):

 Work in https://github.com/juga0/sbws/tree/maint-1.1_bug33060. Not
 changing ticket to needs review cause this is not a blocking 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

[tor-bugs] #33060 [Core Tor/sbws]: Check that consensus timestamp lists is initialied and has at list one item

[Tor Bug Tracker & Wiki]

#33060: Check that consensus timestamp lists is initialied and has at list one 
item
---+---
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.1.0
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points:  0.1|   Reviewer:
  Sponsor: |
---+---
 Working on #30909 realized that even if I realized that when checking ` if
 len(self._consensus_timestamps) >= 1`, in the case that
 `self._consensus_timestamps` wouldn't not be initialized, it'd give a type
 error.
 That doesn't currently happen because that code is call after the
 `__init__` method. It'd still be safer to to check that it's been
 initialized.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33008 [Metrics/Relay Search]: Display a bridge's distribution bucket

[Tor Bug Tracker & Wiki]

#33008: Display a bridge's distribution bucket
--+---
 Reporter:  phw   |  Owner:  metrics-team
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:  s30-o24a1 |  Actual Points:
Parent ID:  #31281| Points:  3
 Reviewer:|Sponsor:  Sponsor30-can
--+---
Changes (by karsten):

 * status:  new => needs_review


Comment:

 Okay, if it's just the distributor bucket/strategy that we want to
 display, the Onionoo side is relatively simple. Please review
 [https://gitweb.torproject.org/user/karsten/metrics-
 web.git/commit/?h=task-33008=633aa3ed1727ca986dd4f193a2d8b9f993c202a9
 commit 633aa3e in my metrics-web task-33008 branch for step 2 above] and
 
[https://gitweb.torproject.org/user/karsten/onionoo.git/commit/?h=task-33008=ff2db949e57f35df8cfffe691e2caeece8fdeccc
 commit ff2db94 in my Onionoo task-33008 branch for step 3 above].

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33059 [Applications/Tor Browser]: Adds "quit" besides "new identity" in Tor Browser mobile notification

[Tor Bug Tracker & Wiki]

#33059: Adds "quit" besides "new identity" in Tor Browser mobile notification
-+--
 Reporter:  uhdv |  Owner:  tbb-team
 Type:  enhancement  | Status:  new
 Priority:  Low  |  Component:  Applications/Tor Browser
  Version:   |   Severity:  Trivial
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 All in the title

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33026 [Applications/Tor Browser]: Problem using obfs4 on Android arm64: executable's TLS segment is underaligned

[Tor Bug Tracker & Wiki]

#33026: Problem using obfs4 on Android arm64: executable's TLS segment is
underaligned
--+---
 Reporter:  uhdv  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by uhdv):

 @boklm

 10

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33054 [Applications/Tor Browser]: TorBrowser gets more captchas than Firefox when using it without Tor

[Tor Bug Tracker & Wiki]

#33054: TorBrowser gets more captchas than Firefox when using it without Tor
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 `privacy.resistFingerprinting` is the cause. There is no cure.

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