Re: [tor-bugs] #31223 [Core Tor/Tor]: Research approaches for improving the availability of services under DoS

[Tor Bug Tracker & Wiki]

#31223: Research approaches for improving the availability of services under DoS
+
 Reporter:  asn |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs tor-dos  |  Actual Points:
Parent ID:  #2  | Points:  15
 Reviewer:  |Sponsor:  Sponsor27-must
+

Comment (by vinay):

 Things to consider:
 * MTP 1.2
 * Combination of hashing with arbitrary-precision computation as in GMP
 (easiest on general-purpose CPUs)

--
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] #31730 [Applications/Tor Browser]: Revert aarch64 fixup for ESR 60-based bundles with Tor Browser 9

[Tor Bug Tracker & Wiki]

#31730: Revert aarch64 fixup for ESR 60-based bundles with Tor Browser 9
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-parity,  |  Actual Points:
  TorBrowserTeam201910, tbb-9.0-must |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 The security level is set automatically both back and forth.

--
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] #31704 [Community/Tor Support]: help

[Tor Bug Tracker & Wiki]

#31704: help
---+--
 Reporter:  kain3e |  Owner:  ggus
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by ggus):

 Hello, please provide more details, e.g. operating system, Tor browser
 version.

 You might want to try these instructions: https://tb-manual.torproject.org
 /known-issues/

--
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] #31572 [Applications/Tor Browser]: Extension errors after a while of surfing with Tor Browser based on ESR68

[Tor Bug Tracker & Wiki]

#31572: Extension errors after a while of surfing with Tor Browser based on 
ESR68
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff68-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 #27413?

--
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] #31506 [Applications/Tor Browser]: Write up comprehensive advice to "Tor unexpectedly exited", and link to it from inside Tor Browser

[Tor Bug Tracker & Wiki]

#31506: Write up comprehensive advice to "Tor unexpectedly exited", and link to 
it
from inside Tor Browser
--+--
 Reporter:  arma  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by ggus):

 * keywords:  docshackathon =>


--
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] #31732 [Applications/Tor Browser]: Windows nightly build failure

[Tor Bug Tracker & Wiki]

#31732: Windows nightly build failure
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201909,   |  Actual Points:
  GeorgKoppen201909  |
Parent ID:  #30322   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 I guess that's https://bugzilla.mozilla.org/show_bug.cgi?id=1577872#c14. I
 think we should switch to what Mozilla is using. I prepare a patch and
 test it shortly.

--
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] #31685 [Circumvention/Snowflake]: Snowflake : ON/OFF switch

[Tor Bug Tracker & Wiki]

#31685: Snowflake : ON/OFF switch
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Trivial  | Resolution:
 Keywords:  snowflake-ux |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cypherpunks):

 When the switch is enabled, I expect to read "ON" and not "(turn) OFF".
 It can be confusing :/

--
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] #30682 [Applications/Tor Browser]: Adapt Intermediate Preloading for Tor Browser

[Tor Bug Tracker & Wiki]

#30682: Adapt Intermediate Preloading for Tor Browser
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff68-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor44-can
--+---

Comment (by acat):

 We could place the bundle in `services/settings/dumps/main/`
 (https://searchfox.org/mozilla-
 
esr68/rev/8d7d1cd37b45b4cb0a512234537d0e950d30a547/services/common/docs/RemoteSettings.rst#154)
 but I think that to use it while avoiding the remote fetch/sync would
 require some patching.

--
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] #31718 [Internal Services/Tor Sysadmin Team]: Update DNS records for .ooni.torproject.org domains

[Tor Bug Tracker & Wiki]

#31718: Update DNS records for .ooni.torproject.org domains
-+-
 Reporter:  hellais  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Another option, if we don't like having .torproject.org sites running on
 non-TPA machines, would be to run a tiny webserver as the .torproject.org
 site, which sends an http-level redirect to the external site?

 I mention it because that http redirect is happening now already, just on
 the remote site.

--
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] #31575 [Applications/Tor Browser]: Firefox is phoning home during start-up in Tor Browser based on ESR 68

[Tor Bug Tracker & Wiki]

#31575: Firefox is phoning home during start-up in Tor Browser based on ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201909   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201909R =>
 ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201909
 * status:  needs_information => needs_revision


Comment:

 If we's go that route then we should rip the code out not comment it
 because the latter makes it harder to figure out what part is actually a
 comment and what part is just code we don't use due to a patch. Let's use
 commenting just for comments.

 So, marking that as `needs revision` either way.

--
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] #31303 [Applications/Tor Browser]: Browser Toolboxfails to open when tor-launcher is present

[Tor Bug Tracker & Wiki]

#31303: Browser Toolboxfails to open when tor-launcher is present
--+---
 Reporter:  pospeselr |  Owner:  pospeselr
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201909  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+---

Comment (by acat):

 Should this be tbb-9.0-must-alpha? Without this inspecting the background
 requests and debugging is a bit more difficult...

--
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] #31538 [Applications/Tor Browser]: Windows bundles based on ESR 68 are not built reproducibly

[Tor Bug Tracker & Wiki]

#31538: Windows bundles based on ESR 68 are not built reproducibly
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  alpha, TorBrowserTeam201909R,  |
  GeorgKoppen201909  |
Parent ID:  #30322   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  new => needs_review
 * keywords:
 tbb-rbm, ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201909,
 GeorgKoppen201909
 =>
 tbb-rbm, ff68-esr, tbb-9.0-must-alpha, TorBrowserTeam201909R,
 GeorgKoppen201909


Comment:

 `bug_31538_v2` (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/log/?h=bug_31538_v2) has wo patches for review (on top of
 #31732), which should fix the problem. I rebuilt the macOS bundles as well
 and they are still matching. Doing currently Linux.

--
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] #31652 [Core Tor/Tor]: hs-v3: Service circuit retry limit should not close a valid circuit

[Tor Bug Tracker & Wiki]

#31652: hs-v3: Service circuit retry limit should not close a valid circuit
-+-
 Reporter:  dgoulet  |  Owner:  neel
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-circuit, 042-should  |  Actual Points:
Parent ID:  #30200   | Points:  0.1
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor27-must
-+-
Changes (by neel):

 * status:  needs_revision => 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

Re: [tor-bugs] #31303 [Applications/Tor Browser]: Browser Toolboxfails to open when tor-launcher is present

[Tor Bug Tracker & Wiki]

#31303: Browser Toolboxfails to open when tor-launcher is present
-+-
 Reporter:  pospeselr|  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201909, tbb-9.0-must-  |  Actual Points:
  alpha  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by pospeselr):

 I thought this was going to be a blocker for me in doing #31286, but I
 discovered that since (most of) the code I'm dealing with is in
 about:preferences so the regular in-page debugging tools work fine so I'm
 not actively working on this.

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

Re: [tor-bugs] #27175 [Applications/Tor Browser]: NoScript plugin does not save per-site permissions/settings when tor browser closes

[Tor Bug Tracker & Wiki]

#27175: NoScript plugin does not save per-site permissions/settings when tor
browser closes
-+-
 Reporter:  tor-user-1234|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:  sbws:
 |  unspecified
 Severity:  Normal   | Resolution:  fixed
 Keywords:  noscript, tbb-regression,|  Actual Points:
  tbb-8.0-issues, TorBrowserTeam201809R, tbb-|
  backported |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 For those reading this ticket in the far future: go to about:config and
 set your extensions.torbutton.noscript_persist option. But be aware of the
 risks, 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] #31303 [Applications/Tor Browser]: Browser Toolboxfails to open when tor-launcher is present

[Tor Bug Tracker & Wiki]

#31303: Browser Toolboxfails to open when tor-launcher is present
-+-
 Reporter:  pospeselr|  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201909, tbb-9.0-must-  |  Actual Points:
  alpha  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  TorBrowserTeam201909 => TorBrowserTeam201909, tbb-9.0-must-
   alpha


Comment:

 Replying to [comment:4 acat]:
 > Should this be tbb-9.0-must-alpha? Without this inspecting the
 background requests and debugging is a bit more difficult...

 If that is slowing down fixing the "real" esr68 issues, sure let's fix
 this quickly.

--
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] #29646 [Applications/Tor Browser]: NoScript XSS user choices are persisted

[Tor Bug Tracker & Wiki]

#29646: NoScript XSS user choices are persisted
-+-
 Reporter:  atac |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-disk-leak xss noscript tbb-  |  Actual Points:
  newnym ux-team |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by antonela):

 Maybe regular users want persistent NoScript options because setting those
 each time you open the browser, is annoying.

 https://trac.torproject.org/projects/tor/ticket/27175

--
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] #31735 [Core Tor/Tor]: Exit and join all threads, before destroying any mutexes in the main thread

[Tor Bug Tracker & Wiki]

#31735: Exit and join all threads, before destroying any mutexes in the main 
thread
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.2.x-final
Component:  Core |Version:  Tor: 0.3.5.1-alpha
  Tor/Tor|   Keywords:  consider-backport-after-042-stable,
 Severity:  Normal   |  consider-backport-if-needed, diagnostics,
 |  042-should, 035-backport-maybe, 040-backport-
 |  maybe, 041-backport-maybe, regression,
 |  BugSmashFund
Actual Points:   |  Parent ID:  #31614
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Otherwise, the mutex could be locked by another thread, and destroying a
 locked mutex triggers undefined behaviour.

 Part of #31614.

--
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] #29399 [Internal Services/Tor Sysadmin Team]: Retire host and services for tordnsel and check (chiwui) (was: Retire host and services for tordnsel and check)

[Tor Bug Tracker & Wiki]

#29399: Retire host and services for tordnsel and check (chiwui)
-+-
 Reporter:  ln5  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #31686   | 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] #31685 [Circumvention/Snowflake]: Snowflake : ON/OFF switch

[Tor Bug Tracker & Wiki]

#31685: Snowflake : ON/OFF switch
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Trivial  | Resolution:
 Keywords:  snowflake-ux |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cohosh):

 Replying to [comment:3 cypherpunks]:
 > When the switch is enabled, I expect to read "ON" and not "(turn) OFF".
 > It can be confusing :/

 Thanks for the input cypherpunks!

 I'd like to get antonela's feedback on this. I'm worried that terminology
 like "State" makes more sense with a computer science background and can
 be confusing for users unfamiliar with coding or things like state
 machines.

 I can see your point on how it could be more immediately clear to see
 simply "ON" or "OFF" with a toggle that changes it, but I don't have a
 background in UX. Are the other visual indicators (colour of snowflake,
 additional text above the toggle) useful?

--
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] #31718 [Internal Services/Tor Sysadmin Team]: Update DNS records for .ooni.torproject.org domains

[Tor Bug Tracker & Wiki]

#31718: Update DNS records for .ooni.torproject.org domains
-+-
 Reporter:  hellais  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 hellais, do you want an actual CNAME (ie. that the user doesn't know they
 get redirected to ooni) or a redirect (that the user *does* end up on
 ooni.io)?

 i do agree that it's unconventional to do those things for us. we usually
 point *.torproject.net at external resources.

 is this domain used by non-HTTP clients?

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

Re: [tor-bugs] #30126 [Applications/Tor Browser]: Make Tor Browser on macOS compatible with Apple's notarization

[Tor Bug Tracker & Wiki]

#30126: Make Tor Browser on macOS compatible with Apple's notarization
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  task| Status:  closed
 Priority:  Very High   |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tbb-security, TorBrowserTeam201909  |  Actual Points:  5.5
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:
+--
Changes (by mcs):

 * actualpoints:  2.5 => 5.5


--
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] #31732 [Applications/Tor Browser]: Windows nightly build failure

[Tor Bug Tracker & Wiki]

#31732: Windows nightly build failure
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201909R,  |  Actual Points:  0.1
  GeorgKoppen201909  |
Parent ID:  #30322   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  new => needs_review
 * keywords:  tbb-rbm, TorBrowserTeam201909, GeorgKoppen201909 => tbb-rbm,
 TorBrowserTeam201909R, GeorgKoppen201909
 * actualpoints:   => 0.1


Comment:

 `bug_31732` (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_31732=554d1014079a9d83586759ee92280c8b094e682a)
 in my `tor-browser-build` repo has a fix for this bug. We follow Mozilla
 in the commit we use which seems to be smarter. :)

--
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] #31734 [Core Tor/Tor]: Add accessor functions for cb_buf, which enforce locking and unlocking

[Tor Bug Tracker & Wiki]

#31734: Add accessor functions for cb_buf, which enforce locking and unlocking
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.2.x-final
Component:  Core |Version:  Tor: 0.3.5.1-alpha
  Tor/Tor|   Keywords:  consider-backport-after-042-stable,
 Severity:  Normal   |  consider-backport-if-needed, diagnostics,
 |  042-should, 035-backport-maybe, 040-backport-
 |  maybe, 041-backport-maybe, regression,
 |  BugSmashFund
Actual Points:   |  Parent ID:  #31614
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Part of #31614

--
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] #30683 [Applications/Tor Browser]: Properties in dom/locales/$lang/chrome/ allow detecting user locale

[Tor Bug Tracker & Wiki]

#30683: Properties in dom/locales/$lang/chrome/ allow detecting user locale
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-locale,   |  Actual Points:
  TorBrowserTeam201909R  |
Parent ID:   | Points:  0.25
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-fingerprinting-locale, TorBrowserTeam201909 => tbb-
 fingerprinting-locale, TorBrowserTeam201909R


--
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] #31736 [Core Tor/Tor]: Stop using mutex_destroy(), when multiple threads can still access the mutex

[Tor Bug Tracker & Wiki]

#31736: Stop using mutex_destroy(), when multiple threads can still access the
mutex
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.2.x-final
Component:  Core |Version:  Tor: 0.3.5.1-alpha
  Tor/Tor|   Keywords:  consider-backport-after-042-stable,
 Severity:  Normal   |  consider-backport-if-needed, diagnostics,
 |  042-should, 035-backport-maybe, 040-backport-
 |  maybe, 041-backport-maybe, regression,
 |  BugSmashFund
Actual Points:   |  Parent ID:  #31614
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Part of #31614, alternative to #31735.

 If we can't join all the threads before destroying a mutex (#31735), and
 we can't otherwise prevent multiple thread access, we should stop
 destroying that mutex. (Because destroying a locked thread invokes
 undefined behaviour.)

 There may be some other pattern that helps us destroy all but one mutex.
 But that involves a "mutex-destruction" mutex. Which is terribly complex.

--
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] #31685 [Circumvention/Snowflake]: Snowflake : ON/OFF switch

[Tor Bug Tracker & Wiki]

#31685: Snowflake : ON/OFF switch
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Trivial  | Resolution:
 Keywords:  snowflake-ux |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by antonela):

 Major design systems recommend avoiding using OFF/ON in the switcher since
 the UI component already reflects that status, especially for preventing
 this kind of confusion.

 We can use a label that doesn't describe the values of a switch: what if
 we use `Status` or something close to it?

 https://material.io/components/selection-controls/#switches
 https://developer.apple.com/design/human-interface-
 guidelines/ios/controls/switches/

--
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] #31575 [Applications/Tor Browser]: Firefox is phoning home during start-up in Tor Browser based on ESR 68

[Tor Bug Tracker & Wiki]

#31575: Firefox is phoning home during start-up in Tor Browser based on ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201909R  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_review => needs_information


Comment:

 Replying to [comment:3 acat]:
 > Patch for review in https://github.com/acatarineu/tor-
 browser/commits/31575 (two commits).
 >
 > I investigated a bit where these requests where coming from, and all are
 from the newtab ActivityStream. The first ones (containing cfr-fxa) are
 done in [https://searchfox.org/mozilla-
 
esr68/rev/5c4a430c9101024114854f47926fdfacc5502294/browser/components/newtab/lib/ASRouter.jsm#238
 ASRouter.jsm], which calls [https://searchfox.org/mozilla-
 
esr68/rev/5c4a430c9101024114854f47926fdfacc5502294/services/settings/RemoteSettingsClient.jsm#254
 RemoteSettingsClient.jsm] and that does a bunch of fetches to sync. The
 snippets ones are coming from [https://searchfox.org/mozilla-
 
esr68/rev/5c4a430c9101024114854f47926fdfacc5502294/browser/components/newtab/lib/ASRouter.jsm#170
 ASRouter.jsm].
 >
 > There are a bunch of `browser.newtabpage.activity-stream.*` prefs that
 probably we could use to disable these, but I opted for the simple
 solution of just not loading the `AboutNewTab.jsm` at all. That means it's
 not possible anymore to change the newtab page, so I also removed that
 option from the UI in the patch.

 Hrm. I am not sure we should strip users from easily adjusting their new
 tab experience. Would we solve this bug by just flipping the prefs? I
 guess that would still fix #30846 as well? What about #30662?

--
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] #31739 [Applications/Tor Browser]: TBB 9.0a6 Issues with Cloudflare

[Tor Bug Tracker & Wiki]

#31739: TBB 9.0a6 Issues with Cloudflare
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  High |  Component:  Applications/Tor
 |  Browser
  Version:   |   Severity:  Trivial
 Keywords:  tbb-must-alpha,  |  Actual Points:
  ff68-esr   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
 UA has changed again so Cloudflare will likely need to be pinged. alt-svc
 no longer redirects to their transparent onions, and reCAPTCHA returns
 consistently on ESR68.

--
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] #31732 [Applications/Tor Browser]: Windows nightly build failure

[Tor Bug Tracker & Wiki]

#31732: Windows nightly build failure
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-rbm, TorBrowserTeam201909R,  |  Actual Points:  0.1
  GeorgKoppen201909  |
Parent ID:  #30322   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

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


Comment:

 Replying to [comment:3 gk]:
 > `bug_31732` (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_31732=554d1014079a9d83586759ee92280c8b094e682a)
 in my `tor-browser-build` repo has a fix for this bug. We follow Mozilla
 in the commit we use which seems to be smarter. :)

 This looks good to me. I merged it to master as commit
 `554d1014079a9d83586759ee92280c8b094e682a`.

--
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] #31681 [Community/Tor Support]: virus

[Tor Bug Tracker & Wiki]

#31681: virus
---+--
 Reporter:  bill   |  Owner:  ggus
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:
Component:  Community/Tor Support  |Version:  Tor: 0.4.1.5
 Severity:  Normal | Resolution:  not a bug
 Keywords:  trojan |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by ggus):

 * status:  new => closed
 * resolution:   => not a bug


Comment:

 Hi, probably is a false positive and you will need to change your
 antivirus settings.

 See [https://forums.malwarebytes.com/topic/198973-tor-browser-being-
 blocked/ here] and [https://forums.malwarebytes.com/topic/206614-can-not-
 get-tor-browser-to-work/ here].

 If you want to be extra cautious and make sure your Tor Browser is good,
 download from the https://www.torproject.org/download and verify the file
 signature following these instructions:
 https://support.torproject.org/tbb/how-to-verify-signature/

--
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] #31293 [Applications/Tor Browser]: tor-android-service gradle failure when probing network interfaces

[Tor Bug Tracker & Wiki]

#31293: tor-android-service gradle failure when probing network interfaces
---+--
 Reporter:  sysrqb |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201908  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cohosh):

 * cc: cohosh (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] #31296 [Webpages/Support]: simplify OpenPGP signature verification instructions

[Tor Bug Tracker & Wiki]

#31296: simplify OpenPGP signature verification instructions
--+--
 Reporter:  dkg   |  Owner:  ggus
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Webpages/Support  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by monmire):

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


Comment:

 Platform: Tor Browser 8.5.5 on macOS Mojave version 10.14.6

 Instructions in the current Support documentation for macOS users
 https://support.torproject.org/tbb/how-to-verify-signature/ causes
 attempts to verify the signature to fail.

 The examples below assume that the macOS user has downloaded the files to
 the "Downloads" folder.

 Terminal command

 `gpg --verify ~/Downloads/TorBrowser-8.5.5-osx64_en-US.dmg.asc
 /Downloads/TorBrowser-8.5.5-osx64_en-US.dmg`

 successfully verifies the signature by returning  Terminal message

 `gpg: Signature made Tue Sep  3 06:07:30 2019 PDT`
 `gpg:   using RSA key EB774491D9FF06E2`
 `gpg: Good signature from "Tor Browser Developers (signing key)
 " [ultimate]`

 In the preceding Terminal command, notice that the `TorBrowser-8.5.5
 -osx64_en-US.dmg.asc` file entry precedes the `TorBrowser-8.5.5-osx64_en-
 US.dmg` file entry.

 The current Support documentation instructs macOS users to enter Terminal
 command

 `gpgv --keyring ./tor.keyring ~/Downloads/TorBrowser-8.5.4-osx64_en-
 US.dmg{.asc,}`

 The preceding Terminal command returns   Terminal message

 `gpgv: keyblock resource './tor.keyring': No such file or directory`
 `gpgv: no valid OpenPGP data found.`
 `gpgv: the signature could not be verified.`
 `Please remember that the signature file (.sig or .asc)`
 `should be the first file given on the command line.`

 Apparently, macOS users must use Terminal command `gpg --verify`, and the
 `{.asc,}` file must appear before the `{.dmg,}` file in the Terminal
 command line before an attempt to verify the signature can be successful.

--
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] #31738 [- Select a component]: issue with tor 8.5.4

[Tor Bug Tracker & Wiki]

#31738: issue with tor 8.5.4
--+
 Reporter:  torqq |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by torqq):

 * Attachment "test_fakepwd.py" 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] #31738 [- Select a component]: issue with tor 8.5.4

[Tor Bug Tracker & Wiki]

#31738: issue with tor 8.5.4
---+--
 Reporter:  torqq  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Immediate  |  Component:  - Select a component
  Version: |   Severity:  Critical
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 Following files in folder
 TorBrowser/PluggableTransports/twisted/python/test

 fakepwd.py
 fakeendpoint.py

 see attached

--
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] #31738 [- Select a component]: issue with tor 8.5.4

[Tor Bug Tracker & Wiki]

#31738: issue with tor 8.5.4
--+
 Reporter:  torqq |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by torqq):

 * Attachment "fakepwd.py" 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] #31738 [- Select a component]: issue with tor 8.5.4

[Tor Bug Tracker & Wiki]

#31738: issue with tor 8.5.4
--+
 Reporter:  torqq |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by torqq):

 * Attachment "fakeendpoint.py" 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] #31738 [- Select a component]: issue with tor 8.5.4

[Tor Bug Tracker & Wiki]

#31738: issue with tor 8.5.4
--+
 Reporter:  torqq |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by torqq):

 * Attachment "test_fakepwd.2.py" 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] #31475 [Core Tor/Tor]: config: stop using atof()

[Tor Bug Tracker & Wiki]

#31475: config: stop using atof()
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Low   |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  .2
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_revision => needs_review
 * actualpoints:   => .2


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

Re: [tor-bugs] #31709 [Webpages/Website]: Add the Digital Climate Strike code to the Tor Website

[Tor Bug Tracker & Wiki]

#31709: Add the Digital Climate Strike code to the Tor Website
--+--
 Reporter:  teor  |  Owner:  hiro
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #31708| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 They've just merged a security patch, please make sure it is included in
 Tor's copy the code:
 https://github.com/fightforthefuture/digital-climate-strike/pull/79

--
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] #31637 [Core Tor/Tor]: Make sure we have test coverage for Option, +Option and /Option across defaults, torrc, command line

[Tor Bug Tracker & Wiki]

#31637: Make sure we have test coverage for Option, +Option and /Option across
defaults, torrc, command line
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-august  |  Actual Points:
Parent ID:  #29211   | Points:
 Reviewer:  teor |Sponsor:
-+-

Comment (by nickm):

 >> * Open a ticket to change how relative paths are interpreted by
 %include.
 > Yes I think we should do this long-term.

 I've opened #31737 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] #31737 [Core Tor/Tor]: Change handling of relative paths in %include directives?

[Tor Bug Tracker & Wiki]

#31737: Change handling of relative paths in %include directives?
--+--
 Reporter:  nickm |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+--
 Right now, relative paths in %include directives are handled relative to
 Tor's working directory, which doesn't make a lot of sense.  Handling them
 relative to the configuration file might make more sense?

 We'd want to figure out a way to handle this that won't break existing
 users.

--
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] #31475 [Core Tor/Tor]: config: stop using atof()

[Tor Bug Tracker & Wiki]

#31475: config: stop using atof()
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  Low   |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 I've added overflow/underflow detection to the branch.  I'm not checking
 for 0 or HUGE_VAL explicitly, but looking at the errno value instead.
 I've added tests to make sure it works.

--
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] #30913 [Applications/Tor Browser]: Tor Browser for Android uses ugly fonts on websites

[Tor Bug Tracker & Wiki]

#30913: Tor Browser for Android uses ugly fonts on websites
--+--
 Reporter:  raxp  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by miekin@…):

 I can confirm that this issue still occurs on my Samsung Galaxy A8 2018

--
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] #26294 [Core Tor/Tor]: attacker can force intro point rotation by ddos

[Tor Bug Tracker & Wiki]

#26294: attacker can force intro point rotation by ddos
-+-
 Reporter:  arma |  Owner:  asn
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-dos, network-team-   |  Actual Points:  6
  roadmap-august, security, 042-should   |
Parent ID:  #2   | Points:  7
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor27-must
-+-

Comment (by asn):

 Replying to [comment:33 arma]:
 > Replying to [comment:27 asn]:
 > > We actually had not heard that replay caches are there to protect
 against traffic analysis attacks. How does the attack work? I considered
 that identical INTRO2 cells could be used as a signal to the HS guard, but
 since they are end-to-end encrypted the singal should not be visible,
 right?
 >
 > The encryption protects the payload, but not the communications metadata
 (timing and volume).
 >

 Thanks for the explanation. The attacks indeed make sense.

 > I worry about two impacts from replays by the intro point:
 >
 > * Capture an intro2 cell and later play it repeatedly, to create a
 pattern at the onion service's guard, at a time of our choosing. The
 replay cache at the onion service doesn't completely resolve this concern,
 because the intro point gets to send the cells before the onion service
 can realize they're replays. But if Mike succeeds at removing every side
 channel from the world, then the replayed intro2 cells are "legitimate"
 (i.e. expected and correctly formed) cells so without a replay cache there
 is no way to realize that they're not wanted.
 >

 I think this side-channel attack is kinda interesting, and it gives even
 more reason to change the current design since (as s7r mentioned) it's
 currently easy to make onion services rotate their introduction points,
 and hence place the attacker in the right position to carry out this
 attack.

 Also, introduction points will always be in position to carry out this
 attack since they can send arbitrary cells to the end of the circuit (the
 HS). If those cells are not expected, the service will drop them (and
 issue a log warning) but the attack will still be carried out since the
 signal will reach the guard.

 IMO, this attack is a reason to increase the lifetime of the introduction
 points, but not a reason to drop this patch.

 > * Capture an intro2 cell and later play it repeatedly to create a
 pattern at the rendezvous point. This one is directly resolved by a replay
 cache at the onion service side. The impact is a bit subtle/indirect, but
 it would for example allow attacks where later you discover which
 rendezvous point a given introduction attempt used.
 >

 This is indeed an attack that becomes possible if this patch gets merged,
 and creates a tradeoff here that is worth discussing.

 I feel like an adversary that would end up launching this attack is
 dealing with a super advanced (almost artificial) scenario: The adversary
 does not know the identity of the onion, but still they capture INTRO2
 cells and then replay them to learn the rendezvous point. Now let's assume
 that they can instantly pair an introduction with a rendezvous point,
 what's next? Maybe if they later learn the actual identity of the onion
 service, they can learn that a given rendezvous circuit was destined to
 that onion? And what's next? Maybe they can do traffic correlation to
 identify the identity of the onion or of the client? But this ends up
 being a super strong attacker suddenly, and would probably have other ways
 to achieve the same goal.

 Also, the patch of this ticket won't allow the introduction point to
 generate arbitrary signals to the rendezvous point, since the replay cache
 needs to be reset before a replay is possible. And a replay cache can only
 be reset by legitimate (non-replay) traffic. So this attack assumes a
 popular onion service, and the attacker can only replay each cell once, so
 they can only create a signal of one rendezvous circuit per cache reset
 (except if they also replay other intro2 cells, but those will be going to
 other rendezvous points).

 So I can see how this attack can work, but it still seems pretty remote,
 compared to the one that is currently possible (attacker forces HS to use
 an evil intro, and then does the above attack, or collects statistics, or
 whatever), and hence I still feel like the patch in this ticket is

[tor-bugs] #31728 [Internal Services/Services Admin Team]: The proxy server is refusing connections Firefox is configured to use a proxy server that is refusing connections. Check the proxy settings t

[Tor Bug Tracker & Wiki]

#31728: The proxy server is refusing connections  Firefox is configured to use a
proxy server that is refusing connections.  Check the proxy settings to
make sure that they are correct. Contact your network administrator to
make sure the proxy server is working.
-+-
 Reporter:  rpptor   |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Immediate|  Component:  Internal Services/Services
  Version:  Tor: |  Admin Team
  unspecified|   Severity:  Critical
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
 I just installed the latest version of TOR BROWSER in a Pendrive USB, but
 when i click Star Tor it shows this error message The proxy server is
 refusing connections

 Firefox is configured to use a proxy server that is refusing connections.

 Check the proxy settings to make sure that they are correct.
 Contact your network administrator to make sure the proxy server is
 working.

 I`ve tried to set all options of Mozilla Firefox Settings Advance settings
 Proxy in Automatic, System, No Proxy, No Manual cause dond`t know
 parameters , also set up Internet Conexions to Automatic but nothing seems
 to work, I use Mozilla Firefox Quantum 69 latest version in a Windows 10
 64 bits, will you please advise how to fix this issue ASAP thanks very
 much .

--
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] #31614 [Core Tor/Tor]: Implement clean_up_backtrace_handler()

[Tor Bug Tracker & Wiki]

#31614: Implement clean_up_backtrace_handler()
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  consider-backport-after-042-stable,  |  Actual Points:  0.2
  consider-backport-if-needed, diagnostics,  |
  042-should, 035-backport-maybe, 040-backport-  |
  maybe, 041-backport-maybe, regression, |
  BugSmashFund   |
Parent ID:   | Points:  0.2
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by teor):

 You're right, there are a bunch of nasty race conditions here.

 This is what we need to fix:
 1. Always lock the mutex before using cb_buf (there are some places where
 we don't do this)
 2. Lock the mutex before adding or removing signal handlers (might not be
 strictly required, but it makes reasoning about locks easier)
 3. Abort if destroying the mutex fails (doesn't save us from undefined
 behaviour, but does notify us when it happens)

 We could also
 4. Lock a mutex before logging anywhere in the err module (this could
 cause more issues than it solves)

 The best way to do this might be to put cb_buf in its own file, and use
 accessor functions.

--
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] #31384 [Circumvention/Snowflake]: localize snowflake website

[Tor Bug Tracker & Wiki]

#31384: localize snowflake website
-+-
 Reporter:  emmapeel |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  l10n, anti-censorship-roadmap-   |  Actual Points:
  september  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor28
-+-

Comment (by emmapeel):

 Replying to [comment:5 dcf]:
 > I have some process-related questions.
 >
 > How do we know which language to use? In comment:2 you mentioned adding
 a menu to the page. I see such a menu at https://tb-
 manual.torproject.org/, defaulting(?) to English. Should we also look at
 the `Accept-Language` HTTP header (i.e., the user's in-browser configured
 language)? Do other Tor Project pages do that?

 The ideal will be to allow users to change it by hand, as our own browser
 allows to hide your language and many people browse the web in English
 because of fingerprinting, or sometimes are using public computers, etc,
 so it is unlikely that they will have the proper language configured.

 > What is the process for handling revisions to the source text? Will the
 translation.git repository periodically get a revised index.html, then
 make changes in that repository? Then we import those changes back into
 snowflake.git? Is there some way to notify each group about when updates
 are ready from the other side?

 I can hook the translation system to the repository at
 https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/plain/proxy/static/index.html, so the changes on
 the file will be reflected some hours later on the translation platform (i
 have done that already with messages.json). transifex will pull the source
 files twice a day I think.

 It would be great if somebody from the team can join transifex, as
 sometimes there are comments translators do on the source strings that
 would be nice if you review.

 From inside of transifex you could see if the file is translated and
 reviewed, the comments, etc.

 I can help you decide on the languages that are ready when you approach
 release.

 We could also make a call for translations to speed up the process,
 currently many languages are translated but not reviewed.

 Also, if you have friends that want to review a specific language before
 publishing, send them to me, as we need trusted reviewers for many
 languages.

--
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] #31729 [Applications/Tor Browser]: Warning about missing GTK wayland related packages in configure script

[Tor Bug Tracker & Wiki]

#31729: Warning about missing GTK wayland related packages in configure script
--+---
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-rbm, ff68-esr
Actual Points:|  Parent ID:  #30321
   Points:|   Reviewer:
  Sponsor:|
--+---
 When running the ESR 68 build on Linux one can see the following warnings
 {{{
  0:10.19 WARNING: Package gtk+-wayland-3.0 was not found in the pkg-config
 search path.
  0:10.19 WARNING: Perhaps you should add the directory containing
 `gtk+-wayland-3.0.pc'
  0:10.19 WARNING: to the PKG_CONFIG_PATH environment variable
  0:10.19 WARNING: No package 'gtk+-wayland-3.0' found
  0:10.19 WARNING: Package xkbcommon was not found in the pkg-config search
 path.
  0:10.19 WARNING: Perhaps you should add the directory containing
 `xkbcommon.pc'
  0:10.19 WARNING: to the PKG_CONFIG_PATH environment variable
  0:10.19 WARNING: No package 'xkbcommon' found
 }}}

--
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] #31729 [Applications/Tor Browser]: Warning about missing GTK wayland related packages in configure script

[Tor Bug Tracker & Wiki]

#31729: Warning about missing GTK wayland related packages in configure script
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm, ff68-esr |  Actual Points:
Parent ID:  #30321| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 I think Mozilla fixed that for their wheezy setup with patches. We might
 be able to copy that approach, not sure.

--
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] #31730 [Applications/Tor Browser]: Revert aarch64 fixup for ESR 60-based bundles with Tor Browser 9

[Tor Bug Tracker & Wiki]

#31730: Revert aarch64 fixup for ESR 60-based bundles with Tor Browser 9
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-mobile, tbb-parity,
 Severity:  Normal   |  TorBrowserTeam201910, tbb-9.0-must
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We solved #31616 and #31140 by making sure the JIT prefs are not enabled
 via our security slider on aarch64.

 We need to revert that for Tor Browser 9 and make sure that the security
 level is actually reset to `low` for those users whose level got set to
 `custom` due to the workaround we deployed. (Doing the latter might
 actually not be trivial).

--
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] #31729 [Applications/Tor Browser]: Warning about missing GTK wayland related packages in configure script

[Tor Bug Tracker & Wiki]

#31729: Warning about missing GTK wayland related packages in configure script
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm, ff68-esr |  Actual Points:
Parent ID:  #30321| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Report on our blog:
 https://blog.torproject.org/comment/283856#comment-283856.

--
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] #31731 [Applications/Tor Browser]: Upgrade to ESR 68-based browser makes description field of bookmarks empty

[Tor Bug Tracker & Wiki]

#31731: Upgrade to ESR 68-based browser makes description field of bookmarks 
empty
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  ff68-esr,
 Severity:  Normal   |  TorBrowserTeam201909
Actual Points:   |  Parent ID:
   Points:  0.5  |   Reviewer:
  Sponsor:   |
-+-
 As reported on our blog
 (https://blog.torproject.org/comment/283838#comment-283838), starting with
 ESR 68 the description fields in bookmarks are empty. Switching back to
 8.5.5 (hence ESR 60) solves that.

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

Re: [tor-bugs] #31731 [Applications/Tor Browser]: Upgrade to ESR 68-based browser makes description field of bookmarks empty

[Tor Bug Tracker & Wiki]

#31731: Upgrade to ESR 68-based browser makes description field of bookmarks 
empty
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff68-esr, TorBrowserTeam201909  |  Actual Points:
Parent ID:  | Points:  0.25
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * points:  0.5 => 0.25


Comment:

 Hrm. It seems this basically got removed: https://www.mozilla.org/en-
 US/firefox/62.0/releasenotes/ (thanks cypherpunk for the link). I wonder
 whether there is more to it for us to do 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] #24653 [Applications/Tor Browser]: Apply security slider improvements made on desktop back to mobile

[Tor Bug Tracker & Wiki]

#24653: Apply security slider improvements made on desktop back to mobile
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-torbutton, tbb-  |  Actual Points:
  security-slider, tbb-parity,   |
  TorBrowserTeam201909   |
Parent ID:  #10760   | Points:  0.25
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:16 acat]:
 > Fixed in https://github.com/acatarineu/tor-browser/commit/24653+1. Isn't
 `custom_summary` already the same as in torbutton?

 Right, my bad. I was looking in the browser without realizing the
 scrollbar. So, I thought the string was cut but it wasn't. Thanks. Now,
 could you just remove the superfluous whitespace on the empty lines in
 {{{
 +});
 +
 +// Use the DOM parser to resolve the entity and extract its real
 value
 +let header = ``;
 +let elem = `&${id};`;
 +let doc = domParser.parseFromString(header + elem, "text/xml");
 +let element = doc.querySelector("elem[id='elementID']");
 +
 +if (element === null) {
 +  throw new Error(`Entity with id='${id}' hasn't been found`);
 +}
 +
 +return element.textContent;
 }}}
 `git` is not happy with those. :)

--
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] #31718 [Internal Services/Tor Sysadmin Team]: Update DNS records for .ooni.torproject.org domains

[Tor Bug Tracker & Wiki]

#31718: Update DNS records for .ooni.torproject.org domains
-+-
 Reporter:  hellais  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by weasel):

 I'm not convinced we want to point more of our torproject.org namespace to
 the outside.  I'll bring this up with the rest of the team.

--
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] #31732 [Applications/Tor Browser]: Windows nightly build failure

[Tor Bug Tracker & Wiki]

#31732: Windows nightly build failure
-+-
 Reporter:  boklm|  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-rbm,
 Severity:  Normal   |  TorBrowserTeam201909
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 The Windows nightly builds currently fail while building firefox with:
 {{{
 31:36.72 /var/tmp/dist/mingw-w64-clang/bin/x86_64-w64-mingw32-clang++
 -mwindows -shared -Wl,--out-implib -Wl,libclearkey.a -Wl,-pdb,clearkey.pdb
 -o clearkey.dll @/var/tmp/build/firefox-e489c5048b76/obj-mingw/media/gmp-
 clearkey/0.1/clearkey_dll.list ./module.res  -Wl,--no-insert-timestamp
 -Wl,--dynamicbase -Wl,--icf=safe-luuid -lusp10 -lgdi32 -lwinmm
 -lwsock32 -luserenv -lsecur32 -lmfuuid
 31:36.77 lld-link: error: undefined symbol: __strcat_chk
 31:36.77 >>> referenced by /var/tmp/build/firefox-e489c5048b76/media/gmp-
 clearkey/0.1/openaes/oaes_lib.c:459
 31:36.77 >>>   oaes_lib.o:(oaes_sprintf)
 31:36.77 clang-8: error: linker command failed with exit code 1 (use -v to
 see invocation)
 31:36.77 /var/tmp/build/firefox-e489c5048b76/config/rules.mk:680: recipe
 for target 'clearkey.dll' failed
 31:36.77 make[4]: *** [clearkey.dll] Error 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] #31732 [Applications/Tor Browser]: Windows nightly build failure

[Tor Bug Tracker & Wiki]

#31732: Windows nightly build failure
-+-
 Reporter:  boklm|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201909,   |  Actual Points:
  GeorgKoppen201909  |
Parent ID:  #30322   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-rbm, TorBrowserTeam201909 => tbb-rbm,
 TorBrowserTeam201909, GeorgKoppen201909
 * points:   => 0.5
 * parent:   => #30322


Comment:

 Okay, that's weird. I gonna look into it. This seems to be happening for
 both 32-but and 64-bit builds.

--
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] #29669 [Core Tor/Tor]: hs: ADD_ONION with NEW:BEST is still pinned on v2

[Tor Bug Tracker & Wiki]

#29669: hs: ADD_ONION with NEW:BEST is still pinned on v2
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-control, hs-v3, tor- |  Actual Points:  0.1
  spec, security, 041-deferred-20190530  |
  042-should |
Parent ID:  #29995   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-must
-+-
Changes (by asn):

 * status:  needs_review => needs_revision


Comment:

 Patch LGTM but the changes file ends in a weird semicolon instead of a
 colon.
 Also we need a spec file and we should be good. Marking as needs_revision
 for the 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

Re: [tor-bugs] #24653 [Applications/Tor Browser]: Apply security slider improvements made on desktop back to mobile

[Tor Bug Tracker & Wiki]

#24653: Apply security slider improvements made on desktop back to mobile
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-torbutton, tbb-  |  Actual Points:
  security-slider, tbb-parity,   |
  TorBrowserTeam201909R  |
Parent ID:  #10760   | Points:  0.25
 Reviewer:   |Sponsor:
-+-
Changes (by acat):

 * keywords:
 tbb-mobile, tbb-torbutton, tbb-security-slider, tbb-parity,
 TorBrowserTeam201909
 =>
 tbb-mobile, tbb-torbutton, tbb-security-slider, tbb-parity,
 TorBrowserTeam201909R
 * status:  needs_revision => needs_review


Comment:

 Done in https://github.com/acatarineu/tor-browser/commit/24653+2.

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

Re: [tor-bugs] #31652 [Core Tor/Tor]: hs-v3: Service circuit retry limit should not close a valid circuit

[Tor Bug Tracker & Wiki]

#31652: hs-v3: Service circuit retry limit should not close a valid circuit
-+-
 Reporter:  dgoulet  |  Owner:  neel
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-circuit, 042-should  |  Actual Points:
Parent ID:  #30200   | Points:  0.1
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor27-must
-+-
Changes (by asn):

 * status:  needs_review => needs_revision


Comment:

 Hmm, seems some test failed and CI is sad. (Didn't do any source code
 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

Re: [tor-bugs] #26294 [Core Tor/Tor]: attacker can force intro point rotation by ddos

[Tor Bug Tracker & Wiki]

#26294: attacker can force intro point rotation by ddos
-+-
 Reporter:  arma |  Owner:  asn
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-dos, network-team-   |  Actual Points:  6
  roadmap-august, security, 042-should   |
Parent ID:  #2   | Points:  7
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor27-must
-+-

Comment (by zmer):

 INTRO cells used to have a timestamp that could be used to discard old
 ones being replayed. All things considered, the reasons given for removing
 it didn't make good sense. Arguably it should be brought back. And perhaps
 in future clients could be made to keep their own accurate time,
 independent of what the host clock is set to. There would be a number of
 benefits. But that is another 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] #26294 [Core Tor/Tor]: attacker can force intro point rotation by ddos

[Tor Bug Tracker & Wiki]

#26294: attacker can force intro point rotation by ddos
-+-
 Reporter:  arma |  Owner:  asn
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-dos, network-team-   |  Actual Points:  6
  roadmap-august, security, 042-should   |
Parent ID:  #2   | Points:  7
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor27-must
-+-

Comment (by s7r):

 > Replying to [comment:35 s7r]:
 > Hm. I still don't see how the hybrid construction can help here: IMO the
 future ideal scenario is that introduction points will last for ever
 (kinda like guards) to resist Sybil atacks, and hence adding any rotation
 parameter apart from time will make rotation happen faster which is no
 good.
 >
 > In particular, adding 'introductions' as a rotation parameter, opens us
 up to the attack of this ticket, where an adversary can force your intros
 to rotate because of too many introductions. The only reason that the
 design from comment:11 works out (in paper) is because the intro will
 rotate after 28 million introductions which is a huge number and will
 never happen (at least in theory, and if it happens it's bad). The problem
 with that is that a replay cache that holds 28million elements will be
 around 1.8 GB of memory (according to my over-the-envelope computations in
 
https://github.com/torproject/tor/pull/1163/commits/6ef1ac5eed85d7cf3cafa1797dc1003912d1a63c)
 which doesn't really work out in practice
 >
 > It is the case that we might want to make the replay cache of this patch
 even bigger since it can currently hold 150k-300k elements for a memory
 overhead of 8.4MB to 16.8MB. Do you think we can afford to make them
 bigger? Perhaps double them or triple them or even bigger? An onion
 service should have about 6 of these right now (and it will become 3 when
 we do #22893).

 Of course, 1.8 GB memory for replay cache is unacceptable. But the way I
 thought of it it was never meant to hold 28 million elements. It should
 hold the same number of elements like it does now, but instead keep one
 more value in memory (`ALLOW_RESET_CACHE`) and choose a number for how
 many times we are willing to allow. When it stats, it starts with  value 1
 and after rand(16384, 16384*2) it gets cleared and reset, and number
 incremented to +1 = 2. When we hit the max. number of ALLOW_RESET_CACHE,
 we rotate the introduction point. So maybe I'm missing something but the
 memory requirement should not be much bigger as opposite to what we have
 now since we need to only keep in memory two things more: how many times
 we already reset the cache and for  how many times are we willing to reset
 it. Again, this is if course not perfect but I think it's better.

 Also, I don't think having the lifetime of introduction points as long as
 possible (based on time) like Guards have is a good idea, because simply
 introduction points are nothing like the Guards. While the Guard is
 (theoretically) know ONLY to the client (the Tor daemon running the onion
 service in this case), the introduction point is known to every client
 trying to connect to the onion service. From my point of view here we
 should assume that every client (visitor) of an onion service is a
 potential attacker. Even the ones that use authentication, are still under
 this threat (what if a genuine client gets squeezed with the door to
 handle the onion auth credentials, etc). So the longer you hold a
 connection to an introduction point the more time you give to an attacker
 to pull a guard discovery attack.

 Introduction points vs vanguards:
 - guard (first hop, layer 1 guard - not know to the onion service visitor)
 - 2nd hop (layer 2 guard - not known to the onion service visitor)
 - 3nd hop (layer 3 guard - not know to the onion service visitor and even
 for these we thought about making the 3rd hop always random because it's
 just before the rendezvous point which is selected by the client
 [potential attacker]. Even if in vanguards we decided 3rd hop static but
 for shortest period of time this node is still at least theoretically not
 directly known to the onion service visitor).

 IMO introduction points don't share the same property as the Guards and
 keeping them static only based on time for longer period of time while
 open the door for easier attacks. In vanguards I believe we already keep
 the 

Re: [tor-bugs] #31672 [Applications/Tor Browser]: Tor Browser for Android: Onion Service authentication

[Tor Bug Tracker & Wiki]

#31672: Tor Browser for Android: Onion Service authentication
--+---
 Reporter:  ggus  |  Owner:  tbb-team
 Type:  enhancement   | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by ggus):

 I think they were using with Orbot+Orfox.

--
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] #24653 [Applications/Tor Browser]: Apply security slider improvements made on desktop back to mobile

[Tor Bug Tracker & Wiki]

#24653: Apply security slider improvements made on desktop back to mobile
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-mobile, tbb-torbutton, tbb-  |  Actual Points:
  security-slider, tbb-parity,   |
  TorBrowserTeam201909R  |
Parent ID:  #10760   | Points:  0.25
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Looks good, now. I cherry-picked the browser patch onto `tor-
 browser-68.1.0esr-9.0-2` (commit 3b5b0d6d502d712734c2c5b7e35c0d29e5f19204)
 and applied the Torbutton one (after updating the translations on
 `master`) on top of `master` as commit
 903d676ccf33e36938438a595b71e781ef13bbe1.

--
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] #31733 [Internal Services/Service - lists]: Add gus@tpo as moderator for community team mailing list

[Tor Bug Tracker & Wiki]

#31733: Add gus@tpo as moderator for community team mailing list
---+-
 Reporter:  ggus   |  Owner:  qbi
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Internal Services/Service - lists  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-


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