Re: [tor-bugs] #26368 [Core Tor/Tor]: Consider circuit isolation when closing redundant intro points

[Tor Bug Tracker & Wiki]

#26368: Consider circuit isolation when closing redundant intro points
-+-
 Reporter:  sysrqb   |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-client, tbb-needs,   |  Actual Points:
  041-can|
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by cypherpunks):

 Why was it removed from the milestones?
 > Tor should only close circuits if the socks request isolation bits
 match.
 What is unclear here?
 Right now FPI can be broken by embedding an onion 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] #31509 [Core Tor/Tor]: config refactor: make test-stem should pass

[Tor Bug Tracker & Wiki]

#31509: config refactor: make test-stem should pass
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  assigned
 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:   |Sponsor:  Sponsor31-must
-+-
Changes (by teor):

 * owner:  nickm => (none)


Comment:

 We should make sure that every PR passes make test-stem, because CI cant
 do that for us right now.

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

Re: [tor-bugs] #31240 [Core Tor/Tor]: Make confparse able to handle multiple config_format_t objects at once

[Tor Bug Tracker & Wiki]

#31240: Make confparse able to handle multiple config_format_t objects at once
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-august  |  Actual Points:  3
Parent ID:  #29211   | Points:  3
 Reviewer:  teor |Sponsor:  Sponsor31-can
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 I think I'm still missing answers to these PR questions:

 https://github.com/nmathewson/tor/pull/3#discussion_r317548828

 https://github.com/nmathewson/tor/pull/3#discussion_r317549159

 https://github.com/nmathewson/tor/pull/3#discussion_r318399721

 Maybe there is too much code, too many commits, or too many comments in
 these PRs.
 GitHub doesn't seem to want to display them all.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31549 [Core Tor/Tor]: Authorities should stop listing relays running pre-0.2.9, or running 0.3.0 through 0.3.4

[Tor Bug Tracker & Wiki]

#31549: Authorities should stop listing relays running pre-0.2.9, or running 
0.3.0
through 0.3.4
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  042-can   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Should we add a torrc option that has a list of rejected versions (or
 version ranges)?

 How often do we want to reject old versions like 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] #31552 [Core Tor]: --disable-module-dirauth broken (missing symbols)

[Tor Bug Tracker & Wiki]

#31552: --disable-module-dirauth broken (missing symbols)
-+-
 Reporter:  LarryBitcoin |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor |Version:  Tor:
 |  0.4.1.5
 Severity:  Normal   | Resolution:
 Keywords:  build, configure, features,  |  Actual Points:
  modules, regression|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Sometimes, LTO errors happen because the function signatures are different
 in different modules.
 Maybe we should check these 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] #31545 [Core Tor/Tor]: CID 1452819: nul-terminated string handling, possibly spurious

[Tor Bug Tracker & Wiki]

#31545: CID 1452819: nul-terminated string handling, possibly spurious
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  042-must, memory-safety?, easy,  |  Actual Points:
  intro, ipv6, logging, fast-fix |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by teor):

 * status:  assigned => needs_review
 * type:  defect => enhancement


Comment:

 I rewrote describe.c to use strlcpy() and strlcat(), and check their
 return values.

 https://github.com/torproject/tor/pull/1270

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31553 [Core Tor/Stem]: "make test-stem" fails with missing cached_tor_manual.cfg

[Tor Bug Tracker & Wiki]

#31553: "make test-stem" fails with missing cached_tor_manual.cfg
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by teor):

 > The long-term fix is lowering #30694 from travis to "make test-stem".
 I'll open a ticket.

 The ticket is #31554

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31554 [Core Tor/Tor]: Restrict "make test-stem" to tests that actually use tor

[Tor Bug Tracker & Wiki]

#31554: Restrict "make test-stem" to tests that actually use tor
-+-
 Reporter:  teor |  Owner:  teor
 Type:   | Status:  assigned
  enhancement|
 Priority:  Medium   |  Milestone:  Tor: 0.4.2.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  tor-ci, fast-fix, 041-backport,
 Severity:  Normal   |  040-backport, 035-backport
Actual Points:   |  Parent ID:
   Points:  0.1  |   Reviewer:
  Sponsor:   |
  Sponsor31-can  |
-+-
 In #30694, we restricted the travis stem job to tests that actually use
 tor.

 But we should lower that change to "make test-stem".

 Gaba, this is sponsor 27 can, because it makes refactoring easier to test.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31553 [Core Tor/Stem]: "make test-stem" fails with missing cached_tor_manual.cfg

[Tor Bug Tracker & Wiki]

#31553: "make test-stem" fails with missing cached_tor_manual.cfg
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 {{{
 test_install [FAILURE]
 test_sdist 0 ms  [SUCCESS]

 ==
 FAIL: test_install
 --
 Traceback (most recent call last):
   File "/Users/base/stem/stem/util/test_tools.py", line 152, in 
 self.method = lambda test: self.result(test)  # method that can be
 mixed into TestCases
   File "/Users/base/stem/stem/util/test_tools.py", line 225, in result
 test.fail(self._result.msg)
 AssertionError: The following files were expected to be in our
 installation but weren't. Maybe our setup.py needs to be updated?

 stem/cached_tor_manual.cfg

 --
 Ran 2 tests in 0.000s

 FAILED (failures=1)
 }}}

 {{{
 ==
  INITIALISING
 ==

   stem version...1.7.1-dev (commit 6790035c)
   tor version... 0.4.2.0-alpha-dev (commit
 04ab357d)
   python version...  3.7.4
   operating system...Darwin (17.7.0)
   cryptography version...2.7
   mock version...1.0
   pyflakes version...missing
   pycodestyle version... missing
   checking for orphaned .pyc files...done (0.0s)
   checking for unused tests...   done (0.0s)
   importing test modules...  done (0.1s)
   emptying our tor data directory... skipped
   running pyflakes...unavailable
   running pycodestyle... unavailable
 }}}

 The long-term fix is lowering #30694 from travis to "make test-stem". I'll
 open a 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] #31510 [Core Tor/Stem]: Stem install test errors: cached_tor_manual and arm.* image

[Tor Bug Tracker & Wiki]

#31510: Stem install test errors: cached_tor_manual and arm.* image
---+---
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  not a bug
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

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


Comment:

 Yeah it was old files.

 So unless you want to fix the clean step, this issue is done.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29786 [Core Tor/Tor]: Path bias circuits can still have cells pending

[Tor Bug Tracker & Wiki]

#29786: Path bias circuits can still have cells pending
--+--
 Reporter:  mikeperry |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by neel):

 * status:  assigned => new


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29786 [Core Tor/Tor]: Path bias circuits can still have cells pending

[Tor Bug Tracker & Wiki]

#29786: Path bias circuits can still have cells pending
--+--
 Reporter:  mikeperry |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by neel):

 * cc: neel (removed)
 * owner:  neel => (none)


Comment:

 Unassigning myself from 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] #31552 [Core Tor]: --disable-module-dirauth broken (missing symbols)

[Tor Bug Tracker & Wiki]

#31552: --disable-module-dirauth broken (missing symbols)
-+-
 Reporter:  LarryBitcoin |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor |Version:  Tor:
 |  0.4.1.5
 Severity:  Normal   | Resolution:
 Keywords:  build, configure, features,  |  Actual Points:
  modules, regression|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  build, configure, features, modules => build, configure,
 features, modules, regression
 * milestone:   => Tor: 0.4.1.x-final


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

Re: [tor-bugs] #31552 [Core Tor]: --disable-module-dirauth broken (missing symbols)

[Tor Bug Tracker & Wiki]

#31552: --disable-module-dirauth broken (missing symbols)
-+-
 Reporter:  LarryBitcoin |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor |Version:  Tor:
 |  0.4.1.5
 Severity:  Normal   | Resolution:
 Keywords:  build, configure, features, modules  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 It works for me, but I se that you're maybe using link-time optimization.
 Can you say more about your build environment?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28942 [Circumvention/Snowflake]: Evaluate pion WebRTC

[Tor Bug Tracker & Wiki]

#28942: Evaluate pion WebRTC
+--
 Reporter:  backkem |  Owner:  cohosh
 Type:  enhancement | Status:  accepted
 Priority:  Medium  |  Milestone:
Component:  Circumvention/Snowflake |Version:
 Severity:  Normal  | Resolution:
 Keywords:  anti-censorship-roadmap-august  |  Actual Points:
Parent ID:  | Points:  5
 Reviewer:  |Sponsor:
|  Sponsor28-must
+--

Comment (by dcf):

 Replying to [comment:39 cohosh]:
 > Just to give an update on this, building Tor Browser with this pion
 library is a bit painful right now. Our reproducible build system (rbm)
 doesn't work nicely with modules and, after a conversation with boklm,
 it's preferrable to create a separate project for each go lib dependency.
 This means a total of 13 pion libraries plus an additional 14+
 dependencies that these libraries have. There might be more, I stopped
 going down the rabbit hole after a while. I don't think creating 30-ish
 projects just to build this is a viable or sustainable option.

 I'm going to try brute-force packaging all the dependency projects. The
 `go mod graph` command outputs a tree of dependencies. I'm going to use
 that to try and automate the creation of most of the dependency projects,
 probably followed by some manual editing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30429 [Applications/Tor Browser]: Rebase Tor Browser patches for Firefox ESR 68

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-nightly,  |  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by gk):

 Alright, I just pushed `tor-browser-68.1.0esr-9.0-1` to our `tor-browser`
 repo. Please use that one for basing your branches and fixup commits on.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28822 [Applications/Tor Browser]: re-implement desktop onboarding for ESR 68

[Tor Bug Tracker & Wiki]

#28822: re-implement desktop onboarding for ESR 68
+--
 Reporter:  mcs |  Owner:  tbb-team
 Type:  defect  | Status:
|  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff68-esr, TorBrowserTeam201908  |  Actual Points:
Parent ID:  #30429  | Points:
 Reviewer:  |Sponsor:
|  Sponsor44-can
+--

Comment (by gk):

 Oh, and while rebasing I saw we have
 {{{
 # UITour
 # DuckDuckGo .onion (used for circuit display onboarding).
 origin  uitour  1   https://3g2upl4pq6kufc4m.onion
 origin  uitour  1   about:home
 origin  uitour  1   about:newtab
 origin  uitour  1   about:tor
 }}}
 I guess `about:home` and `about:newtab` can go now (at least that's my
 expression after re-looking at the webextension converting commit?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31552 [Core Tor]: --disable-module-dirauth broken (missing symbols)

[Tor Bug Tracker & Wiki]

#31552: --disable-module-dirauth broken (missing symbols)
-+-
 Reporter:  LarryBitcoin |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  Core
 |  Tor
  Version:  Tor: 0.4.1.5 |   Severity:  Normal
 Keywords:  build, configure, features, modules  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
 build with ./configure --disable-module-dirauth

 this will fail at linking time because of missing symbols.

 It used to work in 0.4.0.5 and is broken in 0.4.1.5


 for example

 make: *** [Makefile:9672: src/app/tor] Error 1
 ld.lld: error: undefined symbol: dirserv_should_launch_reachability_test
 >>> referenced by ld-temp.o
 >>>
 lto.tmp:(routers_update_status_from_consensus_networkstatus)

 ld.lld: error: undefined symbol: authdir_wants_to_reject_router
 >>> referenced by ld-temp.o
 >>>   lto.tmp:(router_add_to_routerlist)

 ld.lld: error: undefined symbol: dirserv_would_reject_router
 >>> referenced by ld-temp.o
 >>>   lto.tmp:(update_consensus_router_descriptor_downloads)
 clang: error: linker command failed with exit code 1 (use -v to see
 invocation)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31551 [Core Tor/Stem]: ss command is no longer supported by /usr/share/doc/stem-1.7.1/_static/example/relay_connections.py

[Tor Bug Tracker & Wiki]

#31551: ss command is no longer supported by
/usr/share/doc/stem-1.7.1/_static/example/relay_connections.py
--+---
 Reporter:  toralf|  Owner:  atagar
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  Core Tor/Stem
  Version:  Tor: 0.4.1.5  |   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
 I do get :
 {{{
 # for p in 9051 29051 ; do python
 /usr/share/doc/stem-1.7.1/_static/example/relay_connections.py --ctrlport
 $p --resolver ss; done
  0.4.1.5   uptime: 3-01:35:39   flags: Fast, Running, Stable, V2Dir, Valid

 +--+--+--+
 | Type | IPv4 | IPv6 |
 +--+--+--+
 | Inbound to our ORPort|0 |1 |
 +--+--+--+
 | Total|0 |1 |
 +--+--+--+

  0.4.1.5   uptime: 3-01:36:37   flags: Fast, Running, Stable, V2Dir, Valid

 Traceback (most recent call last):
   File "/usr/share/doc/stem-1.7.1/_static/example/relay_connections.py",
 line 130, in 
 main()
   File "/usr/share/doc/stem-1.7.1/_static/example/relay_connections.py",
 line 66, in main
 for conn in get_connections(resolver = args.resolver, process_pid =
 pid):
   File "/usr/lib64/python3.6/site-packages/stem/util/connection.py", line
 300, in get_connections
 raise IOError('No results found using: %s' % resolver_command)
 OSError: No results found using: ss -nptu
 }}}
 at a hardened stable Gentoo Linux with  kernel 5.2.10 and sys-
 apps/iproute2-4.19.0-r1 (provides "ss"), but th ecomamdn itself prints :
 {{{
 mr-fox ~ # ss -nptu | head
 Netid   State Recv-QSend-Q   Local
 Address:Port Peer Address:Port
 tcp ESTAB 0 0
 5.9.158.75:39658
 51.77.52.216:443 users:(("tor",pid=2365,fd=4313))
 tcp ESTAB 0 0
 5.9.158.75:9001
 52.14.166.220:51466   users:(("tor",pid=2397,fd=5105))
 tcp ESTAB 0 1057
 5.9.158.75:46379
 158.174.255.235:4430
 users:(("tor",pid=2365,fd=4663))
 tcp ESTAB 0 0   5.9.158.75:443
 82.35.159.254:57674   users:(("tor",pid=2365,fd=3870))
 tcp ESTAB 0 0
 5.9.158.75:35005
 94.16.113.67:9001users:(("tor",pid=2365,fd=4975))
 tcp ESTAB 0 0
 5.9.158.75:36837
 88.3.139.225:48998   users:(("tor",pid=2365,fd=6473))
 tcp ESTAB 0 0
 5.9.158.75:44183
 82.118.21.60:9001users:(("tor",pid=2365,fd=720))
 tcp ESTAB 0 0
 5.9.158.75:36997
 50.7.115.67:443 users:(("tor",pid=2397,fd=1543))
 tcp ESTAB 1571  1057
 5.9.158.75:9001
 46.165.250.224:34639
 users:(("tor",pid=2397,fd=2352))
 }}}
 All other 3 resolvers are fine and do print something like
 {{{
 # for p in 9051 29051 ; do python
 /usr/share/doc/stem-1.7.1/_static/example/relay_connections.py --ctrlport
 $p; done
  0.4.1.5   uptime: 3-01:51:38   flags: Fast, Running, Stable, V2Dir, Valid

 +--+--+--+
 | Type | IPv4 | IPv6 |
 +--+--+--+
 | Inbound to our ORPort| 2267 |1 |
 | Inbound to our DirPort   |3 |0 |
 | Inbound to our ControlPort   |1 |0 |
 | Outbound to a relay  | 3965 |0 |
 | Outbound uncategorized   |   12 |0 |
 +--+--+--+
 | Total| 6248 |1 |
 +--+--+--+

  0.4.1.5   uptime: 3-01:51:40   flags: Fast, Running, Stable, V2Dir, Valid

 +--+--+--+
 | Type | IPv4 | IPv6 |
 +--+--+--+
 | Inbound to our ORPort| 1629 |2 |
 | Inbound to our ControlPort   |1 |0 |
 | Outbound to a relay  | 4083 |0 |
 | Outbound uncategorized   |   12 |0 |
 +--+--+--+
 | Total| 5725 |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] #28822 [Applications/Tor Browser]: re-implement desktop onboarding for ESR 68

[Tor Bug Tracker & Wiki]

#28822: re-implement desktop onboarding for ESR 68
+--
 Reporter:  mcs |  Owner:  tbb-team
 Type:  defect  | Status:
|  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff68-esr, TorBrowserTeam201908  |  Actual Points:
Parent ID:  #30429  | Points:
 Reviewer:  |Sponsor:
|  Sponsor44-can
+--
Changes (by gk):

 * keywords:  ff68-esr, TorBrowserTeam201908R => ff68-esr,
 TorBrowserTeam201908
 * status:  needs_review => needs_revision


Comment:

 Okay, I took the commits from your `30429+9` and here are my comments:

 ea5f8c2c9ccc0130944f05a6e31ebb2a9322041c - I think it's mostly good. Two
 things:
 {{{
 +const {Services}
 }}}
 I think we settled for space between name and braces in Torbutton? Would
 be good
 here as well.
 {{{
 +   @$(MAKE) -C ../extensions/onboarding/locales chrome AB_CD=$*
 }}}
 It's really just one level up here, right? While all the other items are
 two
 levels up?

 1c9eb3993c5b505c0894b13634b09690bfb97791 - not okay (not sure about the
 changed `onboarding-overlay-button` but we'll see I guess while testing)

 The images are the wrong ones. We want to have those from #30560.

 6f05a139b387c072a63bfae3a086aee2cee95875 - okay
 e19e128476f48278911656db735739f0526f12ce - not okay
 {{{
 -/* The primary button gets the same color as the customize button. */
 }}}
 in `browser/themes/shared/UITour.inc.css` is missing

 742fccfcbb7a19ba9daee44335e9962639773d13 - not okay
 {{{
 -  OnboardingTelemetry:
 "resource://onboarding/modules/OnboardingTelemetry.jsm",
 }}}
 in `browser/extensions/onboarding/bootstrap.js` is missing

 aeb0b6678e61fd282825610ca29a225eb0991281 - I think this is okay, but are
 we affected by https://bugzilla.mozilla.org/show_bug.cgi?id=1498378?

 I'll take the patches, though, for `tor-browser-68.1.0esr-9.0-1`, so
 please provide fixups for the issues above based on that one. (I am about
 to rebase and push it to `tor-browser`).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30429 [Applications/Tor Browser]: Rebase Tor Browser patches for Firefox ESR 68

[Tor Bug Tracker & Wiki]

#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-nightly,  |  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by gk):

 * keywords:  ff68-esr, tbb-9.0-must-nightly, TorBrowserTeam201908R =>
 ff68-esr, tbb-9.0-must-nightly, TorBrowserTeam201908
 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:44 acat]:
 > New branch: https://github.com/acatarineu/tor-browser/commits/30429+8
 >
 > It has latest missing desktop patches from tor-browser-60.8.0esr-9.0-1,
 the latest updater patches, backported #27601
 (https://bugzilla.mozilla.org/show_bug.cgi?id=1330467) and #28711
 (https://bugzilla.mozilla.org/show_bug.cgi?id=1474659) and I also added
 the missing changes to the patch for #25702, which was to copy the release
 `pref/firefox-branding.js` over the nightly and alpha ones, now that the
 updater patches are there.

 I'll comment separately on the onboarding patches in #28822. Here come the
 relevant comment for commits besides them:

 0c19ff1358931bfa1be03dca261ec4d84a9826ee -- okay

 The backported patches for bug 1330467 look mostly good. Part 7 as tiny
 mistake. You end up with:
 {{{
 -  // make sure principals with userContextId or firstPartyDomain use the
 same permissions
 +  // make sure principals with a firstPartyDomain use different
 permissions
Assert.equal(
  Ci.nsIPermissionManager.ALLOW_ACTION,
  pm.testPermissionFromPrincipal(principal6, TEST_PERMISSION)
);
Assert.equal(
 -Ci.nsIPermissionManager.ALLOW_ACTION,
 +Ci.nsIPermissionManager.UNKNOWN_ACTION,
  pm.testPermissionFromPrincipal(principal7, TEST_PERMISSION)
);
 }}}
 but the original is
 {{{
 -  // make sure principals with userContextId or firstPartyDomain use the
 same permissions
 +  // make sure principals with userContextId use the same permissions
Assert.equal(Ci.nsIPermissionManager.ALLOW_ACTION,
 pm.testPermissionFromPrincipal(principal6,
 TEST_PERMISSION));
 -  Assert.equal(Ci.nsIPermissionManager.ALLOW_ACTION,
 +  // make sure principals with a firstPartyDomain use different
 permissions
 +  Assert.equal(Ci.nsIPermissionManager.UNKNOWN_ACTION,
 pm.testPermissionFromPrincipal(principal7,
 TEST_PERMISSION));
 }}}

 cbe8a7e484d4217be86edb0e5cf81709bfe9df68 - okay (mabye squash with
 #25658?)
 1d4f025ccbefad61498044a1e7e1040e935fc736 - okay (mabye squash with
 #25658?)
 fb50127d4f55e8ec102be1a3f7316f96ae2fb578 - okay
 a96dc99a94a687cf4ed6f39ecb4bd09f60e63734 - okay
 849d7121914c595e78e35f068b099c46ba1c6e9a - okay

 I am still debating taking the permission API patches out of the final
 alpha branch. But for now (one or two nightlies) I let them in. So, fixing
 up the tiny mistake above should be a fixup then as I am about to push a
 68.1.0esr branch for further testing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31550 [Applications/Tor Browser]: Fix shellcheck (and related) issues in start-tor-browser

[Tor Bug Tracker & Wiki]

#31550: Fix shellcheck (and related) issues in start-tor-browser
+--
 Reporter:  nickm   |  Owner:  nickm
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201908R, tbb-tbm  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * cc: boklm (added)
 * keywords:  TorBrowserTeam201908R => TorBrowserTeam201908R, tbb-tbm


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31550 [Applications/Tor Browser]: Fix shellcheck (and related) issues in start-tor-browser

[Tor Bug Tracker & Wiki]

#31550: Fix shellcheck (and related) issues in start-tor-browser
--+--
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201908R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:   => TorBrowserTeam201908R


Comment:

 #24755 might be relevant here as well.

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

Re: [tor-bugs] #31550 [Applications/Tor Browser]: Fix shellcheck (and related) issues in start-tor-browser

[Tor Bug Tracker & Wiki]

#31550: Fix shellcheck (and related) issues in start-tor-browser
--+--
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 I've attached the patches.   The first patch should be uncontroversial;
 you may want to consider the others more carefully.  All are against the
 master branch of the tor-browser-build repository, which I hope is right.
 I haven't tested the output, since I can't get rbm working.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31550 [Applications/Tor Browser]: Fix shellcheck (and related) issues in start-tor-browser

[Tor Bug Tracker & Wiki]

#31550: Fix shellcheck (and related) issues in start-tor-browser
--+--
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * Attachment "0004-Exit-when-cd-fails.patch" added.


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

Re: [tor-bugs] #31550 [Applications/Tor Browser]: Fix shellcheck (and related) issues in start-tor-browser

[Tor Bug Tracker & Wiki]

#31550: Fix shellcheck (and related) issues in start-tor-browser
--+--
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * Attachment "0005-Put-curly-quotes-inside-single-quotes-so-
 shellcheck-.patch" added.


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

Re: [tor-bugs] #31550 [Applications/Tor Browser]: Fix shellcheck (and related) issues in start-tor-browser

[Tor Bug Tracker & Wiki]

#31550: Fix shellcheck (and related) issues in start-tor-browser
--+--
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * Attachment "0002-Tolerate-the-case-when-TORARCHITECTURE-is.patch" added.


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

Re: [tor-bugs] #31550 [Applications/Tor Browser]: Fix shellcheck (and related) issues in start-tor-browser

[Tor Bug Tracker & Wiki]

#31550: Fix shellcheck (and related) issues in start-tor-browser
--+--
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * Attachment "0003-Stop-using-a-heredoc-in-start-tor-browser.patch" added.


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

[tor-bugs] #31550 [Applications/Tor Browser]: Fix shellcheck (and related) issues in start-tor-browser

[Tor Bug Tracker & Wiki]

#31550: Fix shellcheck (and related) issues in start-tor-browser
--+--
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 I got a warning when I was running the script, so I ran shellcheck on it
 and got a bunch of warnings.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31550 [Applications/Tor Browser]: Fix shellcheck (and related) issues in start-tor-browser

[Tor Bug Tracker & Wiki]

#31550: Fix shellcheck (and related) issues in start-tor-browser
--+--
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * Attachment "0001-start-tor-browser-fix-most-shellcheck-warnings.patch"
 added.


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

Re: [tor-bugs] #29207 [Circumvention/Snowflake]: New design for broker -- proxy protocol for snowflakes

[Tor Bug Tracker & Wiki]

#29207: New design for broker -- proxy protocol for snowflakes
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  enhancement  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, design, ex-sponsor-19,|  Actual Points:
  anti-censorship-roadmap|
Parent ID:   | Points:  5
 Reviewer:   |Sponsor:
 |  Sponsor28-must
-+-

Comment (by cohosh):

 === Summary of how things work now ===

 Note: see [https://github.com/ahf/snowflake-
 notes/blob/master/Broker.markdown Broker.markdown] for documentation of
 the Snowflake broker. This is a more specific proxy-focused break down of
 the messages sent.

  Proxy Poll 
 The proxy sends
 {{{
 POST [broker URL] HTTP [version]
 X-Session-ID: [session id]

 [session id]
 }}}
 and the broker confirms that the session id given in the header matches
 that given in the body.

 The broker then responds with one of three messages:
 - If the session ID in the header did not match the session ID in the
 body, it sends:
 {{{
  HTTP 400 Bad Request
 }}}
 - If there is a client matched to the proxy, it sends:
 {{{
  HTTP 200 OK

 {
 type: offer
 sdp: [WebRTC SDP]

 }

 }}}
 where the HTTP response body is a serialized WebRTC Session description
 offer
 - If there are no clients matched the proxy, it sends:
 {{{
  HTTP 504 Gateway Timeout
 }}}
  Proxy Answers 
 The proxy sends
 {{{
 POST [broker URL] HTTP[version]
 X-Session-ID: [session id]

 {
 type: answer
 sdp: [WebRTC SDP]
 }
 }}}
 where the HTTP response body is a serialized WebRTC Session description
 answer.

 The broker then uses the provided session ID to match this answer with the
 correct snowflake and provides one of three responses:
 - If the proxy took too long to respond, it sends:
 {{{
  HTTP 410 Gone
 }}}
 - If the body of the POST request was empty or surpassed the read limit,
 it sends:
 {{{
  HTTP 400 Bad Request
 }}}
 - If the answer was sent to the client, it sends:
 {{{
  HTTP 200 OK
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29611 [Applications/Tor Browser]: Work around lack of app.update.enabled pref in Firefox 63+

[Tor Bug Tracker & Wiki]

#29611: Work around lack of app.update.enabled pref in Firefox 63+
-+-
 Reporter:  dcf  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  meek, moat, tbb-update, ff68-esr,|  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by dcf):

 I documented these prefs in the meek webextension for future reference.
   https://gitweb.torproject.org/pluggable-
 transports/meek.git/commit/?id=09754cb550795da768797d63dd57bc732f268c65
   https://gitweb.torproject.org/pluggable-
 transports/meek.git/commit/?id=ec018dd67720587056d8d7d690368c9dbdd4942a

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31476 [Core Tor/Tor]: Practracker: document new features

[Tor Bug Tracker & Wiki]

#31476: Practracker: document new features
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  practracker, tech-debt,  |  Actual Points:  .1
  refactoring, easy, 041-deferred-20190530,  |
  network-team-roadmap-july, dgoulet-merge   |
Parent ID:  #29746   | Points:  .2
 Reviewer:  catalyst |Sponsor:
 |  Sponsor31-must
-+-
Changes (by catalyst):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:2 nickm]:
 > See branch #31476 with PR at https://github.com/torproject/tor/pull/1246
 Thanks! Mostly looks good. I would like to use something other than "H
 file" to refer to header files, though, because it can be a little
 confusing. As far as I know, we don't write anything in a programming
 language called "H". Maybe ".c files" and ".h file"? or "C files" and
 "header files"?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28381 [Applications/Tor Browser]: Oreo adaptive icon shape

[Tor Bug Tracker & Wiki]

#28381: Oreo adaptive icon shape
---+--
 Reporter:  cepxuo |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-mobile, ux-team, ff68-esr  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by sysrqb):

 * keywords:  tbb-mobile, ux-team => tbb-mobile, ux-team, ff68-esr


Comment:

 If we enable the "search widget", then we'll want [https://searchfox.org
 /mozilla-esr68/source/mobile/android/branding/official/res/drawable-
 xhdpi/search_widget_preview.png adaptive icons] for that, 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] #30704 [Circumvention/Snowflake]: Plan for snowflake update versioning and backwards compatability

[Tor Bug Tracker & Wiki]

#30704: Plan for snowflake update versioning and backwards compatability
-+
 Reporter:  cohosh   |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Description changed by cohosh:

Old description:

> We have some upcoming changes that will change the way snowflake
> components talk to each other. We should decide (and possibly on a case-
> by-case basis) how to handle these updates.
> - Do we make sure changes are backwards compatible with clients/proxies
> that haven't updated yet?
> - Should we think about introducing some concept of versioning?
> - If we support older versions, how long until we no longer support them?
>
> Some examples of tickets that we'll need to think about this for:
> - #25429
> - #29206
> - #25985

New description:

 We have some upcoming changes that will change the way snowflake
 components talk to each other. We should decide (and possibly on a case-
 by-case basis) how to handle these updates.
 - Do we make sure changes are backwards compatible with clients/proxies
 that haven't updated yet?
 - Should we think about introducing some concept of versioning?
 - If we support older versions, how long until we no longer support them?

 Some examples of tickets that we'll need to think about this for:
 - #25429
 - #29206
 - #29207
 - #25985

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29207 [Circumvention/Snowflake]: New design for broker -- proxy protocol for snowflakes

[Tor Bug Tracker & Wiki]

#29207: New design for broker -- proxy protocol for snowflakes
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  enhancement  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, design, ex-sponsor-19,|  Actual Points:
  anti-censorship-roadmap|
Parent ID:   | Points:  5
 Reviewer:   |Sponsor:
 |  Sponsor28-must
-+-
Changes (by cohosh):

 * priority:  Very High => High
 * type:  task => enhancement


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

Re: [tor-bugs] #29207 [Circumvention/Snowflake]: New design for broker -- proxy protocol for snowflakes

[Tor Bug Tracker & Wiki]

#29207: New design for broker -- proxy protocol for snowflakes
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  task | Status:
 |  assigned
 Priority:  Very High|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, design, ex-sponsor-19,|  Actual Points:
  anti-censorship-roadmap|
Parent ID:   | Points:  5
 Reviewer:   |Sponsor:
 |  Sponsor28-must
-+-
Changes (by cohosh):

 * owner:  ahf => cohosh


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27841 [Core Tor/Tor]: Surprise race: Intro point closes circuit after NACK, at the same time as client tries to extend circuit to new intro point

[Tor Bug Tracker & Wiki]

#27841: Surprise race: Intro point closes circuit after NACK, at the same time 
as
client tries to extend circuit to new intro point
-+-
 Reporter:  asn  |  Owner:  neel
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs dos 035-backport  |  Actual Points:
  040-backport 041-backport  |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor27
-+-

Comment (by nickm):

 I opened #31549 for just removing old tors from the directory at last.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31549 [Core Tor/Tor]: Authorities should stop listing relays running pre-0.2.9, or running 0.3.0 through 0.3.4

[Tor Bug Tracker & Wiki]

#31549: Authorities should stop listing relays running pre-0.2.9, or running 
0.3.0
through 0.3.4
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  042-can
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 The release series 0.3.0 through 0.3.4 are no longer supported, and we
 have encountered at least one bug (#27841)  caused by them lingering on
 the network.

 We should have the authorities stop listing them in their votes.  The
 patch here is simple enough -- we just edit dirserv_get_status_impl to
 reject everything newer than "0.3.0.0" and less new than "0.3.5.x" (for
 some well chosen "x").

 But before we do this, we should take necessary steps to contact operators
 and let them know that they really really need to upgrade.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27841 [Core Tor/Tor]: Surprise race: Intro point closes circuit after NACK, at the same time as client tries to extend circuit to new intro point

[Tor Bug Tracker & Wiki]

#27841: Surprise race: Intro point closes circuit after NACK, at the same time 
as
client tries to extend circuit to new intro point
-+-
 Reporter:  asn  |  Owner:  neel
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs dos 035-backport  |  Actual Points:
  040-backport 041-backport  |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor27
-+-

Comment (by nickm):

 It's possible, but would require a new consensus method.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31509 [Core Tor/Tor]: config refactor: make test-stem should pass

[Tor Bug Tracker & Wiki]

#31509: config refactor: make test-stem should pass
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  assigned
 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:   |Sponsor:  Sponsor31-must
-+-

Comment (by nickm):

 Should this still be assigned to me?  The issues here are (you say) all
 stem bugs.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27841 [Core Tor/Tor]: Surprise race: Intro point closes circuit after NACK, at the same time as client tries to extend circuit to new intro point

[Tor Bug Tracker & Wiki]

#27841: Surprise race: Intro point closes circuit after NACK, at the same time 
as
client tries to extend circuit to new intro point
-+-
 Reporter:  asn  |  Owner:  neel
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs dos 035-backport  |  Actual Points:
  040-backport 041-backport  |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor27
-+-

Comment (by dgoulet):

 Replying to [comment:31 nickm]:
 > Is there a flag we can stop giving them?

 We would need to remove HSIntro=4 basically from the 032, 033 and 034
 relays so the service will go in legacy mode and this bug is not in the
 legacy code.

 Not sure the authorities can do that :S

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

Re: [tor-bugs] #27841 [Core Tor/Tor]: Surprise race: Intro point closes circuit after NACK, at the same time as client tries to extend circuit to new intro point

[Tor Bug Tracker & Wiki]

#27841: Surprise race: Intro point closes circuit after NACK, at the same time 
as
client tries to extend circuit to new intro point
-+-
 Reporter:  asn  |  Owner:  neel
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs dos 035-backport  |  Actual Points:
  040-backport 041-backport  |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor27
-+-

Comment (by nickm):

 Is there a flag we can stop giving them?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28896 [Applications/Tor Browser]: Make sure our bundled WebExtensions are running in Private Browsing Mode

[Tor Bug Tracker & Wiki]

#28896: Make sure our bundled WebExtensions are running in Private Browsing Mode
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  task| Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ff68-esr TorBrowserTeam201908R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
|  Sponsor44-can
+--
Changes (by acat):

 * status:  new => needs_review
 * keywords:  ff68-esr => ff68-esr TorBrowserTeam201908R


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27841 [Core Tor/Tor]: Surprise race: Intro point closes circuit after NACK, at the same time as client tries to extend circuit to new intro point

[Tor Bug Tracker & Wiki]

#27841: Surprise race: Intro point closes circuit after NACK, at the same time 
as
client tries to extend circuit to new intro point
-+-
 Reporter:  asn  |  Owner:  neel
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs dos 035-backport  |  Actual Points:
  040-backport 041-backport  |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor27
-+-

Comment (by dgoulet):

 Replying to [comment:29 nickm]:
 > I remember that yesterday you were showing me logs that involved an
 intropoint on a relay that still had 0.3.4.  Maybe it's time to tell the
 authorities to stop listing these?

 That is how I found this issue, by running intro points on 0.3.4.9 ... so
 either that or we patch clients to stop selecting them.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30845 [Applications/Tor Browser]: Make sure default Firefox themes are enabled on ESR68

[Tor Bug Tracker & Wiki]

#30845: Make sure default Firefox themes are enabled on ESR68
-+-
 Reporter:  acat |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, TorBrowserTeam201908R, |  Actual Points:
  tbb-9.0-must-alpha |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by acat):

 * status:  new => needs_review
 * keywords:  ff68-esr, TorBrowserTeam201908, tbb-9.0-must-alpha =>
 ff68-esr, TorBrowserTeam201908R, tbb-9.0-must-alpha


Comment:

 Patch in https://www.github.com/acatarineu/tor-browser/commit/30845

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27841 [Core Tor/Tor]: Surprise race: Intro point closes circuit after NACK, at the same time as client tries to extend circuit to new intro point

[Tor Bug Tracker & Wiki]

#27841: Surprise race: Intro point closes circuit after NACK, at the same time 
as
client tries to extend circuit to new intro point
-+-
 Reporter:  asn  |  Owner:  neel
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs dos 035-backport  |  Actual Points:
  040-backport 041-backport  |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor27
-+-

Comment (by nickm):

 I remember that yesterday you were showing me logs that involved an
 intropoint on a relay that still had 0.3.4.  Maybe it's time to tell the
 authorities to stop listing these?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31495 [Core Tor/Tor]: cannot configure bridges

[Tor Bug Tracker & Wiki]

#31495: cannot configure bridges
---+
 Reporter:  mcs|  Owner:  nickm
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor   |Version:  Tor: unspecified
 Severity:  Normal | Resolution:
 Keywords:  regression, tbb-needs  |  Actual Points:  .1
Parent ID:  #29211 | Points:
 Reviewer: |Sponsor:  Sponsor31-must
---+
Changes (by nickm):

 * status:  accepted => needs_review
 * actualpoints:   => .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] #27841 [Core Tor/Tor]: Surprise race: Intro point closes circuit after NACK, at the same time as client tries to extend circuit to new intro point

[Tor Bug Tracker & Wiki]

#27841: Surprise race: Intro point closes circuit after NACK, at the same time 
as
client tries to extend circuit to new intro point
-+-
 Reporter:  asn  |  Owner:  neel
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs dos 035-backport  |  Actual Points:
  040-backport 041-backport  |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor27
-+-
Changes (by dgoulet):

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


Comment:

 Replying to [comment:27 cypherpunks]:
 > > Merged into 035 and master.
 > Wasn't that you?

 It was indeed... hmm it appears the "no backport" discussion was about <=
 034 ... And they are EOL... damn.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31495 [Core Tor/Tor]: cannot configure bridges

[Tor Bug Tracker & Wiki]

#31495: cannot configure bridges
---+
 Reporter:  mcs|  Owner:  nickm
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor   |Version:  Tor: unspecified
 Severity:  Normal | Resolution:
 Keywords:  regression, tbb-needs  |  Actual Points:
Parent ID:  #29211 | Points:
 Reviewer: |Sponsor:  Sponsor31-must
---+

Comment (by nickm):

 See branch `bug31495` with PR at
 https://github.com/torproject/tor/pull/1269

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31396 [Applications/Tor Browser]: Communication with noscript for security settings not working in nightlies

[Tor Bug Tracker & Wiki]

#31396: Communication with noscript for security settings not working in 
nightlies
-+-
 Reporter:  acat |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, TorBrowserTeam201908R, |  Actual Points:
  tbb-9.0-must-alpha |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by acat):

 * keywords:  ff68-esr, TorBrowserTeam201908, tbb-9.0-must-alpha =>
 ff68-esr, TorBrowserTeam201908R, tbb-9.0-must-alpha
 * status:  needs_information => needs_review


Comment:

 Patch: https://github.com/acatarineu/tor-browser/commit/31396

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31495 [Core Tor/Tor]: cannot configure bridges

[Tor Bug Tracker & Wiki]

#31495: cannot configure bridges
---+
 Reporter:  mcs|  Owner:  nickm
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor   |Version:  Tor: unspecified
 Severity:  Normal | Resolution:
 Keywords:  regression, tbb-needs  |  Actual Points:
Parent ID:  #29211 | Points:
 Reviewer: |Sponsor:  Sponsor31-must
---+

Comment (by nickm):

 I've got a fix for this, but I want to include tests and comments.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27841 [Core Tor/Tor]: Surprise race: Intro point closes circuit after NACK, at the same time as client tries to extend circuit to new intro point

[Tor Bug Tracker & Wiki]

#27841: Surprise race: Intro point closes circuit after NACK, at the same time 
as
client tries to extend circuit to new intro point
-+-
 Reporter:  asn  |  Owner:  neel
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs dos 035-backport  |  Actual Points:
  040-backport 041-backport  |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor27
-+-

Comment (by cypherpunks):

 > Merged into 035 and master.
 Wasn't that you?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27841 [Core Tor/Tor]: Surprise race: Intro point closes circuit after NACK, at the same time as client tries to extend circuit to new intro point

[Tor Bug Tracker & Wiki]

#27841: Surprise race: Intro point closes circuit after NACK, at the same time 
as
client tries to extend circuit to new intro point
-+-
 Reporter:  asn  |  Owner:  neel
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs dos 035-backport  |  Actual Points:
  040-backport 041-backport  |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor27
-+-
Changes (by dgoulet):

 * status:  closed => reopened
 * keywords:  tor-hs dos => tor-hs dos 035-backport 040-backport
   041-backport
 * resolution:  fixed =>


Comment:

 I would like us to strongly reconsider the backport this back down to 035.
 Reason is that it is really badly affecting tor clients and thus HS
 reachability. Here is how/why:

 (The following considers that every time the client reaches the intro
 point, it gets NACKed because it has the old descriptor.)

 1. The obvious issue is that tor clients gets the intro circuit destroyed
 while it is trying to re-extend to a new IP. This itself, requires the
 client to do many round trips before noticing and then re-opening a new
 circuit to see the same again until all 3 IP have failed.

 2. This one is a more serious issue.

  I've experienced during my testing a client looping over all IPs trying
 to establish an intro point but instead getting its circuit `TRUNCATED`
 for internal reason just _after_ sending the `INTRODUCE1` cell. This is
 not seen as an "intro failure" by the client so the intro point will be
 retried.

  However, how can we get a `TRUNCATED` _before_ the `INTRODUCE_ACK` nack-
 ing our request? This behavior I've seen a lot where a client can make
 20-30 tries before it finally gets a NACK.

  The reason I believe is in our cell scheduler: When selecting an active
 channel, we ask the cmux subsystem to give the first active circuit queue,
 this is done in `circuitmux_get_first_active_circuit()`. But, we alternate
 between `DESTROY` cell queue and the RELAY cell queue.

  When the intro point sends a NACK, it first queues the `INTRODUCE_ACK`
 cell and then, because of this bug still everywhere in the network, it
 queues a `DESTROY` just after. Then our scheduler, at that point in time,
 decides to send the `DESTROY` _before_ the ack resulting in our client
 receiving a truncated cell, not noticing the NACK and thus retrying the
 same intro point after.

  If no `DESTROY` cells were sent on the channel cmux yet, then it is
 prioritized from the relay cell. So, it is not actually 1/2 chance of
 hitting this, I believe it is much high probability to hit the issue I
 just described especially on smaller relays.

 Considering the above, I'm strongly asking for 035, 040 and 041 backport.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26878 [Community/Translations]: translation bot publishes incomplete translations on the translation_completed branches

[Tor Bug Tracker & Wiki]

#26878: translation bot publishes incomplete translations on the
translation_completed branches
+--
 Reporter:  emmapeel|  Owner:  emmapeel
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Community/Translations  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by emmapeel):

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


Comment:

 yes! fixed with https://gitweb.torproject.org/translation-
 
tools.git/commit/update_translations?id=a24e9b0cba60137316f78d74dc87d17d9094b8e9

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31493 [Circumvention/Snowflake]: Add a version to the metrics output

[Tor Bug Tracker & Wiki]

#31493: Add a version to the metrics output
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+--

Comment (by cohosh):

 Replying to [comment:5 karsten]:
 > In dir-spec, lines starting with `@` are treated as annotations that
 ''precede'' a descriptor and that can be stripped off without changing the
 descriptor. Including such a line inside a descriptor might be
 problematic.
 >
 > But after reading this ticket and #29461, I wonder if my suggestion to
 add a version number was bad advice. After all, we already have
 `snowflake-stats-end` in the first line as unique identifier of this
 descriptor type. And if something in the data format changes, there will
 be a specification update introducing new lines anyway. It's probably not
 worth the effort to update existing specification, implementation, and
 data to add something that we probably won't need. Can I take this
 suggestion back and we leave the format unchanged? (Sorry!!)

 Thanks karsten and no worries, it's best to figure out how to make our
 lives easier in the future and plan for changes now. So if we do end up
 changing the specification later, will leaving out a version annotation be
 okay to deal with? I suppose we can archive old versions of the spec in
 the snowflake repo and make a note of when the change to the new spec was
 made. I agree now that I'm looking into the annotations more that it's
 best to leave it out of the descriptor itself.

 I'm looking at `https://metrics.torproject.org/collector.html` now and if
 the snowflake metrics are going to be archived there, it probably does
 make sense for them to have an annotation similar to all of the other
 archived metrics. Just to clarify how the annotations typically work,
 would we simply move the `"@type snowflake-stats 1.0"` line to before
 `snowflake-stats-end`? Do these other collected metrics provide
 annotations to CollecTor along with the metrics data in the GET request?
 Or are they added on your end?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31542 [Core Tor/Tor]: Cannot connect to IPv6 addresses using Tor SOCKS

[Tor Bug Tracker & Wiki]

#31542: Cannot connect to IPv6 addresses using Tor SOCKS
--+
 Reporter:  sega01|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.5
 Severity:  Normal| Resolution:
 Keywords:  042-should, ipv6  |  Actual Points:
Parent ID:  #26664| Points:
 Reviewer:|Sponsor:
--+

Comment (by sega01):

 Great, thank you! Let me know if you need anything else from me.

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

Re: [tor-bugs] #31396 [Applications/Tor Browser]: Communication with noscript for security settings not working in nightlies

[Tor Bug Tracker & Wiki]

#31396: Communication with noscript for security settings not working in 
nightlies
-+-
 Reporter:  acat |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, TorBrowserTeam201908,  |  Actual Points:
  tbb-9.0-must-alpha |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by acat):

 >In-memory IndexedDB is not ready. In-PBM too. Of course,
 extensions.webextensions.ExtensionStorageIDB.enabled for now.
 I don't think in-memory indexeddb will be used in webextensions, it will
 always persist.

 >Sounds like we should go with the other option for now. What are the
 drawbacks for that one?
 AFAIK the old implementation is synchronous and writes the whole key-value
 store to disk every time there is some change. But for reasonable usage of
 the storage (which noscript and https everywhere probably has) this should
 not be a problem.

 There is some migration code that is ran when
 `extensions.webextensions.ExtensionStorageIDB.enabled` which might be
 removed in the future, but I think that should not be an issue at least
 until next ESR.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31541 [Core Tor/Tor]: hs-v3: Client can re-pick bad intro points

[Tor Bug Tracker & Wiki]

#31541: hs-v3: Client can re-pick bad intro points
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Major| Resolution:  invalid
 Keywords:  tor-hs tor-client 035-backport,  |  Actual Points:
  040-backport, 041-backport |
Parent ID:  #30200   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-must
-+-
Changes (by dgoulet):

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


Comment:

 I'm invalidating this one. The issue is not on the client side IP failure
 cache as far as I can tell.

 There seems to be issues with intro circuit being `TRUNCATED` for which
 the client doesn't consider that a failure and thus repeats quite a bit. I
 haven't figured out yet why IP circuit get truncated like that after an
 INTRO1 cell is sent.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30665 [Applications/Tor Browser]: Get Firefox 68 ESR Working with latest android toolchain

[Tor Bug Tracker & Wiki]

#30665: Get Firefox 68 ESR Working with latest android toolchain
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  nightly, TorBrowserTeam201908  |
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by sisbell):

 Those missing dependencies are in 0827-patched branch (not in 0827 branch,
 which doesn't require them). I think you need to clean out your gradle-
 dependencies-6 cache prior to building.

 Replying to [comment:10 gk]:
 > Replying to [comment:8 sisbell]:
 > > I have branch esr68_0827. This is based off of 9.0-3 branch.
 > >
 > > Branch esr68_0827-patched is based off of
 https://git.torproject.org/user/sysrqb/tor-browser.git :
 2dbb7aefeaeb0499ac69c67df470e2ed6df8cb71.
 > >
 > > Overall it looks very good. The patched branch builds and I tested the
 armv7 apk on Android Q. Tor starts and I'm able to access an external
 site.
 >
 > Compilation does not work for me if I build the x86 target at least. My
 `tor-browser-build` repo is at 571d14f36daa6dd1162803882475eae6ff20d3df.
 And I've pointed my `firefox` config to `2dbb7aefea` for the nightly
 target and started the build with `make nightly-android-x86`. What I get
 is an error early in the browser step:
 > {{{
 >  0:51.43 FAILURE: Build failed with an exception.
 >  0:51.43 * What went wrong:
 >  0:51.43 Could not resolve all files for configuration
 ':app:withoutGeckoBinariesDebugAndroidTestRuntimeClasspath'.
 >  0:51.43 > Could not resolve net.freehaven.tor.control:jtorctl:0.2.
 >  0:51.43   Required by:
 >  0:51.43   project :app
 >  0:51.43> No cached version of net.freehaven.tor.control:jtorctl:0.2
 available for offline mode.
 >  0:51.43> No cached version of net.freehaven.tor.control:jtorctl:0.2
 available for offline mode.
 >  0:51.43> No cached version of net.freehaven.tor.control:jtorctl:0.2
 available for offline mode.
 >  0:51.43 > Could not resolve org.slf4j:slf4j-api:1.7.25.
 >  0:51.43   Required by:
 >  0:51.43   project :app
 >  0:51.43> No cached version of org.slf4j:slf4j-api:1.7.25 available
 for offline mode.
 >  0:51.43> No cached version of org.slf4j:slf4j-api:1.7.25 available
 for offline mode.
 >  0:51.43> No cached version of org.slf4j:slf4j-api:1.7.25 available
 for offline mode.
 >  0:51.43 > Could not resolve org.slf4j:slf4j-android:1.7.25.
 >  0:51.43   Required by:
 >  0:51.43   project :app
 >  0:51.43> No cached version of org.slf4j:slf4j-android:1.7.25
 available for offline mode.
 >  0:51.43> No cached version of org.slf4j:slf4j-android:1.7.25
 available for offline mode.
 >  0:51.43> No cached version of org.slf4j:slf4j-android:1.7.25
 available for offline mode.
 > }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31240 [Core Tor/Tor]: Make confparse able to handle multiple config_format_t objects at once

[Tor Bug Tracker & Wiki]

#31240: Make confparse able to handle multiple config_format_t objects at once
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-august  |  Actual Points:  3
Parent ID:  #29211   | Points:  3
 Reviewer:  teor |Sponsor:  Sponsor31-can
-+-
Changes (by nickm):

 * 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] #31240 [Core Tor/Tor]: Make confparse able to handle multiple config_format_t objects at once

[Tor Bug Tracker & Wiki]

#31240: Make confparse able to handle multiple config_format_t objects at once
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-august  |  Actual Points:  3
Parent ID:  #29211   | Points:  3
 Reviewer:  teor |Sponsor:  Sponsor31-can
-+-

Comment (by nickm):

 I've answered the questions on the ticket; your conclusions were correct.

 To fix the commit message, I've done a rebase of the orignal branch, plus
 the commits on the merge branch.  This has created a new branch, called
 `ticket31240v2`, and a new merge branch, `ticket31240v2_merged_2`.  The
 new PR is at https://github.com/torproject/tor/pull/1268 .

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30080 [Webpages/Support]: support portal: keep anchor when changing language

[Tor Bug Tracker & Wiki]

#30080: support portal: keep anchor when changing language
--+--
 Reporter:  emmapeel  |  Owner:  hiro
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Webpages/Support  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by emmapeel):

 oops, my bad, you are right.

  i didn't actually tested the description, but only
 https://support.torproject.org/connecting/connecting-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] #31491 [Applications/Tor Launcher]: clean up the old meek http helper browser profiles

[Tor Bug Tracker & Wiki]

#31491: clean up the old meek http helper browser profiles
-+-
 Reporter:  mcs  |  Owner:  mcs
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Launcher|Version:
 Severity:  Normal   | Resolution:
 Keywords:  meek, utls, ff68-esr, tbb-9.0-must-  |  Actual Points:
  alpha, TorBrowserTeam201909|
Parent ID:  #29430   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by brade):

 * cc: dcf (added)


Comment:

 Since it will not be harmful to leave the unused meek helper profiles on
 disk for a little while, Mark and I do not plan to work on this before the
 first ESR68-based alpha. We believe this task can wait until the next
 alpha release (assuming we make additional alpha releases before our first
 stable release).

 cc: dcf to make them aware that Tor Browser will (soon) automatically
 remove the old meek helper profiles (which might be surprising if they are
 using them for testing).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30080 [Webpages/Support]: support portal: keep anchor when changing language

[Tor Bug Tracker & Wiki]

#30080: support portal: keep anchor when changing language
--+--
 Reporter:  emmapeel  |  Owner:  hiro
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Webpages/Support  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


Comment:

 No.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31241 [Core Tor/Tor]: Refactor config validation

[Tor Bug Tracker & Wiki]

#31241: Refactor config validation
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  task | Status:  needs_revision
 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:  1.5
 Reviewer:   |Sponsor:  Sponsor31-can
-+-

Comment (by nickm):

 Based on review and backlog, I think I should postpone working on this
 branch till after #31240 is merged, and after we've caught up with other
 backlog.  This will probably cause other conflicts as I re-create a new
 version of this branch, but so be it.

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

Re: [tor-bugs] #28238 [Applications/Tor Browser]: Use mingw-w64/clang toolchain to build Firefox

[Tor Bug Tracker & Wiki]

#28238: Use mingw-w64/clang toolchain to build Firefox
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-rbm, tbb-9.0-must-nightly,   |  Actual Points:
  TorBrowserTeam201908R, GeorgKoppen201908   |
Parent ID:  #30322   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

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


Comment:

 Ok, I merged it to master as commits
 8aeb04965f9993b7572c7fe98d9ad3e0b2fe4453,
 6ca067d2d716283c47c6b2fb822305e61b16e168,
 9b4b31f5bacfffb2b35e914fe5535999c7db45e1,
 84d95d6d2a51d93f62e9927cfa2e63e674066c7d and
 023ce30eb3c6082af3353fe6876c202d849cfea8.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29430 [Applications/Tor Browser]: Use uTLS for meek TLS camouflage in Tor Browser

[Tor Bug Tracker & Wiki]

#29430: Use uTLS for meek TLS camouflage in Tor Browser
-+-
 Reporter:  dcf  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  meek, utls, ff68-esr,|  Actual Points:
  TorBrowserTeam201908   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by brade):

 * keywords:  meek, utls, ff68-esr, TorBrowserTeam201908R => meek, utls,
 ff68-esr, TorBrowserTeam201908


Comment:

 Replying to [comment:36 cypherpunks]:
 > `TorBrowserTeam201908R`->`TorBrowserTeam201908`
 Thanks. Fixed.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28716 [Applications/Tor Browser]: Create a mingw-w64-clang project

[Tor Bug Tracker & Wiki]

#28716: Create a mingw-w64-clang project
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-rbm, tbb-9.0-must-nightly,   |  Actual Points:
  TorBrowserTeam201908R, GeorgKoppen201908   |
Parent ID:  #28238   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

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


Comment:

 This is fixed with commits 8aeb04965f9993b7572c7fe98d9ad3e0b2fe4453 and
 6ca067d2d716283c47c6b2fb822305e61b16e168.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30080 [Webpages/Support]: support portal: keep anchor when changing language

[Tor Bug Tracker & Wiki]

#30080: support portal: keep anchor when changing language
--+
 Reporter:  emmapeel  |  Owner:  hiro
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Support  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by emmapeel):

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


Comment:

 this works now

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

Re: [tor-bugs] #31396 [Applications/Tor Browser]: Communication with noscript for security settings not working in nightlies

[Tor Bug Tracker & Wiki]

#31396: Communication with noscript for security settings not working in 
nightlies
-+-
 Reporter:  acat |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, TorBrowserTeam201908,  |  Actual Points:
  tbb-9.0-must-alpha |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by cypherpunks):

 In-memory IndexedDB is not ready. In-PBM too. Of course,
 `extensions.webextensions.ExtensionStorageIDB.enabled` for now.

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

Re: [tor-bugs] #31010 [Applications/Tor Browser]: Rebase Tor Browser mobile/ patches for Firefox ESR 68

[Tor Bug Tracker & Wiki]

#31010: Rebase Tor Browser mobile/ patches for Firefox ESR 68
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-9.0-must-nightly,|  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:  #30429   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Replying to [comment:14 sysrqb]:
 > Replying to [comment:11 acat]:
 > > Some comments on acat30429+5_tor-browser_android_68esr_39:

 > > 805a0b25be322d44138bae0d3a862070c9348fea
 > > {{{
 > >   +// Avoid throwing an error because Ci.nsIPushService isn't
 implemented
 > >   +// All other clearing actions should succeed if we arrive
 here.
 > >   +Promise.resolve();
 > > }}}
 > >   Promise.resolve(); is not really doing anything I think.
 >
 > I don't actually know. I'll try testing this without that line and see
 if it still works.
 >

 It seems like you're correct, we don't need this. However, I don't know if
 we should keep this such that the code is more readable/easier to
 understand? Alternatively, I can delete the `resolve()` line and modify
 the comment.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31548 [Core Tor/Tor]: hs-v3: Service can pick more than HiddenServiceNumIntroductionPoints intro points

[Tor Bug Tracker & Wiki]

#31548: hs-v3: Service can pick more than HiddenServiceNumIntroductionPoints 
intro
points
+--
 Reporter:  dgoulet |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  |   Keywords:  tor-hs service hs-v3
Actual Points:  |  Parent ID:  #29995
   Points:  |   Reviewer:
  Sponsor:  Sponsor27-must  |
+--
 During my testing of #30200, I ended up with service descriptor with 4
 intro points even though `HiddenServiceNumIntroductionPoints` is set to 3
 (default).

 Further investigation confirmed this by adding a log in the
 `decode_intro_points()` function which showed me 4 intro points.

 I haven't found out why but one feature of HS is that we launch
 `HiddenServiceNumIntroductionPoints` + 2 intro circuits in parallel and
 the first one to finish are picked.

 It appears that more than the defined value can finish at the same time
 and will be picked.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31396 [Applications/Tor Browser]: Communication with noscript for security settings not working in nightlies

[Tor Bug Tracker & Wiki]

#31396: Communication with noscript for security settings not working in 
nightlies
-+-
 Reporter:  acat |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, TorBrowserTeam201908,  |  Actual Points:
  tbb-9.0-must-alpha |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by gk):

 Replying to [comment:3 acat]:
 > The issue has to do with a indexedDB error (`InvalidStateError: A
 mutation operation was attempted on a database that did not allow
 mutations.`), which is thrown when noscript tries to store something via
 `browser.storage.local` API (when it receives the setting change message
 from torbutton). This API moved to a indexedDB implementation in 62.
 >
 > I tracked down the cause of indexedDB not working to the quota manager
 service clearing (`Services.qms.clear()`) in torbutton. This is done on
 startup and on `New Identity`.
 >
 > I can reproduce this also on Firefox 68:
 >
 > 1. Create a new profile.
 > 2. Install noscript from AMO.
 > 3. Set `dom.quotaManager.testing` pref to `true`.
 > 4. Call `Services.qms.clear()` in console.
 > 5. Set `dom.quotaManager.testing` pref to `false`.
 > 6. Open debug addon window for noscript in `about:debugging`.
 > 7. Run `browser.storage.local.set({foo:bar})`, it should throw
 `InvalidStateError: A mutation operation was attempted on a database that
 did not allow mutations.`.
 >
 > I think this does not affect indexeddb itself, but just the
 `browser.storage.*` implementation that uses indexeddb internally. I
 suspect `Services.qms.clear()` must be clearing some internal indexedDB
 data that is preventing the webextension storage API from working
 properly.
 >
 > Not sure if this is really a bug from Firefox side, since probably we
 should not be calling `Services.qms.clear()` directly. But perhaps we can
 file one.

 Please do.

 > So we can solve this by not calling `Services.qms.clear()` (do we still
 need it? was it just for asm.js?). Or we can set
 `extensions.webextensions.ExtensionStorageIDB.enabled` to `false`, to use
 the previous non-indexedDB backend for `browser.storage.*`.

 Good questions. I don't know the answers without looking closer. Maybe we
 could file a ticket for that? Sounds like we should go with the other
 option for now. What are the drawbacks for that 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] #30665 [Applications/Tor Browser]: Get Firefox 68 ESR Working with latest android toolchain

[Tor Bug Tracker & Wiki]

#30665: Get Firefox 68 ESR Working with latest android toolchain
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  nightly, TorBrowserTeam201908  |
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by gk):

 Replying to [comment:8 sisbell]:
 > I have branch esr68_0827. This is based off of 9.0-3 branch.
 >
 > Branch esr68_0827-patched is based off of
 https://git.torproject.org/user/sysrqb/tor-browser.git :
 2dbb7aefeaeb0499ac69c67df470e2ed6df8cb71.
 >
 > Overall it looks very good. The patched branch builds and I tested the
 armv7 apk on Android Q. Tor starts and I'm able to access an external
 site.

 Compilation does not work for me if I build the x86 target at least. My
 `tor-browser-build` repo is at 571d14f36daa6dd1162803882475eae6ff20d3df.
 And I've pointed my `firefox` config to `2dbb7aefea` for the nightly
 target and started the build with `make nightly-android-x86`. What I get
 is an error early in the browser step:
 {{{
  0:51.43 FAILURE: Build failed with an exception.
  0:51.43 * What went wrong:
  0:51.43 Could not resolve all files for configuration
 ':app:withoutGeckoBinariesDebugAndroidTestRuntimeClasspath'.
  0:51.43 > Could not resolve net.freehaven.tor.control:jtorctl:0.2.
  0:51.43   Required by:
  0:51.43   project :app
  0:51.43> No cached version of net.freehaven.tor.control:jtorctl:0.2
 available for offline mode.
  0:51.43> No cached version of net.freehaven.tor.control:jtorctl:0.2
 available for offline mode.
  0:51.43> No cached version of net.freehaven.tor.control:jtorctl:0.2
 available for offline mode.
  0:51.43 > Could not resolve org.slf4j:slf4j-api:1.7.25.
  0:51.43   Required by:
  0:51.43   project :app
  0:51.43> No cached version of org.slf4j:slf4j-api:1.7.25 available
 for offline mode.
  0:51.43> No cached version of org.slf4j:slf4j-api:1.7.25 available
 for offline mode.
  0:51.43> No cached version of org.slf4j:slf4j-api:1.7.25 available
 for offline mode.
  0:51.43 > Could not resolve org.slf4j:slf4j-android:1.7.25.
  0:51.43   Required by:
  0:51.43   project :app
  0:51.43> No cached version of org.slf4j:slf4j-android:1.7.25
 available for offline mode.
  0:51.43> No cached version of org.slf4j:slf4j-android:1.7.25
 available for offline mode.
  0:51.43> No cached version of org.slf4j:slf4j-android:1.7.25
 available for offline mode.
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31396 [Applications/Tor Browser]: Communication with noscript for security settings not working in nightlies

[Tor Bug Tracker & Wiki]

#31396: Communication with noscript for security settings not working in 
nightlies
-+-
 Reporter:  acat |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, TorBrowserTeam201908,  |  Actual Points:
  tbb-9.0-must-alpha |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by acat):

 * status:  new => needs_information


Comment:

 The issue has to do with a indexedDB error (`InvalidStateError: A mutation
 operation was attempted on a database that did not allow mutations.`),
 which is thrown when noscript tries to store something via
 `browser.storage.local` API (when it receives the setting change message
 from torbutton). This API moved to a indexedDB implementation in 62.

 I tracked down the cause of indexedDB not working to the quota manager
 service clearing (`Services.qms.clear()`) in torbutton. This is done on
 startup and on `New Identity`.

 I can reproduce this also on Firefox 68:

 1. Create a new profile.
 2. Install noscript from AMO.
 3. Set `dom.quotaManager.testing` pref to `true`.
 4. Call `Services.qms.clear()` in console.
 5. Set `dom.quotaManager.testing` pref to `false`.
 6. Open debug addon window for noscript in `about:debugging`.
 7. Run `browser.storage.local.set({foo:bar})`, it should throw
 `InvalidStateError: A mutation operation was attempted on a database that
 did not allow mutations.`.

 I think this does not affect indexeddb itself, but just the
 `browser.storage.*` implementation that uses indexeddb internally. I
 suspect `Services.qms.clear()` must be clearing some internal indexedDB
 data that is preventing the webextension storage API from working
 properly.

 Not sure if this is really a bug from Firefox side, since probably we
 should not be calling `Services.qms.clear()` directly. But perhaps we can
 file one.

 So we can solve this by not calling `Services.qms.clear()` (do we still
 need it? was it just for asm.js?). Or we can set
 `extensions.webextensions.ExtensionStorageIDB.enabled` to `false`, to use
 the previous non-indexedDB backend for `browser.storage.*`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31541 [Core Tor/Tor]: hs-v3: Client can re-pick bad intro points

[Tor Bug Tracker & Wiki]

#31541: hs-v3: Client can re-pick bad intro points
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Major| Resolution:
 Keywords:  tor-hs tor-client 035-backport,  |  Actual Points:
  040-backport, 041-backport |
Parent ID:  #30200   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-must
-+-

Old description:

> Ok this one took me a while to figure out!
>
> This is sorta related to #25882 as it is a bug that makes the client
> retry constantly the same intro point even though it was flagged as
> having an error.
>
> Problem lies in `client_get_random_intro()` which randomly selects an
> intro point from the descriptor. Sparing the detail, this is where it
> goes wrong:
>
> {{{
> ip = smartlist_get(usable_ips, idx);
> smartlist_del(usable_ips, idx);
> }}}
>
> ... and then we use `ip` to check if usable and if yes, we connect to it.
>
> We can't `del()` the value from the list until we are done with the `ip`
> object. The `smartlist_get()` returns a pointer to location *in the list*
> so if we change the list order right after acquiring the reference, we
> are accessing bad things, possibly junk.
>
> So basically, junk can be used, the wrong IP can be used even though it
> would not pass the `intro_point_is_usable()` if it was correct pointer.
>
> I was able to find this using a pathological case where the HS pins its
> intro point to 3 specific nodes. So, even upon a restart or desc
> rotation, the same IPs are re-used but with different auth key.
>
> If a client had already connected to that service and thus had those IPs
> in its failure cache, it will fail to eternity to connect to the service
> because it basically never realize it needs to refetch a new descriptor.
>
> Even though there is a catch all with
> `hs_client_any_intro_points_usable()` before extending to an intro point,
> the problem lies with the above which can make the code NEVER pick a
> certain intro point so the catch all always validate to true since there
> is one intro point in the list that was never tried.
>
> This is very bad for reachability, network load, but also simple "code
> safety". I strongly recommend backport to our maintained version >= 032.
>
> Fortunately for us, the fix is trivial, we should only `del()` when done
> with the IP object.

New description:

 Ok this one took me a while to figure out!

 This is sorta related to #25882 as it is a bug that makes the client retry
 constantly the same intro point even though it was flagged as having an
 error.

 Problem lies in `client_get_random_intro()` which randomly selects an
 intro point from the descriptor. Sparing the detail, this is where it goes
 wrong:

 {{{
 ip = smartlist_get(usable_ips, idx);
 smartlist_del(usable_ips, idx);
 }}}
 ... and then we use `ip` to check if usable and if yes, we connect to it.

 ~~We can't `del()` the value from the list until we are done with the `ip`
 object. The `smartlist_get()` returns a pointer to location *in the list*
 so if we change the list order right after acquiring the reference, we are
 accessing bad things, possibly junk.~~

 ~~So basically, junk can be used, the wrong IP can be used even though it
 would not pass the `intro_point_is_usable()` if it was correct pointer.~~

 I was able to find this using a pathological case where the HS pins its
 intro point to 3 specific nodes. So, even upon a restart or desc rotation,
 the same IPs are re-used but with different auth key.

 If a client had already connected to that service and thus had those IPs
 in its failure cache, it will fail to eternity to connect to the service
 because it basically never realize it needs to refetch a new descriptor.

 Even though there is a catch all with
 `hs_client_any_intro_points_usable()` before extending to an intro point,
 the problem lies with the above which can make the code NEVER pick a
 certain intro point so the catch all always validate to true since there
 is one intro point in the list that was never tried.

 This is very bad for reachability, network load, but also simple "code
 safety". I strongly recommend backport to our maintained version >= 032.

 Fortunately for us, the fix is trivial, we should only `del()` when done
 with the IP object.

--

Comment (by dgoulet):

 Indeed, I actually was mistaken there 

Re: [tor-bugs] #31385 [Circumvention/Snowflake]: Snowflake client fails after bootstrap

[Tor Bug Tracker & Wiki]

#31385: Snowflake client fails after bootstrap
-+
 Reporter:  cypherpunks  |  Owner:  cohosh
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by amiableclarity2011):

 Replying to [comment:29 cohosh]:
 > Replying to [comment:25 amiableclarity2011]:
 > > Hello, currently, in China, I still can't open any webpage in 9.0a4
 version Tor browser through snowflake bridge. I can connect to Tor network
 through snowflake bridge. I upload my torrc-defaults file, my torrc file,
 my state file, my cached-microdescs.new file and my cached-descriptors
 file.
 >
 > Hi amiableclarity2011,
 >
 > As cypherpunks said, we've pushed a fix out for this ticket and it will
 take a while for updates to propagate. Hopefully your connection will
 improve soon.

 Thank you very much for your help. I really appreciate it.

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

Re: [tor-bugs] #28238 [Applications/Tor Browser]: Use mingw-w64/clang toolchain to build Firefox

[Tor Bug Tracker & Wiki]

#28238: Use mingw-w64/clang toolchain to build Firefox
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-9.0-must-nightly,   |  Actual Points:
  TorBrowserTeam201908R, GeorgKoppen201908   |
Parent ID:  #30322   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:52 boklm]:
 > The patches from branch `gk/bug_28238_v16` look good to me.
 >
 > I think a possible improvement is defining `var/setup` in
 `projects/mingw-w64-clang/config` so that we can define `var/compiler` in
 the projects where we want to use it:
 > https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_28238_v2=1510201478c07569466e1fea83873dd1ffb4c1ca
 > https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_28238_v2=d93e89635eae1718b0c44be0d698e998754d4289
 > https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_28238_v2=5ef691810ea0e4f97d9262283947298756b88507
 >
 > In branch `bug_28238_v3` I squashed the suggested fixup patches, and
 rebased on master:
 > https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/log/?h=bug_28238_v3
 >
 > I am currently testing a build with this branch.

 Works for me and the fixups look good.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31547 [Applications/Tor Browser]: Back out or modify patches for Mozilla's bug 1574980

[Tor Bug Tracker & Wiki]

#31547: Back out or modify patches for Mozilla's bug 1574980
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201908, tbb-update  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Tom has another approach
 https://bugzilla.mozilla.org/show_bug.cgi?id=1575975
 But who the heck added
 https://bugzilla.mozilla.org/show_bug.cgi?id=1572844#a1528159_580382 to
 
https://bugzilla.mozilla.org/buglist.cgi?f1=cf_status_firefox_esr68=equals
 =fix-optional ?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28238 [Applications/Tor Browser]: Use mingw-w64/clang toolchain to build Firefox

[Tor Bug Tracker & Wiki]

#28238: Use mingw-w64/clang toolchain to build Firefox
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-9.0-must-nightly,   |  Actual Points:
  TorBrowserTeam201908R, GeorgKoppen201908   |
Parent ID:  #30322   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 The patches from branch `gk/bug_28238_v16` look good to me.

 I think a possible improvement is defining `var/setup` in
 `projects/mingw-w64-clang/config` so that we can define `var/compiler` in
 the projects where we want to use it:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_28238_v2=1510201478c07569466e1fea83873dd1ffb4c1ca
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_28238_v2=d93e89635eae1718b0c44be0d698e998754d4289
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_28238_v2=5ef691810ea0e4f97d9262283947298756b88507

 In branch `bug_28238_v3` I squashed the suggested fixup patches, and
 rebased on master:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/log/?h=bug_28238_v3

 I am currently testing a build with this branch.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31547 [Applications/Tor Browser]: Back out or modify patches for Mozilla's bug 1574980

[Tor Bug Tracker & Wiki]

#31547: Back out or modify patches for Mozilla's bug 1574980
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  task | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  TorBrowserTeam201908,
 Severity:  Normal   |  tbb-update
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 The patches for bug 1574980 fix a security flaw in dealing with the
 maintenance service on Windows. We don't use that one, so we should be not
 affected. However, the way the fix was written is that it drags
 maintenance service related code into the general updater code: we build
 that now, too, which was not the case before. We don't want and need that
 and should either back out the whole patches (both for esr60 and esr68) or
 come up with a better solution.

 I guess due to time constraints we follow the former idea and try to write
 better patches later on (and get those upstreamed).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  nightly, TorBrowserTeam201908, |
  GeorgKoppen201908  |
Parent ID:  #30322   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 libtool?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30575 [Applications/Tor Browser]: "unable to connect" if Firefox GPOs configure proxy settings

[Tor Bug Tracker & Wiki]

#30575: "unable to connect" if Firefox GPOs configure proxy settings
-+-
 Reporter:  kT3Ycp9jwm   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-proxy-bypass,|  Actual Points:
  TorBrowserTeam201906, GeorgKoppen201906, tbb-  |
  backported |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:
 tbb-proxy-bypass, TorBrowserTeam201906, GeorgKoppen201906, tbb-
 backport
 =>
 tbb-proxy-bypass, TorBrowserTeam201906, GeorgKoppen201906, tbb-
 backported


Comment:

 Backported by cherry-picking the fix onto `tor-browser-60.8.0esr-8.5-1`
 (commit 85e9a040aea41cf3c926394da1bcf22a298bf081).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27503 [Applications/Tor Browser]: Disabling accessibility on Windows breaks screen readers

[Tor Bug Tracker & Wiki]

#27503: Disabling accessibility on Windows breaks screen readers
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-8.0-issues, tbb-regression,  |  Actual Points:
  GeorgKoppen201903, tbb-8.5,|
  TorBrowserTeam201907R, tbb-backported  |
Parent ID:   | Points:
 Reviewer:  boklm|Sponsor:
-+-
Changes (by gk):

 * keywords:
 tbb-8.0-issues, tbb-regression, GeorgKoppen201903, tbb-8.5,
 TorBrowserTeam201907R, tbb-backport
 =>
 tbb-8.0-issues, tbb-regression, GeorgKoppen201903, tbb-8.5,
 TorBrowserTeam201907R, tbb-backported


Comment:

 We try to include that fix in Tor Browser 8.5.5. I cherry-picked the
 relevant `tor-browser-build` patches` in commit
 75a80131971499cff36930b3eba75306749a1e5c and
 08145374a2249acd6aa90dd7705f632e8774c9d0. It seems we already had the
 needed `tor-browser` patch on our 8.5 branch, so we are good 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] #29013 [Applications/Tor Browser]: Provide stack smashing protection for mingw-clang builds

[Tor Bug Tracker & Wiki]

#29013: Provide stack smashing protection for mingw-clang builds
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201908,   |  Actual Points:
  GeorgKoppen201908  |
Parent ID:  #30322   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * parent:  #28238 => #30322


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31314 [Core Tor/Tor]: Modify git-merge-forward.sh so it can create test merge branches

[Tor Bug Tracker & Wiki]

#31314: Modify git-merge-forward.sh so it can create test merge branches
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  git-scripts, network-team-roadmap-   |  Actual Points:  0.8
  october|
Parent ID:  #31178   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  Sponsor31-must
-+-
Changes (by asn):

 * status:  needs_review => needs_revision


Comment:

 I'm happy with the answers.

 I did some testing with `-t` and `-u` and it seems to work fine. The code
 also seems fine. I was mostly worried about opening up to command
 injection issues based on the more complicated cmd evaluations, but I did
 not find anything suspicious, given that attacker-controlled arguments are
 branch names which can't contain special characters.

 I noticed that shellcheck is giving out a failure that we might want to
 fix:
 {{{
 In ./scripts/git/git-merge-forward.sh line 360:
   printf "%s Handling branch \\n" "$MARKER" "${BYEL}$target${CNRM}"
 ^-- SC2154: target is
 referenced but not assigned.
 }}}

 Also, a bit more docs to document the use of the test branch mode would be
 nice.

 Other than that, looks good to me!

 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] #30665 [Applications/Tor Browser]: Get Firefox 68 ESR Working with latest android toolchain

[Tor Bug Tracker & Wiki]

#30665: Get Firefox 68 ESR Working with latest android toolchain
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  nightly, TorBrowserTeam201908  |
Parent ID:  #30324   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by cypherpunks):

 Replying to [comment:8 sisbell]:
 > Branch esr68_0827-patched is based off of
 https://git.torproject.org/user/sysrqb/tor-browser.git :
 2dbb7aefeaeb0499ac69c67df470e2ed6df8cb71.
 Usually, the links to branches are provided. The link to the commit is
 https://gitweb.torproject.org/user/sysrqb/tor-
 browser.git/commit/?h=acat30429%2b5_tor-
 browser_android_68esr_53=2dbb7aefeaeb0499ac69c67df470e2ed6df8cb71

 Also `TorBrowserTeam201908R`, if it ` 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] #28238 [Applications/Tor Browser]: Use mingw-w64/clang toolchain to build Firefox

[Tor Bug Tracker & Wiki]

#28238: Use mingw-w64/clang toolchain to build Firefox
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-9.0-must-nightly,   |  Actual Points:
  TorBrowserTeam201908R, GeorgKoppen201908   |
Parent ID:  #30322   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:46 tom]:
 > > >  - fxc2 requires the winpthread dll to be in its bin directly IIRC;
 but I don't see where you're copying that. (I might have missed it. If
 you're not getting errors on fxc2 it must be working.)
 > >
 > > I think we don't need it when building with `mingw-w64-clang`. At
 least the build passes and I'd suspect compile time issues if that were a
 problem.
 > >
 >
 > No, from my recollection it will compile fine but won't run if the dll
 is missing from the directory.  (However if firefox builds, then fxc2
 didn't error and it worked...)
 >
 >
 > > >  - I'm not sure what you do about PDBs; but it would be good to get
 a bug on file about generating/outputting them. (Perhaps in some
 configuration generating the static clang libraries with debug info also.)
 > >
 > > I agree. Right now don't generate them.
 >
 > I suspect you do generate them; but without setting MOZ_COPY_PDBs they
 are not winding up next to the outputed files so they're not winding up in
 the final tarball. You could stick that into the mozconfig and see if they
 show up though.

 I think that might be true for 64bit, yes. However, for 32bit we
 explicitly set `--disable-debug-symbols` as we are still not cross-
 compiling 64bit->32bit (which #30384 should solve). Anyway, I've filed
 #31546 for generatin/exposing PDB files.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31469 [Applications/Tor Browser]: Switch our cross-compile environments to Debian Buster

[Tor Bug Tracker & Wiki]

#31469: Switch our cross-compile environments to Debian Buster
--+---
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Duplicate of #31127.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31472 [Applications/Tor Browser]: Switch Android builds to Debian Buster

[Tor Bug Tracker & Wiki]

#31472: Switch Android builds to Debian Buster
--+---
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:  #31469| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Duplicate of #31130.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31470 [Applications/Tor Browser]: Switch macOS builds to Debian Buster

[Tor Bug Tracker & Wiki]

#31470: Switch macOS builds to Debian Buster
--+---
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:  #31469| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Duplicate of 31129.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31471 [Applications/Tor Browser]: Switch Windows builds to Debian Buster

[Tor Bug Tracker & Wiki]

#31471: Switch Windows builds to Debian Buster
--+---
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:  #31469| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Duplicate of #31228.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31546 [Applications/Tor Browser]: Create and expose PDB files for Tor Browser debugging on Windows

[Tor Bug Tracker & Wiki]

#31546: Create and expose PDB files for Tor Browser debugging on Windows
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-rbm
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Now that we are about to use `mingw-w64-clang` for the Firefox part in Tor
 Browser we are able to get PDB files for debugging. We should make sure
 they show up after the build and probably expose them (at least the 64bit
 ones) similarly to the Linux debug symbols to aid in debugging Windows
 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] #30249 [Applications/Tor Browser]: Tor Browser starts two copies of meek-client-torbrowser, immediately kills one of them

[Tor Bug Tracker & Wiki]

#30249: Tor Browser starts two copies of meek-client-torbrowser, immediately 
kills
one of them
--+
 Reporter:  dcf   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 It is also a `wontfix`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28238 [Applications/Tor Browser]: Use mingw-w64/clang toolchain to build Firefox

[Tor Bug Tracker & Wiki]

#28238: Use mingw-w64/clang toolchain to build Firefox
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-9.0-must-nightly,   |  Actual Points:
  TorBrowserTeam201908R, GeorgKoppen201908   |
Parent ID:  #30322   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:45 gk]:
 > Replying to [comment:44 tom]:
 > >  - Have you confirmed you don't need the spec thing for
 https://bugzilla.mozilla.org/show_bug.cgi?id=1460801 ?  (If so, I can
 close that bug.)
 >
 > I think it worked for me back then a couple of months ago when I worked
 on the toolchain. I'll double-check with nightly builds once things landed
 but am optimistic.
 >
 > >  - fxc2 requires the winpthread dll to be in its bin directly IIRC;
 but I don't see where you're copying that. (I might have missed it. If
 you're not getting errors on fxc2 it must be working.)
 >
 > I think we don't need it when building with `mingw-w64-clang`. At least
 the build passes and I'd suspect compile time issues if that were a
 problem.
 >
 > >  - I see some flags in our mozconfig you don't have:
 > >- https://searchfox.org/mozilla-
 
central/rev/325c1a707819602feff736f129cb36055ba6d94f/browser/config/mozconfigs/win32/mingwclang#53-54
 >
 > Yes, I am not sure why we don't need those but the build is not
 breaking, so we could leave that investigation for later.

 From reading a bit more in the respective Mozilla bug I think we don't
 need those lines as we only have one clang available in our build
 environment (the one we intend to get used). Thus, there won't be any
 potential compiler confusion.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28238 [Applications/Tor Browser]: Use mingw-w64/clang toolchain to build Firefox

[Tor Bug Tracker & Wiki]

#28238: Use mingw-w64/clang toolchain to build Firefox
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-9.0-must-nightly,   |  Actual Points:
  TorBrowserTeam201908R, GeorgKoppen201908   |
Parent ID:  #30322   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:45 gk]:
 > Replying to [comment:44 tom]:
 > >  - Have you confirmed you don't need the spec thing for
 https://bugzilla.mozilla.org/show_bug.cgi?id=1460801 ?  (If so, I can
 close that bug.)
 >
 > I think it worked for me back then a couple of months ago when I worked
 on the toolchain. I'll double-check with nightly builds once things landed
 but am optimistic.

 I think this works now without the spec hack due to switching to ucrt
 which should be available on all supported platforms. It seems both 64bit
 and 32bit bundles are working both on Windows 7 and Windows 10 systems and
 I tried the new 32bit version on my Windows 7 box where I previously had
 the problem at hand. However, it works there as well now. Thus, I'd say we
 are good here. I'll close the respective bugs on our side once the patch
 for this bug lands.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20600 [Circumvention/meek]: meek-client-torbrowser should always use TOR_BROWSER_TOR_DATA_DIR

[Tor Bug Tracker & Wiki]

#20600: meek-client-torbrowser should always use TOR_BROWSER_TOR_DATA_DIR
+--
 Reporter:  mcs |  Owner:  dcf
 Type:  defect  | Status:  reopened
 Priority:  Medium  |  Milestone:
Component:  Circumvention/meek  |Version:
 Severity:  Minor   | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by dcf):

 * cc: brade, dcf (removed)
 * status:  closed => reopened
 * resolution:  wontfix =>
 * severity:  Normal => Minor
 * parent:  #20599 =>


Comment:

 I'll leave this open as a meek 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] #29430 [Applications/Tor Browser]: Use uTLS for meek TLS camouflage in Tor Browser

[Tor Bug Tracker & Wiki]

#29430: Use uTLS for meek TLS camouflage in Tor Browser
-+-
 Reporter:  dcf  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  meek, utls, ff68-esr,|  Actual Points:
  TorBrowserTeam201908R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by cypherpunks):

 `TorBrowserTeam201908R`->`TorBrowserTeam201908`

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20600 [Circumvention/meek]: meek-client-torbrowser should always use TOR_BROWSER_TOR_DATA_DIR

[Tor Bug Tracker & Wiki]

#20600: meek-client-torbrowser should always use TOR_BROWSER_TOR_DATA_DIR
+-
 Reporter:  mcs |  Owner:  dcf
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Circumvention/meek  |Version:
 Severity:  Normal  | Resolution:  wontfix
 Keywords:  |  Actual Points:
Parent ID:  #20599  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by gk):

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


Comment:

 No need for that anymore after the patches for #29430 landed.

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