Re: [tor-bugs] #31293 [Applications/Tor Browser]: tor-android-service gradle failure when probing network interfaces

[Tor Bug Tracker & Wiki]

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

Comment (by gk):

 So, I asked pospeselr to try again with latest `master` and interestingly
 enough the build proceeds until the firefox project there it is failing
 early with the following log output (which I suspect is related to this
 issue):
 {{{
  0:08.30 Traceback (most recent call last):
  0:08.30   File "/usr/lib/python2.7/runpy.py", line 174, in
 _run_module_as_main
  0:08.30 "__main__", fname, loader, pkg_name)
  0:08.30   File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
  0:08.30 exec code in run_globals
  0:08.30   File "/var/tmp/build/firefox-
 8fe3191e67d0/python/mozbuild/mozbuild/action/file_generate.py", line 120,
 in 
  0:08.30 sys.exit(main(sys.argv[1:]))
  0:08.30   File "/var/tmp/build/firefox-
 8fe3191e67d0/python/mozbuild/mozbuild/action/file_generate.py", line 71,
 in main
  0:08.30 ret = module.__dict__[method](output,
 *args.additional_arguments, **kwargs)
  0:08.30   File "/var/tmp/build/firefox-
 8fe3191e67d0/mobile/android/gradle.py", line 46, in assemble_app
  0:08.30 return android('assemble-app')
  0:08.30   File "/var/tmp/build/firefox-
 8fe3191e67d0/mobile/android/gradle.py", line 38, in android
  0:08.30 subprocess.check_call(cmd, env=env)
  0:08.30   File "/usr/lib/python2.7/subprocess.py", line 186, in
 check_call
  0:08.30 raise CalledProcessError(retcode, cmd)
  0:08.30 subprocess.CalledProcessError: Command '['/var/tmp/build/firefox-
 8fe3191e67d0/obj-arm-linux-androideabi/_virtualenvs/init/bin/python',
 u'/var/tmp/build/firefox-8fe3191e67d0/mach', 'android', 'assemble-app']'
 returned non-zero exit status 1
  0:08.31 backend.mk:64: recipe for target '.deps/android_apks.stub' failed
  0:08.31 make[4]: *** [.deps/android_apks.stub] Error 1
 }}}
 What is failing after looking more closely is gradle-related again:
 {{{
  0:07.62 FAILURE: Build failed with an exception.
  0:07.62 * What went wrong:
  0:07.62 Could not connect to the Gradle daemon.
  0:07.62 Daemon uid: 4615d007-b627-4f79-a0e8-d4c768e8b71e with
 diagnostics:
  0:07.62 Daemon pid: 4031
  0:07.62   log file: /var/tmp/dist/android-
 toolchain/gradle/daemon/4.10.2/daemon-4031.out.log
 }}}
 Looking at the gradle log, though, does not ring a bell immediately (see
 attachment)

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

Re: [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| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by tom):

 Hm. Is it possible that they are symlinked into dist/firefox and not
 making it into an output archive?

 Could you get me a --verbose build log that I could look at to see if I
 can notice anything?

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

Re: [tor-bugs] #15910 [Applications/Tor Browser]: Figure out what to do with OpenH264 (downloads) in Tor Browser

[Tor Bug Tracker & Wiki]

#15910: Figure out what to do with OpenH264 (downloads) in Tor Browser
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff60-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 And? What's the problem to upstream deterministic builds to 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] #31840 [Core Tor/Tor]: Refactor some control error-handling code

[Tor Bug Tracker & Wiki]

#31840: Refactor some control error-handling code
+
 Reporter:  teor|  Owner:  teor
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt 042-can  |  Actual Points:  0.1
Parent ID:  | Points:  0.1
 Reviewer:  catalyst|Sponsor:  Sponsor31-can
+
Changes (by teor):

 * reviewer:   => catalyst


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

Re: [tor-bugs] #31853 [Core Tor/Tor]: Move this_not_that.md into our coding standards document

[Tor Bug Tracker & Wiki]

#31853: Move this_not_that.md into our coding standards document
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-november,   |  Actual Points:
  s31-docs   |
Parent ID:  #29214   | Points:
 Reviewer:  nickm|Sponsor:
-+-
Changes (by teor):

 * reviewer:   => nickm


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

Re: [tor-bugs] #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:  nickm
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  042-can 041-backport consider-   |  Actual Points:
  backport-after-authority-test consider-|
  backport-after-0423 tor-dirauth tor-   |
  bridgeauth |
Parent ID:  #25882   | Points:
 Reviewer:  dgoulet, teor|Sponsor:
-+-
Changes (by teor):

 * keywords:
 042-can 041-backport consider-backport-after-authority-test consider-
 backport-after-0421 tor-dirauth tor-bridgeauth
 =>
 042-can 041-backport consider-backport-after-authority-test consider-
 backport-after-0423 tor-dirauth tor-bridgeauth


Comment:

 Updating my previous status report:

 Replying to [comment:5 nickm]:
 > I've made a branch `ticket31549` with PR at
 https://github.com/torproject/tor/pull/1276 .

 At the moment:
 * 2 authorities are on 0.4.0
 * 6 authorities are on 0.4.1
 * 1 authority is on 0.4.2 alpha
 * the bridge authority is on 0.3.5
 https://consensus-health.torproject.org/#authorityversions

 Here are the backport constraints:
 * release 0.4.2.2-alpha: Mid October?
 * finish test on moria1: End October?
 
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases#Current

 Unless we need to get this change deployed early, I think we should avoid
 backporting. And just let authorities upgrade to 0.4.2 after it is stable.

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

Re: [tor-bugs] #31611 [Core Tor/Tor]: Work out why chutney didn't fail due to #31495 cannot configure bridges

[Tor Bug Tracker & Wiki]

#31611: Work out why chutney didn't fail due to #31495 cannot configure bridges
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-september,  |  Actual Points:
  042-should |
Parent ID:  #29211   | Points:
 Reviewer:  teor |Sponsor:
 |  Sponsor31-must
-+-
Changes (by teor):

 * status:  needs_review => new
 * reviewer:   => teor


Comment:

 Replying to [comment:4 nickm]:
 > Moving forward, here are the possible solutions I can see:
 >
 > 1. When we fuzz configurations, we test that if a configuration passes
 validation, it still passes validation when it is duplicated.

 Seems sensible, but fuzzing takes much longer to show failures than tests.
 Let's defer this task, unless the other options don't get us what we want.

 > 2. (a) We can document more carefully the dangers of configuration
 values where NULL and "" mean different things.  (In the case of
 EntryNodes, NULL means "all nodes are included", and "" means "no nodes
 are included".)

 Yes, let's add comments in 0.4.2.

 > 2. (b) We avoid configuration types where NULL and "" mean different
 things.  We would have to add a new routerset type meaning "all routers",
 (maybe, "*"?) and have that be the default for EntryNodes.  [We probably
 could not make NULL mean the same as "" for all cases, since there are
 lots of string-valued configuration types.]

 Let's consider making NULL and "" mean the same thing in 0.4.3.

 > 3. We write a testing tool that uses stem to try assigning
 configurations and making sure that they pass and fail with the expected
 errors messages.

 Let's consider a change like this.

 Here are some specific suggestions:
 * 0.4.2: add an extra config test to stem, so it is run by tor's "make
 test-stem"
   * let's try to add a stem test that would have caught this bug?
 * 0.4.3: add a SETCONF step to the newly added config parsing tests run by
 "make check"
   * maybe? This seems like overkill.

 > 4. We change the implementation of SETCONF so that instead of starting
 with config_dup(), it remembers the actual sequence of configuration
 values, appends the controller's new configuration values, and replays all
 of them in sequence. [This solution would require arbitrary amounts of
 memory.]

 This feels like a bad idea, it seems to lock in a particular config model.
 It might make configs really hard to split or maintain in future.

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

Re: [tor-bugs] #31796 [Core Tor/Tor]: practracker git hook warning: Unusual pattern permitted.h in testdata

[Tor Bug Tracker & Wiki]

#31796: practracker git hook warning: Unusual pattern permitted.h in testdata
+--
 Reporter:  teor|  Owner:  nickm
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.2.x-final
Component:  Core Tor/Tor|Version:  Tor: unspecified
 Severity:  Normal  | Resolution:  worksforme
 Keywords:  042-should, 042-regression  |  Actual Points:
Parent ID:  | Points:  0.1
 Reviewer:  |Sponsor:  Sponsor31-can
+--
Changes (by teor):

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


Comment:

 I can't reproduce this issue any more, I think we fixed it in some other
 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] #31634 [Core Tor/Tor]: Check .may_include order and tor subsystem init order are compatible

[Tor Bug Tracker & Wiki]

#31634: Check .may_include order and tor subsystem init order are compatible
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  diagnostics, 043-should, |  Actual Points:
  practracker|
Parent ID:   | Points:  2
 Reviewer:  teor |Sponsor:
 |  Sponsor31-can
-+-
Changes (by teor):

 * keywords:  diagnostics, 042-should?, practracker => diagnostics,
 043-should, practracker
 * status:  needs_review => needs_revision
 * milestone:  Tor: 0.4.2.x-final => Tor: 0.4.3.x-final


Comment:

 Yes, I think we should make big changes like this in 0.4.3.

 And in 0.4.2, we should avoid:
 * changes to .may_include
 * changes to the module init order

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  assigned
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.4.0.5
 Severity:  Normal| Resolution:
 Keywords:  ipv6  |  Actual Points:
Parent ID:  #26664| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * status:  new => assigned
 * keywords:  042-can, ipv6 => ipv6
 * version:  Tor: 0.4.1.5 => Tor: 0.4.0.5
 * owner:  asn => (none)
 * milestone:  Tor: 0.4.2.x-final => Tor: unspecified


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

Re: [tor-bugs] #31286 [Applications/Tor Browser]: Include bridge configuration into about:preferences

[Tor Bug Tracker & Wiki]

#31286: Include bridge configuration into about:preferences
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-alpha,  |  Actual Points:
  TorBrowserTeam201909R, ff68-esr, ux-team   |
Parent ID:  #10760   | Points:  15
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by pospeselr):

 Test builds of my bug_31286_review branch!

 Linux: https://people.torproject.org/~richard/builds/tor-browser-linux64
 -tbb-nightly_en-US-31286.tar.xz
 macOS: later

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

Re: [tor-bugs] #31543 [Core Tor/Tor]: Add unit tests or chutney tests for IPv6Traffic

[Tor Bug Tracker & Wiki]

#31543: Add unit tests or chutney tests for IPv6Traffic
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.5
 Severity:  Normal| Resolution:
 Keywords:  ipv6  |  Actual Points:
Parent ID:  #26664| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * keywords:  042-should, ipv6 => ipv6
 * owner:  teor => (none)
 * milestone:  Tor: 0.4.2.x-final => Tor: unspecified


Comment:

 If this bug existed in 0.4.0 and 0.4.1, it's not new. So there is unlikely
 to be a quick fix. And we don't need to fix it in 0.4.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] #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:  asn
 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-can, ipv6  |  Actual Points:
Parent ID:  #26664 | Points:
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * status:  needs_information => new
 * keywords:  042-should, ipv6 => 042-can, ipv6


Comment:

 If this bug existed in 0.4.0 and 0.4.1, it's not new. So there is unlikely
 to be a quick fix. And we don't need to fix it in 0.4.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] #31794 [Circumvention/Snowflake]: Errors swallowed

[Tor Bug Tracker & Wiki]

#31794: Errors swallowed
-+
 Reporter:  sah  |  Owner:  (none)
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  cohosh   |Sponsor:
-+

Comment (by sah):

 >> Might as well be consistent. Looks like ​this error message is still
 capitalized.
 Line 47 is a log message, and not an error. If it is to be changed, then
 line 45 will need to be changed as well.

 I've updated the error message, moved the change to the increments to the
 correct commit, and updated the socksAcceptLoop to not return an error.
 Note: In that method the return would have terminated the loop, so I have
 replaced it with a break statement (as well as a log statement).

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

Re: [tor-bugs] #31391 [Circumvention/Snowflake]: Do a reachability check before polling for clients

[Tor Bug Tracker & Wiki]

#31391: Do a reachability check before polling for clients
-+-
 Reporter:  cypherpunks  |  Owner:  arlolra
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  cohosh   |Sponsor:
-+-

Comment (by arlolra):

 Noting that commits ending in https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/commit/?id=8d81270a9f217a5d0867a5db9237a02c8498eef9
 got merged 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] #31537 [Circumvention/Snowflake]: snowflake.tp.o could use a favicon

[Tor Bug Tracker & Wiki]

#31537: snowflake.tp.o could use a favicon
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  cohosh   |Sponsor:
-+-

Comment (by arlolra):

 Merged as https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/commit/?id=a5071ec1d623182eb2d9bc36f033f0990f50ec6f

 For what it's worth, I went an onion instead of a snowflake here because I
 was concerned that there might be some confusion with the extension's
 toolbar icon.

 However, maybe it's worth adding a snowflake favicon to
 https://snowflake.torproject.org/embed.html that gets updated with state,
 similar to the extension's browserAction.setIcon, so that you can use a
 pinned tab in situations where installing an extension is not feasible.

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

Re: [tor-bugs] #29708 [Core Tor]: Update trac wiki teams page

[Tor Bug Tracker & Wiki]

#29708: Update trac wiki teams page
--+
 Reporter:  juga  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gaba):

 * status:  new => closed
 * resolution:   => 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] #31391 [Circumvention/Snowflake]: Do a reachability check before polling for clients

[Tor Bug Tracker & Wiki]

#31391: Do a reachability check before polling for clients
-+-
 Reporter:  cypherpunks  |  Owner:  arlolra
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  cohosh   |Sponsor:
-+-
Changes (by arlolra):

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


Comment:

 > However, I'm wondering about the use case in which a user sees the
 message that WebRTC has been disabled, goes into their about:config to
 enable it, and then cannot redo the check without restarting their web
 browser.

 This was brought up in comment:5:ticket:31109 as well.

 At present, if the `PeerConnection` constructor is in scope and then you
 toggle off `media.peerconnection.enabled`, you can still make a
 connection.  My point being that a configuration hidden behind
 `about:config` might benefit from a browser restart since it's unclear how
 they're intended to be used.

 > Perhaps a solution to any possible confusion here or with the error
 messages in general would be a short FAQ section for all of our missing
 feature error messages on snowflake.torproject.org (which the user arrives
 at by clicking on the "Learn more" link).

 Filed as #31902

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31903 [Circumvention/BridgeDB]: Update translations and push translation requests to Transifex

[Tor Bug Tracker & Wiki]

#31903: Update translations and push translation requests to Transifex
+---
 Reporter:  phw |  Owner:  phw
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Circumvention/BridgeDB  |Version:
 Severity:  Normal  |   Keywords:  s30-o22a3
Actual Points:  |  Parent ID:  #31279
   Points:  0.5 |   Reviewer:
  Sponsor:  Sponsor30-must  |
+---
 It's time to update BridgeDB's existing translations and to push new
 translation requests because some of BridgeDB's strings have changed in
 the meanwhile.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31902 [Circumvention/Snowflake]: Add a short FAQ to snowflake.tp.o

[Tor Bug Tracker & Wiki]

#31902: Add a short FAQ to snowflake.tp.o
-+
 Reporter:  arlolra  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 This should include explanations for the missing feature error messages.
 See comment:13:ticket:31391

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

Re: [tor-bugs] #16285 [Applications/Tor Browser]: Make sure EME is no tracking risk in Tor Browser

[Tor Bug Tracker & Wiki]

#16285: Make sure EME is no tracking risk in Tor Browser
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-linkability, GeorgKoppen201705,  |  Actual Points:
  TorBrowserTeam201910R, ff68-esr, tbb-no-   |
  uplift-60  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

 * status:  assigned => needs_review
 * keywords:
 tbb-linkability, GeorgKoppen201705, TorBrowserTeam201705, ff68-esr,
 tbb-no-uplift-60
 =>
 tbb-linkability, GeorgKoppen201705, TorBrowserTeam201910R, ff68-esr,
 tbb-no-uplift-60


Comment:

 I pushed `bug16285_68esr_00` for 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] #31723 [Community/Training]: design help documents for the help service and provide support for new users

[Tor Bug Tracker & Wiki]

#31723: design help documents for the help service and provide support for new
users
+--
 Reporter:  anarcat |  Owner:  ggus
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Community/Training  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  #30608  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by ggus):

 Hello, I possibly can help here to have this ship to sail.

 Do you want to create a new entry in help.tpo and also 1:1 helpdesk thing?

 And when do you plan to start this so I can put on my work roadmap.

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

Re: [tor-bugs] #31880 [Applications/Tor Browser]: Disabling EME per configure option does not work on mobile anymore

[Tor Bug Tracker & Wiki]

#31880: Disabling EME per configure option does not work on mobile anymore
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  alpha, TorBrowserTeam201909R   |
Parent ID:  #30324   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 For reference, see ticket:16285#comment:34

 {{{
 On Android, it's more interesting. #31880 didn't yield any interesting
 results
 because nothing is changed at compile-time. Fennec and GeckoView use the
 Android
 system DRM support when it is available. This is controlled separately by
 media.mediadrm-widevinecdm.visible.
 }}}

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

Re: [tor-bugs] #16285 [Applications/Tor Browser]: Make sure EME is no tracking risk in Tor Browser

[Tor Bug Tracker & Wiki]

#16285: Make sure EME is no tracking risk in Tor Browser
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-linkability, GeorgKoppen201705,  |  Actual Points:
  TorBrowserTeam201705, ff68-esr, tbb-no-|
  uplift-60  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 For 68esr, it looks like we are still good here. We don't need the adobe
 prefs anymore (since Bug
 [https://bugzilla.mozilla.org/show_bug.cgi?id=1329543 1329543]).

 From #31880, we found `--disable-eme` still prevents enabling EME on
 desktop builds. When EME is enabled (using `--enable-eme`), the content
 decryption module (CDM) must be specified. Mozilla only support `--enable-
 eme=widevine` in 68esr.

 By default, the following prefs are [https://gitweb.torproject.org/tor-
 browser.git/tree/browser/app/profile/firefox.js?h=tor-
 browser-68.1.0esr-9.0-2#n194 not defined]:
 `media.gmp-widevinecdm.visible` and `media.gmp-widevinecdm.enabled`


 and `browser.eme.ui.enabled` is `false` [https://gitweb.torproject.org
 /tor-browser.git/tree/browser/app/profile/firefox.js?h=tor-
 browser-68.1.0esr-9.0-2#n194 by default].

 When configured with `--enable-eme=widevine`, then `media.gmp-
 widevinecdm.visible`, `media.gmp-widevinecdm.enabled`, and
 `browser.eme.ui.enabled` are set `true`.

 We set `--disable-eme` on desktops and these prefs are
 [https://gitweb.torproject.org/tor-
 browser.git/tree/browser/app/profile/000-tor-browser.js?h=tor-
 browser-68.1.0esr-9.0-2#n215 overwritten]as `false`.

 If, in addition to these prefs, `media.eme.enabled` is false and the CDM
 is not ClearKey, then the code path [https://gitweb.torproject.org/tor-
 browser.git/tree/dom/media/eme/MediaKeySystemAccessManager.cpp?h=tor-
 browser-68.1.0esr-9.0-2#n102 aborts early] and it doesn't download the
 file from a remote server.

 If the CDM is ClearKey and these prefs are false, then on desktop,
 [https://gitweb.torproject.org/tor-
 browser.git/tree/dom/media/eme/MediaKeySystemAccess.cpp?h=tor-
 browser-68.1.0esr-9.0-2#n115 MediaKeySystemAccess::GetKeySystemStatus]
 returns `MediaKeySystemStatus::Cdm_not_supported`, and
 [https://gitweb.torproject.org/tor-
 browser.git/tree/dom/media/eme/MediaKeySystemAccessManager.cpp?h=tor-
 browser-68.1.0esr-9.0-2#n117 MediaKeySystemAccessManager::Request] returns
 without resolving the Promise.

 On Android, it's more interesting. #31880 didn't yield any interesting
 results because nothing is changed at compile-time. Fennec and GeckoView
 use the Android system DRM support when it is available.  This is
 controlled separately by `media.mediadrm-widevinecdm.visible`.

 I'll write a fixup patch that removes the old Adobe CDM prefs and adds the
 Android pref.

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

Re: [tor-bugs] #31843 [Circumvention/Snowflake]: Make safelogger thread safe

[Tor Bug Tracker & Wiki]

#31843: Make safelogger thread safe
-+
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  phw  |Sponsor:
-+
Changes (by cohosh):

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


Comment:

 Merged in `3c28380bc6`

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

Re: [tor-bugs] #30830 [Circumvention/Snowflake]: Clean up snowflake broker logs

[Tor Bug Tracker & Wiki]

#30830: Clean up snowflake broker logs
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  logs, stats anti-censorship- |  Actual Points:
  roadmap-july   |
Parent ID:   | Points:
 Reviewer:  phw  |Sponsor:
 |  Sponsor28
-+-
Changes (by cohosh):

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


Comment:

 Merged in `f3be34a459`

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

Re: [tor-bugs] #31794 [Circumvention/Snowflake]: Errors swallowed

[Tor Bug Tracker & Wiki]

#31794: Errors swallowed
-+
 Reporter:  sah  |  Owner:  (none)
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  cohosh   |Sponsor:
-+
Changes (by cohosh):

 * status:  needs_review => needs_revision


Comment:

 >I refer you to the widely cited
 ​https://github.com/golang/go/wiki/CodeReviewComments#error-strings
 These are also a list of suggestions and there are many recommendations
 here that I do not like and would not recommend in this code base (for
 example the suggestion to use single character variable names).

 That being said I'm ok with generally not capitalizing error messages, and
 I agree with dcf's comment that error messages starting with identifiers
 should match the capitalization of the identifier.

 Some additional feedback:

 - Might as well be consistent. Looks like
 [https://github.com/shaneHowearth/snowflake/compare/linter-fixes#diff-
 bad3023f4e3a006241527544f4e9efd2R47 this] error message is still
 capitalized.

 - This
 
[https://github.com/shaneHowearth/snowflake/commit/a2e9133a5f30672d3f680b763de009a9a9bf395b
 #diff-090a189afcd6b3645ff26daa525859f6L30 change] is still in the error
 commits and not in the general linter commit.

 - In
 
[https://github.com/shaneHowearth/snowflake/commit/cf52da4619781ce9a660be895fe5c398cf6c119d
 #diff-79897051d7aac1f314600a930afebe9aR385 this] error message, it would
 be more correct to say something along the lines of:
 {{{
 log.Fatalf("reload of Geo IP databases on signal %s returned error: %v",
 signal, err)
 }}}
  (note also the change from `;` to `:` there)

 - In
 
[https://github.com/shaneHowearth/snowflake/commit/e5a1bc32827482f971b003142acea3d9ea0b493a
 #diff-227e0da595ae35c9cef78b0e687e78f3R59 this] case the other connection
 the copyloop is copying to is not an ORPort, it's a SOCKS connection.

 - I am not a fan of
 
[https://github.com/shaneHowearth/snowflake/commit/e5a1bc32827482f971b003142acea3d9ea0b493a
 #diff-0efd2b39fd0c8010b9dd51b4f07edf1bL157 this] change. I'd rather change
 `socksAcceptLoop` to not return an error since it's not necessary to
 handle it from the calling code. So something like:
 {{{
 func socksAcceptLoop(ln *pt.SocksListener, snowflakes
 sf.SnowflakeCollector) {
 defer ln.Close()
 log.Println("Started SOCKS listener.")
 for {
 log.Println("SOCKS listening...")
 conn, err := ln.AcceptSocks()
 if err != nil {
 if e, ok := err.(net.Error); ok && e.Temporary() {
 continue
 }
 log.Printf("SOCKS accept error: %s", err)
 }
 log.Println("SOCKS accepted: ", conn.Req)
 err = sf.Handler(conn, snowflakes)
 if err != nil {
 log.Printf("handler error: %s", err)
 }
 }
 }
 }}}

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

Re: [tor-bugs] #31898 [Core Tor/Tor]: Occasional crash during shutdown when using Tor API

[Tor Bug Tracker & Wiki]

#31898: Occasional crash during shutdown when using Tor API
-+-
 Reporter:  sysrqb   |  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  042-regression, crash, 042-must  |  Actual Points:
  041-backport? 041-regression?  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor31-must
-+-

Comment (by nickm):

 A smaller test case might help here, or maybe a link to the RunMain
 source.

 One thing to note is that the stack trace that you're describing seems to
 be happening inside the initialization code, before Tor is actually
 running.  Maybe this is something that happens on a second initialization
 and not a first?

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

Re: [tor-bugs] #30344 [Core Tor/Tor]: conn_read_callback is called on connections that are marked for closed

[Tor Bug Tracker & Wiki]

#30344: conn_read_callback is called on connections that are marked for closed
-+-
 Reporter:  robgjansen   |  Owner:  asn
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.8
 Severity:  Normal   | Resolution:
 Keywords:  tor-conn, 035-backport,  |  Actual Points:
  041-deferred-20190530, 042-should  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by robgjansen):

 * cc: pastly (added)


Comment:

 Hello! Pastly has been running some Shadow experiments lately where he was
 experiencing the issue described in this ticket. He fixed it in a 3rd
 place (i.e., not my patch and not your patch). He is going to go back and
 test your patch to make sure it does indeed fix the problem.

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

Re: [tor-bugs] #15910 [Applications/Tor Browser]: Figure out what to do with OpenH264 (downloads) in Tor Browser

[Tor Bug Tracker & Wiki]

#15910: Figure out what to do with OpenH264 (downloads) in Tor Browser
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff60-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sysrqb):

 Replying to [comment:19 cypherpunks]:
 > Replying to [comment:5 gk]:
 > > The download URL looks something like:
 
http://ciscobinary.openh264.org/openh264-linux32-4adf9cd6dd1358eefe3cbb5eddbfbf4ff06cfa65.zip
 > >
 > > Yes, HTTP and no deterministic build. *headdesk*
 > There are no MinGW URLs.
 > They offer to build it yourself https://github.com/cisco/openh264#for-
 windows-builds.

 comment:20 :
 {{{
 Q: If I use the source code in my product, and then distribute that
 product on my
 own, will Cisco cover the MPEG LA licensing fees which I'd otherwise have
 to pay?

 A: No. Cisco is only covering the licensing fees for its own binary
 module, and
 products or projects that utilize it must download it at the time the
 product or
 project is installed on the user's computer or device. Cisco will not be
 liable for
 any licensing fees incurred by other parties.
 }}}

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

Re: [tor-bugs] #31881 [Applications/Tor Browser]: Enabling bundled fonts does not work anymore on Android

[Tor Bug Tracker & Wiki]

#31881: Enabling bundled fonts does not work anymore on Android
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  alpha, TorBrowserTeam201909R   |
Parent ID:  #30324   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Looks good. Could you file a follow-up ticket to investigate the font
 fingerprinting defense approach outlined above and make it blocking
 #18097? Feel free to close this ticket then, thanks!

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

Re: [tor-bugs] #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:  nickm
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  042-can 041-backport consider-   |  Actual Points:
  backport-after-authority-test consider-|
  backport-after-0421 tor-dirauth tor-   |
  bridgeauth |
Parent ID:  #25882   | Points:
 Reviewer:  dgoulet, teor|Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_information => merge_ready
 * reviewer:   => dgoulet, teor


Comment:

 I think we should go forward with this patch. We've done a lot of the
 necessary steps to inform as much as we can operators.

 We also have a blog post in the making about this before we roll out that
 patch.

 Here is the current count:

 {{{
 == Relays - Series ==
 <= 0.2.8 series: 285 [w: 0.56%]
 0.3.0x - 0.3.4.x series: 505 [w: 11.87%]

 == Bridge - Series ==
 <= 0.2.8 series: 354 [w: 0.76%]
 0.3.0x - 0.3.4.x series: 552 [w: 10.43%]
 }}}

 Number of relays has gone down by 281. Now much the total bw weight
 unfortunately.

 I've reviewed it. All comments have been addressed. Moving to
 `merge_ready`.

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

Re: [tor-bugs] #31786 [Internal Services/Tor Sysadmin Team]: move dictyotum off moly

[Tor Bug Tracker & Wiki]

#31786: move dictyotum off moly
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29974   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 the backup/restore procedures for the director changed, so we might want
 to test those instead of duplicating the machine. it would also test the
 bacula::directory class from the bottom up, which would also be a great
 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

Re: [tor-bugs] #31189 [Core Tor/Tor]: potential docs update needed for GuardLifetime?

[Tor Bug Tracker & Wiki]

#31189: potential docs update needed for GuardLifetime?
-+-
 Reporter:  cypherpunks  |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  docs, guardlifetime, 042-should  |  Actual Points:  .1
  BugSmashFund   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  assigned => needs_review
 * keywords:  docs, guardlifetime, 042-should => docs, guardlifetime,
 042-should BugSmashFund
 * actualpoints:   => .1


Comment:

 > Is the expected behavior that setting UseEntryGuards 1 and GuardLifetime
 1 day will result in guards being used for no longer than one day?

 To be pedantic: if GuardLifetime 1 day is set, then guards will be removed
 from the list of sampled guards 1 day after they are sampled from the
 directory, or 1 day after they are confirmed (first used for a good
 circuit) -- whichever comes first.

 Note that nothing prevents a guard from being re-sampled immediately after
 it is removed: this is intentional, since behaving otherwise would be less
 random.

 It may be that we allow the interval for sampled, unconfirmed guards to be
 configured independently from the interval for confirmed guards.  That's a
 different ticket, though, and we'd have to consider it for 0.4.3.

 I've got a documentation fix against maint-0.3.5 in branch
 `ticket31189_035` with PR at https://github.com/torproject/tor/pull/1381 .
 It is documentation-only, and merges cleanly to master.

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

Re: [tor-bugs] #30009 [Internal Services/Tor Sysadmin Team]: consider trocla for secrets management in puppet

[Tor Bug Tracker & Wiki]

#30009: consider trocla for secrets management in puppet
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  project  | Status:
 |  needs_review
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29387   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 after a bumpy start, this seems to be working well now. i added
 documentation on trocla (and incidentally, hkdf while i was there) in the
 Puppet docs/wiki. that will need to be updated if we convert from hkdf().

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

Re: [tor-bugs] #31768 [Applications/Tor Browser]: Introduce Tor network settings and other updates in TB9 onboarding

[Tor Bug Tracker & Wiki]

#31768: Introduce Tor network settings and other updates in TB9 onboarding
-+-
 Reporter:  antonela |  Owner:  dunqan
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, TorBrowserTeam201909,   |  Actual Points:
  tbb-9.0-must-alpha |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by catalyst):

 * cc: catalyst (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] #31880 [Applications/Tor Browser]: Disabling EME per configure option does not work on mobile anymore

[Tor Bug Tracker & Wiki]

#31880: Disabling EME per configure option does not work on mobile anymore
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  alpha, TorBrowserTeam201909R   |
Parent ID:  #30324   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Thanks. Looks good to me.

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

Re: [tor-bugs] #16285 [Applications/Tor Browser]: Make sure EME is no tracking risk in Tor Browser

[Tor Bug Tracker & Wiki]

#16285: Make sure EME is no tracking risk in Tor Browser
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-linkability, GeorgKoppen201705,  |  Actual Points:
  TorBrowserTeam201705, ff68-esr, tbb-no-|
  uplift-60  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:
 tbb-linkability, GeorgKoppen201705, TorBrowserTeam201705, ff60-esr,
 tbb-no-uplift-60
 =>
 tbb-linkability, GeorgKoppen201705, TorBrowserTeam201705, ff68-esr,
 tbb-no-uplift-60


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

Re: [tor-bugs] #31685 [Circumvention/Snowflake]: Snowflake : ON/OFF switch

[Tor Bug Tracker & Wiki]

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

 * reviewer:  cohosh => antonela


Comment:

 Looks good, and the code is good to merge. I'm going to ask antonela for
 the final say here since this is a user facing issue.

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

Re: [tor-bugs] #31564 [Applications/Tor Browser]: Android bundles based on ESR 68 are not built reproducibly anymore

[Tor Bug Tracker & Wiki]

#31564: Android bundles based on ESR 68 are not built reproducibly anymore
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-alpha,  |  Actual Points:
  TorBrowserTeam201909, GeorgKoppen201909|
Parent ID:  #30324   | Points:  5
 Reviewer:   |Sponsor:
-+-

Comment (by eighthave):

 If you have a reproducible test case for this `BrutException` failure,
 please file a bug report (e.g. send an email to `sub...@bugs.debian.org`
 with `Package: apktool` as the first line in the body).

 The version number in the smali lib filenames is only cosmetic, I guess
 the buildsystem failed there.

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

Re: [tor-bugs] #31564 [Applications/Tor Browser]: Android bundles based on ESR 68 are not built reproducibly anymore

[Tor Bug Tracker & Wiki]

#31564: Android bundles based on ESR 68 are not built reproducibly anymore
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-alpha,  |  Actual Points:
  TorBrowserTeam201909, GeorgKoppen201909|
Parent ID:  #30324   | Points:  5
 Reviewer:   |Sponsor:
-+-

Comment (by eighthave):

 For ''apktool'', you could probably just include the testing package
 directly in buster
 if you're not already using buster-backports.

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

Re: [tor-bugs] #31537 [Circumvention/Snowflake]: snowflake.tp.o could use a favicon

[Tor Bug Tracker & Wiki]

#31537: snowflake.tp.o could use a favicon
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  cohosh   |Sponsor:
-+-
Changes (by cohosh):

 * status:  needs_review => merge_ready


Comment:

 Heh, I hadn't noticed tp.o doesn't have one.

 Looks good to me. This is also related to #19774, we could keep an eye on
 that and think about whether we want a similar favicon for all our
 circumvention stuff.

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

Re: [tor-bugs] #31843 [Circumvention/Snowflake]: Make safelogger thread safe

[Tor Bug Tracker & Wiki]

#31843: Make safelogger thread safe
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  phw  |Sponsor:
-+-
Changes (by phw):

 * status:  needs_review => merge_ready


Comment:

 Looks good to me.

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

Re: [tor-bugs] #31685 [Circumvention/Snowflake]: Snowflake : ON/OFF switch

[Tor Bug Tracker & Wiki]

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

 * reviewer:   => 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] #31537 [Circumvention/Snowflake]: snowflake.tp.o could use a favicon

[Tor Bug Tracker & Wiki]

#31537: snowflake.tp.o could use a favicon
-+--
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  cohosh   |Sponsor:
-+--
Changes (by cohosh):

 * reviewer:   => 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] #30830 [Circumvention/Snowflake]: Clean up snowflake broker logs

[Tor Bug Tracker & Wiki]

#30830: Clean up snowflake broker logs
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  task | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  logs, stats anti-censorship- |  Actual Points:
  roadmap-july   |
Parent ID:   | Points:
 Reviewer:  phw  |Sponsor:
 |  Sponsor28
-+-

Comment (by cohosh):

 Replying to [comment:9 phw]:
 > comment:4 mentions that we shouldn't worry operators by returning 504
 codes. Are we still going to do this? If so, in this ticket, or somewhere
 else?
 Thanks! This is being handled in #29207

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

Re: [tor-bugs] #31391 [Circumvention/Snowflake]: Do a reachability check before polling for clients

[Tor Bug Tracker & Wiki]

#31391: Do a reachability check before polling for clients
-+-
 Reporter:  cypherpunks  |  Owner:  arlolra
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  cohosh   |Sponsor:
-+-
Changes (by cohosh):

 * status:  needs_review => merge_ready


Comment:

 The code looks good to me, and is ready to merge. I like the refactoring
 changes you made the websocket class and putting both missingFeature
 checks in the initToggle.

 I tested this out and it looks great. I like that in addition to
 displaying the message, it also prevents the user from retrying to enable
 the webextension. However, I'm wondering about the use case in which a
 user sees the message that WebRTC has been disabled, goes into their
 about:config to enable it, and then cannot redo the check without
 restarting their web browser.

 Perhaps a solution to any possible confusion here or with the error
 messages in general would be a short FAQ section for all of our missing
 feature error messages on snowflake.torproject.org (which the user arrives
 at by clicking on the "Learn more" link).

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

Re: [tor-bugs] #31796 [Core Tor/Tor]: practracker git hook warning: Unusual pattern permitted.h in testdata

[Tor Bug Tracker & Wiki]

#31796: practracker git hook warning: Unusual pattern permitted.h in testdata
+--
 Reporter:  teor|  Owner:  nickm
 Type:  defect  | Status:
|  needs_information
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.2.x-final
Component:  Core Tor/Tor|Version:  Tor: unspecified
 Severity:  Normal  | Resolution:
 Keywords:  042-should, 042-regression  |  Actual Points:
Parent ID:  | Points:  0.1
 Reviewer:  |Sponsor:  Sponsor31-can
+--
Changes (by nickm):

 * status:  assigned => needs_information


Comment:

 I am having a hard time reproducing this.  Does it still happen for you?
 I think that both the includes.py and practracker.py entrypoints now only
 search under "src" by default.

 If this is still happening, can you verify:

 1. which of the two entrypoints (practracker.py or includes.py) causes
 this warning.

 2. the actual command line and environment that are passed to that entry
 point.

 3. The exact version of the git hook that you're using

 4. the directory that you are committing from in relation to the git
 checkout.

 Thanks for your help!

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

Re: [tor-bugs] #30830 [Circumvention/Snowflake]: Clean up snowflake broker logs

[Tor Bug Tracker & Wiki]

#30830: Clean up snowflake broker logs
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  task | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  logs, stats anti-censorship- |  Actual Points:
  roadmap-july   |
Parent ID:   | Points:
 Reviewer:  phw  |Sponsor:
 |  Sponsor28
-+-
Changes (by phw):

 * status:  needs_review => merge_ready


Comment:

 The fix looks good to me.

 comment:4 mentions that we shouldn't worry operators by returning 504
 codes. Are we still going to do this? If so, in this ticket, or somewhere
 else?

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

Re: [tor-bugs] #31611 [Core Tor/Tor]: Work out why chutney didn't fail due to #31495 cannot configure bridges

[Tor Bug Tracker & Wiki]

#31611: Work out why chutney didn't fail due to #31495 cannot configure bridges
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-september,  |  Actual Points:
  042-should |
Parent ID:  #29211   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor31-must
-+-
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 Putting this in needs_review -- there is not a chosen solution here yet,
 and there is no code, but I would like feedback on which of the several
 possible solutions look like good ideas.  None of them is trivial.

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

Re: [tor-bugs] #31634 [Core Tor/Tor]: Check .may_include order and tor subsystem init order are compatible

[Tor Bug Tracker & Wiki]

#31634: Check .may_include order and tor subsystem init order are compatible
-+-
 Reporter:  teor |  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:  diagnostics, 042-should?,|  Actual Points:
  practracker|
Parent ID:   | Points:  2
 Reviewer:  teor |Sponsor:
 |  Sponsor31-can
-+-

Comment (by nickm):

 (Right now I am not asking for review on the code per se, since it is not
 ready. I'm asking for review on the decision to defer this to 0.4.3 when
 we willing to take more stability risks.)

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

Re: [tor-bugs] #31611 [Core Tor/Tor]: Work out why chutney didn't fail due to #31495 cannot configure bridges

[Tor Bug Tracker & Wiki]

#31611: Work out why chutney didn't fail due to #31495 cannot configure bridges
-+-
 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-september,  |  Actual Points:
  042-should |
Parent ID:  #29211   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor31-must
-+-

Comment (by nickm):

 Moving forward, here are the possible solutions I can see:

 1. When we fuzz configurations, we test that if a configuration passes
 validation, it still passes validation when it is duplicated.

 2. (a) We can document more carefully the dangers of configuration values
 where NULL and "" mean different things.  (In the case of EntryNodes, NULL
 means "all nodes are included", and "" means "no nodes are included".)

 2. (b) We avoid configuration types where NULL and "" mean different
 things.  We would have to add a new routerset type meaning "all routers",
 (maybe, "*"?) and have that be the default for EntryNodes.  [We probably
 could not make NULL mean the same as "" for all cases, since there are
 lots of string-valued configuration types.]

 3. We write a testing tool that uses stem to try assigning configurations
 and making sure that they pass and fail with the expected errors messages.

 4. We change the implementation of SETCONF so that instead of starting
 with config_dup(), it remembers the actual sequence of configuration
 values, appends the controller's new configuration values, and replays all
 of them in sequence. [This solution would require arbitrary amounts of
 memory.]

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

Re: [tor-bugs] #31611 [Core Tor/Tor]: Work out why chutney didn't fail due to #31495 cannot configure bridges

[Tor Bug Tracker & Wiki]

#31611: Work out why chutney didn't fail due to #31495 cannot configure bridges
-+-
 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-september,  |  Actual Points:
  042-should |
Parent ID:  #29211   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor31-must
-+-

Comment (by nickm):

 So, on investigation: bug #31495 only happened when the configuration
 change arrived over the control port via SETCONF.  If instead it arrived
 in the initial configuration, or via a SIGHUP, then #31495 would not occur
 and the configuration would not be rejected.  Chutney doesn't use SETCONF,
 so it didn't find #31495.

 But, why were the two cases handled differently?

 That's because when we build a new configuration from scratch, we
 initialize a new configuration objects, assign the defaults to it, and
 then assign each of the user-provided options in sequence.  But when we
 get new values via SETCONF, we first duplicate the existing configuration,
 and then use setconf to apply new values on top of it.  The bug here was
 in config_dup()'s handling of NULL routerset values.  Instead of encoding
 them as a null entry, we encoded them as an empty string, which was then
 re-parsed as a semantically different value.  This was due to a bug in
 routerset's var_type implementation.

 We could add a check here to make sure that config_dup() always returns an
 equal object, although that wouldn't have helped in this instance, since
 the defeault "equal" implementation for a var_type defers to the "encode"
 implementation, which is what had the bug.

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

Re: [tor-bugs] #31881 [Applications/Tor Browser]: Enabling bundled fonts does not work anymore on Android

[Tor Bug Tracker & Wiki]

#31881: Enabling bundled fonts does not work anymore on Android
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  alpha, TorBrowserTeam201909R   |
Parent ID:  #30324   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

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


Comment:

 Similar to #31880, `--enable-bundled-fonts` is restricted to `browser`:
 https://searchfox.org/mozilla-esr68/source/toolkit/moz.configure#1323

 It seems bundled-fonts was always desktop-only, `configure` simply didn't
 error when targeting Android before FF64.
 [https://bugzilla.mozilla.org/show_bug.cgi?id=1491419 Bug 1491419] moved
 this from `old-configure.in` into `moz.configure`. We can see `old-
 configure.in` before this change [https://hg.mozilla.org/releases/mozilla-
 esr68/file/2a985dd40eba10801b2da141d1e8966b2ec060a5/old-configure.in#l3005
 described it] as "Enable support for bundled fonts on desktop platforms"
 (and now I notice it says this in `toolkit/moz.configure`, too).

 This feature was originally added in
 [https://bugzilla.mozilla.org/show_bug.cgi?id=998844 bug 998844] and this
 was limited to desktop builds because Fennec already shipped with bundled
 fonts: https://bugzilla.mozilla.org/show_bug.cgi?id=998844#c15.

 It seems like we should take note of
 [https://bugzilla.mozilla.org/show_bug.cgi?id=998844#c8 comment 8]:
 {{{
 This is already possible on Android and Firefox OS, where font files in
 the "font"
 sub-dir of a profile are loaded on startup:
 http://dxr.mozilla.org/mozilla-
 central/source/gfx/thebes/gfxFT2FontList.cpp#1266
 }}}

 [https://dxr.mozilla.org/mozilla-
 central/source/gfx/thebes/gfxFT2FontList.cpp#1115
 gfxFT2FontList::FindFontsInOmnijar] is a slightly more helpful function
 (from FF32). This was implemented in
 [https://bugzilla.mozilla.org/show_bug.cgi?id=878674 Bug 878674].

 This is the current location: https://searchfox.org/mozilla-
 esr68/source/gfx/thebes/gfxFT2FontList.cpp#1079

 {{{
   static const char* sJarSearchPaths[] = {
   "res/fonts/*.ttf$",
   };
   RefPtr reader = Omnijar::GetReader(Omnijar::Type::GRE);
   for (unsigned i = 0; i < ArrayLength(sJarSearchPaths); i++) {
 nsZipFind* find;
 if (NS_SUCCEEDED(reader->FindInit(sJarSearchPaths[i], &find))) {
   const char* path;
   uint16_t len;
   while (NS_SUCCEEDED(find->FindNext(&path, &len))) {
 nsCString entryName(path, len);
 AppendFacesFromOmnijarEntry(reader, entryName, aCache,
 jarChanged);
   }
   delete find;
 }
   }
 }}}

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

Re: [tor-bugs] #31286 [Applications/Tor Browser]: Include bridge configuration into about:preferences

[Tor Bug Tracker & Wiki]

#31286: Include bridge configuration into about:preferences
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-alpha,  |  Actual Points:
  TorBrowserTeam201909R, ff68-esr, ux-team   |
Parent ID:  #10760   | Points:  15
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by antonela):

 * cc: antonela (removed)
 * keywords:  tbb-9.0-must-alpha, TorBrowserTeam201909R, ff68-esr => tbb-9.0
 -must-alpha, TorBrowserTeam201909R, ff68-esr, ux-team


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

Re: [tor-bugs] #31880 [Applications/Tor Browser]: Disabling EME per configure option does not work on mobile anymore

[Tor Bug Tracker & Wiki]

#31880: Disabling EME per configure option does not work on mobile anymore
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  alpha, TorBrowserTeam201909R   |
Parent ID:  #30324   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

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


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

Re: [tor-bugs] #31880 [Applications/Tor Browser]: Disabling EME per configure option does not work on mobile anymore

[Tor Bug Tracker & Wiki]

#31880: Disabling EME per configure option does not work on mobile anymore
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  alpha, TorBrowserTeam201909|
Parent ID:  #30324   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Configuring `mobile/android/` with `--disable-eme` results in:

 {{{
 0:01.23 Traceback (most recent call last):
  0:01.23   File "/home/android/tor-browser/configure.py", line 132, in
 
  0:01.23 sys.exit(main(sys.argv))
  0:01.23   File "/home/android/tor-browser/configure.py", line 38, in main
  0:01.23 sandbox.run(os.path.join(os.path.dirname(__file__),
 'moz.configure'))
  0:01.23   File "/home/android/tor-
 browser/python/mozbuild/mozbuild/configure/__init__.py", line 441, in run
  0:01.23 self._value_for(option)
  0:01.23   File "/home/android/tor-
 browser/python/mozbuild/mozbuild/configure/__init__.py", line 528, in
 _value_for
  0:01.23 return self._value_for_option(obj)
  0:01.23   File "/home/android/tor-
 browser/python/mozbuild/mozbuild/util.py", line 947, in method_call
  0:01.23 cache[args] = self.func(instance, *args)
  0:01.23   File "/home/android/tor-
 browser/python/mozbuild/mozbuild/configure/__init__.py", line 591, in
 _value_for_option
  0:01.23 % option_string.split('=', 1)[0])
  0:01.23 mozbuild.configure.options.InvalidOptionError: --disable-eme is
 not available in this configuration
  0:01.27 *** Fix above errors and then restart with\
  0:01.27"./mach build"
  0:01.27 client.mk:111: recipe for target 'configure' failed
  0:01.27 make: *** [configure] Error 1
 }}}

 `--enable-eme` only affects `MOZ_EME_MODULES`. The MODULES are only
 defined for [https://searchfox.org/mozilla-
 esr68/search?q=MOZ_EME_MODULES&path= browser]. In FF67, enabling eme was
 [https://hg.mozilla.org/releases/mozilla-
 esr68/rev/43965f6107dcdd7051afae588ebe0c3b12612ec8  restricted] by OS,
 kernel, and CPU arch.

 [https://searchfox.org/mozilla-esr68/source/toolkit/moz.configure#519
 moz.configure}:
 {{{
 @depends(target)
 def eme_choices(target):
 if (target.kernel in ('Darwin', 'WINNT', 'Linux') and
 target.os not in ('Android', 'iOS') and
 target.cpu in ('x86', 'x86_64')):
 return ('widevine',)
 if target.kernel == 'WINNT' and target.cpu == 'aarch64':
 return ('widevine',)
 [snip]

 option('--enable-eme',
nargs='+',
choices=eme_choices,
default=eme_default,
when=eme_choices,
help='{Enable|Disable} support for Encrypted Media Extensions')
 }}}

 The "choices" returned by [https://searchfox.org/mozilla-
 esr68/source/toolkit/moz.configure#519 eme_choices] is `false-ish` (I
 assume) on Android and iOS, and configure [https://searchfox.org/mozilla-
 esr68/source/python/mozbuild/mozbuild/configure/__init__.py#580 errors] as
 a result of this.

 {{{
 when = self._conditions.get(option)
 # If `when` resolves to a false-ish value, we always return None.
 # This makes option(..., when='--foo') equivalent to
 # option(..., when=depends('--foo')(lambda x: x)).
 if when and not self._value_for(when) and value is not None:
 # If the option was passed explicitly, we throw an error that
 # the option is not available. Except when the option was
 passed
 # from the environment, because that would be too cumbersome.
 if value.origin not in ('default', 'environment'):
 raise InvalidOptionError(
 '%s is not available in this configuration'
 % option_string.split('=', 1)[0])
 self._logger.log(TRACE, '%r = None', option)
 return None
 }}}

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

Re: [tor-bugs] #31071 [Metrics/ExoneraTor]: Add a notice if we're missing data for a lookup

[Tor Bug Tracker & Wiki]

#31071: Add a notice if we're missing data for a lookup
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  irl |Sponsor:
+--
Changes (by karsten):

 * status:  assigned => needs_review


Comment:

 I finished a first implementation of this feature. It's pretty much as
 described in my previous comment, with the following exceptions:

  - I extended the view to missing statuses. That means if the directory
 authorities do not produce a consensus for an extended time, we'll put out
 a warning, too. This case is much less likely than a failing exit scanner,
 but it seemed related enough to include this case here.

  - I did not restrict the warning to cases when we're missing consecutive
 18 hours of statuses or exit lists, but for cases when we're missing any
 18 hours in the 3 or 4 days we're looking at. This was slightly easier to
 implement, but it's probably also slightly more robust, because it also
 addresses cases where the scanner dies, comes back shortly, and dies
 again.

  - I updated `src/main/sql/exonerator2.sql` rather than creating a new
 file `src/main/sql/exonerator3.sql`, because the changes did not affect
 any tables or views, just a single function. Let's be honest, the whole
 update is going to be a manual process anyway, and one needs to know
 exactly what one is doing. That's why I kept this simple.

 Please take a look at the attached screenshot with examples how this new
 warning would look like. It's the "However, the database..." part. We
 could of course make this more visible and clearer. Maybe that's a UX team
 mission, though.

 [[Image(task-31071-note.png, 700px)]]

 Regarding code, please take a look at
 
[https://gitweb.torproject.org/user/karsten/exonerator.git/commit/?h=task-31071&id=b0165cb03138e933a337ddc8400c3a8bbe889b3d
 commit b0165cb in my task-31071 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

Re: [tor-bugs] #31071 [Metrics/ExoneraTor]: Add a notice if we're missing data for a lookup

[Tor Bug Tracker & Wiki]

#31071: Add a notice if we're missing data for a lookup
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  enhancement | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  irl |Sponsor:
+--
Changes (by karsten):

 * Attachment "task-31071-note.png" added.


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

Re: [tor-bugs] #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:  asn
 Type:  defect| Status:  needs_information
 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:
--+
Changes (by asn):

 * status:  assigned => needs_information


Comment:

 Tim, I checked the children of #26664 and they seem quite related to this
 ticket. Is there a bug present in this ticket that is not filed under
 #26664 that we are looking for? Or will fixing the children of #26664
 (e.g. #24833) also fix this bug?

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

Re: [tor-bugs] #30344 [Core Tor/Tor]: conn_read_callback is called on connections that are marked for closed

[Tor Bug Tracker & Wiki]

#30344: conn_read_callback is called on connections that are marked for closed
-+-
 Reporter:  robgjansen   |  Owner:  asn
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.8
 Severity:  Normal   | Resolution:
 Keywords:  tor-conn, 035-backport,  |  Actual Points:
  041-deferred-20190530, 042-should  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by asn):

 * cc: pastly (removed)
 * status:  assigned => needs_information


Comment:

 Hello Rob, I took your patch from the top comment and slimmed it down a
 bit to https://github.com/torproject/tor/pull/1380

 I removed the parts about the writing/flushing because I did not
 understand exactly what they were doing, and also because the patch from
 comment:1 did not seem to need them. What are we missing by not doing it?

 Also I did not do the approach from comment:1 because we don't want to add
 stuff to `connection_mark_for_close()` (Also see the documentation change
 I did to this effect).

 Let me know how you like this, and if it works for you please!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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, GeorgKoppen201908,  |  Actual Points:
  TorBrowserTeam201909, tbb-9.0  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 So, not adding `libssp.dll.a` solves actually both issues I had (the
 dynamically linking and the crashes). I might be tempted to pick this up
 to get it still into 9.0 or 9.5a1 if the former is too risky. :)

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

Re: [tor-bugs] #30344 [Core Tor/Tor]: conn_read_callback is called on connections that are marked for closed

[Tor Bug Tracker & Wiki]

#30344: conn_read_callback is called on connections that are marked for closed
-+-
 Reporter:  robgjansen   |  Owner:  asn
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.8
 Severity:  Normal   | Resolution:
 Keywords:  tor-conn, 035-backport,  |  Actual Points:
  041-deferred-20190530, 042-should  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pastly):

 * cc: pastly (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] #28196 [Applications/Tor Browser]: about:preferences#general is not properly translated anymore starting with Tor Browser 8.5a4

[Tor Bug Tracker & Wiki]

#28196: about:preferences#general is not properly translated anymore starting 
with
Tor Browser 8.5a4
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-regression,  |  Actual Points:
  TorBrowserTeam201909R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by acat):

 * keywords:  tbb-regression, TorBrowserTeam201909 => tbb-regression,
 TorBrowserTeam201909R
 * status:  needs_revision => needs_review


Comment:

 Revised patches in https://github.com/acatarineu/tor-
 browser/commits/28196+1 (4 commits) and
 https://github.com/acatarineu/torbutton/commit/28196+1

 Replying to [comment:14 steph]:
 > I'm for the alignment as well.
 > brandProductName Tor Browser
 > vendorShortName  The Tor Project
 > trademarkInfo.part1 Tor and Tor onion logos are trademarks of The Tor
 Project, Inc.
 I reused `tor.TrademarkStatement` from torbutton which is very close to
 the suggested `Tor and Tor onion logos are trademarks of The Tor Project,
 Inc.`. And used the en-US one as fallback for locales that do not have
 that string yet.

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_revision => needs_review


Comment:

 I fixed the issue while allowing tests to pass.

 However, I believe my code is tested with the test routine
 `test_service_event()`:

 {{{
 /* Now, we'll create an IP with a registered circuit. The IP object
  * shouldn't go away. */
 ip = helper_create_service_ip();
 service_intro_point_add(service->desc_current->intro_points.map, ip);
 ed25519_pubkey_copy(&circ->hs_ident->intro_auth_pk,
 &ip->auth_key_kp.pubkey);
 hs_circuitmap_register_intro_circ_v3_service_side(
  circ, &ip->auth_key_kp.pubkey);
 run_housekeeping_event(now);
 tt_int_op(digest256map_size(service->desc_current->intro_points.map),
   OP_EQ, 1);
 /* We'll mangle the IP object to expire. */
 ip->time_to_expire = now;
 run_housekeeping_event(now);
 tt_int_op(digest256map_size(service->desc_current->intro_points.map),
   OP_EQ, 0);
 }}}

 Setting as 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] #31634 [Core Tor/Tor]: Check .may_include order and tor subsystem init order are compatible

[Tor Bug Tracker & Wiki]

#31634: Check .may_include order and tor subsystem init order are compatible
-+-
 Reporter:  teor |  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:  diagnostics, 042-should?,|  Actual Points:
  practracker|
Parent ID:   | Points:  2
 Reviewer:  teor |Sponsor:
 |  Sponsor31-can
-+-
Changes (by nickm):

 * status:  assigned => needs_review
 * keywords:  diagnostics, 042-should, practracker => diagnostics,
 042-should?, practracker
 * reviewer:   => teor


Comment:

 I have started this, but I believe it is bigger than we should do in
 0.4.2, and we should defer part of it till 0.4.3.  Here is why:

* Our subsystems do not currently to our directory structures.
 Notably, these subsystems are defined in with names that do not match
 their locations: btrack, network, ocirc_event, oconn_event, relay,
 threads, tortls, winprocess.

* Our subsystem order does not currently match the topology very well
 at all: there are four discontinuities on the ordering.  I think they are
 caused by: btrack, compress, winprocess, threads.  We should re-order
 these, but doing so will require us to re-organize some of our code.  That
 seems like a stability risk.

 I have checked in a work-in-progress version of the code to do these
 checks as `ticket31634`.  Do you think it's reasonable to defer to 0.4.3
 based on the above reasoning?  If not, please re-assign to me for 0.4.2,
 but this just got bigger than we anticipated.

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

Re: [tor-bugs] #30090 [UX]: Make a list of potential .onion errors

[Tor Bug Tracker & Wiki]

#30090: Make a list of potential .onion errors
+
 Reporter:  pili|  Owner:  antonela
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  UX  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  #19251  | Points:
 Reviewer:  |Sponsor:  Sponsor27-must
+
Changes (by mcs):

 * cc: brade, mcs (added)


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

Re: [tor-bugs] #30036 [Applications/Tor Browser]: Remove Orfox patches that were related to Orbot communication

[Tor Bug Tracker & Wiki]

#30036: Remove Orfox patches that were related to Orbot communication
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-8.5, tbb-mobile, |  Actual Points:
  GeorgKoppen201905, TorBrowserTeam201909|
Parent ID:   | Points:  0
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

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


Comment:

 This was resolved during the rebase onto 68esr in #31010.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by asn):

 Replying to [comment:19 neel]:
 > To clarify, is the bug you are talking about related to removing the
 intro point if `hs_circ_service_get_intro_circ()` is true? If not, what is
 it?

 Yep! Before `861ff757712d008424746e9d1e9bd85b3f472dee` we used to return
 `True` if `hs_circ_service_get_intro_circ(ip)` is true. After that commit,
 we return `False`.
 This seems like a behavior change and not just refactoring.

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

Re: [tor-bugs] #17359 [Core Tor/Tor]: __DisablePredictedCircuits causes bootstrap to hang at "Connecting to Tor Network"

[Tor Bug Tracker & Wiki]

#17359: __DisablePredictedCircuits causes bootstrap to hang at "Connecting to 
Tor
Network"
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  tor-hs bootstrap sponsor8-maybe  |  Actual Points:
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:16 dgoulet]:
 > Replying to [comment:15 teor]:
 > > In #17592 in Tor 0.3.1.1-alpha, we replaced
 PredictedPortsRelevanceTime and CircuitIdleTimeout with
 CircuitsAvailableTimeout.
 > >
 > > So the current workaround is:
 > > {{{
 > > LongLivedPorts
 > > LearnCircuitBuildTimeout 0
 > > # and
 > > PredictedPortsRelevanceTime 0 seconds
 > > # or
 > > CircuitsAvailableTimeout (a small timeout? a large timeout?)
 > > }}}
 > >
 > > We can't disable predicted ports separately any more, which is
 annoying.
 >
 > I'm having this issue with Exitmap and the above workaround do not work
 :S ...
 >
 > No circuit activity stalls bootstrap progression basically :(.

 Those workarounds make tor stop building as many circuits as possible.
 They are a workaround for this use case:

 "I am running lots of tor instances, and I don't want them to build
 useless circuits."

 I don't know what the workaround for your use case is. But I think your
 use case is:

 "I am running a tor instance, and I don't want it to stall."

 Maybe you should try:

 LongLivedPorts 80,443
 LearnCircuitBuildTimeout 1
 PredictedPortsRelevanceTime (Maximum allowed time)
 CircuitsAvailableTimeout (I'm not really sure, maybe use the default? Or
 try a large or small timeout, and see how you go.)

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

Re: [tor-bugs] #31768 [Applications/Tor Browser]: Introduce Tor network settings and other updates in TB9 onboarding

[Tor Bug Tracker & Wiki]

#31768: Introduce Tor network settings and other updates in TB9 onboarding
-+-
 Reporter:  antonela |  Owner:  dunqan
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, TorBrowserTeam201909,   |  Actual Points:
  tbb-9.0-must-alpha |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

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


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

Re: [tor-bugs] #17359 [Core Tor/Tor]: __DisablePredictedCircuits causes bootstrap to hang at "Connecting to Tor Network"

[Tor Bug Tracker & Wiki]

#17359: __DisablePredictedCircuits causes bootstrap to hang at "Connecting to 
Tor
Network"
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  tor-hs bootstrap sponsor8-maybe  |  Actual Points:
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 My first thought is that we should distinguish between "predicted"
 circuits, meaning circuits that are made for the purpose of having extra
 clean circuits sitting around if we need them, and other kinds of
 circuits, such as the ones we use to see if we can connect to the network.

 And we should do all of the other things that we need circuits for, even
 if 'predicted' circuits are disabled.

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

Re: [tor-bugs] #17359 [Core Tor/Tor]: __DisablePredictedCircuits causes bootstrap to hang at "Connecting to Tor Network"

[Tor Bug Tracker & Wiki]

#17359: __DisablePredictedCircuits causes bootstrap to hang at "Connecting to 
Tor
Network"
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  tor-hs bootstrap sponsor8-maybe  |  Actual Points:
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-
Description changed by arma:

Old description:

> When __DisablePredictedCircuits is set in the torrc, bootstrap hangs at
> 80% - "Connecting to Tor Network".
>
> This happens in hidden service configurations, it may happen in other
> client or server configurations as well.
>
> I think this is because:
> * no predicted circuits are being built, and therefore
> * tor never completes an OR connection, and therefore
> * tor never thinks it has bootstrapped, and therefore
> * tor doesn't make any of the OR connections it would make as part of its
> configured function
>
> To fix this, we need to either:
> * assume tor is connected to the network if it gets to "Connecting to Tor
> Network" and __DisablePredictedCircuits is set, or
> * make at least one connection at "Connecting to Tor Network" even if
> __DisablePredictedCircuits is set
>
> The first risks repeatedly making connections if tor isn't connected to
> the network, the second risks making connections the user doesn't want.

New description:

 When {{{__DisablePredictedCircuits}}} is set in the torrc, bootstrap hangs
 at 80% - "Connecting to Tor Network".

 This happens in hidden service configurations, it may happen in other
 client or server configurations as well.

 I think this is because:
 * no predicted circuits are being built, and therefore
 * tor never completes an OR connection, and therefore
 * tor never thinks it has bootstrapped, and therefore
 * tor doesn't make any of the OR connections it would make as part of its
 configured function

 To fix this, we need to either:
 * assume tor is connected to the network if it gets to "Connecting to Tor
 Network" and {{{__DisablePredictedCircuits}}} is set, or
 * make at least one connection at "Connecting to Tor Network" even if
 {{{__DisablePredictedCircuits}}} is set

 The first risks repeatedly making connections if tor isn't connected to
 the network, the second risks making connections the user doesn't want.

--

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

Re: [tor-bugs] #31882 [Core Tor/Tor]: move Android build config into core tor

[Tor Bug Tracker & Wiki]

#31882: move Android build config into core tor
-+
 Reporter:  eighthave|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, tbb-mobile  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by eighthave):

 Also, FYI, OnionBrowser on iOS has been building and using tor like this
 for a while 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] #30090 [UX]: Make a list of potential .onion errors

[Tor Bug Tracker & Wiki]

#30090: Make a list of potential .onion errors
+
 Reporter:  pili|  Owner:  antonela
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  UX  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  #19251  | Points:
 Reviewer:  |Sponsor:  Sponsor27-must
+

Comment (by antonela):

 https://lists.torproject.org/pipermail/tor-dev/2019-September/014046.html

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

Re: [tor-bugs] #31882 [Core Tor/Tor]: move Android build config into core tor

[Tor Bug Tracker & Wiki]

#31882: move Android build config into core tor
-+
 Reporter:  eighthave|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, tbb-mobile  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by teor):

 Replying to [comment:3 eighthave]:
 > ...
 >
 > I already have a working Android CI build in gitlab-ci (plus I started
 porting the ''.travis.yml'' to ''.gitlab-ci.yml'' while I was at it and
 threw in a couple of distro builds).  It should be relatively
 straightforward to port the Android CI job ''.travis.yml'' for someone who
 know that whole matrix setup.
 > https://gitlab.com/eighthave/tor/blob/dbeb6f7d8/.gitlab-ci.yml
 > And here's an example run on the latest ''master'':
 > https://gitlab.com/eighthave/tor/pipelines/85003730

 I'm currently rewriting and simplifying our build matrix in #30860. It
 might be easier to port the .travis.yml after I'm 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] #31720 [Applications/Tor Browser]: Address bar auto-complete is broken on Android

[Tor Bug Tracker & Wiki]

#31720: Address bar auto-complete is broken on Android
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-mobile, ff68-esr,|  Actual Points:  0.5
  TorBrowserTeam201909R  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

 * actualpoints:   => 0.5


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

Re: [tor-bugs] #31192 [Applications/Tor Browser]: TBA - Support x86_64 target

[Tor Bug Tracker & Wiki]

#31192: TBA - Support x86_64 target
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-mobile, tbb-rbm, ff68-esr,   |  Actual Points:  2.5
  GeorgKoppen201907, TorBrowserTeam201909|
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by sysrqb):

 * actualpoints:   => 2.5


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

Re: [tor-bugs] #31882 [Core Tor/Tor]: move Android build config into core tor

[Tor Bug Tracker & Wiki]

#31882: move Android build config into core tor
-+
 Reporter:  eighthave|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, tbb-mobile  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by eighthave):

 lol, yeah, not by design.  I just tried `./configure --enable-pic` and it
 works as a .so

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

Re: [tor-bugs] #31734 [Core Tor/Tor]: Add accessor functions for cb_buf, which enforce locking and unlocking

[Tor Bug Tracker & Wiki]

#31734: Add accessor functions for cb_buf, which enforce locking and unlocking
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  diagnostics, 042-should, no- |  Actual Points:  0.2
  backport, regression, BugSmashFund |
Parent ID:  #31614   | Points:  0.2
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:
 consider-backport-after-042-stable, consider-backport-if-needed,
 diagnostics, 042-should, 035-backport-maybe, 040-backport-maybe, 041
 -backport-maybe, regression, BugSmashFund
 => diagnostics, 042-should, no-backport, regression, BugSmashFund
 * status:  assigned => needs_review
 * points:   => 0.2
 * actualpoints:   => 0.2


Comment:

 This ticket depends on #31614 and #31594. I don't think we'll backport
 both of those branches, so I'm marking this one as no-backport.

 See my PR:
 * master: https://github.com/torproject/tor/pull/1379

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

Re: [tor-bugs] #17359 [Core Tor/Tor]: __DisablePredictedCircuits causes bootstrap to hang at "Connecting to Tor Network"

[Tor Bug Tracker & Wiki]

#17359: __DisablePredictedCircuits causes bootstrap to hang at "Connecting to 
Tor
Network"
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Minor| Resolution:
 Keywords:  tor-hs bootstrap sponsor8-maybe  |  Actual Points:
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 Replying to [comment:15 teor]:
 > In #17592 in Tor 0.3.1.1-alpha, we replaced PredictedPortsRelevanceTime
 and CircuitIdleTimeout with CircuitsAvailableTimeout.
 >
 > So the current workaround is:
 > {{{
 > LongLivedPorts
 > LearnCircuitBuildTimeout 0
 > # and
 > PredictedPortsRelevanceTime 0 seconds
 > # or
 > CircuitsAvailableTimeout (a small timeout? a large timeout?)
 > }}}
 >
 > We can't disable predicted ports separately any more, which is annoying.

 I'm having this issue with Exitmap and the above workaround do not work :S
 ...

 No circuit activity stalls bootstrap progression basically :(.

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

Re: [tor-bugs] #31886 [Applications/Tor Browser]: ko bundles are broken - XML Parsing Error (was: ko bundles are broken - XML Pasing Error)

[Tor Bug Tracker & Wiki]

#31886: ko bundles are broken - XML Parsing Error
-+-
 Reporter:  Thorin   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201909, tbb-   |  Actual Points:
  regression |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by neel):

 To clarify, is the bug you are talking about related to removing the intro
 point if `hs_circ_service_get_intro_circ()` is true? If not, what is 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] #31736 [Core Tor/Tor]: Stop using mutex_destroy(), when multiple threads can still access the mutex

[Tor Bug Tracker & Wiki]

#31736: Stop using mutex_destroy(), when multiple threads can still access the
mutex
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  consider-backport-after-042-stable,  |  Actual Points:  0.5
  consider-backport-if-needed, diagnostics,  |
  042-should, 035-backport-maybe, 040-backport-  |
  maybe, 041-backport-maybe, regression, |
  BugSmashFund   |
Parent ID:   | Points:  0.2
 Reviewer:  nickm|Sponsor:
-+-
Changes (by teor):

 * parent:  #31614 =>


Comment:

 This ticket can be merged independently of its parent.

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

Re: [tor-bugs] #31882 [Core Tor/Tor]: move Android build config into core tor

[Tor Bug Tracker & Wiki]

#31882: move Android build config into core tor
-+
 Reporter:  eighthave|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, tbb-mobile  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by nickm):

 Whoa, that's not how you're supposed to make an .so file, is it?  I
 thought you were supposed to use a specific set of linker options in order
 to make a .so.

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

Re: [tor-bugs] #31898 [Core Tor/Tor]: Occasional crash during shutdown when using Tor API

[Tor Bug Tracker & Wiki]

#31898: Occasional crash during shutdown when using Tor API
-+-
 Reporter:  sysrqb   |  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  042-regression, crash, 042-must  |  Actual Points:
  041-backport? 041-regression?  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor31-must
-+-
Changes (by nickm):

 * owner:  (none) => nickm
 * keywords:  042-regression, crash, 042-must => 042-regression, crash,
 042-must 041-backport? 041-regression?
 * status:  new => accepted


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

Re: [tor-bugs] #31734 [Core Tor/Tor]: Add accessor functions for cb_buf, which enforce locking and unlocking

[Tor Bug Tracker & Wiki]

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

 * status:  new => assigned
 * owner:  (none) => teor


Comment:

 Distributing 0.4.2 tickets between network team members.

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

Re: [tor-bugs] #31683 [Core Tor/Tor]: md: Bad family line in cached-microdescs.new

[Tor Bug Tracker & Wiki]

#31683: md: Bad family line in cached-microdescs.new
---+
 Reporter:  dgoulet|  Owner:  nickm
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  microdesc, 042-should  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by ahf):

 * owner:  (none) => nickm
 * status:  new => assigned


Comment:

 Distributing 0.4.2 tickets between network team members.

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

Re: [tor-bugs] #31634 [Core Tor/Tor]: Check .may_include order and tor subsystem init order are compatible

[Tor Bug Tracker & Wiki]

#31634: Check .may_include order and tor subsystem init order are compatible
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  diagnostics, 042-should, |  Actual Points:
  practracker|
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
 |  Sponsor31-can
-+-
Changes (by ahf):

 * owner:  (none) => nickm
 * status:  new => assigned


Comment:

 Distributing 0.4.2 tickets between network team members.

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

Re: [tor-bugs] #31611 [Core Tor/Tor]: Work out why chutney didn't fail due to #31495 cannot configure bridges

[Tor Bug Tracker & Wiki]

#31611: Work out why chutney didn't fail due to #31495 cannot configure bridges
-+-
 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-september,  |  Actual Points:
  042-should |
Parent ID:  #29211   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor31-must
-+-
Changes (by ahf):

 * status:  new => assigned
 * owner:  (none) => nickm


Comment:

 Distributing 0.4.2 tickets between network team members.

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

Re: [tor-bugs] #31543 [Core Tor/Tor]: Add unit tests or chutney tests for IPv6Traffic

[Tor Bug Tracker & Wiki]

#31543: Add unit tests or chutney tests for IPv6Traffic
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 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:
--+
Changes (by ahf):

 * status:  new => assigned
 * owner:  (none) => teor


Comment:

 Distributing 0.4.2 tickets between network team members.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  asn
 Type:  defect| Status:  assigned
 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:
--+
Changes (by ahf):

 * owner:  (none) => asn
 * status:  new => assigned


Comment:

 Distributing 0.4.2 tickets between network team members.

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

Re: [tor-bugs] #31189 [Core Tor/Tor]: potential docs update needed for GuardLifetime?

[Tor Bug Tracker & Wiki]

#31189: potential docs update needed for GuardLifetime?
-+-
 Reporter:  cypherpunks  |  Owner:  nickm
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  docs, guardlifetime, 042-should  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ahf):

 * status:  new => assigned
 * owner:  (none) => nickm


Comment:

 Distributing 0.4.2 tickets between network team members.

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

Re: [tor-bugs] #31364 [Core Tor/Tor]: tor_bug_occurred_(): Bug: ../src/feature/nodelist/microdesc.c:494: warn_if_nul_found: Non-fatal assertion !(nul_found) failed. (on Tor 0.4.0.5 )

[Tor Bug Tracker & Wiki]

#31364: tor_bug_occurred_(): Bug: ../src/feature/nodelist/microdesc.c:494:
warn_if_nul_found: Non-fatal assertion !(nul_found) failed. (on Tor 0.4.0.5
)
-+-
 Reporter:  computer_freak   |  Owner:  nickm
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  microdesc assert 042-should  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ahf):

 * status:  new => assigned
 * owner:  (none) => nickm


Comment:

 Distributing 0.4.2 tickets between network team members.

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

Re: [tor-bugs] #31036 [Core Tor/Tor]: Logfile grow upto 2GB tor fails and refuse to start

[Tor Bug Tracker & Wiki]

#31036: Logfile grow upto 2GB tor fails and refuse to start
-+-
 Reporter:  cypherpunks  |  Owner:
 |  catalyst
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-backport, 040-backport,  |  Actual Points:
  041-backport, 042-should   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ahf):

 * status:  new => assigned
 * owner:  (none) => catalyst


Comment:

 Distributing 0.4.2 tickets between network team members.

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

Re: [tor-bugs] #31022 [Core Tor/Tor]: Tor's windows "--service install" should warn if it installs on a global writeable path

[Tor Bug Tracker & Wiki]

#31022: Tor's windows "--service install" should warn if it installs on a global
writeable path
-+-
 Reporter:  asn  |  Owner:  ahf
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  hackerone, bug-bounty, security, |  Actual Points:
  042-should |
Parent ID:   | Points:  0.3
 Reviewer:   |Sponsor:
-+-
Changes (by ahf):

 * status:  new => assigned
 * owner:  (none) => ahf


Comment:

 Distributing 0.4.2 tickets between network team members.

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

Re: [tor-bugs] #30344 [Core Tor/Tor]: conn_read_callback is called on connections that are marked for closed

[Tor Bug Tracker & Wiki]

#30344: conn_read_callback is called on connections that are marked for closed
-+-
 Reporter:  robgjansen   |  Owner:  asn
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.8
 Severity:  Normal   | Resolution:
 Keywords:  tor-conn, 035-backport,  |  Actual Points:
  041-deferred-20190530, 042-should  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ahf):

 * owner:  (none) => asn
 * status:  new => assigned


Comment:

 Distributing 0.4.2 tickets between network team members.

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

Re: [tor-bugs] #29911 [Core Tor/Tor]: Update HelpfulTools.md once we have some experience with practracker

[Tor Bug Tracker & Wiki]

#29911: Update HelpfulTools.md once we have some experience with practracker
-+-
 Reporter:  teor |  Owner:
 |  catalyst
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  doc, postfreeze-ok,  |  Actual Points:
  041-deferred-20190719, 042-should  |
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+-
Changes (by ahf):

 * status:  new => assigned
 * owner:  (none) => catalyst


Comment:

 Distributing 0.4.2 tickets between network team members.

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

Re: [tor-bugs] #29698 [Core Tor/Tor]: Edge case that causes improper circuit prioritization for one scheduling run

[Tor Bug Tracker & Wiki]

#29698: Edge case that causes improper circuit prioritization for one scheduling
run
-+-
 Reporter:  pastly   |  Owner:  dgoulet
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, tor-cmux, kist,   |  Actual Points:
  041-deferred-20190530, 042-should  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ahf):

 * status:  new => assigned
 * owner:  (none) => dgoulet


Comment:

 Distributing 0.4.2 tickets between network team members.

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

Re: [tor-bugs] #29546 [Core Tor/Tor]: Update Maintaining.md after new merge policy is final

[Tor Bug Tracker & Wiki]

#29546: Update Maintaining.md after new merge policy is final
-+-
 Reporter:  teor |  Owner:  teor
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  policy, doc, 041-deferred-20190530,  |  Actual Points:
  042-should |
Parent ID:   | Points:  0.3
 Reviewer:   |Sponsor:
-+-
Changes (by ahf):

 * owner:  (none) => teor


Comment:

 Distributing 0.4.2 tickets between network team members.

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