Re: [tor-bugs] #33416 [Applications/Tor Browser]: Android container creation breaks when building Tor Browser 9.5a6

[Tor Bug Tracker & Wiki]

#33416: Android container creation breaks when building Tor Browser 9.5a6
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam200202  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

 * keywords:  tbb-rbm, TorBrowserTeam202002 => tbb-rbm, TorBrowserTeam200202


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

Re: [tor-bugs] #33416 [Applications/Tor Browser]: Android container creation breaks when building Tor Browser 9.5a6

[Tor Bug Tracker & Wiki]

#33416: Android container creation breaks when building Tor Browser 9.5a6
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam202002  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

 * keywords:   => tbb-rbm, TorBrowserTeam202002


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33416 [Applications/Tor Browser]: Android container creation breaks when building Tor Browser 9.5a6

[Tor Bug Tracker & Wiki]

#33416: Android container creation breaks when building Tor Browser 9.5a6
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 When starting tbb-9.5a6-build1 I get:

 And the log says:
 {{{
 Get:41 http://deb.debian.org/debian buster/main amd64 libxrender1 amd64
 1:0.9.10-1 [33.0 kB]
 Get:42 http://deb.debian.org/debian buster/main amd64 x11-common all
 1:7.7+19 [251 kB]
 Get:43 http://deb.debian.org/debian buster/main amd64 libxtst6 amd64
 2:1.2.3-1 [27.8 kB]
 Err:44 http://deb.debian.org/debian buster/main amd64 openjdk-11-jre-
 headless amd64 11.0.4+11-1~deb10u1
   404  Not Found [IP: 2a04:4e42:14::204 80]
 Get:45 http://deb.debian.org/debian buster/main amd64 default-jre-headless
 amd64 2:1.11-71 [10.9 kB]
 Get:46 http://deb.debian.org/debian buster/main amd64 ca-certificates-java
 all 20190405 [15.7 kB]
 Get:47 http://deb.debian.org/debian buster/main amd64 publicsuffix all
 20190415.1030-1 [116 kB]
 Fetched 9894 kB in 0s (21.1 MB/s)
 E: Failed to fetch
 http://deb.debian.org/debian/pool/main/n/nss/libnss3_3.42.1-1+deb10u1_amd64.deb
 404  Not Found [IP: 2a04:4e42:14::204 80]
 E: Failed to fetch
 http://deb.debian.org/debian/pool/main/o/openjdk-11/openjdk-11-jre-
 headless_11.0.4+11-1~deb10u1_amd64.deb  404  Not Found [IP:
 2a04:4e42:14::204 80]
 E: Unable to fetch some archives, maybe run apt-get update or try with
 --fix-missing?
 }}}
 And, indeed,
 http://deb.debian.org/debian/pool/main/n/nss/libnss3_3.42.1-1+deb10u1_amd64.deb
 is not available anymore. Just a deb10u2.

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

Re: [tor-bugs] #33401 [Circumvention/Snowflake]: turbotunnel-quic snowflake-client occasionally uses lots of CPU

[Tor Bug Tracker & Wiki]

#33401: turbotunnel-quic snowflake-client occasionally uses lots of CPU
-+
 Reporter:  dcf  |  Owner:  dcf
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  turbotunnel  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by dcf):

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


Comment:

 Calling this closed with the quic-go upgrade from comment:15:ticket:6.
 https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h
 =turbotunnel-quic=42c07f2c140e4c6f1f752329a67fdf15cd6bd8c5

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

Re: [tor-bugs] #33336 [Circumvention/Snowflake]: Trial deployment of Snowflake with Turbo Tunnel

[Tor Bug Tracker & Wiki]

#6: Trial deployment of Snowflake with Turbo Tunnel
-+--
 Reporter:  dcf  |  Owner:  dcf
 Type:  task | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  turbotunnel  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dcf):

 Replying to [comment:12 dcf]:
 > I can try doing another Tor Browser build with a more recent version of
 quic-go, assuming I can find a new enough version of quic-go that is also
 compatible with pion-quic (which
 [https://github.com/pion/quic/blob/v0.1.1/go.mod#L4 currently specifies]
 the old version from 2019-04-01).

 I have a couple of updated branches and I'm starting on Tor Browser builds
 with them. They make the kcp idle timeout fix from comment:14 and update
 to a newer quic-go as mentioned in comment:12.

  * [https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h
 =turbotunnel-kcp=90746c1c3fce5db371038b092c32abb548504d9d turbotunnel-
 kcp]
  * [https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h
 =turbotunnel-quic=42c07f2c140e4c6f1f752329a67fdf15cd6bd8c5 turbotunnel-
 quic]

 The upgrade of quic-go was a bit of a gross process. The
 [https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h
 =turbotunnel-quic=42c07f2c140e4c6f1f752329a67fdf15cd6bd8c5 API changes]
 are mild. pion-quic is unfortunately incompatible with the newer version;
 but I worked around that with a patch in the tor-browser-build project. I
 selected a very specific commit of quic-go to upgrade to: we need at least
 [https://github.com/lucas-clemente/quic-
 go/commit/6407f5bf680283bf7e3755976306767da2c55e66 6407f5bf] because it
 has the keepalive fix for comment:12 and those in #33401. But I didn't
 want to use [https://github.com/lucas-clemente/quic-
 go/commit/572ef44cf2d1197428f493e90cdfdd161e584f2c 572ef44c] or later,
 because it adds a huge number of new transitive dependencies that I didn't
 have the ambition to start packaging for tor-browser-build. (It's a
 ''lot'' of dependencies—`go mod graph` goes from 59 lines to 283 lines.
 And one of the dependencies—google.golang.org/api—is over 550 MB!)
 Upgrading quic-go also requires upgrading go itself to 1.13, because the
 qtls library is coupled to crypto/tls in the standard library. The
 upgraded client was not compatible with the server I deployed in
 comment:8, so I rebuilt the server at commit
 
[https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=turbotunnel=42c07f2c140e4c6f1f752329a67fdf15cd6bd8c5
 42c07f2c] and deployed it at 2020-02-22T04:13:
 {{{
 lrwxrwxrwx 1 root root   37 Feb 22 04:12 snowflake-server ->
 snowflake-server.turbotunnel.42c07f2c
 -rwxr-xr-x 1 root root  9067083 Feb 18 23:18 snowflake-server.normal
 -rwxr-xr-x 1 root root 15648527 Feb 22 04:11 snowflake-
 server.turbotunnel.42c07f2c
 -rwxr-xr-x 1 root root 12459290 Feb 19 18:01 snowflake-
 server.turbotunnel.da37211c
 }}}
 Overall, it's making me feel more and more meh about deploying quic-go; it
 and QUIC are still changing fast and I foresee maintenance and
 compatibility difficulties.

 In the new Tor Browser builds I'm going to enable snowflake-client logging
 by default and enable some torrc options to try and make tor more
 reluctant to give up on its circuits. The latter idea I got from the
 [http://meetbot.debian.net/tor-meeting/2020/tor-
 meeting.2020-02-20-18.00.log.html#l-32 2020-02-20 anti-censorship meeting]
 (staring at about 18:10:00).
 {{{
 LearnCircuitBuildTimeout 0
 CircuitBuildTimeout 300
 CircuitStreamTimeout 300
 }}}

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

Re: [tor-bugs] #33189 [Internal Services/Tor Sysadmin Team]: Plan for increase in CiviCRM email send rate

[Tor Bug Tracker & Wiki]

#33189: Plan for increase in CiviCRM email send rate
-+-
 Reporter:  richarde |  Owner:  tpa
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by richarde):

 After consulting with the comms team, GR is on track to pilot this about a
 week from today, Friday, Feb 28. Any red flags or further
 planning/monitoring from TPA folks?

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

Re: [tor-bugs] #33336 [Circumvention/Snowflake]: Trial deployment of Snowflake with Turbo Tunnel

[Tor Bug Tracker & Wiki]

#6: Trial deployment of Snowflake with Turbo Tunnel
-+--
 Reporter:  dcf  |  Owner:  dcf
 Type:  task | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  turbotunnel  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dcf):

 Replying to [comment:12 dcf]:
 > Replying to [comment:11 dcf]:
 > >  * It may be my imagination, but I get the impression that everything
 works better while the connection is being used. Initially my impression
 was positive as I was trying to stress the system by having videos playing
 in the background. Then the experience became more frustrating as I tried
 normal text browsing and I encountered the occasional delays mentioned
 above. It made me think that perhaps there is something in the proxy that
 drops idle connections, but I didn't find anything like that. It's
 possible that this is my imagination and that my initial impression was
 just getting good luck with proxies.
 >
 > I think I know why idle browsing seemed to disconnect more, at least in
 the quic case.

 And I think I see what was going wrong with kcp as well. The keepalive
 interval was fine, but the idle timeout was too low (30 s). Because it
 takes over 30 s to realize that you have a bad proxy, the first bad proxy
 would kill your connection. The effect was magnified because the
 
[https://gitweb.torproject.org/user/dcf/snowflake.git/tree/client/lib/snowflake.go?h
 =turbotunnel-kcp=874a11f6779429246263522fc751f1cc0d9c3af0#n91 copyLoop]
 function, when the session timed out due to idleness, would only exit the
 socks←webRTC loop, but would keep running the webRTC←socks loop for about
 another 2 minutes (might be tor SocksTimeout, not sure). So one bad proxy
 would knock you out for at least 2.5 minutes, as well as killing all your
 existing circuits.

 I made these commits:
  * [https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h
 =turbotunnel-kcp=5973a6940147f6e69fe9d74ebc4a912c89a59fd0 5973a694] Set
 the smux KeepAliveTimeout (idle timeout) to 10 minutes.
  * [https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h
 =turbotunnel-kcp=ec1468f841b7e40d7351e1426d4947ec2d3bead5 ec1468f8] Let
 copyLoop exit when either direction finishes.

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

Re: [tor-bugs] #33316 [Core Tor/Tor]: Re-order early subsystem init order to match dependency order

[Tor Bug Tracker & Wiki]

#33316: Re-order early subsystem init order to match dependency order
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  diagnostics, practracker  |  Actual Points:  .3
Parent ID:  #31634| Points:
 Reviewer:  catalyst  |Sponsor:
--+
Changes (by nickm):

 * status:  needs_revision => merge_ready


Comment:

 Thanks for the review!  I've made the suggested changes and pushed to
 github again. CI is passing, so I'll mark it merge_ready, but I'll not
 merge it till I'm back at work on Monday.

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

Re: [tor-bugs] #33415 [Core Tor/Tor]: Adjust clang-format name in script to be parameterized

[Tor Bug Tracker & Wiki]

#33415: Adjust clang-format name in script to be parameterized
---+
 Reporter:  nickm  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  c-format clang-format  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

 * 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] #32921 [Core Tor/Tor]: Code and script changes to run clang-format without breaking checkSpaces or coccinelle

[Tor Bug Tracker & Wiki]

#32921: Code and script changes to run clang-format without breaking 
checkSpaces or
coccinelle
+
 Reporter:  nickm   |  Owner:  nickm
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  style, 043-can  |  Actual Points:  1.5
Parent ID:  #29226  | Points:
 Reviewer:  catalyst|Sponsor:
+
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 Oops! I forgot to push my commit from last week that added the warnings
 about not running the scripts on master yet.  I've added it to the branch,
 along with a note about what we know so far about required versions.

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

Re: [tor-bugs] #19757 [Applications/Tor Browser]: Make a menu to add onion and auth-cookie to TB

[Tor Bug Tracker & Wiki]

#19757: Make a menu to add onion and auth-cookie to TB
-+-
 Reporter:  mrphs|  Owner:  brade
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ux-team, tbb-usability, tor-hs,  |  Actual Points:  7.5
  TorBrowserTeam202002R, tbb-9.5a6   |
Parent ID:  #3   | Points:  8
 Reviewer:  pospeselr, acat, sysrqb, emmapeel|Sponsor:
 |  Sponsor27-must
-+-
Changes (by sysrqb):

 * keywords:  ux-team, tbb-usability, tor-hs, TorBrowserTeam202002R => ux-
 team, tbb-usability, tor-hs, TorBrowserTeam202002R, tbb-9.5a6


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

Re: [tor-bugs] #32921 [Core Tor/Tor]: Code and script changes to run clang-format without breaking checkSpaces or coccinelle

[Tor Bug Tracker & Wiki]

#32921: Code and script changes to run clang-format without breaking 
checkSpaces or
coccinelle
+
 Reporter:  nickm   |  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:  style, 043-can  |  Actual Points:  1.5
Parent ID:  #29226  | Points:
 Reviewer:  catalyst|Sponsor:
+

Comment (by nickm):

 I've opened #33415 for the parameterization 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

[tor-bugs] #33415 [Core Tor/Tor]: Adjust clang-format name in script to be parameterized

[Tor Bug Tracker & Wiki]

#33415: Adjust clang-format name in script to be parameterized
--+---
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  c-format clang-format
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 After merging #32921, we'll need to adjust our code reformatting script so
 that it can handle the case where clang-format >= 6.0 is not named "clang-
 format", but instead something else.

 I'd lean towards an environment variable, something like
 `TOR_CLANG_FORMAT`, but I don't feel too strongly and I'm open to other
 ideas too.

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

Re: [tor-bugs] #19757 [Applications/Tor Browser]: Make a menu to add onion and auth-cookie to TB

[Tor Bug Tracker & Wiki]

#19757: Make a menu to add onion and auth-cookie to TB
-+-
 Reporter:  mrphs|  Owner:  brade
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ux-team, tbb-usability, tor-hs,  |  Actual Points:  7.5
  TorBrowserTeam202002R  |
Parent ID:  #3   | Points:  8
 Reviewer:  pospeselr, acat, sysrqb, emmapeel|Sponsor:
 |  Sponsor27-must
-+-
Changes (by sysrqb):

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


Comment:

 Replying to [comment:45 sysrqb]:
 > Emma, we're proposing adding the following new strings.
 Emma said these look okay. We'll see how well they work after we have
 localizations. We won't have any in this update, but we should have some
 for the next update.

 Thanks everyone!

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

Re: [tor-bugs] #19757 [Applications/Tor Browser]: Make a menu to add onion and auth-cookie to TB

[Tor Bug Tracker & Wiki]

#19757: Make a menu to add onion and auth-cookie to TB
-+-
 Reporter:  mrphs|  Owner:  brade
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-usability, tor-hs,  |  Actual Points:  7.5
  TorBrowserTeam202002R  |
Parent ID:  #3   | Points:  8
 Reviewer:  pospeselr, acat, sysrqb, emmapeel|Sponsor:
 |  Sponsor27-must
-+-

Comment (by sysrqb):

 Replying to [comment:38 mcs]:
 > Here are the new patches (all are on `bug19757-02` branches within
 brade's various repos):
 >
 > Torbutton strings:
 >
 
https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug19757-02=fddbe371f2eb43d7d6007561db38d1ad8a6ff8e4
 >
 > Torbutton control port module enhancements:
 >
 
https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug19757-02=dc1871601fad289645696bb8138e8b14c46dd60a
 >

 These are merged with commit `078ae18e5f1cbf888e7c86c8aecaa383a727bf0d` on
 master.

 > Tor Launcher string:
 > https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug19757-02=f53497c7255b040b6c97738c3c64e98b69cc96e4
 >
 > Tor Launcher enhancement to create an onion-auth directory for storage
 of the keys:
 > https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug19757-02=6ceda2e5565702f13933b83653c1951789fc0252

 These are merged with commit `bb1bff811c12fd8638ebede1514be512a9a4fbd7`.

 Replying to [comment:40 mcs]:
 >
 > We only revised the browser patch; the new one is here:
 > https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug19757-03=2d0f4658894642a4bf92e3117ef8c36e5528b7e7

 cherry-picked as commit `aed69dc95387429e18b18ad578fb78d4a83d91f2` on
 `tor-browser-68.5.0esr-9.5-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] #33211 [Circumvention/Snowflake]: proxy-go sometimes gets into a 100+% CPU state

[Tor Bug Tracker & Wiki]

#33211: proxy-go sometimes gets into a 100+% CPU state
-+--
 Reporter:  dcf  |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by cohosh):

 * owner:  (none) => cohosh
 * status:  needs_information => assigned


Comment:

 I filed these two tickets:
 - https://github.com/pion/webrtc/issues/1043
 - https://github.com/pion/dtls/issues/199

 I'm going to work on a patch for the second one 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] #33211 [Circumvention/Snowflake]: proxy-go sometimes gets into a 100+% CPU state

[Tor Bug Tracker & Wiki]

#33211: proxy-go sometimes gets into a 100+% CPU state
-+---
 Reporter:  dcf  |  Owner:  (none)
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by cohosh):

 Looks like there's no way to set the DTLS ciphersuites from the API. I've
 attached a patch I used on pion/webrtc to set the ciphersuite to just
 `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`.

 The result was a huge improvement in performance. The CPU profile output
 is now:

 {{{
 (pprof) top --cum
 Showing nodes accounting for 1.94s, 27.09% of 7.16s total
 Dropped 182 nodes (cum <= 0.04s)
 Showing top 10 nodes out of 231
   flat  flat%   sum%cum   cum%
  0 0% 0%  2.12s 29.61%  runtime.systemstack
  1.74s 24.30% 24.30%  1.74s 24.30%  runtime.futex
  0 0% 24.30%  1.29s 18.02%  runtime.mcall
  0.04s  0.56% 24.86%  1.23s 17.18%  runtime.schedule
  0 0% 24.86%  1.15s 16.06%  runtime.park_m
  0.02s  0.28% 25.14%  1.01s 14.11%  runtime.futexsleep
  0.05s   0.7% 25.84%  0.98s 13.69%  runtime.findrunnable
  0 0% 25.84%  0.93s 12.99%
 github.com/pion/sctp.(*Association).writeLoop
  0.09s  1.26% 27.09%  0.93s 12.99%  runtime.sysmon
  0 0% 27.09%  0.91s 12.71%  runtime.mstart
 }}}

 One client downloading a large file now takes 10-20% CPU as opposed to the
 ~50% before.

 It would be best for us to be able to set the ciphersuites in the API, so
 I'll file an issue with pion for that. I'll also file an issue to take a
 look at the performance of CCM and suggest using a more popular
 ciphersuite as the default.

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

Re: [tor-bugs] #33211 [Circumvention/Snowflake]: proxy-go sometimes gets into a 100+% CPU state

[Tor Bug Tracker & Wiki]

#33211: proxy-go sometimes gets into a 100+% CPU state
-+---
 Reporter:  dcf  |  Owner:  (none)
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by cohosh):

 * Attachment "0001-Change-list-of-dtls-ciphersuites.2.patch" added.


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

Re: [tor-bugs] #33211 [Circumvention/Snowflake]: proxy-go sometimes gets into a 100+% CPU state

[Tor Bug Tracker & Wiki]

#33211: proxy-go sometimes gets into a 100+% CPU state
-+---
 Reporter:  dcf  |  Owner:  (none)
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by cohosh):

 * Attachment "0001-Change-list-of-dtls-ciphersuites.patch" added.


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

Re: [tor-bugs] #33211 [Circumvention/Snowflake]: proxy-go sometimes gets into a 100+% CPU state

[Tor Bug Tracker & Wiki]

#33211: proxy-go sometimes gets into a 100+% CPU state
-+---
 Reporter:  dcf  |  Owner:  (none)
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by cohosh):

 * Attachment "0001-Change-list-of-dtls-ciphersuites.patch" added.


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

Re: [tor-bugs] #33414 [Core Tor/Tor]: Split router.c, and disable it (mostly) when building without relay support.

[Tor Bug Tracker & Wiki]

#33414: Split router.c, and disable it (mostly) when building without relay
support.
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-design, network-team-roadmap-|  Actual Points:  0.5
  2020Q1, 043-deferred   |
Parent ID:  #31851   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 CI has passed; I've added a changes file and am putting this in
 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] #32921 [Core Tor/Tor]: Code and script changes to run clang-format without breaking checkSpaces or coccinelle

[Tor Bug Tracker & Wiki]

#32921: Code and script changes to run clang-format without breaking 
checkSpaces or
coccinelle
+
 Reporter:  nickm   |  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:  style, 043-can  |  Actual Points:  1.5
Parent ID:  #29226  | Points:
 Reviewer:  catalyst|Sponsor:
+
Changes (by catalyst):

 * status:  needs_review => needs_revision


Comment:

 Following up from last week's C style meeting: I think this is almost
 ready, given what we agreed on as the scope of this ticket.

 There should be disclaimers in the .clang-format and the script about how
 the style isn't official yet, and that people shouldn't commit or merge
 the results yet.  Maybe also a comment about the minimum required clang-
 format version, which I think is 6.0 but might be earlier?

 We should open a separate ticket to parameterize the clang-format
 executable name to make it easier for developers to run the minimum
 required clang-format version even when it's not called clang-format
 (e.g., clang-format-6.0 on Xenial).  nickm, would you like to do that?  I
 can also open it if you like.

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

Re: [tor-bugs] #33413 [Internal Services/Tor Sysadmin Team]: ida.org can't mail torproject.org ("Connection reset by peer")

[Tor Bug Tracker & Wiki]

#33413: ida.org can't mail torproject.org ("Connection reset by peer")
-+-
 Reporter:  arma |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 >RC4-SHA

 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] #33316 [Core Tor/Tor]: Re-order early subsystem init order to match dependency order

[Tor Bug Tracker & Wiki]

#33316: Re-order early subsystem init order to match dependency order
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  diagnostics, practracker  |  Actual Points:  .3
Parent ID:  #31634| Points:
 Reviewer:  catalyst  |Sponsor:
--+
Changes (by catalyst):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:3 nickm]:
 > Based on work on #31634 (parent), I've had to make a couple more changes
 here.
 Thanks! Mostly looks good.

 I made a comment on the pull request about a missing newline.  Nit: The
 changes file could maybe be amended to reflect the last few commits that
 were made after its creation.

 Please feel free to merge once those are 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] #33405 [Circumvention/Snowflake]: Bug in interaction between uMatrix and Snowflake (snowflake-webextension)

[Tor Bug Tracker & Wiki]

#33405: Bug in interaction between uMatrix and Snowflake 
(snowflake-webextension)
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by cohosh):

 * cc: cohosh, dcf, phw, arlolra (added)


Comment:

 Weird that we didn't get automatically cc'd on this. I guess when you set
 the component later it doesn't happen.

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

Re: [tor-bugs] #33211 [Circumvention/Snowflake]: proxy-go sometimes gets into a 100+% CPU state

[Tor Bug Tracker & Wiki]

#33211: proxy-go sometimes gets into a 100+% CPU state
-+---
 Reporter:  dcf  |  Owner:  (none)
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by cohosh):

 I did some investigating and looks like pion is using DTLS with the
 ciphersuite `TLS_ECDHE_ECDSA_WITH_AES_128_CCM`. I'm almost certain this is
 not a common ciphersuite to use and that we'll be changing this later
 anyway once we have a better idea of the difference between snowflake
 WebRTC fingerprints and other common WebRTC tools. In fact, looking at a
 previous analysis of Snowflake that used the popular Chrome WebRTC
 library, CCM is never listed in the ClientHello as a possible ciphersuite:
 https://trac.torproject.org/projects/tor/wiki/doc/Snowflake/Fingerprinting

 What's relevant to this discussion is that a large amount of the CPU time
 is spent on the CCM encryption operation and I noticed that while
 pion/dtls uses the builtin golang crypto implementations for the other
 ciphersuites it supports, they
 [https://github.com/pion/dtls/tree/master/pkg/crypto/ccm roll their own
 CCM implementation]. My current plan is to remove CCM from the list of
 accepted ciphersuites and see what impact this has on the performance
 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] #33191 [Applications/GetTor]: Write database tests for twisted adbapi for GetTor

[Tor Bug Tracker & Wiki]

#33191: Write database tests for twisted adbapi for GetTor
-+
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:  .5
 Reviewer:  hiro |Sponsor:
-+
Changes (by cohosh):

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


Comment:

 Merged at
 
[https://gitweb.torproject.org/gettor.git/commit/?id=64df8b27b36bca24f7612b83697e52becbe3dc32
 3dc32] and deployed as of `2020-02-21T18:39:13`.

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

Re: [tor-bugs] #33085 [Internal Services/Tor Sysadmin Team]: decomission unifolium/kvm2, 6 VMs to migrate

[Tor Bug Tracker & Wiki]

#33085: decomission unifolium/kvm2, 6 VMs to migrate
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tpa-roadmap-february |  Actual Points:
Parent ID:   | Points:  5
 Reviewer:   |Sponsor:
-+-
Description changed by anarcat:

Old description:

> * [ ] cupani.torproject.org (git-rw)
>  * [ ] polyanthum.torproject.org (bridges)
>  * [ ] omeiense.torproject.org (onionoo.torproject.org)
>  * [ ] savii.torproject.org (static content backend)
>  * [ ] build-x86-07.torproject.org (buildbox)
>  * [x] ~~bracteata.torproject.org (sandstorm)~~ decom'd in #32390
>
> Requires a new gnt node (#33081).

New description:

 * [ ] cupani.torproject.org (git-rw)
  * [ ] polyanthum.torproject.org (bridges)
  * [ ] omeiense.torproject.org (onionoo.torproject.org) (possibly to
 decom? see #32268)
  * [ ] savii.torproject.org (static content backend) (TO DECOMISSION,
 check fastly firt)
  * [ ] build-x86-07.torproject.org (buildbox) (TO DECOMISSION, maybe
 create a new node in gnt-fsn later?)
  * [x] ~~bracteata.torproject.org (sandstorm)~~ decom'd in #32390

 Requires a new gnt node (#33081).

--

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

Re: [tor-bugs] #32268 [Internal Services/Tor Sysadmin Team]: second new onionoo backend

[Tor Bug Tracker & Wiki]

#32268: second new onionoo backend
-+-
 Reporter:  weasel   |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #31659   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 can this be setup soon? i'm hoping to decomission unifolium next week and
 omeiense is one of the boxes to migrate. from what i understand, it's to
 be replaced by this setup.

 it would be great if I could just decomission omeiense instead, as it
 would save me a ton of work..

 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] #33085 [Internal Services/Tor Sysadmin Team]: decomission unifolium/kvm2, 6 VMs to migrate

[Tor Bug Tracker & Wiki]

#33085: decomission unifolium/kvm2, 6 VMs to migrate
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tpa-roadmap-february |  Actual Points:
Parent ID:   | Points:  5
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * status:  new => assigned


Old description:

> * [ ] cupani.torproject.org (git-rw)
>  * [ ] polyanthum.torproject.org (bridges)
>  * [ ] omeiense.torproject.org (onionoo.torproject.org)
>  * [ ] savii.torproject.org (static content backend)
>  * [ ] build-x86-07.torproject.org (buildbox)
>  * [ ] bracteata.torproject.org (sandstorm) #32390
>
> Requires a new gnt node (#33081).

New description:

 * [ ] cupani.torproject.org (git-rw)
  * [ ] polyanthum.torproject.org (bridges)
  * [ ] omeiense.torproject.org (onionoo.torproject.org)
  * [ ] savii.torproject.org (static content backend)
  * [ ] build-x86-07.torproject.org (buildbox)
  * [x] ~~bracteata.torproject.org (sandstorm)~~ decom'd in #32390

 Requires a new gnt node (#33081).

--

Comment:

 new node (fsn-node-04) online, ready to start migration. also, bracteata
 not required because migrated already.

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

Re: [tor-bugs] #33362 [Internal Services/Tor Sysadmin Team]: Please provision a VM for the new exit scanner

[Tor Bug Tracker & Wiki]

#33362: Please provision a VM for the new exit scanner
-+-
 Reporter:  irl  |  Owner:  anarcat
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 i hope to be able to set you up with this machine early next week, sorry
 for the delays.

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

Re: [tor-bugs] #33369 [Core Tor]: Tor Manual:Add TOC and Cross-Reference links

[Tor Bug Tracker & Wiki]

#33369: Tor Manual:Add TOC and Cross-Reference links
+--
 Reporter:  swati   |  Owner:  (none)
 Type:  task| Status:
|  merge_ready
 Priority:  Medium  |  Milestone:
Component:  Core Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  documentation, tor-client, manpage  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  catalyst, nickm |Sponsor:
+--
Changes (by catalyst):

 * status:  needs_review => merge_ready


Comment:

 Updated pull request at https://github.com/torproject/tor/pull/1761

 Please merge that one.

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

Re: [tor-bugs] #33406 [Internal Services/Tor Sysadmin Team]: automate reboots

[Tor Bug Tracker & Wiki]

#33406: automate reboots
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  project  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major| Resolution:
 Keywords:  tpa-roadmap-march|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 i wrote a simple reboot prototype that does just that, but can also be
 used as a `reboot-guest` replacement:

 https://gitweb.torproject.org/admin/tsa-misc.git/tree/ganeti-reboot-
 cluster-fabric-prototype

 it's mostly a test to see how Fabric works and is not intended to be a
 replacement for all tools just yet.

 but i find the results promising: it's much nicer to work in python with
 that stuff: errors are (mostly) well defined and it's easy to modularize
 things. for example, i originally wrote the thing to migrate fsn-node-01
 (and that worked) but then i could extend it to also reboot arbitrary node
 (and i rebooted gayi).

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

Re: [tor-bugs] #24532 [Metrics/Statistics]: Make metrics-web runs independent of server locale

[Tor Bug Tracker & Wiki]

#24532: Make metrics-web runs independent of server locale
+--
 Reporter:  iwakeh  |  Owner:  metrics-team
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  irl |Sponsor:
+--
Changes (by karsten):

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


Comment:

 Thanks for looking. Merged and pushed to master. Closing.

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

Re: [tor-bugs] #33414 [Core Tor/Tor]: Split router.c, and disable it (mostly) when building without relay support.

[Tor Bug Tracker & Wiki]

#33414: Split router.c, and disable it (mostly) when building without relay
support.
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-design, network-team-roadmap-|  Actual Points:  0.5
  2020Q1, 043-deferred   |
Parent ID:  #31851   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 I have a branch called `extract_router` with a PR at
 https://github.com/torproject/tor/pull/1762`.

 There are a few notes here:
   * The branch starts out by splitting the descriptor-generation code into
 its own file.
   * There is some code (currently in clientkey.[ch]) that I was not able
 to extract, since it is used when running as a client.  I believe this
 code to be useless for clients, and I'll open another ticket to look at
 removing it or making it relay only.  But that refactoring seems
 orthogonal to this one.
   * I've tried using some helper macros to generate the stubs in router.h.
 If we like those, we could extract them and use them to generate stubs in
 other files.

 I'm traveling today, so I won't be able to check whether or not CI has
 passed.  I'll put this into needs_review if it does.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33414 [Core Tor/Tor]: Split router.c, and disable it (mostly) when building without relay support.

[Tor Bug Tracker & Wiki]

#33414: Split router.c, and disable it (mostly) when building without relay
support.
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.4.4.x-final
Component:  Core |Version:
  Tor/Tor|   Keywords:  tor-design, network-team-roadmap-
 Severity:  Normal   |  2020Q1, 043-deferred
Actual Points:  0.5  |  Parent ID:  #31851
   Points:  0.5  |   Reviewer:
  Sponsor:   |
-+-
 The last ''big'' piece of code in feature/relay that we want to turn off
 when --disable-module-relay is set is `router.c`.

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

Re: [tor-bugs] #32460 [Webpages/Website]: download page has confusing flow, especially with donate banner

[Tor Bug Tracker & Wiki]

#32460: download page has confusing flow, especially with donate banner
--+-
 Reporter:  arma  |  Owner:  hiro
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by antonela):

 Replying to [comment:17 mcs]:
 > Replying to [comment:16 antonela]:
 > > We deployed a new iteration of the download page
 > >
 > > https://www.torproject.org/download/
 > > ...
 >
 > Nice! One possible issue: the top banner is displayed on the download
 page if I switch to a different language (e.g., from en to es) before I go
 to the download page. Is this a bug?
 >

 It is a bug. Thanks!

 > It would also be good to make the language switcher control available on
 the download page somehow (enhancement request).

 Right.

 Filed https://dip.torproject.org/torproject/web/tpo/issues/59 for both.

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

Re: [tor-bugs] #32460 [Webpages/Website]: download page has confusing flow, especially with donate banner

[Tor Bug Tracker & Wiki]

#32460: download page has confusing flow, especially with donate banner
--+-
 Reporter:  arma  |  Owner:  hiro
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by mcs):

 Replying to [comment:16 antonela]:
 > We deployed a new iteration of the download page
 >
 > https://www.torproject.org/download/
 > ...

 Nice! One possible issue: the top banner is displayed on the download page
 if I switch to a different language (e.g., es) before I go to the download
 page. Is this a bug?

 It would also be good to make the language switcher control available on
 the download page somehow (enhancement request).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33413 [Internal Services/Tor Sysadmin Team]: ida.org can't mail torproject.org ("Connection reset by peer")

[Tor Bug Tracker & Wiki]

#33413: ida.org can't mail torproject.org ("Connection reset by peer")
-+-
 Reporter:  arma |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 A person at ida.org is trying to mail my torproject.org address, and the
 mail never arrives. I see these lines in our torproject.org mailserver
 (timestamps are in UTC):
 {{{
 Feb 21 10:58:30 eugeni/eugeni postfix/smtpd[17909]: connect from
 mail5.ida.org[129.246.225.242]
 Feb 21 10:58:32 eugeni/eugeni postfix/smtpd[17909]: SSL_accept error from
 mail5.ida.org[129.246.225.242]: Connection reset by peer
 Feb 21 10:58:32 eugeni/eugeni postfix/smtpd[17909]: lost connection after
 STARTTLS from mail5.ida.org[129.246.225.242]
 Feb 21 10:58:32 eugeni/eugeni postfix/smtpd[17909]: disconnect from
 mail5.ida.org[129.246.225.242] ehlo=1 starttls=0/1 commands=1/2
 }}}
 i.e. it is trying to connect to us, and then it's hanging up.

 The issue repeats, e.g. mail5.ida.org comes back and tries again 60
 minutes later, and the same "Connection reset by peer" issue stops it then
 too.

 For comparison, mail from ida.org directly to moria.csail.mit.edu (e.g. my
 @freehaven.net address) does work (times in EST):
 {{{
 Feb 21 06:32:49 moria postfix/smtpd[64015]: connect from
 mail4.ida.org[129.246.225.241]
 Feb 21 06:32:49 moria postfix/smtpd[64015]: setting up TLS connection from
 mail4.ida.org[129.246.225.241]
 Feb 21 06:32:50 moria postfix/smtpd[64015]: Anonymous TLS connection
 established from mail4.ida.org[129.246.225.241]: TLSv1.2 with cipher
 RC4-SHA (112/128 bits)
 Feb 21 06:32:50 moria postgrey[2193]: action=pass, reason=triplet found,
 client_name=mail4.ida.org, client_address=129.246.225.241,
 sender=x...@ida.org, recipient=a...@freehaven.net
 Feb 21 06:32:50 moria postfix/smtpd[64015]: 48FD91E03BE:
 client=mail4.ida.org[129.246.225.241]
 Feb 21 06:32:50 moria postfix/cleanup[64106]: 48FD91E03BE: message-
 id=<8o7jf1knqetkgvld41v8dken.1582284768...@emailplus.mobileiron.com>
 Feb 21 06:32:50 moria postfix/qmgr[2303]: 48FD91E03BE: from=,
 size=6337, nrcpt=1 (queue active)
 Feb 21 06:32:51 moria postfix/local[64128]: 718821E030F:
 to=, relay=local, delay=2.5, delays=0.19/0/0/2.3,
 dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail)
 Feb 21 06:32:51 moria postfix/qmgr[2303]: 718821E030F: removed
 }}}
 (moria's log mentions mail4, not mail5, but eugeni is seeing failures from
 both mail4 and mail5.)

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

Re: [tor-bugs] #33406 [Internal Services/Tor Sysadmin Team]: automate reboots

[Tor Bug Tracker & Wiki]

#33406: automate reboots
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  project  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major| Resolution:
 Keywords:  tpa-roadmap-march|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 just for future reference, ganeti-reboot-cluster, as we have in our puppet
 repo, doesn't work in our cluster, because it relies on assumptions
 specific to the DSA clusters (namely that the last node is an empty
 spare). so it fails with:

 {{{
 fsn-node-03.torproject.org not empty.
 }}}

 apparently, the latest version of the script might fix that with the
 `crossmigratemany` function:

 https://salsa.debian.org/dsa-team/mirror/dsa-
 puppet/raw/master/modules/ganeti2/files/ganeti-reboot-cluster

 for now, i'll just do the reboot by hand.

 in theory, rebooting a ganeti node is to:

  1. migrate all the primaries off of the node: `ssh $master gnt-migrate
 $node`
  2. if it's a master, promote another master: `ssh $notmaster gnt-cluster
 master-failover` (optional, only if we can't afford having the master down
 during the reboot)
  3. reboot the node `ssh $node reboot`

 ... for each node.

 i'm testing that procedure on fsn-node-03 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] #32460 [Webpages/Website]: download page has confusing flow, especially with donate banner

[Tor Bug Tracker & Wiki]

#32460: download page has confusing flow, especially with donate banner
--+-
 Reporter:  arma  |  Owner:  hiro
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by antonela):

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


Comment:

 We deployed a new iteration of the download page

 https://www.torproject.org/download/

 Changes:

 - remove EOY campaign banner
 - add a better label to the download button, mentioning the OS. Eg.
 `Download for Windows`
 - add an [?] icon near to the signature link for people to learn more
 about what it is and why it is important
 - removes the top navigation to avoid confusion with multiple links and
 retain focus in one user flow.

 https://dip.torproject.org/torproject/web/tpo/commit/
 5fcd29f27025d7651559d746875214494c11744f
 7e9da94fdb7172d02a24eb4b90e46a8f2773d563
 9821026a8c55dd805f5c57ae0955ee7ed5becaa7
 0308ca518be503b715f3462c2a9650c528453ded

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

Re: [tor-bugs] #32749 [Webpages/Website]: Tor download button on your site does nothing when I click on it

[Tor Bug Tracker & Wiki]

#32749: Tor download button on your site does nothing when I click on it
+--
 Reporter:  get-lead-out.44mag  |  Owner:  hiro
 Type:  defect  | Status:  reopened
 Priority:  Very High   |  Milestone:
Component:  Webpages/Website|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ux-team |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by antonela):

 * parent:  #32460 =>


Comment:

 unparenting - (not related)

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

Re: [tor-bugs] #33412 [Internal Services/Tor Sysadmin Team]: ganeti cluster backend is IPv4-only (was: ganeti-reboot-cluster fails to connect to all nodes)

[Tor Bug Tracker & Wiki]

#33412: ganeti cluster backend is IPv4-only
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 I looked into fixing this in Puppet, but that is quite involved: the IP
 address passed into the ganeti module is carried not only in the
 authorized_keys but also the ipsec and ferm modules, which makes it a bit
 too "tangly" for a hot fix.

 but it is definitely something that needs fixing in puppet in any case: we
 don't want to rely on "legacy" IPv4 like we're doing now.

 for now i hacked at the ganeti-reboot-cluster script to add `-4` to all
 `ssh` calls.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33412 [Internal Services/Tor Sysadmin Team]: ganeti-reboot-cluster fails to connect to all nodes

[Tor Bug Tracker & Wiki]

#33412: ganeti-reboot-cluster fails to connect to all nodes
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 I tried to reboot the ganeti cluster yesterday and it failed with:

 {{{
 r...@fsn-node-04.torproject.org: Permission denied (publickey).
 }}}

 weasel diagnosed this as:

 {{{
 16:57:08  etc/ssh/userkeys/root only has v4 addresses in from=..
 16:57:22  that is probably a 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] #33406 [Internal Services/Tor Sysadmin Team]: automate reboots

[Tor Bug Tracker & Wiki]

#33406: automate reboots
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  project  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major| Resolution:
 Keywords:  tpa-roadmap-march|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Old description:

> in #31957 we have worked on automating upgrades, but that's only part of
> the problem. we also need to reboot in some situations.
>
> we have various mechanisms to do so right now:
>
>  * `tsa-misc/reboot-host` - reboot script for kvm boxes, kind of a mess,
> to be removed when we finish the kvm-ganeti migration
>  * `tsa-misc/reboot-guest` - reboot a single host. kind of a hack, but
> useful to reboot a single machine
>  * `misc/multi-tool/torproject-reboot-simple` - iterate over all hosts
> with `rebootPolicy=justdoit` in LDAP and reboot them with `torproject-
> reboot-many`
>  * `misc/multi-tool/torproject-reboot-simple` - iterate over all hosts
> with `rebootPolicy=rotation` in LDAP and reboot them with `torproject-
> reboot-many`, with a 30 minute delay between each host
>  * `ganeti-reboot-cluster` - a tool to reboot the ganeti cluster
>
> There are various problems with all this:
>
>  * the `torproject-reboot-*` scripts do not take care of
> `rebootPolicy=manual` hosts
>  * the `ganeti-reboot-cluster` script has been known to fail if a cluster
> is unbalanced
>  * the `ganeti-reboot-cluster` script currently fails when hosts talk to
> each other over IPv6 somehow
>  * we have 5 different ways of performing reboots, we should have just
> one script that does it all
>  * reboot-{host,guest} do not check if hosts need reboot before rebooting
> (but the multi-tool does)
>
> In short, this is kind of a mess, and we should refactor this. We should
> consider using needrestart, which knows how to reboot individual hosts.
>
> I also added a [https://github.com/xneelo/hetzner-needrestart/issues/23
> feature request to the needrestart puppet module] to expose its knowledge
> as a puppet fact, so we can use that information from PuppetDB instead of
> SSH'ing in each host and calling the dsa-* tools.

New description:

 in #31957 we have worked on automating upgrades, but that's only part of
 the problem. we also need to reboot in some situations.

 we have various mechanisms to do so right now:

  * `tsa-misc/reboot-host` - reboot script for kvm boxes, kind of a mess,
 to be removed when we finish the kvm-ganeti migration
  * `tsa-misc/reboot-guest` - reboot a single host. kind of a hack, but
 useful to reboot a single machine
  * `misc/multi-tool/torproject-reboot-simple` - iterate over all hosts
 with `rebootPolicy=justdoit` in LDAP and reboot them with `torproject-
 reboot-many`
  * `misc/multi-tool/torproject-reboot-simple` - iterate over all hosts
 with `rebootPolicy=rotation` in LDAP and reboot them with `torproject-
 reboot-many`, with a 30 minute delay between each host
  * `ganeti-reboot-cluster` - a tool to reboot the ganeti cluster

 There are various problems with all this:

  * the `torproject-reboot-*` scripts do not take care of
 `rebootPolicy=manual` hosts
  * the `ganeti-reboot-cluster` script has been known to fail if a cluster
 is unbalanced
  * the `ganeti-reboot-cluster` script currently fails when hosts talk to
 each other over IPv6 somehow (see #33412)
  * we have 5 different ways of performing reboots, we should have just one
 script that does it all
  * reboot-{host,guest} do not check if hosts need reboot before rebooting
 (but the multi-tool does)

 In short, this is kind of a mess, and we should refactor this. We should
 consider using needrestart, which knows how to reboot individual hosts.

 I also added a [https://github.com/xneelo/hetzner-needrestart/issues/23
 feature request to the needrestart puppet module] to expose its knowledge
 as a puppet fact, so we can use that information from PuppetDB instead of
 SSH'ing in each host and calling the dsa-* tools.

--

Comment (by anarcat):

 filed bug #33412 about the ganeti-reboot-cluster 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] #33277 [Internal Services/Tor Sysadmin Team]: adopt puppetlabs apt module

[Tor Bug Tracker & Wiki]

#33277: adopt puppetlabs apt module
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:  closed
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major| Resolution:  fixed
 Keywords:  tpa-roadmap-february |  Actual Points:  0.5
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

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


Comment:

 all our patches were merged. future improvements are welcome, but are
 probably better followed up in the upstream issue tracker.

 ie. we'll fix those when we have time, they are not blockers.

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

Re: [tor-bugs] #32532 [Internal Services/Tor Sysadmin Team]: Install ZNC on Chives, make pastly admin it

[Tor Bug Tracker & Wiki]

#32532: Install ZNC on Chives, make pastly admin it
-+-
 Reporter:  pastly   |  Owner:  pastly
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 And: once this is a real service, can somebody add a line to
 https://trac.torproject.org/projects/tor/wiki/org/operations/services
 along with who is the service maintainer, so it is possible for people to
 try to report issues with the service without secretly already knowing who
 runs it? :)

 (maybe in the 'internal stuff' section)

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

Re: [tor-bugs] #32532 [Internal Services/Tor Sysadmin Team]: Install ZNC on Chives, make pastly admin it

[Tor Bug Tracker & Wiki]

#32532: Install ZNC on Chives, make pastly admin it
-+-
 Reporter:  pastly   |  Owner:  pastly
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 pastly: chives was rebooted last night and it seems the bouncer didn't
 come back on. could you take a look?

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

Re: [tor-bugs] #33115 [Webpages/Blog]: Migrating the blog to a static web site with Lektor

[Tor Bug Tracker & Wiki]

#33115: Migrating the blog to a static web site with Lektor
---+--
 Reporter:  hiro   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:  10
 Reviewer: |Sponsor:
---+--

Comment (by anarcat):

 Replying to [comment:5 teor]:
 > What's our plan for converting links in old posts?
 > Can links between old blog posts point to the new blog, once the old
 posts have been converted?

 That's always the tricky part in a conversion. I've done Drupal
 "fossilizations" before, which consists of turning a dynamic website into
 a static one. It's an involved process, but it can be done, with enough
 time and tweaking. The result is a static archive of the Drupal site, in
 raw HTML.

 The tricky part is where to put that archive. If we want to keep the
 `blog.torproject.org` domain active with the new lektor site, we'll have
 to do some dance like we did with the main website (move the old website
 to 2019.www.tpo, specifically). I'm not sure that worked very well,
 because it broke a *lot* of links and we didn't have good mechanisms to
 redirect to the older site on the new one.

 Could we consider creating the new site on a new domain, say
 `news.torproject.org`?

 > Is there a proof of concept somewhere, that we could look at?
 > Or are we not at that stage yet?

 ... but yeah, maybe we're getting ahead of ourselves a little here. As far
 as I know, we haven't resolved those questions yet and there's no proof of
 concept. But those are excellent questions!

 Replying to [comment:6 arma]:
 > Do we have anybody on our side with real in-depth experience in managing
 discourse communities? [... notes about the limitations of stack exchange
 and reddit ...]
 > do we have a plan for how this time will be different? Delegating our
 community moderation to a third party platform means giving the control to
 steer topics to...whom exactly?

 The key difference between Reddit/Stackexchange and "our own discourse
 instance" (whether it's self-hosted or hosted at discoursehosting.net, as
 we plan to do) is that we would be admins of the instance, which is not
 the case of the other communities. We would have the final say in what's
 in and what's out, the same way we do right now with the blog comments.
 Although...

 >  At least with the current blog case, it fails closed when we spend a
 while not giving it attention, rather than failing open by going off in
 some surprising and unhelpful direction.

 ... I am not familiar with how blog moderation works now. If it's "a
 priori moderation" (ie. that a comment does not show up before it's
 approved), that might be difficult to replicate in Discourse. But I'm not
 too worried about this: Discourse is specifically built to help manage a
 more healthy forum community, and I'm hopefully we can build one with
 existing staff resources (who currently moderate the blog) and possibly
 even community people (who would be promoted within the normal Discourse
 process)

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

Re: [tor-bugs] #33406 [Internal Services/Tor Sysadmin Team]: automate reboots

[Tor Bug Tracker & Wiki]

#33406: automate reboots
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  project  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major| Resolution:
 Keywords:  tpa-roadmap-march|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 Replying to [comment:2 arma]:
 > Replying to [comment:1 anarcat]:
 > > i also wonder, in general, if we should warn users about those
 reboots, as part of the reboot script.
 >
 > This idea might not at all be worth the hassle of implementing it, but
 your "rebooting x", "x is back" lines from #tor-project irc seem eminently
 automatable.

 That's exactly what I had in mind. The trick is whether individual hosts
 should connect to IRC to issue those notifications (?!) or whether the
 calling script should. Either way, we'd need some sort of notification
 bot, which has been kind of a pain in the arse before in my experience.
 But maybe we could leverage KGB for this?

 It's one of the reasons I'm thinking of rebuilding this system in the
 first place as well...

 Thanks for the feedback!

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

Re: [tor-bugs] #32672 [Core Tor/Tor]: Reject 0.2.9 and 0.4.0 in dirserv_rejects_tor_version()

[Tor Bug Tracker & Wiki]

#32672: Reject 0.2.9 and 0.4.0 in dirserv_rejects_tor_version()
-+-
 Reporter:  teor |  Owner:  neel
 Type:  task | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  044-should, 043-backport,|  Actual Points:
  041-backport, 042-backport, consider-  |
  backport-after-authority-test, fast-fix,   |
  network-health |
Parent ID:   | Points:  0.5
 Reviewer:  teor |Sponsor:
-+-

Comment (by ggus):

 >I am waiting for ggus here so we can coordinate.

 Hi, yesterday I contacted organizations and relay operators from Brazil,
 Chile, Mexico, Costa Rica. I sent localized email in Spanish and
 Portuguese, some people replied and upgraded their relays.

 GeKo, we could select relay operators from two or three countries, and
 contact them today (Friday) or Wednesday. I'll be offline next Monday and
 Tuesday, so I can't follow up with they have questions.

 And here's Roger email that we can use:

 {{{
 Hi,

 You are running a Tor relay, which is great:
 http://rougmnvswfsmd4dq.onion/rs.html#details/$fingerprint

 But that Tor version is obsolete, and because of old bugs, we will soon
 cut relays running those versions out of the network. Please consider
 upgrading!

 You can find Tor packages and instructions for your distro / OS here:
 https://community.torproject.org/relay/setup/guard/

 Ideally you will switch to keeping up with our stable releases, but if
 you need a stable that is especially stable, the Tor 0.3.5 branch will
 be maintained until Feb 2022:
 
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases#Current
 and you can see the lifetimes of other Tor versions on that table too.

 Let us know if we can do anything to make the process easier.

 And lastly, I am cc'ing the new network health mailing list (which
 has public archives), to help us stay synced:
 https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkHealthTeam

 Thanks!
 --$name
 }}}

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

Re: [tor-bugs] #33115 [Webpages/Blog]: Migrating the blog to a static web site with Lektor

[Tor Bug Tracker & Wiki]

#33115: Migrating the blog to a static web site with Lektor
---+--
 Reporter:  hiro   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:  10
 Reviewer: |Sponsor:
---+--

Comment (by arma):

 Replying to [ticket:33115 hiro]:
 > I propose to migrate the blog to a static website with lektor and have
 comments running from discourse.org.

 I like this plan in theory. I agree that our current situation is not
 really sustainable.

 I have two concerns that I want to make sure we address well enough with
 the new plan:

 > Moderation on discourse is much easier than on drupal comments (another
 pain point for the blog), and we would get a forum that we could use for
 other purposes too.

 Do we have anybody on our side with real in-depth experience in managing
 discourse communities? I ask because with both the stackexchange case and
 the reddit case, we had plans for real Tor people who actually understand
 Tor things to engage, and it started out working that way, but then those
 people got distracted or burnt out or otherwise didn't keep up, and the
 platforms (for better or for worse) have a mechanism for random people to
 become highly trusted if they just stick with it -- so the result was that
 all the moderators are now random people whose primary property is that
 they have free time and they're stubborn, rather than that they are people
 we know and have some relationship with.

 I no longer engage much with Tor's stackexchange, because some of the
 recent times I did, some random person stepped in and told me I was wrong
 about my answer and changed it to an answer I didn't want it to be. The
 original plan there was to pick a better platform for building our FAQ...
 but if we can't choose the answers on our FAQ, that's not so helpful to
 us.

 So: do we have a plan for how this time will be different? Delegating our
 community moderation to a third party platform means giving the control to
 steer topics to...whom exactly?

 At least with the current blog case, it fails closed when we spend a while
 not giving it attention, rather than failing open by going off in some
 surprising and unhelpful direction.

 > What we will lose:
 >  - Old comments. I see no value in migrating old blog comments to
 discourse to be honest. It would be a lot of effort and the old comments
 will be archived anyways in the blog archive.

 I agree that migrating old blog comments to discourse seems like a bad
 step. But are the only two choices 'migrate to discourse' or 'drop'? For
 example, another option might be to migrate them to the static html blog
 entries.

 Many of our old blog posts have real content that would be a shame to
 lose. For two examples,
 https://blog.torproject.org/comment/224125#comment-224125
 and
 https://blog.torproject.org/comment/78918#comment-78918
 but there are many many more.

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

Re: [tor-bugs] #33105 [Webpages/Blog]: evaluate if discourse can be used as comments platform for the blog

[Tor Bug Tracker & Wiki]

#33105: evaluate if discourse can be used as comments platform for the blog
---+--
 Reporter:  hiro   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #32090 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by teor):

 Discourse uses Google analytics, universal analytics, and google tag
 manager:
 
https://github.com/discourse/discourse/blob/f5d391a48a63bd7d5597d621423dd020270bec45/app/assets/javascripts/discourse/initializers
 /page-tracking.js.es6#L24

 A pikwik patch was refused:
 https://github.com/discourse/discourse/pull/3219

 There doesn't seem to be any way to turn tracking off, but I didn't look
 very hard.

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

Re: [tor-bugs] #33086 [Core Tor/Tor]: Support brotli compression for directory requests

[Tor Bug Tracker & Wiki]

#33086: Support brotli compression for directory requests
--+
 Reporter:  nickm |  Owner:  rl1987
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by rl1987):

 * status:  new => accepted
 * owner:  (none) => rl1987


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

Re: [tor-bugs] #33105 [Webpages/Blog]: evaluate if discourse can be used as comments platform for the blog

[Tor Bug Tracker & Wiki]

#33105: evaluate if discourse can be used as comments platform for the blog
---+--
 Reporter:  hiro   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #32090 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by teor):

 They have link tracking, we should see if it can be turned off:

 Search for "link tracking" on https://www.discourse.org/features

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

Re: [tor-bugs] #33115 [Webpages/Blog]: Migrating the blog to a static web site with Lektor

[Tor Bug Tracker & Wiki]

#33115: Migrating the blog to a static web site with Lektor
---+--
 Reporter:  hiro   |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:  10
 Reviewer: |Sponsor:
---+--

Comment (by teor):

 Sounds like a great plan. Less work, less risk, and lower cost.

 Replying to [comment:4 pili]:
 > I would like to highlight the need for an events/calendar plugin or
 similar.

 I think the calendar is the one big missing piece.

 We also have "Recent Updates" on the blog, are we keeping that?
 It seems easy to implement using a template.

 I also see tags on posts, they should be easy with a template.

 And I think it's ok to lose comments and old versions of posts.
 Discourse is a great platform, it's really well designed for healthier
 conversations.

 What's our plan for migrating media?

 What's our plan for converting links in old posts?
 Can links between old blog posts point to the new blog, once the old posts
 have been converted?

 Is there anything else we're going to lose, or any other changes we don't
 know about?

 Is there a proof of concept somewhere, that we could look at?
 Or are we not at that stage 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] #33407 [Core Tor/Tor]: Chutney bridge authorities have an empty networkstatus-bridges

[Tor Bug Tracker & Wiki]

#33407: Chutney bridge authorities have an empty networkstatus-bridges
+--
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ipv6, prop311, tor-bridge, chutney  |  Actual Points:
Parent ID:  #33232  | Points:  1
 Reviewer:  |Sponsor:
|  Sponsor55-can
+--

Comment (by teor):

 One thing I can tell you is that chutney bridges *have* descriptors.
 Otherwise chutney bridge clients wouldn't be able to make any 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] #33379 [Core Tor/Chutney]: Make chutney wait for all relays in the consensus before verifying

[Tor Bug Tracker & Wiki]

#33379: Make chutney wait for all relays in the consensus before verifying
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6, prop311 |  Actual Points:  0.5
Parent ID:  #33232| Points:  0.5
 Reviewer:  nickm |Sponsor:  Sponsor55-must
--+
Changes (by teor):

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


Comment:

 I've done some work on this ticket, and it's almost complete.

 It was a bit bigger than I thought, because I forgot about bridges.

 I also forgot that bridges will have their own descriptor in their cached-
 descriptors file (as well as the bridge authority, and bridge clients). So
 I'll have to fix that up.

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

Re: [tor-bugs] #33407 [Core Tor/Tor]: Chutney bridge authorities have an empty networkstatus-bridges

[Tor Bug Tracker & Wiki]

#33407: Chutney bridge authorities have an empty networkstatus-bridges
+--
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ipv6, prop311, tor-bridge, chutney  |  Actual Points:
Parent ID:  #33232  | Points:  1
 Reviewer:  |Sponsor:
|  Sponsor55-can
+--

Comment (by teor):

 Replying to [comment:1 arma]:
 > Can you give us some hints about what is going wrong? That is, why the
 bridge authority in Chutney doesn't have any bridges in its networkstatus-
 bridges file?
 >
 > For example, are bridges publishing to it?
 >
 > The "fix bugs in" options are very broad and vague, so it is hard to
 pick from them yet. :)

 I haven't done any analysis yet, I've just noticed the issue while
 implementing #33378 and #33379.

 Once those tickets are implemented, chutney will tell me which nodes have
 other nodes descriptors.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33411 [Core Tor/Tor]: Make DirCache default to 0 on Windows relays

[Tor Bug Tracker & Wiki]

#33411: Make DirCache default to 0 on Windows relays
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.4.x-final
Component:  Core |Version:  Tor: 0.3.1.9
  Tor/Tor|   Keywords:  044-should, cpu, windows, linux,
 Severity:  Normal   |  performance, regression, 033-triage-20180326,
 |  033-removed-20180326, 034-deferred-20180602,
 |  035-removed-20180711, 032-unreached-backport,
 |  040-roadmap-proposed, 033-unreached-backport-
 |  maybe, network-health
Actual Points:   |  Parent ID:  #24857
   Points:  0.2  |   Reviewer:
  Sponsor:   |
-+-
 In #24857, tor's consensus diff cache implementation causes high CPU load
 on Windows.

 As a workaround, we could make DirCache default to 0 on Windows.

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

Re: [tor-bugs] #24857 [Core Tor/Tor]: Tor uses 100% CPU when accessing the cache directory on Windows

[Tor Bug Tracker & Wiki]

#24857: Tor uses 100% CPU when accessing the cache directory on Windows
-+-
 Reporter:  Eugene646|  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.9
 Severity:  Normal   | Resolution:
 Keywords:  044-should, cpu, windows, linux, |  Actual Points:
  performance, regression, 033-triage-20180326,  |
  033-removed-20180326, 034-deferred-20180602,   |
  035-removed-20180711, 032-unreached-backport,  |
  040-roadmap-proposed, 033-unreached-backport-  |
  maybe, network-health  |
Parent ID:  #25500   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 A Windows relay operators has confirmed that setting DirCache 0 resolves
 this issue:
 https://lists.torproject.org/pipermail/tor-
 relays/2020-February/018165.html

 They can help test any Windows patches for this issue, once the patch is
 in the Tor Expert Bundle.
 So I guess that means a Tor Browser Alpha?

 Alternatively, as a workaround, we could make DirCache default to 0 on
 Windows. I'll open a child 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

[tor-bugs] #33410 [Applications/Tor Browser]: Use RLBox for sandboxing Graphite on macOS

[Tor Bug Tracker & Wiki]

#33410: Use RLBox for sandboxing Graphite on macOS
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-security,
 Severity:  Normal   |  GeorgKoppen202002
Actual Points:   |  Parent ID:  #32379
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 In https://bugzilla.mozilla.org/show_bug.cgi?id=1610149 and child tickets
 Mozilla landed support for RLBox sandboxing Graphite on macOS as well.
 This ticket tracks the work for backporting the patches for Tor Browser.

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

Re: [tor-bugs] #33407 [Core Tor/Tor]: Chutney bridge authorities have an empty networkstatus-bridges

[Tor Bug Tracker & Wiki]

#33407: Chutney bridge authorities have an empty networkstatus-bridges
+--
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ipv6, prop311, tor-bridge, chutney  |  Actual Points:
Parent ID:  #33232  | Points:  1
 Reviewer:  |Sponsor:
|  Sponsor55-can
+--

Comment (by arma):

 Can you give us some hints about what is going wrong? That is, why the
 bridge authority in Chutney doesn't have any bridges in its networkstatus-
 bridges file?

 For example, are bridges publishing to it?

 The "fix bugs in" options are very broad and vague, so it is hard to pick
 from them 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] #33336 [Circumvention/Snowflake]: Trial deployment of Snowflake with Turbo Tunnel

[Tor Bug Tracker & Wiki]

#6: Trial deployment of Snowflake with Turbo Tunnel
-+--
 Reporter:  dcf  |  Owner:  dcf
 Type:  task | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  turbotunnel  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by arma):

 Replying to [comment:12 dcf]:
 > I think I know why idle browsing seemed to disconnect more, at least in
 the quic case. It's because the older version of quic-go we are using
 (2019-04-01) does not send frequent enough keepalives. It sets the
 keepalive interval to half the idle timeout, which for us is
 
[https://gitweb.torproject.org/user/dcf/snowflake.git/tree/client/lib/snowflake.go?h
 =turbotunnel-quic=d5be0906ffe4ef8de8a9345690713bc362d3bcee#n72 10
 minutes]. Keepalives every 5 minutes are not enough to prevent
 
[https://gitweb.torproject.org/user/dcf/snowflake.git/tree/client/lib/webrtc.go?h
 =turbotunnel-quic=d5be0906ffe4ef8de8a9345690713bc362d3bcee#n110
 checkForStaleness] from killing the connection after 30 seconds of
 idleness.

 Remember that Tor has its own application level (i.e. tor client <=> tor
 bridge in this case) keepalives.

 Which by an odd quirk of fate are also sent and received every 5 minutes:
 see the KeepalivePeriod torrc option:
 https://gitweb.torproject.org/tor.git/tree/src/core/mainloop/mainloop.c#n1236

 You could in theory crank this number down to 20 seconds to workaround the
 problem at the quic layer. But it is definitely not the right long term
 answer, and also it might introduce other weird side effects, like
 apparently we use the Keepalive parameter to decide if we've waited long
 enough that we should give up on an in-progress-but-not-yet-open OR
 connection:
 https://gitweb.torproject.org/tor.git/tree/src/core/mainloop/mainloop.c#n1236

 It is in any case an option to explore if upgrading the quic libs turns
 out to be messier than expected. :)

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

Re: [tor-bugs] #33401 [Circumvention/Snowflake]: turbotunnel-quic snowflake-client occasionally uses lots of CPU

[Tor Bug Tracker & Wiki]

#33401: turbotunnel-quic snowflake-client occasionally uses lots of CPU
-+--
 Reporter:  dcf  |  Owner:  dcf
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  turbotunnel  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dcf):

 I tracked this down to a bug in quic-go that has been fixed in a newer
 version.
  * [https://github.com/lucas-clemente/quic-
 go/commit/079279b9cf4cb5dafc8b7f673a2e7e47a4b6a06e fix mismatching
 expectation of the keep alive timer]
> session.maybeResetTimer() and session.run() were using slightly
 different definitions of when a keep-alive PING should be sent. Under
 certain conditions, this would make us repeatedly set a timer for the
 keep-alive, but on timer expiration no keep-alive would be sent.

 What was going wrong is [https://github.com/lucas-clemente/quic-
 go/blob/907071221cf97f75398d9cf8b1174e94f56e8f96/session.go#L449 here].
 {{{
 deadline = s.idleTimeoutStartTime().Add(s.peerParams.IdleTimeout / 2)
 }}}
 If the current time is more than 50% of `IdleTimeout` past
 `idleTimeoutStartTime`, then this line computes a deadline in the past.
 The deadline in the past makes the `s.timer` always immediately
 selectable, which makes `session.run` always call back right into
 `maybeResetTimer` and set another deadline in the past. It continues until
 some external event such as an arriving packet resets
 `idleTimeoutStartTime`.

 We can resolve the problem by using a more recent commit of quic-go. But
 the commit [https://github.com/lucas-clemente/quic-
 go/commit/079279b9cf4cb5dafc8b7f673a2e7e47a4b6a06e 079279b] we need is not
 in any published release yet (v0.14.4 is the newest as of this writing,
 released just 4 days ago). So we would have to set it to a specific commit
 rather than a tag.

 The instability of quic-go is making me like it less for Turbo Tunnel
 purposes. This isn't the first time I've found a bug in the most recent
 tagged release that had already been fixed in master (i.e., not in any
 version that `go get` would get for you with Go modules activated). The
 other time was [https://github.com/lucas-clemente/quic-go/issues/2172
 GH#2172].

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

Re: [tor-bugs] #33401 [Circumvention/Snowflake]: turbotunnel-quic snowflake-client occasionally uses lots of CPU

[Tor Bug Tracker & Wiki]

#33401: turbotunnel-quic snowflake-client occasionally uses lots of CPU
-+--
 Reporter:  dcf  |  Owner:  dcf
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  turbotunnel  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by dcf):

 * Attachment "quic-go-negative-timer.zip" added.

 Test program for manually bisecting quic-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

[tor-bugs] #33409 [Core Tor/Tor]: Pre-commit hook does not stash unstaged changes before running code style checkers

[Tor Bug Tracker & Wiki]

#33409: Pre-commit hook does not stash unstaged changes before running code 
style
checkers
--+
 Reporter:  rl1987|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 How to reproduce:

 1) Make some changes to C files and violate whitespace rules.
 2) `git add` affected files and try to `git commit`. Pre-commit hook will
 not allow it and will print the whitespace issues it found.
 3) Fix whitespace problems, but forget to `git add` the files.
 4) Running `git commit` again does not reject the changes, despite
 whitespace fixes not being staged. New commit now includes whitespace
 violations and none of the fixes that were done in step 3.

 This is not limited to whitespace issues, but could affect other code
 style checks as well.

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

Re: [tor-bugs] #33357 [Applications/Tor Browser]: Add option to remove addresses from window/tab titles

[Tor Bug Tracker & Wiki]

#33357: Add option to remove addresses from window/tab titles
+--
 Reporter:  juannelly   |  Owner:  tbb-team
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeamTriaged, ux-team  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by pili):

 * keywords:   => TorBrowserTeamTriaged, ux-team
 * owner:  antonela => tbb-team
 * component:  UX => Applications/Tor Browser


Comment:

 Thank you for the enhancement request, we will add this to our list 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] #33381 [Applications/Orbot]: orbot vpn

[Tor Bug Tracker & Wiki]

#33381: orbot vpn
+---
 Reporter:  rfeola54|  Owner:  n8fr8
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by pili):

 * owner:  legind => n8fr8
 * version:  Tor: 0.4.3.2-alpha =>
 * component:  HTTPS Everywhere => Applications/Orbot
 * severity:  Major => Normal


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

Re: [tor-bugs] #33390 [Applications/Tor Browser]: Consider Open in Browser addon

[Tor Bug Tracker & Wiki]

#33390: Consider Open in Browser addon
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  new-addon, tbb-usability, tbb-   |  Actual Points:
  security, TorBrowserTeamTriaged, ux-team   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pili):

 * cc: antonela (added)
 * keywords:  new-addon, tbb-usability, tbb-security => new-addon, tbb-
 usability, tbb-security, TorBrowserTeamTriaged, ux-team
 * type:  defect => enhancement


Comment:

 Thank you for the enhancement request we will add it to our list 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] #33406 [Internal Services/Tor Sysadmin Team]: automate reboots

[Tor Bug Tracker & Wiki]

#33406: automate reboots
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  project  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major| Resolution:
 Keywords:  tpa-roadmap-march|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Replying to [comment:1 anarcat]:
 > i also wonder, in general, if we should warn users about those reboots,
 as part of the reboot script.

 This idea might not at all be worth the hassle of implementing it, but
 your "rebooting x", "x is back" lines from #tor-project irc seem eminently
 automatable.

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