Re: [tor-bugs] #32240 [Core Tor/Tor]: Tor Travis: Make chutney work on Xenial and Bionic images

[Tor Bug Tracker & Wiki]

#32240: Tor Travis: Make chutney work on Xenial and Bionic images
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, chutney, 043-should, |  Actual Points:
  029-backport, 035-backport, 040-backport,  |
  041-backport, 042-backport |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Chutney also fails when run on bionic, see:
 https://trac.torproject.org/projects/tor/ticket/32630#comment:2
 https://travis-ci.org/teor2345/chutney/jobs/618413136#L1607

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

Re: [tor-bugs] #32632 [Core Tor/Fallback Scripts]: Fallback Scripts Travis: Use the latest dependencies

[Tor Bug Tracker & Wiki]

#32632: Fallback Scripts Travis: Use the latest dependencies
---+-
 Reporter:  teor   |  Owner:  teor
 Type:  task   | Status:  merge_ready
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:  0.3
Parent ID:  #28863 | Points:  0.5
 Reviewer: |Sponsor:
---+-
Changes (by teor):

 * status:  assigned => merge_ready
 * actualpoints:  0.1 => 0.3


Comment:

 Here's a PR that updates the dependencies:
 * master: https://github.com/torproject/fallback-scripts/pull/8

 It also implements part of #28863, getting a minimal set of python 3
 builds installed and failing on python 3 issues. (Rather than config
 issues.)

 I'll merge this once CI passes. Anyone is free to 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] #32632 [Core Tor/Fallback Scripts]: Fallback Scripts Travis: Use the latest dependencies

[Tor Bug Tracker & Wiki]

#32632: Fallback Scripts Travis: Use the latest dependencies
---+
 Reporter:  teor   |  Owner:  teor
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:  0.3
Parent ID:  #28863 | Points:  0.5
 Reviewer: |Sponsor:
---+
Changes (by teor):

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


Comment:

 Merged 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] #32631 [Core Tor/Chutney]: Chutney Travis: Use the latest dependencies

[Tor Bug Tracker & Wiki]

#32631: Chutney Travis: Use the latest dependencies
--+
 Reporter:  teor  |  Owner:  teor
 Type:  task  | Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  0.3
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  assigned => needs_revision
 * actualpoints:  0.1 => 0.3


Comment:

 I have two branches, ticket32631 and ticket 32631-pref-python3.

 I just need to check that they pass CI, and are using the correct python
 versions.

 I'm deferring switching to bionic right now, because it triggers #32630.

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

Re: [tor-bugs] #32629 [Core Tor/Tor]: Re-enable 1 or 2 more macOS jobs in Travis

[Tor Bug Tracker & Wiki]

#32629: Re-enable 1 or 2 more macOS jobs in Travis
--+
 Reporter:  teor  |  Owner:  teor
 Type:  task  | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-ci|  Actual Points:  0.2
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  assigned => needs_revision
 * points:  0.2 => 0.5
 * actualpoints:   => 0.2


Comment:

 I have some draft ticket32629_* branches, but I need to check that they
 pass CI, and check now much extra time they cost us.

 If we have to disable any jobs, it should be the Rust job, because that's
 lower priority than chutney IPv6.

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

Re: [tor-bugs] #32629 [Core Tor/Tor]: Re-enable 1 or 2 more macOS jobs in Travis

[Tor Bug Tracker & Wiki]

#32629: Re-enable 1 or 2 more macOS jobs in Travis
-+-
 Reporter:  teor |  Owner:  teor
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  consider-backport-immediately, tor-  |  Actual Points:  0.3
  ci, ipv6, macos, 029-backport, 035-backport,   |
  040-backport, 041-backport, 042-backport   |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_revision => needs_review
 * keywords:  tor-ci =>
 consider-backport-immediately, tor-ci, ipv6, macos, 029-backport,
 035-backport, 040-backport, 041-backport, 042-backport
 * actualpoints:  0.2 => 0.3


Comment:

 I re-enabled the macOS chutney job, but not the macOS Rust job. (macOS is
 slow, and Rust is the lowest priority.)

 Here are my PRs:
 * 0.2.9: https://github.com/torproject/tor/pull/1575
 * 0.3.5: https://github.com/torproject/tor/pull/1576
 * 0.4.2: https://github.com/torproject/tor/pull/1577

 Test branches:
 * https://github.com/teor2345/tor/branches/all?query=32629

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

Re: [tor-bugs] #23875 [Applications/Tor Browser]: Facebook's onion site is a single hop onion, but clicking on the Tor onion icon shows that it is a 6 hop circuit.

[Tor Bug Tracker & Wiki]

#23875: Facebook's onion site is a single hop onion, but clicking on the Tor 
onion
icon shows that it is a 6 hop circuit.
--+---
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-circuit-display, ux-team  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor27-can
--+---

Comment (by cypherpunks):

 Replying to [comment:14 teor]:
 > This is particularly true in recent tor versions, which implement
 "fallback to a 3-hop path on address or connection failure" on v2 and v3
 onions.
 Can you please clarify what that feature is?

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

Re: [tor-bugs] #23875 [Applications/Tor Browser]: Facebook's onion site is a single hop onion, but clicking on the Tor onion icon shows that it is a 6 hop circuit.

[Tor Bug Tracker & Wiki]

#23875: Facebook's onion site is a single hop onion, but clicking on the Tor 
onion
icon shows that it is a 6 hop circuit.
--+---
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-circuit-display, ux-team  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor27-can
--+---

Comment (by teor):

 Here's the spec:
 https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1487
 https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1934

 Here is what we actually implemented in 0.4.2.1-alpha and 0.4.1.6:
 https://gitweb.torproject.org/tor.git/tree/ChangeLog#n345

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32653 [Circumvention/Snowflake]: Yesterday, in China, I tried to connect to Tor network through snowflake bridge for 10 times. But all of the connections failed

[Tor Bug Tracker & Wiki]

#32653: Yesterday, in China, I tried to connect to Tor network through snowflake
bridge for 10 times. But all of the connections failed
+-
 Reporter:  amiableclarity2011  |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Immediate   |  Component:  Circumvention/Snowflake
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
 Yesterday, in China, I tried to connect to Tor network through snowflake
 bridge for 10 times. But all of the connections failed.

 Below is Tor log message.



 11/30/19, 05:31:12.347 [NOTICE] DisableNetwork is set. Tor will not make
 or accept non-control network connections. Shutting down all existing
 connections.
 11/30/19, 05:31:18.328 [NOTICE] DisableNetwork is set. Tor will not make
 or accept non-control network connections. Shutting down all existing
 connections.
 11/30/19, 05:31:18.328 [NOTICE] DisableNetwork is set. Tor will not make
 or accept non-control network connections. Shutting down all existing
 connections.
 11/30/19, 05:31:18.328 [NOTICE] DisableNetwork is set. Tor will not make
 or accept non-control network connections. Shutting down all existing
 connections.
 11/30/19, 05:31:18.328 [NOTICE] Opening Socks listener on 127.0.0.1:9150
 11/30/19, 05:31:18.328 [NOTICE] Opened Socks listener on 127.0.0.1:9150
 11/30/19, 05:31:19.237 [NOTICE] Bootstrapped 1% (conn_pt): Connecting to
 pluggable transport
 11/30/19, 05:31:19.239 [NOTICE] Bootstrapped 2% (conn_done_pt): Connected
 to pluggable transport
 11/30/19, 05:31:27.660 [NOTICE] Bootstrapped 10% (conn_done): Connected to
 a relay
 11/30/19, 05:31:57.600 [WARN] Problem bootstrapping. Stuck at 10%
 (conn_done): Connected to a relay. (DONE; DONE; count 1; recommendation
 warn; host 2B280B23E1107BB62ABFC40DDCC8824814F80A72 at 0.0.3.0:1)
 11/30/19, 05:31:57.610 [WARN] 1 connections have failed:
 11/30/19, 05:31:57.610 [WARN] 1 connections died in state handshaking
 (TLS) with SSL state SSLv3/TLS write client hello in HANDSHAKE
 11/30/19, 05:31:57.760 [NOTICE] Closing no-longer-configured Socks
 listener on 127.0.0.1:9150
 11/30/19, 05:31:57.760 [NOTICE] DisableNetwork is set. Tor will not make
 or accept non-control network connections. Shutting down all existing
 connections.
 11/30/19, 05:31:57.770 [WARN] Pluggable Transport process terminated with
 status code 0
 11/30/19, 05:35:38.791 [NOTICE] DisableNetwork is set. Tor will not make
 or accept non-control network connections. Shutting down all existing
 connections.
 11/30/19, 05:35:38.791 [NOTICE] DisableNetwork is set. Tor will not make
 or accept non-control network connections. Shutting down all existing
 connections.
 11/30/19, 05:35:38.791 [NOTICE] DisableNetwork is set. Tor will not make
 or accept non-control network connections. Shutting down all existing
 connections.
 11/30/19, 05:35:38.791 [NOTICE] Opening Socks listener on 127.0.0.1:9150
 11/30/19, 05:35:38.791 [NOTICE] Opened Socks listener on 127.0.0.1:9150
 11/30/19, 05:36:16.809 [WARN] Problem bootstrapping. Stuck at 10%
 (conn_done): Connected to a relay. (DONE; DONE; count 2; recommendation
 warn; host 2B280B23E1107BB62ABFC40DDCC8824814F80A72 at 0.0.3.0:1)
 11/30/19, 05:36:16.809 [WARN] 2 connections have failed:
 11/30/19, 05:36:16.809 [WARN] 2 connections died in state handshaking
 (TLS) with SSL state SSLv3/TLS write client hello in HANDSHAKE
 11/30/19, 05:36:16.814 [NOTICE] Closing no-longer-configured Socks
 listener on 127.0.0.1:9150
 11/30/19, 05:36:16.814 [NOTICE] DisableNetwork is set. Tor will not make
 or accept non-control network connections. Shutting down all existing
 connections.
 11/30/19, 05:36:16.814 [WARN] Pluggable Transport process terminated with
 status code 0
 11/30/19, 05:38:04.197 [NOTICE] DisableNetwork is set. Tor will not make
 or accept non-control network connections. Shutting down all existing
 connections.
 11/30/19, 05:38:04.197 [NOTICE] DisableNetwork is set. Tor will not make
 or accept non-control network connections. Shutting down all existing
 connections.
 11/30/19, 05:38:04.197 [NOTICE] DisableNetwork is set. Tor will not make
 or accept non-control network connections. Shutting down all existing
 connections.
 11/30/19, 05:38:04.197 [NOTICE] Opening Socks listener on 127.0.0.1:9150
 11/30/19, 05:38:04.197 [NOTICE] Opened Socks listener on 127.0.0.1:9150
 11/30/19, 05:38:37.581 [WARN] Problem bootstrapping. Stuck at 10%
 (conn_done): Connected to a relay. (DONE; DONE; count 3; recommendation
 warn; host 2B280B23E1107BB62ABFC40DDCC8824814F80A72 at 0.0.3.0:1)
 11/30/19, 05:38:37.581 [WARN] 3 connections have failed:
 11/30/19, 05:38:37.581 [WARN] 3 connections died in state handshaking
 (TLS) with SSL sta

Re: [tor-bugs] #32653 [Circumvention/Snowflake]: Yesterday, in China, I tried to connect to Tor network through snowflake bridge for 10 times. But all of the connections failed

[Tor Bug Tracker & Wiki]

#32653: Yesterday, in China, I tried to connect to Tor network through snowflake
bridge for 10 times. But all of the connections failed
-+
 Reporter:  amiableclarity2011   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Immediate|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by amiableclarity2011):

 * Attachment "torrc" 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] #32653 [Circumvention/Snowflake]: Yesterday, in China, I tried to connect to Tor network through snowflake bridge for 10 times. But all of the connections failed

[Tor Bug Tracker & Wiki]

#32653: Yesterday, in China, I tried to connect to Tor network through snowflake
bridge for 10 times. But all of the connections failed
-+
 Reporter:  amiableclarity2011   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Immediate|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by amiableclarity2011):

 * Attachment "state" 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] #32653 [Circumvention/Snowflake]: Yesterday, in China, I tried to connect to Tor network through snowflake bridge for 10 times. But all of the connections failed

[Tor Bug Tracker & Wiki]

#32653: Yesterday, in China, I tried to connect to Tor network through snowflake
bridge for 10 times. But all of the connections failed
-+
 Reporter:  amiableclarity2011   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Immediate|  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by amiableclarity2011):

 * Attachment "torrc-defaults" 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:  (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:  #32314| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:6 teor]:
 > I can't see anything obvious, but the exit does seem to be closing the
 connection.
 >

 I see this, isn't this the problem? no hop found:


 {{{
 [info] {CIRC} choose_good_exit_server_general(): Found 1066 servers that
 might support 0/0 pending connections.
 }}}

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

Re: [tor-bugs] #32648 [Core Tor/Tor]: core dump centos8

[Tor Bug Tracker & Wiki]

#32648: core dump centos8
--+
 Reporter:  mikeb |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.6
 Severity:  Normal| Resolution:
 Keywords:  centos core dump  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by mikeb):

 Silly me, it was the low port used for obfs4.

 {{{
 (gdb) bt
 #0  0x7f97bb67d93f in raise () from /lib64/libc.so.6
 #1  0x7f97bb667c95 in abort () from /lib64/libc.so.6
 #2  0x55812b25e4df in tor_abort_ () at src/lib/log/util_bug.c:173
 #3  0x55812b2d8109 in managed_proxy_stdout_callback
 (process=process@entry=0x55812ba27010, line=,
 line@entry=0x55812c307760 "SMETHOD-ERROR obfs4 listen tcp 0.0.0.0:587:
 bind: permission denied", size=) at
 src/feature/client/transports.c:1836
 #4  0x55812b3e9d63 in process_read_lines (callback=0x55812b2d7e60
 , buffer=0x55812ba430c0,
 process=0x55812ba27010) at src/lib/process/process.c:784
 #5  process_read_data (process=0x55812ba27010, buffer=0x55812ba430c0,
 callback=0x55812b2d7e60 ) at
 src/lib/process/process.c:706

 #6  0x7f97bd171ff1 in event_process_active_single_queue () from
 /lib64/libevent-2.1.so.6
 #7  0x7f97bd172787 in event_base_loop () from /lib64/libevent-2.1.so.6
 #8  0x55812b3ae70b in tor_libevent_run_event_loop (base=, once=) at src/lib/evloop/compat_libevent.c:506
 #9  0x55812b273f03 in run_main_loop_once () at
 src/core/mainloop/mainloop.c:2423
 #10 run_main_loop_until_done () at src/core/mainloop/mainloop.c:2489
 #11 do_main_loop () at src/core/mainloop/mainloop.c:2380
 #12 0x55812b2602ae in run_tor_main_loop () at src/app/main/main.c:1235
 #13 0x55812b2615f5 in tor_run_main (tor_cfg=) at
 src/app/main/main.c:1330
 #14 0x55812b25eabe in tor_main (argc=7, argv=0x7fff7e32f988) at
 src/feature/api/tor_api.c:164
 #15 0x55812b25e64d in main (argc=, argv=) at src/app/main/tor_main.c:32
 }}}

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

Re: [tor-bugs] #30570 [Applications/Tor Browser]: Implement per-site security settings support

[Tor Bug Tracker & Wiki]

#30570: Implement per-site security settings support
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  enhancement  | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, TorBrowserTeam201911,   |  Actual Points:
  tbb-9.5|
Parent ID:  #25658   | Points:  10
 Reviewer:   |Sponsor:
 |  Sponsor9
-+-
Changes (by pospeselr):

 * cc: ma1 (added)


Comment:

 From what I understand having looked a bit into NoScript's source, we
 would need to make some not insignificant changes to how NoScript works
 (both in technical terms and probably from a design/UX perspective as
 well) if we were to build our proposed system on top of NoScript.

 Alternatively, we can integrate these new things into Firefox directly and
 have it enabled/disabled via pref so that users who prefer the power and
 customization of NoScript to use that instead. This avoids the mismatch in
 UX and functionality between our systems and NoScript but obviously more
 work for us in the short-term and the long-term.

 **ma1**: do you have any thoughts on any of this?

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

Re: [tor-bugs] #32644 [Internal Services/Tor Sysadmin Team]: Please double the disk space in colchicifolium.torproject.org

[Tor Bug Tracker & Wiki]

#32644: Please double the disk space in colchicifolium.torproject.org
-+-
 Reporter:  irl  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * Attachment "snap-2019.12.01-15.27.58.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] #32644 [Internal Services/Tor Sysadmin Team]: Please double the disk space in colchicifolium.torproject.org

[Tor Bug Tracker & Wiki]

#32644: Please double the disk space in colchicifolium.torproject.org
-+-
 Reporter:  irl  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 will take a look at this tomorrow afternoon, hopefully. in the meantime
 the disk warning disappeared on the server, but i guess it's just a matter
 of time until it comes back?

 looks like there's a monthly process that cleans up the disk that just
 ran:

 [[Image(snap-2019.12.01-15.27.58.png,700px​)]]

 this is why this is intermittent, but i guess it wouldn't hurt to remove
 that warning in the long term anyways...

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

Re: [tor-bugs] #29360 [Applications/Tor Browser]: Tor-Browser Linux: no audio playback (pulseaudio) on CentOS 6

[Tor Bug Tracker & Wiki]

#29360: Tor-Browser Linux: no audio playback (pulseaudio) on CentOS 6
--+---
 Reporter:  tries |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by strix):

 In Slackware 14.2 stable (which runs pulseaudio 9.0), the default install
 of Tor Browser 9.0.1 (from tor-browser SBo, which uses the pre-built
 package from dist.torproject.org) will crash the pulseaudio user daemon.
 Usually, the user will need to kill the daemon after closing Tor Browser
 so a functioning daemon can be spawned for other applications.

 The fix in Slackware 14.2 is nearly identical to what the submitter of
 this ticket suggested for CentOS 6:
 {{{
 $ cp -pf $HOME/.esd_auth $HOME/.tor-browser/INSTALL/Browser
 $ cp -pfr $HOME/.config/pulse/ $HOME/.tor-browser/INSTALL/Browser
 }}}
 (The cookie file is copied with the pulse directory.)

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

Re: [tor-bugs] #32398 [Core Tor/Stem]: Stem str/bytes confusion on error

[Tor Bug Tracker & Wiki]

#32398: Stem str/bytes confusion on error
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by atagar):

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


Comment:

 Thanks teor! Reproed this by killing the tor process during our integ
 tests. [https://gitweb.torproject.org/stem.git/commit/?id=728b71e 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] #32642 [Core Tor/Nyx]: nyx crashes on startup with `ValueError: Input needs to be a non-negative integer, got '-33538'`

[Tor Bug Tracker & Wiki]

#32642: nyx crashes on startup with `ValueError: Input needs to be a 
non-negative
integer, got '-33538'`
--+
 Reporter:  strugee   |  Owner:  atagar
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by atagar):

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


Comment:

 Thanks strugee, that's certainly a weird one. Unfortunately lacking a
 local repro I'm not quite sure what's up, but
 [https://gitweb.torproject.org/stem.git/commit/?id=160915a pushed a little
 fix] that will ensure nyx's release doesn't crash that way.

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

Re: [tor-bugs] #32325 [Applications/Tor Browser]: Allow Letterboxing opt-in/out

[Tor Bug Tracker & Wiki]

#32325: Allow Letterboxing opt-in/out
-+-
 Reporter:  antonela |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.0-issues, |  Actual Points:
  TorBrowserTeam202001   |
Parent ID:  #32324   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arthuredelstein):

 I don't think Mozilla would necessarily be opposed to having a patch for
 the about:preferences page, assuming the checkbox only appears when
 privacy.resistFingerprinting is enabled.

 On the other hand, perhaps I'm missing some context -- is there a strong
 desire from users to disable letterboxing? It's really quite an important
 part of fingerprinting resistance.

 Also -- the name "letterboxing" is probably not the best. ;)

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

Re: [tor-bugs] #32547 [Applications/Tor Browser]: Set up default bridge at the University of Minnesota

[Tor Bug Tracker & Wiki]

#32547: Set up default bridge at the University of Minnesota
--+--
 Reporter:  phw   |  Owner:  phw
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-bridges   |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--

Comment (by jvsg):

 We keep having problem with firewall every once in a while. Is it fine if
 I change obfs4 port to 22 ? That would not be harmful to the clients in
 any way, right?

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

Re: [tor-bugs] #32634 [Core Tor/Stem]: Stem can't fetch hidden service descriptors with descriptor ID.

[Tor Bug Tracker & Wiki]

#32634: Stem can't fetch hidden service descriptors with descriptor ID.
---+
 Reporter:  moonsikpark|  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Thanks moonsikpark! If **await_result** is provided this looks like it'll
 fail (note the "event.address == address" conditionals below).

 Would you mind describing your use case? I've never run across someone
 that wanted to query HS descriptors via their identifier.

 In checking the spec there's a couple other wrinkles with identifier
 queries...

 * "DescIDs can only be version 2 IDs."

   So despite taking a version prefix this doesn't work at all with v3
 services. This is a bit concerning because v2 will be deprecated at some
 point. Is there a ticket for adding tor support for querying v3 services
 by their descriptor id? If not then it sounds like this capability might
 be going away.

 * "If a DescId is specified, at least one Server MUST also be provided"

   If we do decide to support this within stem we'll need to raise a
 ValueError if we get a descriptor id and a server argument is not
 supplied.

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

Re: [tor-bugs] #32325 [Applications/Tor Browser]: Allow Letterboxing opt-in/out

[Tor Bug Tracker & Wiki]

#32325: Allow Letterboxing opt-in/out
-+-
 Reporter:  antonela |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.0-issues, |  Actual Points:
  TorBrowserTeam202001   |
Parent ID:  #32324   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pospeselr):

 Replying to [comment:11 arthuredelstein]:
 > I don't think Mozilla would necessarily be opposed to having a patch for
 the about:preferences page, assuming the checkbox only appears when
 privacy.resistFingerprinting is enabled.
 >
 > On the other hand, perhaps I'm missing some context -- is there a strong
 desire from users to disable letterboxing? It's really quite an important
 part of fingerprinting resistance.
 >
 > Also -- the name "letterboxing" is probably not the best. ;)

 Yeah there was a fair bit of backlash and bugs filed when the letterboxing
 changes went live in 9.0. Some vocal users really want all of their screen
 real estate, despite how finger-printable it makes them while others think
 the margin is a bug.

 We have ticket #32324 to improve our user-onboarding to better inform
 users about what/why letterboxing is and should be enabled. We also have
 Mozilla 1594455 ( https://bugzilla.mozilla.org/show_bug.cgi?id=1594455 )
 to uplift some of our design changes to make the UX feel a bit more
 polished (a prototype of this is in the latest Tor Browser Alpha if you're
 curious)

 I'm open to alternative less-scary names for letterboxing. :D

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

Re: [tor-bugs] #32629 [Core Tor/Tor]: Re-enable 1 or 2 more macOS jobs in Travis

[Tor Bug Tracker & Wiki]

#32629: Re-enable 1 or 2 more macOS jobs in Travis
-+-
 Reporter:  teor |  Owner:  teor
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  consider-backport-immediately, tor-  |  Actual Points:  0.3
  ci, ipv6, macos, 029-backport, 035-backport,   |
  040-backport, 041-backport, 042-backport   |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 (Some test branches appear to fail in the GitHub list, but that's just due
 to spurious coverage reductions.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32654 [Applications/Tor Launcher]: Torbrowser overides user disabling tor proxy after restart

[Tor Bug Tracker & Wiki]

#32654: Torbrowser overides user disabling tor proxy after restart
--+---
 Reporter:  woyazi|  Owner:  brade
 Type:  defect| Status:  new
 Priority:  Low   |  Component:  Applications/Tor Launcher
  Version:  Tor: unspecified  |   Severity:  Minor
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
 extensions.torlauncher.start_tor false, network.proxy.type 0, and
 network.proxy.socks_remote_dns false allow a user to disable the tor proxy
 and still use the security and privacy benefits of the tor browser.
 However, after restarting the browser, network.proxy.type resets to 1 and
 network.proxy.socks_remote_dns resets to true.

 Tor Browser version: 9.0.1

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

Re: [tor-bugs] #32631 [Core Tor/Chutney]: Chutney Travis: Use the latest dependencies

[Tor Bug Tracker & Wiki]

#32631: Chutney Travis: Use the latest dependencies
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  0.4
Parent ID:| Points:  0.5
 Reviewer:  nickm |Sponsor:
--+--
Changes (by teor):

 * status:  needs_revision => needs_review
 * reviewer:   => nickm
 * actualpoints:  0.3 => 0.4


Comment:

 Here's my PR:
 * master: https://github.com/torproject/chutney/pull/39

 It updates chutney's CI to use:
 * Tor 0.4.2 (and label 0.4.1 as stable)
 * Latest Travis macOS image
 * Latest python versions (including python 2)

 It updates chutney to:
 * Prefer python3 when the user has not set $PYTHON

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

Re: [tor-bugs] #32631 [Core Tor/Chutney]: Chutney Travis: Use the latest dependencies

[Tor Bug Tracker & Wiki]

#32631: Chutney Travis: Use the latest dependencies
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  0.4
Parent ID:| Points:  0.5
 Reviewer:  nickm |Sponsor:
--+--

Comment (by teor):

 (Yes, there are a lot of tor and python versions there, but we only run
 chutney's CI occasionally, and it's fast, because it doesn't compile tor.)

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

Re: [tor-bugs] #32534 [Applications/Tor Browser]: settle on one canonical jtorctl

[Tor Bug Tracker & Wiki]

#32534: settle on one canonical jtorctl
-+-
 Reporter:  eighthave|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, tbb-mobile, jtorctl,|  Actual Points:
  TorBrowserTeam202001   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 Overall looks good. A few clarifications, questions.

  1. From an API perspective, the distinction between rawEventListeners and
 the EventHandlers isn't obvious. Why is one called handler and the other
 is called listener? What is the different? Should we use consistent terms?
  1. Better to use ArrayList.isEmpty rather than ArrayList.size() == 0
 (!TorControlConnection:221)
  1. What is the package name we are going with (net.freehaven? or
 org.torproject?)
  1. We do have clear SignalType enums, Does it make sense to use these for
 type safety?

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

Re: [tor-bugs] #32534 [Applications/Tor Browser]: settle on one canonical jtorctl

[Tor Bug Tracker & Wiki]

#32534: settle on one canonical jtorctl
-+-
 Reporter:  eighthave|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, tbb-mobile, jtorctl,|  Actual Points:
  TorBrowserTeam202001   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 ANTLR would be the standard one for Java.  The performance isn't great for
 a lot of small, high-speed events due to the startup time of the parser
 (this may have improved since I was using it a couple of years ago). So
 that's one area of caution.

 !https://www.antlr.org/

 Replying to [comment:15 eighthave]:


 > For future work: there are tools for generating Java parsers based on
 the ABNF (Augmented Backus-Naur Form) grammar that the control-spec uses.
 Since it seems there are crasher bugs based on parsing events, it seems
 work trying one of these generated parsers using the control-spec.  It
 claims to be RFC2234 ABNF, which might not be the same as the newer
 RFC5234.  Here are two parser generators that I found that would be worth
 trying:
 > * https://github.com/ldthomas/apg-java
 > * http://www.parse2.com/abnf.shtml

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

Re: [tor-bugs] #32634 [Core Tor/Stem]: Stem can't fetch hidden service descriptors with descriptor ID.

[Tor Bug Tracker & Wiki]

#32634: Stem can't fetch hidden service descriptors with descriptor ID.
---+
 Reporter:  moonsikpark|  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by teor):

 Replying to [comment:2 atagar]:
 > Thanks moonsikpark! If **await_result** is provided this looks like
 it'll fail (note the "event.address == address" conditionals below).
 >
 > Would you mind describing your use case? I've never run across someone
 that wanted to query HS descriptors via their identifier.
 >
 > In checking the spec there's a couple other wrinkles with identifier
 queries...
 >
 > * "DescIDs can only be version 2 IDs."
 >
 >   So despite taking a version prefix this doesn't work at all with v3
 services. This is a bit concerning because v2 will be deprecated at some
 point. Is there a ticket for adding tor support for querying v3 services
 by their descriptor id? If not then it sounds like this capability might
 be going away.
 >
 > * "If a DescId is specified, at least one Server MUST also be provided"
 >
 >   If we do decide to support this within stem we'll need to raise a
 ValueError if we get a descriptor id and a server argument is not
 supplied.

 There's no equivalent for the "Descriptor ID" in the v3 onion service
 protocol.

 The onion address can be used to derive a blinded public key for each time
 period:
 https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n655

 The blinded public key works on any HSDir:
 https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n974

 And the blinded public key can be used to find the relevant set of HSDirs:
 https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n781

 For debugging, we might eventually want to query the previous/current/next
 sets of HSDirs, but that's complicated, and not implemented yet:
 https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n885

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

Re: [tor-bugs] #32630 [Core Tor/Tor]: Chutney Travis: Make chutney work on Bionic images (was: Chutney Travis: Make chutney work on Xenial and Bionic images)

[Tor Bug Tracker & Wiki]

#32630: Chutney Travis: Make chutney work on Bionic images
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  chutney-ci|  Actual Points:
Parent ID:  #32240| Points:  0.1
 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] #32476 [Applications/Tor Browser]: Support Launching TorService Using JNI

[Tor Bug Tracker & Wiki]

#32476: Support Launching TorService Using JNI
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, tbb-mobile, |  Actual Points:
  TorBrowserTeam201911   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 I'm not in exact agreement that startup can't be shared without making the
 code unmaintainable (although this has some subjectivity). I'm using a
 base broadcaster, followed by an Android broadcaster that encapsulates the
 logic. The main class is then just invoking the interface implementation.

 https://github.com/sisbell/tor-android-
 
service/blob/master/service/src/main/java/org/torproject/android/service/AndroidEventBroadcaster.java

 
https://github.com/thaliproject/Tor_Onion_Proxy_Library/blob/master/universal/src/main/java/com/msopentech/thali/toronionproxy/BaseEventBroadcaster.java

 This all doesn't have to be decided up-front. It looks good enough for
 now. After getting the Android tor variant integrated into the build
 system, the next step will be to pick this up to include the embedded JNI
 interface and implementation. After that, we can circle back on more
 integration specifics.

 Replying to [comment:7 eighthave]:


 > I agree that having Java support is good, plus I don't think it'll be
 much work.  I've been working on TorService and jtorctl always with
 supporting both Java and Android in mind.  The JNI code should already
 support Java, its just not tested there for a while.
 >
 > The clear border of sharing is
 ''src/feature/api/org_torproject_jni_TorService.c'' instead of
 ''TorService.java''.  The biggest block of logic in ''TorService.java'' is
 the startup procedure, and it seems very unlikely that the startup
 procedure should be shared between Java and Android.  They will have
 similarities, but not close enough that code sharing makes sense.  So if
 that core stuff isn't shared, then separating the Android-specific stuff
 like broadcasts from the Android-specific startup logic would only make
 the code more unreadable and unmaintainable.

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

Re: [tor-bugs] #32501 [Applications/Tor Browser]: Add hasDormantCanceledByStartup to TOPL TorSettings Interface

[Tor Bug Tracker & Wiki]

#32501: Add hasDormantCanceledByStartup to TOPL TorSettings Interface
---+---
 Reporter:  sisbell|  Owner:  tbb-team
 Type:  defect | Status:
   |  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201911R  |  Actual Points:
Parent ID: | Points:  .25
 Reviewer: |Sponsor:
---+---
Changes (by sisbell):

 * keywords:  tbb-mobile, TorBrowserTeam201911 => tbb-mobile,
 TorBrowserTeam201911R
 * status:  needs_revision => needs_review


Comment:

 Fixed space issue

 
https://github.com/sisbell/Tor_Onion_Proxy_Library/commit/e653904bab08a2f942bf8519db6ea5ae18e9887d

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

Re: [tor-bugs] #32522 [Core Tor/Tor]: Create better tooling for canonical tor header includes

[Tor Bug Tracker & Wiki]

#32522: Create better tooling for canonical tor header includes
---+---
 Reporter:  teor   |  Owner:  teor
 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:  5
Parent ID:  #31851 | Points:  1
 Reviewer:  nickm  |Sponsor:  Sponsor31-can
---+---
Changes (by teor):

 * status:  assigned => needs_review
 * reviewer:   => nickm
 * actualpoints:  4 => 5


Comment:

 Here's my draft pull request:
 * https://github.com/torproject/tor/pull/1578

 And here's what the code actually ends up doing:
 * better canonical header paths
 * delete unused PRIVATE, INTERNAL, and EXPOSE defines
 * delete duplicate includes
 * standardise whitespace (conforming to `make check-spaces`, plus extra
 fixes)
 * add command-line arguments to control which files get which fixes

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32655 [Core Tor/Tor]: Try finding unused includes by compiling without each include

[Tor Bug Tracker & Wiki]

#32655: Try finding unused includes by compiling without each include
--+
 Reporter:  teor  |  Owner:  teor
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  teor-backlog
Actual Points:|  Parent ID:  #32522
   Points:  3 |   Reviewer:
  Sponsor:|
--+
 In #32522, we deleted some includes and PRIVATE defines, because they were
 duplicate (or the defines were never actually checked in the headers).

 But we could go further, using this algorithm:
 1. Make sure all the files are sorted
 2. Find all the includes (and maybe PRIVATE defines)
 3. Delete the first include
 4. Try compiling
 5. If the include is required to compile, revert
 6. Try again from step 3, with the next include

 We'd need to skip conditional includes, and check the results in CI before
 merging.

 I'll wait until #32522 is reviewed, and also see if we want this task on
 our 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] #32520 [Applications/Tor Browser]: Output of go project contains nonreproducible datetime values

[Tor Bug Tracker & Wiki]

#32520: Output of go project contains nonreproducible datetime values
---+--
 Reporter:  JeremyRand |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201911  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by JeremyRand):

 Fix at https://notabug.org/JeremyRand/tor-browser-build/src/reproducible-
 go (Git commit hash `0ab49005efd962074e80cafb52fe4dd9cb286229`).  Tested
 to work fine for the linux-x86_64 target (builds without errors and the
 resulting Tor Browser connects to obfs4 without issues).  I can't think of
 any reason it would cause problems for other targets, but haven't tested
 on them yet.  A side benefit is that it decreases the size of the `go`
 project's output by circa 34 MiB.

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

Re: [tor-bugs] #32516 [Applications/Tor Browser]: Make Write Methods Clearer in TorConfigBuilder

[Tor Bug Tracker & Wiki]

#32516: Make Write Methods Clearer in TorConfigBuilder
---+---
 Reporter:  sisbell|  Owner:  tbb-team
 Type:  defect | Status:
   |  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201911R  |  Actual Points:
Parent ID: | Points:  .25
 Reviewer: |Sponsor:
---+---
Changes (by sisbell):

 * keywords:  tbb-mobile, TorBrowserTeam201911 => tbb-mobile,
 TorBrowserTeam201911R
 * status:  needs_revision => needs_review


Comment:

 Changes:

 
https://github.com/sisbell/Tor_Onion_Proxy_Library/commit/75491165af6339f28503eae09b1984632df78b0c

  1. Use writeAddress for orPort. SocksListenAddress doesn't take a port
 (as far as I can tell) so I can't use the writeAddress method for it as
 this would add ':auto' constant to the field.
  1. ClientTransportPlugin loads meek_lite, obf3 and obfs4 on same line.
 The implementation will write out all of the supported bridges from
 settings onto a single line. This assumes that all bridges can be handled
 by one clientTransportPlugin. This is suitable for the Android
 implementation but we should revisit this issue later.
  1. Use varargs for writeLine method so we can add as many values as we
 like
  1. Changed writeTrueProperty and writeFalseProperty to use writeLine
  1. The auto port issue was fixed in previous commit (and is also in this
 commit). Port will be "auto" if null or if port value is less than 0.

 Open Issues:

  1. SocksListenAddress is deprecated. So need to investigate
 removal/migration of the field. This needn't be addressed in this commit.

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

Re: [tor-bugs] #32516 [Applications/Tor Browser]: Make Write Methods Clearer in TorConfigBuilder

[Tor Bug Tracker & Wiki]

#32516: Make Write Methods Clearer in TorConfigBuilder
---+---
 Reporter:  sisbell|  Owner:  tbb-team
 Type:  defect | Status:
   |  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201912R  |  Actual Points:
Parent ID: | Points:  .25
 Reviewer: |Sponsor:
---+---
Changes (by sisbell):

 * keywords:  tbb-mobile, TorBrowserTeam201911R => tbb-mobile,
 TorBrowserTeam201912R


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

Re: [tor-bugs] #32501 [Applications/Tor Browser]: Add hasDormantCanceledByStartup to TOPL TorSettings Interface

[Tor Bug Tracker & Wiki]

#32501: Add hasDormantCanceledByStartup to TOPL TorSettings Interface
---+---
 Reporter:  sisbell|  Owner:  tbb-team
 Type:  defect | Status:
   |  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201912R  |  Actual Points:
Parent ID: | Points:  .25
 Reviewer: |Sponsor:
---+---
Changes (by sisbell):

 * keywords:  tbb-mobile, TorBrowserTeam201911R => tbb-mobile,
 TorBrowserTeam201912R


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

Re: [tor-bugs] #32325 [Applications/Tor Browser]: Allow Letterboxing opt-in/out

[Tor Bug Tracker & Wiki]

#32325: Allow Letterboxing opt-in/out
-+-
 Reporter:  antonela |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.0-issues, |  Actual Points:
  TorBrowserTeam202001   |
Parent ID:  #32324   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by Thorin):

 One other thing to take into consideration here is new window issues. For
 some?/many? users, those using the bookmarks toolbar, even if they stick
 to original new window size (as they are constantly told to for OpSec and
 best practice), they are affected, by only a few pixels - see #27845
 (upstream https://bugzilla.mozilla.org/show_bug.cgi?id=1418537 ) ; in
 other words, they are being penalized almost 100px in margin height by
 doing nothing wrong. Our setup/advise/patches seem hypocritical for lack
 of a better word

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

Re: [tor-bugs] #28863 [Core Tor/Fallback Scripts]: updateFallbackDirs.py thinks it is python 3 compatible but it is not

[Tor Bug Tracker & Wiki]

#28863: updateFallbackDirs.py thinks it is python 3 compatible but it is not
---+--
 Reporter:  starlight  |  Owner:  (none)
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback-ci, 043-must  |  Actual Points:  0.5
Parent ID:  #30971 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by teor):

 * status:  needs_information => needs_review
 * actualpoints:   => 0.5


Comment:

 See my PR:
 * fallback master: https://github.com/torproject/fallback-scripts/pull/9

 I tried to make minimal changes to get the 3 fallback scripts working with
 python 3.6 and later. I also made sure I maintained compatibility with
 python 2. We should see if any of the CI fails, it has a lot more python
 versions.

 We might fix check_existing and OUTPUT_CANDIDATES modes in #31021, but
 they aren't a high priority, because we don't use them very often.

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

Re: [tor-bugs] #32631 [Core Tor/Chutney]: Chutney Travis: Use the latest dependencies

[Tor Bug Tracker & Wiki]

#32631: Chutney Travis: Use the latest dependencies
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  0.4
Parent ID:| Points:  0.5
 Reviewer:|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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #22919, #21952, #26861, #27045, ...

[Tor Bug Tracker & Wiki]

Batch modification to #22919, #21952, #26861, #27045, #27903, #28745, #30237, 
#30334, #30501, #30552, #30558, #31650, #32116, #32531 by gk:


Comment:
We are in December now.

--
Tickets URL: 

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