Re: [tor-bugs] #28279 [Core Tor/Tor]: control: Add a key to GETINFO to fetch the circuit onion handshake rephist values

2020-05-27 Thread Tor Bug Tracker & Wiki
#28279: control: Add a key to GETINFO to fetch the circuit onion handshake 
rephist
values
---+--
 Reporter:  dgoulet|  Owner:  neel
 Type:  enhancement| Status:  needs_review
 Priority:  Low|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-control, tor-spec  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by neel):

 * status:  assigned => needs_review


Comment:

 PRs:

  * Tor: https://github.com/torproject/tor/pull/1907

  * Torspec: https://github.com/torproject/torspec/pull/117

 Setting as needs review.

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


Re: [tor-bugs] #16822 [Core Tor/Tor]: make certificate lifetime accessible through Tor's ControlPort

2020-05-27 Thread Tor Bug Tracker & Wiki
#16822: make certificate lifetime accessible through Tor's ControlPort
-+-
 Reporter:  proper   |  Owner:  neel
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-spec, tor-control, intro,  |  Actual Points:
  tor-relay  |
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-
Changes (by neel):

 * cc: neel (added)
 * owner:  (none) => neel
 * status:  new => assigned


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


Re: [tor-bugs] #34305 [Applications/Tor Browser]: NoScript inconsistent behaviour in Firefox 77 (currently beta)

2020-05-27 Thread Tor Bug Tracker & Wiki
#34305: NoScript inconsistent behaviour in Firefox 77 (currently beta)
-+-
 Reporter:  acat |  Owner:  acat
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  noscript TorBrowserTeam202005,   |  Actual Points:
  ff78-esr   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by ma1):

 Replying to [comment:7 acat]:
 > Thanks! I think the response was actually pretty fast :)
 >

 Please check
 https://github.com/hackademix/noscript/releases/tag/11.0.27rc1

 Thanks you.

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


[tor-bugs] #34319 [- Select a component]: remove symlink support from the updater

2020-05-27 Thread Tor Bug Tracker & Wiki
#34319: remove symlink support from the updater
--+
 Reporter:  mcs   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Our updater patch (#4234) adds support for handling symlinks during MAR
 file generation and in the updater itself. The original reason for adding
 this feature was to support meek's use of a second browser for its HTTP
 tunnel; see #12647.

 We no longer use symlinks on any platform. Kathy and I think we should
 remove the symlink portions of the #4234 patch (smaller patches == good).

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


Re: [tor-bugs] #34319 [Applications/Tor Browser]: remove symlink support from the updater

2020-05-27 Thread Tor Bug Tracker & Wiki
#34319: remove symlink support from the updater
--+--
 Reporter:  mcs   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

 * owner:  (none) => tbb-team
 * component:  - Select a component => Applications/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] #34129 [Circumvention/Snowflake]: Use STUN to determine NAT behaviour of peers

2020-05-27 Thread Tor Bug Tracker & Wiki
#34129: Use STUN to determine NAT behaviour of peers
-+---
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+---

Comment (by cohosh):

 I submitted a PR to upstream the changes to pion/stun:
 https://github.com/pion/stun/pull/33

 There are a couple ways to move forward with this. I'm suggesting the
 following steps:
 - Do NAT discovery at the proxy and use that to decide how often they poll

  This is actually more useful for webextension users to do than standalone
 go proxies since we have way more of them. There's no functionality for
 this in the webrtc library we're using, but the
 [https://www.npmjs.com/package/stun stun] package claims to have partial
 support for RFC 5780, and lists the attributes we need.

  This basically replaces our datachannel failure heuristic with a NAT type
 heuristic. We can do both but should make sure they interact correctly.

 - Do NAT discovery at the proxy and client and send that information to
 the broker to match them up in a smarter way.

  I'd like some feedback on this before moving forward since it will take
 some effort and be a substantial change to the way the broker works. I'm
 also hesitant to make decisions that prioritize some proxies over others
 that rely on proxy honestly since it increases the ability of a malicious
 party to DoS Snowflake with bad proxies. If they can falsely report a
 value to get their bad proxies prioritized over others, we'll be in a
 worse situation w.r.t. DoS than we are 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] #34303 [Metrics/Onionperf]: Find out why onion service measurements have gotten slower

2020-05-27 Thread Tor Bug Tracker & Wiki
#34303: Find out why onion service measurements have gotten slower
---+
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor59-must
---+

Comment (by karsten):

 Here are some very early results from two new OnionPerf instances running
 0.2.9.17 and 0.3.3.12 (thanks, acute, for the help with setting these
 up!):

 [[Image(onionperf-2020-05-27-2.png, 700px)]]

 Something has changed between 0.2.9.17 and 0.3.3.12. I'll set up new
 OnionPerf instances.

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


Re: [tor-bugs] #34303 [Metrics/Onionperf]: Find out why onion service measurements have gotten slower

2020-05-27 Thread Tor Bug Tracker & Wiki
#34303: Find out why onion service measurements have gotten slower
---+
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor59-must
---+
Changes (by karsten):

 * Attachment "onionperf-2020-05-27-2.png" added.


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


Re: [tor-bugs] #33664 [Applications/Tor Browser]: Sponsor 58: Migrate Tor Browser for Android to Firefox’s Fenix

2020-05-27 Thread Tor Bug Tracker & Wiki
#33664: Sponsor 58: Migrate Tor Browser for Android to Firefox’s Fenix
--+---
 Reporter:  pili  |  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor58
--+---
Description changed by sysrqb:

Old description:

> This is the master ticket for the whole Sponsor58 project.

New description:

 This is the master ticket for the whole Sponsor58 project.

 https://trac.torproject.org/projects/tor/wiki/org/sponsors/Sponsor58

--

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


Re: [tor-bugs] #30123 [Core Tor/Tor]: MAPADDRESS result can mix status codes

2020-05-27 Thread Tor Bug Tracker & Wiki
#30123: MAPADDRESS result can mix status codes
---+
 Reporter:  catalyst   |  Owner:  neel
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:  Tor: 0.4.0.1-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-control, tor-spec  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by neel):

 * status:  new => assigned
 * cc: neel (added)
 * owner:  (none) => neel


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


Re: [tor-bugs] #33617 [Core Tor/Tor]: Add a BandwidthStatistics option and consensus parameter

2020-05-27 Thread Tor Bug Tracker & Wiki
#33617: Add a BandwidthStatistics option and consensus parameter
-+-
 Reporter:  teor |  Owner:
 |  MrSquanchee
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  extra-review, prop313, ipv6, |  Actual Points:
  outreachy-ipv6, network-team-roadmap-2020Q1|
Parent ID:  #33052   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  Sponsor55-can
-+-

Comment (by MrSquanchee):

 Hii, asn.
 1. `rep_hist_bw_stats_write()` gets called from
 `write_stats_file_callback` in mainloop.c.
  This function handles disk write for all the stats produced.
  So, do you want exhaustive unit-tests for `write_stats_file_callback`,
 which would test
  for all the stats ?? or should I write unit tests for
 `write_stats_file_callback`
  pertaining only to the bandwidth statistics ??
 2. Also, `rep_hist_bw_stats_write()` writes the stats to the disk, so does
 many other stat
  functions, but I haven't yet seen a unit test that tests for a directory
 and contents of
  a file maybe for some reasons I don't know or maybe I am wrong and you
 can point me to
  an appropriate test.
  Would you like to explain how I can write such a test  ??

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


Re: [tor-bugs] #33556 [Applications/Tor Browser]: Add TBB project for android-components

2020-05-27 Thread Tor Bug Tracker & Wiki
#33556: Add TBB project for android-components
-+-
 Reporter:  sisbell  |  Owner:  gk
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, |  Actual Points:
  TorBrowserTeam202005, GeorgKoppen202005|
Parent ID:  #33184   | Points:
 Reviewer:  sysrqb   |Sponsor:
 |  Sponsor58-must
-+-

Comment (by gk):

 So, [comment:10:ticket:33932 this] has been a big PITA and I found another
 .jar file was missing. I am still not sure why. But I added both "by hand"
 to be able to work on the integration of your custom `geckoview` further.
 `bug_33556_v4` (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/log/?h=bug_33556_v4) is what I am currently using for that.

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


[tor-bugs] #34318 [Circumvention/BridgeDB]: BridgeDB doesn't like non-UTF8 encoded requests

2020-05-27 Thread Tor Bug Tracker & Wiki
#34318: BridgeDB doesn't like non-UTF8 encoded requests
+
 Reporter:  phw |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Circumvention/BridgeDB  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  0.25|   Reviewer:
  Sponsor:  |
+
 I stumbled upon the following exception in BridgeDB's log:

 {{{
 Traceback (most recent call last):
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/twisted/web/http.py", line 1755, in dataReceived
 finishCallback(data[contentLength:])
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/twisted/web/http.py", line 2171, in _finishRequestBody
 self.allContentReceived()
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/twisted/web/http.py", line 2284, in allContentReceived
 req.requestReceived(command, path, version)
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/twisted/web/http.py", line 946, in requestReceived
 self.process()
 ---  ---
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/twisted/web/server.py", line 235, in process
 self.render(resrc)
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/twisted/web/server.py", line 302, in render
 body = resrc.render(self)
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/twisted/web/resource.py", line 265, in render
 return m(request)
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/bridgedb-0.10.0+34.ga6eb0d1c.dirty-
 py3.7.egg/bridgedb/distributors/https/server.py", line 722, in render_POST
 return CaptchaProtectedResource.render_POST(self, request)
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/bridgedb-0.10.0+34.ga6eb0d1c.dirty-
 py3.7.egg/bridgedb/distributors/https/server.py", line 573, in render_POST
 request.args = stringifyRequestArgs(request.args)
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-
 packages/bridgedb-0.10.0+34.ga6eb0d1c.dirty-
 py3.7.egg/bridgedb/distributors/https/server.py", line 109, in
 stringifyRequestArgs
 arg = arg if isinstance(arg, str) else arg.decode("utf-8")
 builtins.UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc2 in
 position 1: invalid continuation byte
 }}}

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


Re: [tor-bugs] #28672 [Applications/Tor Browser]: Android reproducible build of Snowflake

2020-05-27 Thread Tor Bug Tracker & Wiki
#28672: Android reproducible build of Snowflake
-+-
 Reporter:  dcf  |  Owner:  cohosh
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, |  Actual Points:
  TorBrowserTeam202005R, GeorgKoppen201904, ex-  |
  sponsor-19 |
Parent ID:  #30318   | Points:
 Reviewer:  gk   |Sponsor:
 |  Sponsor28-must
-+-
Changes (by gk):

 * keywords:
 tbb-mobile, tbb-rbm, TorBrowserTeam202005, GeorgKoppen201904, ex-
 sponsor-19
 =>
 tbb-mobile, tbb-rbm, TorBrowserTeam202005R, GeorgKoppen201904, ex-
 sponsor-19


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


Re: [tor-bugs] #34185 [Internal Services/Tor Sysadmin Team]: ganeti clusters don't like automatic upgrades

2020-05-27 Thread Tor Bug Tracker & Wiki
#34185: ganeti clusters don't like automatic upgrades
-+-
 Reporter:  anarcat  |  Owner:  hiro
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major| Resolution:
 Keywords:  tpa-roadmap-may  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hiro):

 Migrating VMs between nodes returns the VM back online.

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


Re: [tor-bugs] #34185 [Internal Services/Tor Sysadmin Team]: ganeti clusters don't like automatic upgrades

2020-05-27 Thread Tor Bug Tracker & Wiki
#34185: ganeti clusters don't like automatic upgrades
-+-
 Reporter:  anarcat  |  Owner:  hiro
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major| Resolution:
 Keywords:  tpa-roadmap-may  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hiro):

 Tested reinstalling openvswitch with

 {{{
 apt install --reinstall openvswitch-switch
 }}}

 On fsn-node-06. It caused openvswitch-switch to restart:


 {{{
 Active: active (exited) since Wed 2020-05-27 17:09:27 UTC; 2min 44s ago
 }}}

 I think openvswitch should be upgraded manually for the time being.

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


Re: [tor-bugs] #31660 [Applications/Tor Browser]: Revise onboarding to take new Firefox experience into account

2020-05-27 Thread Tor Bug Tracker & Wiki
#31660: Revise onboarding to take new Firefox experience into account
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.5,|  Actual Points:
  TorBrowserTeam202005R, ReleaseTrainMigration   |
Parent ID:  #33658   | Points:  4
 Reviewer:   |Sponsor:
 |  Sponsor58-can
-+-
Changes (by gk):

 * keywords:  ux-team, tbb-9.5, TorBrowserTeam202005, ReleaseTrainMigration
 => ux-team, tbb-9.5, TorBrowserTeam202005R, ReleaseTrainMigration


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


Re: [tor-bugs] #34185 [Internal Services/Tor Sysadmin Team]: ganeti clusters don't like automatic upgrades

2020-05-27 Thread Tor Bug Tracker & Wiki
#34185: ganeti clusters don't like automatic upgrades
-+-
 Reporter:  anarcat  |  Owner:  hiro
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major| Resolution:
 Keywords:  tpa-roadmap-may  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hiro):

 Openvswitch was updated together with the following group of packages:

 {{{
 2020-05-10 06:12:53,754 INFO Packages that will be upgraded: base-files
 distro-info-data iputils-arping iputils-ping iputils-tracepath
 libbrlapi0.6 libfuse2 l
 ibpam-systemd libsystemd0 libudev1 linux-compiler-gcc-8-x86 linux-headers-
 amd64 linux-image-amd64 linux-kbuild-4.19 openvswitch-common openvswitch-
 switch post
 fix postfix-cdb rake rubygems-integration systemd systemd-sysv tzdata udev
 }}}

 Checking openvswitch status it has not been restarted since the 10th of
 may:

 {{{
 Loaded: loaded (/lib/systemd/system/openvswitch-switch.service; enabled;
 vendor preset: enabled)
Active: active (exited) since Sun 2020-05-10 14:05:11 UTC; 2 weeks 3
 days ago

 }}}

 And from the log on that day I actually see it died twice:

 2020-05-10T06:13:16.534Z|3|vlog(monitor)|INFO|opened log file
 /var/log/openvswitch/ovs-vswitchd.log
 2020-05-10T06:13:16.534Z|4|daemon_unix(monitor)|INFO|pid 3211 died,
 exit status 0, exiting
 2020-05-10T06:13:16.787Z|1|vlog|INFO|opened log file
 /var/log/openvswitch/ovs-vswitchd.log
 2020-05-10T06:13:16.788Z|2|ovs_numa|INFO|Discovered 12 CPU cores on
 NUMA node 0
 2020-05-10T06:13:16.788Z|3|ovs_numa|INFO|Discovered 1 NUMA nodes and
 12 CPU cores
 
2020-05-10T06:13:16.788Z|4|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
 connecting...
 
2020-05-10T06:13:16.788Z|5|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
 connected
 2020-05-10T06:13:16.791Z|6|bridge|INFO|ovs-vswitchd (Open vSwitch)
 2.10.1
 2020-05-10T06:13:17.332Z|2|daemon_unix(monitor)|INFO|pid 29781 died,
 exit status 0, exiting
 2020-05-10T06:13:17.621Z|1|vlog|INFO|opened log file
 /var/log/openvswitch/ovs-vswitchd.log
 2020-05-10T06:13:17.623Z|2|ovs_numa|INFO|Discovered 12 CPU cores on
 NUMA node 0
 2020-05-10T06:13:17.623Z|3|ovs_numa|INFO|Discovered 1 NUMA nodes and
 12 CPU cores
 
2020-05-10T06:13:17.623Z|4|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
 connecting...
 
2020-05-10T06:13:17.623Z|5|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
 connected
 2020-05-10T06:13:17.630Z|6|bridge|INFO|ovs-vswitchd (Open vSwitch)
 2.10.1

 ...

 2020-05-10T14:02:23.078Z|00036|bridge|INFO|bridge br0: using datapath ID
 7eb83553f345
 2020-05-10T14:02:23.398Z|00037|bridge|INFO|bridge br0: deleted interface
 br0 on port 65534
 2020-05-10T14:02:23.578Z|2|daemon_unix(monitor)|INFO|pid 29951 died,
 exit status 0, exiting
 2020-05-10T14:05:05.241Z|1|vlog|INFO|opened log file
 /var/log/openvswitch/ovs-vswitchd.log
 2020-05-10T14:05:05.247Z|2|ovs_numa|INFO|Discovered 12 CPU cores on
 NUMA node 0
 2020-05-10T14:05:05.247Z|3|ovs_numa|INFO|Discovered 1 NUMA nodes and
 12 CPU cores
 
2020-05-10T14:05:05.247Z|4|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
 connecting...
 
2020-05-10T14:05:05.247Z|5|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
 connected
 2020-05-10T14:05:05.250Z|6|bridge|INFO|ovs-vswitchd (Open vSwitch)
 2.10.1
 2020-05-10T14:05:09.384Z|7|ofproto_dpif|INFO|system@ovs-system:
 Datapath supports recirculation
 2020-05-10T14:05:09.384Z|8|ofproto_dpif|INFO|system@ovs-system: VLAN
 header stack length probed as 2
 2020-05-10T14:05:09.384Z|9|ofproto_dpif|INFO|system@ovs-system: MPLS
 label stack length probed as 1
 2020-05-10T14:05:09.384Z|00010|ofproto_dpif|INFO|system@ovs-system:
 Datapath supports truncate action
 2020-05-10T14:05:09.384Z|00011|ofproto_dpif|INFO|system@ovs-system:
 Datapath supports unique flow ids


 {{{

 }}}

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


Re: [tor-bugs] #31660 [Applications/Tor Browser]: Revise onboarding to take new Firefox experience into account

2020-05-27 Thread Tor Bug Tracker & Wiki
#31660: Revise onboarding to take new Firefox experience into account
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.5,|  Actual Points:
  TorBrowserTeam202005, ReleaseTrainMigration|
Parent ID:  #33658   | Points:  4
 Reviewer:   |Sponsor:
 |  Sponsor58-can
-+-

Comment (by sysrqb):

 Replying to [comment:30 sysrqb]:
 > Replying to [comment:24 brade]:
 > > The current onboarding code displays two different "tours" (sets of
 panels):
 > >  * "newtour" for new users
 > >  * "updatetour" for users who have upgraded
 > >
 > > Should we omit "What's New" from the "newtour" and only have it for
 "updatetour"?
 > > It is easy to control this via the browser.onboarding.* preferences.
 > >
 > >
 >
 > For new users should we call it "Additional Features" or "See More"?
 Phrasing that indicates more information is available? Maybe we can use
 "More Information", and re-use the PageInfo string (but that's not exactly
 an ideal string for this use case).

 "Learn 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] #31660 [Applications/Tor Browser]: Revise onboarding to take new Firefox experience into account

2020-05-27 Thread Tor Bug Tracker & Wiki
#31660: Revise onboarding to take new Firefox experience into account
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.5,|  Actual Points:
  TorBrowserTeam202005, ReleaseTrainMigration|
Parent ID:  #33658   | Points:  4
 Reviewer:   |Sponsor:
 |  Sponsor58-can
-+-

Comment (by mcs):

 Replying to [comment:28 sysrqb]:
 > Ah, this follows on from brade's comment. That was exactly the way I'd
 do it (modulo testing :)), but we should give new users a link to the
 webpage, as well (somewhere). Are you suggesting we use this for users who
 update, and we have the additional tab for new users?

 Yes, I think that makes sense.

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


Re: [tor-bugs] #31660 [Applications/Tor Browser]: Revise onboarding to take new Firefox experience into account

2020-05-27 Thread Tor Bug Tracker & Wiki
#31660: Revise onboarding to take new Firefox experience into account
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.5,|  Actual Points:
  TorBrowserTeam202005, ReleaseTrainMigration|
Parent ID:  #33658   | Points:  4
 Reviewer:   |Sponsor:
 |  Sponsor58-can
-+-

Comment (by sysrqb):

 Replying to [comment:24 brade]:
 > The current onboarding code displays two different "tours" (sets of
 panels):
 >  * "newtour" for new users
 >  * "updatetour" for users who have upgraded
 >
 > Should we omit "What's New" from the "newtour" and only have it for
 "updatetour"?
 > It is easy to control this via the browser.onboarding.* preferences.
 >
 >

 For new users should we call it "Additional Features" or "See More"?
 Phrasing that indicates more information is available? Maybe we can use
 "More Information", and re-use the PageInfo string (but that's not exactly
 an ideal string for this use case).

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


Re: [tor-bugs] #31660 [Applications/Tor Browser]: Revise onboarding to take new Firefox experience into account

2020-05-27 Thread Tor Bug Tracker & Wiki
#31660: Revise onboarding to take new Firefox experience into account
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.5,|  Actual Points:
  TorBrowserTeam202005, ReleaseTrainMigration|
Parent ID:  #33658   | Points:  4
 Reviewer:   |Sponsor:
 |  Sponsor58-can
-+-

Comment (by sysrqb):

 Replying to [comment:26 mcs]:
 > Replying to [comment:25 mcs]:
 > > If you make the "See what's new in Tor Browser" button that is
 displayed on about:tor go directly to the web page then we would not need
 any new strings.  I am not sure how difficult that would be to implement
 though.
 >
 > Maybe it is as simple as doing something like this inside
 `handleClick()` (in Onboarding.jsm):
 > {{{
 > ...
 > case "onboarding-overlay-button":
 > ...
 > if (this._tourType === "update")
 >   this.sendMessageToChrome("tor-open-tab", {url: ...});
 > } else {
 >   this.showOverlay();
 >   this.gotoPage(this._firstUncompleteTour.id);
 > }
 > }}}
 >
 > Untested of course ;)

 Ah, this follows on from brade's comment. That was exactly the way I'd do
 it (modulo testing :)), but we should give new users a link to the
 webpage, as well (somewhere). Are you suggesting we use this for users who
 update, and we have the additional tab for new users?

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


Re: [tor-bugs] #31660 [Applications/Tor Browser]: Revise onboarding to take new Firefox experience into account

2020-05-27 Thread Tor Bug Tracker & Wiki
#31660: Revise onboarding to take new Firefox experience into account
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.5,|  Actual Points:
  TorBrowserTeam202005, ReleaseTrainMigration|
Parent ID:  #33658   | Points:  4
 Reviewer:   |Sponsor:
 |  Sponsor58-can
-+-

Comment (by mcs):

 Replying to [comment:25 mcs]:
 > If you make the "See what's new in Tor Browser" button that is displayed
 on about:tor go directly to the web page then we would not need any new
 strings.  I am not sure how difficult that would be to implement though.

 Maybe it is as simple as doing something like this inside `handleClick()`
 (in Onboarding.jsm):
 {{{
 ...
 case "onboarding-overlay-button":
 ...
 if (this._tourType === "update")
   this.sendMessageToChrome("tor-open-tab", {url: ...});
 } else {
   this.showOverlay();
   this.gotoPage(this._firstUncompleteTour.id);
 }
 }}}

 Untested of course ;)

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


Re: [tor-bugs] #31660 [Applications/Tor Browser]: Revise onboarding to take new Firefox experience into account

2020-05-27 Thread Tor Bug Tracker & Wiki
#31660: Revise onboarding to take new Firefox experience into account
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.5,|  Actual Points:
  TorBrowserTeam202005, ReleaseTrainMigration|
Parent ID:  #33658   | Points:  4
 Reviewer:   |Sponsor:
 |  Sponsor58-can
-+-

Comment (by sysrqb):

 Replying to [comment:25 mcs]:
 > Replying to [comment:23 sysrqb]:
 > > Replying to [comment:22 acat]:
 > > > Would it make it simpler to make "What's New" open the link to
 https://www.torproject.org/releases/tor-browser-95 directly? (without
 showing the "subview" on the right). It seems to me the last step of
 clicking `See What's New` is a bit redundant, and maybe we could save some
 design/strings.
 > >
 > > Oh! Nice idea! That will avoid adding many new strings, too. (We'll
 still need "What's New")
 >
 > If you make the "See what's new in Tor Browser" button that is displayed
 on about:tor go directly to the web page then we would not need any new
 strings.  I am not sure how difficult that would be to implement though.

 Hr. That would be relatively easy. In that case, we move all important
 onboarding information to the webpage.

 I'm a little torn right now because the onboarding experience provides a
 nice tutorial for new users. But we can sacrifice that aspect of
 onboarding for both 1) simplicity, and 2) we'll need to reimplement all of
 this for 78esr anyway.

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


Re: [tor-bugs] #31660 [Applications/Tor Browser]: Revise onboarding to take new Firefox experience into account

2020-05-27 Thread Tor Bug Tracker & Wiki
#31660: Revise onboarding to take new Firefox experience into account
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.5,|  Actual Points:
  TorBrowserTeam202005, ReleaseTrainMigration|
Parent ID:  #33658   | Points:  4
 Reviewer:   |Sponsor:
 |  Sponsor58-can
-+-

Comment (by mcs):

 Replying to [comment:23 sysrqb]:
 > Replying to [comment:22 acat]:
 > > Would it make it simpler to make "What's New" open the link to
 https://www.torproject.org/releases/tor-browser-95 directly? (without
 showing the "subview" on the right). It seems to me the last step of
 clicking `See What's New` is a bit redundant, and maybe we could save some
 design/strings.
 >
 > Oh! Nice idea! That will avoid adding many new strings, too. (We'll
 still need "What's New")

 If you make the "See what's new in Tor Browser" button that is displayed
 on about:tor go directly to the web page then we would not need any new
 strings.  I am not sure how difficult that would be to implement though.

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


Re: [tor-bugs] #28279 [Core Tor/Tor]: control: Add a key to GETINFO to fetch the circuit onion handshake rephist values

2020-05-27 Thread Tor Bug Tracker & Wiki
#28279: control: Add a key to GETINFO to fetch the circuit onion handshake 
rephist
values
---+--
 Reporter:  dgoulet|  Owner:  neel
 Type:  enhancement| Status:  assigned
 Priority:  Low|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-control, tor-spec  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by neel):

 * cc: neel (added)
 * owner:  (none) => neel
 * status:  new => assigned


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


Re: [tor-bugs] #31660 [Applications/Tor Browser]: Revise onboarding to take new Firefox experience into account

2020-05-27 Thread Tor Bug Tracker & Wiki
#31660: Revise onboarding to take new Firefox experience into account
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.5,|  Actual Points:
  TorBrowserTeam202005, ReleaseTrainMigration|
Parent ID:  #33658   | Points:  4
 Reviewer:   |Sponsor:
 |  Sponsor58-can
-+-

Comment (by brade):

 The current onboarding code displays two different "tours" (sets of
 panels):
  * "newtour" for new users
  * "updatetour" for users who have upgraded

 Should we omit "What's New" from the "newtour" and only have it for
 "updatetour"?
 It is easy to control this via the browser.onboarding.* preferences.

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


Re: [tor-bugs] #31660 [Applications/Tor Browser]: Revise onboarding to take new Firefox experience into account

2020-05-27 Thread Tor Bug Tracker & Wiki
#31660: Revise onboarding to take new Firefox experience into account
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.5,|  Actual Points:
  TorBrowserTeam202005, ReleaseTrainMigration|
Parent ID:  #33658   | Points:  4
 Reviewer:   |Sponsor:
 |  Sponsor58-can
-+-

Comment (by sysrqb):

 Replying to [comment:22 acat]:
 > Would it make it simpler to make "What's New" open the link to
 https://www.torproject.org/releases/tor-browser-95 directly? (without
 showing the "subview" on the right). It seems to me the last step of
 clicking `See What's New` is a bit redundant, and maybe we could save some
 design/strings.

 Oh! Nice idea! That will avoid adding many new strings, too. (We'll still
 need "What's New")

 I did find the subview as redundant, as well, but I decided to follow the
 same pattern as the other items. I'll create another patch with this
 behavior.

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


Re: [tor-bugs] #31660 [Applications/Tor Browser]: Revise onboarding to take new Firefox experience into account

2020-05-27 Thread Tor Bug Tracker & Wiki
#31660: Revise onboarding to take new Firefox experience into account
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.5,|  Actual Points:
  TorBrowserTeam202005, ReleaseTrainMigration|
Parent ID:  #33658   | Points:  4
 Reviewer:   |Sponsor:
 |  Sponsor58-can
-+-

Comment (by acat):

 Would it make it simpler to make "What's New" open the link to
 https://www.torproject.org/releases/tor-browser-95 directly? (without
 showing the "subview" on the right). It seems to me the last step of
 clicking `See What's New` is a bit redundant, and maybe we could save some
 design/strings.

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


Re: [tor-bugs] #34311 [Core Tor/Tor]: Space out code in relay.c

2020-05-27 Thread Tor Bug Tracker & Wiki
#34311: Space out code in relay.c
--+--
 Reporter:  neel  |  Owner:  neel
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by neel):

 * status:  assigned => 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] #34174 [Internal Services/Tor Sysadmin Team]: Update majus errors recipient

2020-05-27 Thread Tor Bug Tracker & Wiki
#34174: Update majus errors recipient
-+-
 Reporter:  antonela |  Owner:  anarcat
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Replying to [comment:6 anarcat]:
 > done. i recommend you somehow simulate a failure to make sure you still
 receive notifications. I can also try to see if we can do that straight
 from nagios if you prefer.

 Thanks anarcat. Instead of simulating a failure we (accidentally) broke
 the system instead (and triggered alerts from nagios). Long(er) story,
 short, now we know the nagios alerts are reaching the new mailing list.

 {{{
 Subject: [translation-admin] ** PROBLEM Service Alert: majus/translation
 cron - stuck is CRITICAL **
 Subject: [translation-admin] ** RECOVERY Service Alert: majus/translation
 cron - stuck is OK **
 }}}

 I think we are done here.

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


Re: [tor-bugs] #32802 [Internal Services/Tor Sysadmin Team]: retire kvm4, 8 VMs to migrate

2020-05-27 Thread Tor Bug Tracker & Wiki
#32802: retire kvm4, 8 VMs to migrate
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  project  | Status:
 |  merge_ready
 Priority:  High |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major| Resolution:
 Keywords:  tpa-roadmap-may  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 hum, okay... it failed with an error, and when i tried to open a new
 script to test, everything collapse in a flaming heap. now the server
 doesn't respond to pings, so hopefully it's really dead now.

 tomorrow hetzner should retire it completely and this will be done.

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


Re: [tor-bugs] #33577 [Applications/Tor Browser]: Picture-in-Picture not working with dom.w3c_pointer_events.enabled=false

2020-05-27 Thread Tor Bug Tracker & Wiki
#33577: Picture-in-Picture not working with dom.w3c_pointer_events.enabled=false
--+
 Reporter:  acat  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff78-esr  |  Actual Points:
Parent ID:  #33533| Points:
 Reviewer:|Sponsor:  Sponsor58-must
--+
Changes (by acat):

 * keywords:   => ff78-esr


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


Re: [tor-bugs] #33737 [Applications/Tor Browser]: Fix aboutDialog.js error for Firefox nightlies

2020-05-27 Thread Tor Bug Tracker & Wiki
#33737: Fix aboutDialog.js error for Firefox nightlies
---+---
 Reporter:  acat   |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam202004 ff78-esr  |  Actual Points:
Parent ID:  #33533 | Points:
 Reviewer: |Sponsor:  Sponsor58-can
---+---
Changes (by acat):

 * keywords:  TorBrowserTeam202004 => TorBrowserTeam202004 ff78-esr


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


Re: [tor-bugs] #33697 [Applications/Tor Browser]: Investigate new Search Engine configuration

2020-05-27 Thread Tor Bug Tracker & Wiki
#33697: Investigate new Search Engine configuration
---+---
 Reporter:  acat   |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam202004 ff78-esr  |  Actual Points:
Parent ID:  #33533 | Points:
 Reviewer: |Sponsor:
   |  Sponsor58-must
---+---
Changes (by acat):

 * keywords:  TorBrowserTeam202004 => TorBrowserTeam202004 ff78-esr


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


Re: [tor-bugs] #33734 [Applications/Tor Browser]: Consider setting MOZ_NORMANDY=False

2020-05-27 Thread Tor Bug Tracker & Wiki
#33734: Consider setting MOZ_NORMANDY=False
---+---
 Reporter:  acat   |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam202004 ff78-esr  |  Actual Points:
Parent ID:  #33533 | Points:
 Reviewer: |Sponsor:  Sponsor58-can
---+---
Changes (by acat):

 * keywords:  TorBrowserTeam202004 => TorBrowserTeam202004 ff78-esr


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


Re: [tor-bugs] #31660 [Applications/Tor Browser]: Revise onboarding to take new Firefox experience into account

2020-05-27 Thread Tor Bug Tracker & Wiki
#31660: Revise onboarding to take new Firefox experience into account
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.5,|  Actual Points:
  TorBrowserTeam202005, ReleaseTrainMigration|
Parent ID:  #33658   | Points:  4
 Reviewer:   |Sponsor:
 |  Sponsor58-can
-+-
Changes (by sysrqb):

 * status:  new => needs_review


Comment:

 Replying to [comment:20 sysrqb]:
 > 1) Is the current design/UX a good idea?
 > 2) We have very little time for getting strings translated. What strings
 should we use?

 3) I re-used/repurposed an image from the original Onboarding experience
 for this new entry. It mostly fits, but I don't know if we have a better
 graphic available.

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


Re: [tor-bugs] #31660 [Applications/Tor Browser]: Revise onboarding to take new Firefox experience into account

2020-05-27 Thread Tor Bug Tracker & Wiki
#31660: Revise onboarding to take new Firefox experience into account
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.5,|  Actual Points:
  TorBrowserTeam202005, ReleaseTrainMigration|
Parent ID:  #33658   | Points:  4
 Reviewer:   |Sponsor:
 |  Sponsor58-can
-+-

Comment (by sysrqb):

 We should have something included in the 9.5 release onboarding for the
 new features. Antonela and I decided we can have one new entry named
 "What's New" (following Mozilla's new onboarding experience). This entry
 simply has a link to a webpage where new features are described.

 The webpage is currently being developed at
 https://www.torproject.org/releases/tor-browser-95/

 I have a Linux testbuild at
 https://people.torproject.org/~sysrqb/bug31660/ and I'm building a macOS X
 testbuild now (should be ready in ~2 hours).

 1) Is the current design/UX a good idea?
 2) We have very little time for getting strings translated. What strings
 should we use?

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


Re: [tor-bugs] #31660 [Applications/Tor Browser]: Revise onboarding to take new Firefox experience into account

2020-05-27 Thread Tor Bug Tracker & Wiki
#31660: Revise onboarding to take new Firefox experience into account
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.5,|  Actual Points:
  TorBrowserTeam202005, ReleaseTrainMigration|
Parent ID:  #33658   | Points:  4
 Reviewer:   |Sponsor:
 |  Sponsor58-can
-+-
Changes (by sysrqb):

 * Attachment "bug31660_00_whats-new.png" added.

 What's New

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


Re: [tor-bugs] #32802 [Internal Services/Tor Sysadmin Team]: retire kvm4, 8 VMs to migrate

2020-05-27 Thread Tor Bug Tracker & Wiki
#32802: retire kvm4, 8 VMs to migrate
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  project  | Status:
 |  merge_ready
 Priority:  High |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major| Resolution:
 Keywords:  tpa-roadmap-may  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 hum. the first wipe didn't automatically exit, so it probably got hung
 there for a few hours. i hit "enter" and it started the second round. eta
 45 minutes to apocalypse.

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


Re: [tor-bugs] #34264 [Circumvention/Snowflake]: Discussion on using a library for HTTP requests.

2020-05-27 Thread Tor Bug Tracker & Wiki
#34264: Discussion on using a library for HTTP requests.
-+-
 Reporter:  HashikD  |  Owner:  (none)
 Type:  task | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-mobile |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by HashikD):

 Added Retrofit library at commit id :
 8c4725e5ad1db9a43d5b3a380a0bb0e59ddba267
 [https://github.com/Hashik-Donthineni/Snowflake-Mobile/commits/master
 Github Mirror]

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


Re: [tor-bugs] #34307 [Circumvention/Snowflake]: RxJava library for making asynchronous calls.

2020-05-27 Thread Tor Bug Tracker & Wiki
#34307: RxJava library for making asynchronous calls.
-+-
 Reporter:  HashikD  |  Owner:  (none)
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-mobile |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by HashikD):

 Added RxJava library at commit id :
 733e5f3d2a7b677be91dc2db43343a7fd7bf5f32

 [https://github.com/Hashik-Donthineni/Snowflake-Mobile Github Mirror]

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


Re: [tor-bugs] #33617 [Core Tor/Tor]: Add a BandwidthStatistics option and consensus parameter

2020-05-27 Thread Tor Bug Tracker & Wiki
#33617: Add a BandwidthStatistics option and consensus parameter
-+-
 Reporter:  teor |  Owner:
 |  MrSquanchee
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  extra-review, prop313, ipv6, |  Actual Points:
  outreachy-ipv6, network-team-roadmap-2020Q1|
Parent ID:  #33052   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  Sponsor55-can
-+-
Changes (by asn):

 * status:  needs_review => needs_revision


Comment:

 Sorry for the late review here.

 The code looks good, but I'm wondering that there is no unittest for this
 functionality. In particularly, I'm refering to
 `rep_hist_bw_stats_write()` and its position in
 `wep_hist_bw_stats_write()`. I think we need a unittest that tests the
 latter function and makes sure that `rep_hist_bw_stats_write()` will be
 called (or not be called) based on the consensus/torrc parameter, and that
 when it's called it does the right thing.

 Please let me know if you need help designing this unittest.

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


Re: [tor-bugs] #33458 [Core Tor/Tor]: Assertion desc failed in hs_client_close_intro_circuits_from_desc at src/feature/hs/hs_client.c: 2413

2020-05-27 Thread Tor Bug Tracker & Wiki
#33458: Assertion desc failed in hs_client_close_intro_circuits_from_desc at
src/feature/hs/hs_client.c: 2413
-+-
 Reporter:  asn  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  reopened
 Priority:  High |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs client-auth assert  043-must  |  Actual Points:  0.3
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by asn):

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


Comment:

 Hm, perhaps that was not merged to 043.

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


Re: [tor-bugs] #24844 [Core Tor/Tor]: Add HS v3 status to the SIGUSR1 dumpstats()

2020-05-27 Thread Tor Bug Tracker & Wiki
#24844: Add HS v3 status to the SIGUSR1 dumpstats()
-+-
 Reporter:  dgoulet  |  Owner:  neel
 Type:  enhancement  | Status:  closed
 Priority:  Low  |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, 034-triage-20180328, |  Actual Points:
  034-removed-20180328   |
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by asn):

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


Comment:

 Merged. 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] #34303 [Metrics/Onionperf]: Find out why onion service measurements have gotten slower

2020-05-27 Thread Tor Bug Tracker & Wiki
#34303: Find out why onion service measurements have gotten slower
---+
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor59-must
---+

Comment (by dgoulet):

 Ok so in theory, we are not running into #29427 with KIST _off_. Lets see
 what OnionPerf old version says. If we are still seeing this difference,
 we'll likely require deeper analysis of `tor` between 029 and 035 in those
 contexts...

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


Re: [tor-bugs] #34303 [Metrics/Onionperf]: Find out why onion service measurements have gotten slower

2020-05-27 Thread Tor Bug Tracker & Wiki
#34303: Find out why onion service measurements have gotten slower
---+
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor59-must
---+

Comment (by acute):

 Yes, luckily I had not deleted the disk yet. The existing version of
 Onionperf is now running on that machine.

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


Re: [tor-bugs] #34303 [Metrics/Onionperf]: Find out why onion service measurements have gotten slower

2020-05-27 Thread Tor Bug Tracker & Wiki
#34303: Find out why onion service measurements have gotten slower
---+
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor59-must
---+

Comment (by karsten):

 Replying to [comment:10 karsten]:
 > Replying to [comment:9 acute]:
 > > I can't think of any changes to Onionperf that would have had this
 effect, but I could fire up the op-ab VM at the University, which still
 runs Tor 0.2.9, and run the latest Onionperf for the day - what do you
 think?
 >
 > Oh, you still have that instance? Yes, please! That's the best way
 forward. Thanks!

 I should have been clearer: Please turn it back on without making any
 changes and let it run for a few days, with the exact same Tor version and
 OnionPerf version. 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] #34303 [Metrics/Onionperf]: Find out why onion service measurements have gotten slower

2020-05-27 Thread Tor Bug Tracker & Wiki
#34303: Find out why onion service measurements have gotten slower
---+
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor59-must
---+

Comment (by karsten):

 Replying to [comment:9 acute]:
 > I can't think of any changes to Onionperf that would have had this
 effect, but I could fire up the op-ab VM at the University, which still
 runs Tor 0.2.9, and run the latest Onionperf for the day - what do you
 think?

 Oh, you still have that instance? Yes, please! That's the best way
 forward. 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] #34303 [Metrics/Onionperf]: Find out why onion service measurements have gotten slower

2020-05-27 Thread Tor Bug Tracker & Wiki
#34303: Find out why onion service measurements have gotten slower
---+
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor59-must
---+

Comment (by acute):

 Replying to [comment:8 karsten]:
 > I should also say that the new instances that we set up four weeks ago
 are running a much newer OnionPerf branch than the old instances which we
 had not updated for a long time. I'll also look into setting up an
 OnionPerf instance running the OnionPerf code from ~1 year ago.
 >
 > acute, do you have any intuitions whether one of the changes from the
 past year or so would have caused onion service measurements getting this
 slow while at the same time producing very comparable public service
 measurements?

 I can't think of any changes to Onionperf that would have had this effect,
 but I could fire up the op-ab VM at the University, which still runs Tor
 0.2.9, and run the latest Onionperf for the day - what do you think?

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


Re: [tor-bugs] #34305 [Applications/Tor Browser]: NoScript inconsistent behaviour in Firefox 77 (currently beta)

2020-05-27 Thread Tor Bug Tracker & Wiki
#34305: NoScript inconsistent behaviour in Firefox 77 (currently beta)
-+-
 Reporter:  acat |  Owner:  acat
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  noscript TorBrowserTeam202005,   |  Actual Points:
  ff78-esr   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by acat):

 * status:  needs_information => new


Comment:

 Thanks! I think the response was actually pretty fast :)

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


Re: [tor-bugs] #34303 [Metrics/Onionperf]: Find out why onion service measurements have gotten slower

2020-05-27 Thread Tor Bug Tracker & Wiki
#34303: Find out why onion service measurements have gotten slower
---+
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor59-must
---+

Comment (by karsten):

 I should also say that the new instances that we set up four weeks ago are
 running a much newer OnionPerf branch than the old instances which we had
 not updated for a long time. I'll also look into setting up an OnionPerf
 instance running the OnionPerf code from ~1 year ago.

 acute, do you have any intuitions whether one of the changes from the past
 year or so would have caused onion service measurements getting this slow
 while at the same time producing very comparable public service
 measurements?

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


Re: [tor-bugs] #34303 [Metrics/Onionperf]: Find out why onion service measurements have gotten slower

2020-05-27 Thread Tor Bug Tracker & Wiki
#34303: Find out why onion service measurements have gotten slower
---+
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor59-must
---+

Comment (by karsten):

 Replying to [comment:6 arma]:
 > In the graph above, it looks like the "before" and "after" overlap for a
 bit of time, at the end of April? So how come the old measurements are
 fast, and the new measurements are slow, even when they're done at the
 same time?

 Exactly, that's the question. The Tor '''network''' was the same, yet the
 old and new instances produced vastly different results.

 So, first results from `"Schedulers Vanilla"` are that this setting does
 not affect measurements at all:

 [[Image(onionperf-2020-05-27.png, 700px)]]

 Some observations:

  - The blue line is from the old `op-hk` instance from early April. It
 didn't run anymore towards the end of April, but judging from the graph
 above we would expect its performance to stay the same. Note that it shows
 time to first byte, not time to 50 KiB, though the difference is probably
 minor.

  - The orange line is from the new `op-hk2` instance from yesterday.

  - The green line is from the newly setup Hong Kong instance with the
 `"Schedulers Vanilla"` setting. I'm 90% certain that I did not mess up
 setting that option. There's no easy way to check, because we're not
 writing out the `torrc` file to disk but feeding it into the `tor`
 processes via stdin. However, when I first tried it, I passed `"Schedulers
 Vanilla"` without newline, and it complained about `"VanillaRunAsDaemon"`
 not being a valid scheduler option, and it stopped complaining after I
 passed `"Schedulers Vanilla\n"`. So, it might have worked. The results are
 equally bad as in the orange line.

  - Note that I made this graph using yet unmerged OnionPerf branches. The
 TTFB definition in this graph is the same as in the other graphs above.

 I'll try older Tor versions today. The `op-hk` instance was running,
 *ahem*, 0.2.9, whereas the new instances are running 0.3.5. I'll see what
 versions between those two I get compiled and running, and I might also
 try newer 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] #34303 [Metrics/Onionperf]: Find out why onion service measurements have gotten slower

2020-05-27 Thread Tor Bug Tracker & Wiki
#34303: Find out why onion service measurements have gotten slower
---+
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor59-must
---+
Changes (by karsten):

 * Attachment "onionperf-2020-05-27.png" added.


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