Re: [tor-bugs] #28765 [Applications/Tor Browser]: LibEvent Build for Android

[Tor Bug Tracker & Wiki]

#28765: LibEvent Build for Android
-+-
 Reporter:  sisbell  |  Owner:  sisbell
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, tbb-parity, |  Actual Points:
  TorBrowserTeam202002   |
Parent ID:  #28704   | Points:  0.25
 Reviewer:  sysrqb, boklm|Sponsor:
-+-

Comment (by sisbell):

 Replying to [comment:12 sysrqb]:


 > Replying to [ticket:28704#comment:23 sisbell]:
 >
 > > Other issues:
 > >
 > > 1. There was a suggestion to move some of the fields in configure_opt
 up to rbm.  OpenSSL doesn't use the same configure_host value as other
 projects so this will require some more discussion if we want to move
 forward with this suggestion.
 > > 1. Information regarding libevent --disable-libevent-regress--disable-
 samples. I need to look back through my notes. I'll post in a follow up
 comment.
 > >
 >
 > From ticket:28704#comment:26, do including these change the size of the
 resulting library? I'd rather disable these for all platforms in a
 separate ticket.

 The tar files themselves are a few bytes off (looks to be due to timestamp
 differences on files). But after unarchiving, the following directories
 all have the same size

  * libevent --disable-libevent-regress --disable-samples
  * libevent --disable-libevent-regress
  * libevent --disable-samples
  * libevent

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 (was: Deploy a Turbo Tunnel–aware Snowflake bridge)

[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: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. 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.

 The keepalive issue is [https://github.com/lucas-clemente/quic-
 go/issues/2200 fixed in a newer version of quic-go] (2019-11-10):
 > Currently, we're sending a keep-alive-PING after half the idle-timeout
 period. This doesn't work well for long idle timeouts, if we need to keep
 a NAT binding alive. We should send a PING after `min(30s, idle timeout /
 2)`.
 The [https://github.com/lucas-clemente/quic-
 go/commit/bd94f21ab091e4e3403869faa43605db457d5e0d actual commit] uses
 20s, not 30s, which is low enough to inhibit checkForStaleness as long as
 the connection is actually working.

 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).

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

Re: [tor-bugs] #33081 [Internal Services/Tor Sysadmin Team]: new gnt-fsn node (fsn-node-04)

[Tor Bug Tracker & Wiki]

#33081: new gnt-fsn node (fsn-node-04)
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:  closed
 Priority:  High |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tpa-roadmap-february |  Actual Points:
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 the result of the rebalancing:

 {{{
 Node   DTotal  DFree MTotal MNode MFree Pinst Sinst
 fsn-node-01.torproject.org 893.1G 570.6G  62.8G 13.5G 48.8G 513
 fsn-node-02.torproject.org 893.1G 638.6G  62.8G 17.1G 45.3G 514
 fsn-node-03.torproject.org 893.6G 628.7G  62.8G 14.1G 48.1G 412
 fsn-node-04.torproject.org 893.6G 578.9G  62.8G 22.4G 39.7G 412
 }}}

 real nice.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #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  |Version:
  Tor/Tor |
 Severity:  Normal|   Keywords:  ipv6, prop311, tor-bridge, chutney
Actual Points:|  Parent ID:  #33232
   Points:  1 |   Reviewer:
  Sponsor:|
  Sponsor55-can   |
--+
 Chutney bridge authorities don't have any bridges in their networkstatus-
 bridges. That's a problem, because we want to check networkstatus-bridges
 for the reachability checks in #33232.

 Here are some alternative fixes:
 * fix bugs in tor or chutney that stop bridges posting their descriptors
 to the bridge authority
 * fix bugs in tor or chutney that stop the bridge authority writing
 bridges to the networkstatus (maybe it doesn't respect AssumeReachable?)
 * grep the bridge's logs for its reachability tests

 If we end up fixing tor, chutney will need to know which tor versions have
 these fixes (otherwise old branches will fail CI). So we may need some
 kind of environmental variable, tag, or version update.

 We don't have to do these fixes, because it should be enough to test relay
 reachability. But we would risk breaking bridge reachability tests, and
 not knowing about it until after a release.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33408 [Core Tor/Tor]: Make tor versions sortable, by adding the commit number to EXTRA_INFO

[Tor Bug Tracker & Wiki]

#33408: Make tor versions sortable, by adding the commit number to EXTRA_INFO
---+-
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal |   Keywords:  prop311, needs-version-spec
Actual Points: |  Parent ID:  #33232
   Points:  0.2|   Reviewer:
  Sponsor:  Sponsor55-can  |
---+-
 In #30899, sbws starts using the PEP 440 sortable version scheme:
 {{{
 The version previous to this commit was 1.1.1-dev0, after
 this commit, it becomes 1.1.0+xx.g, ie. xx commits after
 1.1.0 plus the git short hash ().
 }}}

 PEP440 is specified here:
 https://www.python.org/dev/peps/pep-0440/

 We should do something similar in tor, so that we can sort all tor
 versions lexically, even unreleased versions.

 The current format is:
 {{{
 MAJOR.MINOR.MICRO[.PATCHLEVEL][-STATUS_TAG][ (EXTRA_INFO)]*
 }}}

 EXTRA_INFO is currently:
 {{{
 git rev-parse --short=16 HEAD
 }}}

 But we could use:
 {{{
 git describe --tags --dirty --broken --always --match "tor-*"
 }}}

 Possibly with some post-processing. We should also add a prefix that sorts
 after any versions in the previous format. (The prefix will only matter
 for 0.4.4.0-alpha-dev.)

 Here's the relevant part of the current version spec:
 https://gitweb.torproject.org/torspec.git/tree/version-spec.txt#n22

 Or we could just use python-versioneer to generate a version script for
 tor:
 https://github.com/warner/python-versioneer

 We might need this change for Sponsor 55, so that chutney knows which
 unreleased tor versions have bridge authority fixes (see #33407)

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

Re: [tor-bugs] #33219 [Circumvention/Censorship analysis]: Tor in China (Android) stops at 5%

[Tor Bug Tracker & Wiki]

#33219: Tor in China (Android) stops at 5%
---+---
 Reporter:  TiC|  Owner:  (none)
 Type:  defect | Status:
   |  needs_information
 Priority:  Medium |  Milestone:
Component:  Circumvention/Censorship analysis  |Version:
 Severity:  Normal | Resolution:
 Keywords:  cn |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by sigvids):

 Re the slowdown -- In early February, Redditors in China reported general
 slowness and international packet loss with VPNs. This was not specific to
 Tor.

 
https://www.reddit.com/r/China/comments/f03s6z/question_to_those_still_in_china_how_have_your/

 
https://www.reddit.com/r/dumbclub/comments/ezvdqf/how_are_everyones_speeds_doing_lately/

 Re the requested bridges -- is this the same as #30767 Custom obfs4 bridge
 does not work on Tor Browser for Android?

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

Re: [tor-bugs] #32992 [Applications/Tor Browser]: TBB Project for LZMA

[Tor Bug Tracker & Wiki]

#32992: TBB Project for LZMA
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, tbb-parity, |  Actual Points:
  TorBrowserTeam202002   |
Parent ID:  #28704   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 As far as I can tell, it does have a signed tag but I'm unable to verify
 it with rbm build

 From git project for xz

 {{{
 $ git tag -v v5.2.4
 object b5be61cc06088bb07f488f9baf7d447ff47b37c1
 type commit
 tag v5.2.4
 tagger Lasse Collin  1525017879 +0300

 XZ Utils 5.2.4
 gpg: Signature made Sun 29 Apr 2018 09:04:44 AM PDT
 gpg:using RSA key 3690C240CE51B4670D30AD1C38EE757D69184620
 gpg:issuer "lasse.col...@tukaani.org"
 gpg: Good signature from "Lasse Collin "
 [unknown]
 gpg: WARNING: This key is not certified with a trusted signature!
 gpg:  There is no indication that the signature belongs to the
 owner.
 Primary key fingerprint: 3690 C240 CE51 B467 0D30  AD1C 38EE 757D 6918
 4620
 }}}

 I add the following to xz/config

 {{{
 version: 5.2.4
 git_url: https://git.tukaani.org/xz.git
 git_hash: 'v[% c("version") %]'
 tag_gpg_id: 1
 gpg_keyring: xz.gpg
 filename: '[% project %]-[% c("version") %]-[% c("var/osname") %]-[%
 c("var/build_id") %].tar.gz'
 }}}

 The xz.gpg file has the key

 {{{
 ./xz.gpg
 
 pub   rsa4096 2010-10-24 [SC] [expires: 2020-12-22]
   3690C240CE51B4670D30AD1C38EE757D69184620
 uid   [ unknown] Lasse Collin 
 sub   rsa4096 2010-10-24 [E] [expires: 2020-12-22]
 }}}

 And then building the project, I get an error

 {{{
 Error: v5.2.4 is not a signed tag
 }}}

 Any ideas on what is going wrong?

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

Re: [tor-bugs] #32991 [Applications/Tor Browser]: TBB Project For ZSTD

[Tor Bug Tracker & Wiki]

#32991: TBB Project For ZSTD
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, tbb-parity, |  Actual Points:
  TorBrowserTeam202002   |
Parent ID:  #28704   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 Replying to [comment:8 sysrqb]:
 > This is based on commit 191e603664aa5eba0ae670a48af1cb6501248372 from
 ticket:28704#comment:23.
 >
 > {{{
 > +git_hash: 'v[% c("version") %]'
 > }}}
 > Does Facebook sign their git tags for zstd? If not, then we should use
 the git commit hash instead.

 No zstd does not have a signed tag (but does have a signed commit)

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

Re: [tor-bugs] #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):

 note that this may very well mean just removing tsa-misc/reboot-host and
 tsa-misc/reboot-guest, and documenting the multi-tool better. :)

 i just tried `./torproject-reboot-rotation` and ``./torproject-reboot-
 simple` and the unattended operation isn't great... it fires up all those
 reboots, and doesn't show clearly what it did. for example, it seems to
 have queued reboots on a bunch of hosts, but it doesn't say which.

 after further inspection (with `cumin '*' 'screen -ls | grep reboot-
 job'`), i have found it has scheduled reboots on

 * static-master-fsn.torproject.org
 * cdn-backend-sunet-01.torproject.org
 * web-fsn-01.torproject.org
 * onionoo-frontend-01.torproject.org
 * orestis.torproject.org
 * nutans.torproject.org
 * chives.torproject.org
 * onionbalance-01.torproject.org
 * listera.torproject.org
 * peninsulare.torproject.org

 Most of those are okay and should return unattended. But in some cases,
 those could have been covered by a libvirt reboot (i had performed those
 before, in this case, so non were). Eventually though, that point is moot
 because we'll all be running under ganeti and will separate host and guest
 reboot procedures.

 one host is problematic in there (chives) as it needs a specific warning
 to users. maybe chives should be taken out of "justdoit" rotation...

 i also wonder, in general, if we should warn users about those reboots, as
 part of the reboot script.

 then i don't know which hosts are left to do manually, but i guess that,
 with time, nagios will let us know. it would be nice to have a scenario
 for those 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] #33081 [Internal Services/Tor Sysadmin Team]: new gnt-fsn node (fsn-node-04)

[Tor Bug Tracker & Wiki]

#33081: new gnt-fsn node (fsn-node-04)
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:  closed
 Priority:  High |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tpa-roadmap-february |  Actual Points:
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 i started a cluster rebalance after the node was online. this was the
 situation before:

 {{{
 root@fsn-node-01:~# gnt-node list
 Node   DTotal  DFree MTotal MNode MFree Pinst Sinst
 fsn-node-01.torproject.org 893.1G 465.9G  62.8G 31.2G 31.0G 818
 fsn-node-02.torproject.org 893.1G 473.4G  62.8G 18.9G 43.5G 533
 fsn-node-03.torproject.org 893.6G 676.9G  62.8G 16.1G 46.1G 5 0
 fsn-node-04.torproject.org 893.6G 800.8G  62.8G  131M 62.1G 0 0
 }}}

 it's going to take all night, but it's going to be interesting to see
 where nodes end 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] #31957 [Internal Services/Tor Sysadmin Team]: automate upgrades

[Tor Bug Tracker & Wiki]

#31957: automate upgrades
-+-
 Reporter:  anarcat  |  Owner:  hiro
 Type:  project  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tpa-roadmap-february |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Old description:

> upgrades take up a significant chunk of time every week and distract
> sysadmins (or at least me) from focusing on other projects.
>
> upgrades should be therefore automated, as much as possible.
>
> see also #31239 about upgrades and this is part of the wider "ops card
> questionnaire", where we answered no to a question about this, see
> #30881.
>
> checklist:
>
> * [x] install needrestart everywhere, in interactive mode
> * [x] switch needrestart to automatic mode
> * [ ] install unattended-upgrades everywhere
> * [ ] fix major upgrades docs to disable unattended-upgrades during the
> upgrade run

New description:

 upgrades take up a significant chunk of time every week and distract
 sysadmins (or at least me) from focusing on other projects.

 upgrades should be therefore automated, as much as possible.

 see also #31239 about auomated installs and this is part of the wider "ops
 card questionnaire", where we answered no to a question about this, see
 #30881.

 checklist:

 * [x] install needrestart everywhere, in interactive mode
 * [x] switch needrestart to automatic mode
 * [ ] install unattended-upgrades everywhere
 * [ ] fix major upgrades docs to disable unattended-upgrades during the
 upgrade run
 * ~~[ ] automate reboots~~ see #33406 instead

--

Comment (by anarcat):

 move automated reboots to another ticket, #33406

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #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   |Version:
  Team   |   Keywords:  tpa-
 Severity:  Major|  roadmap-march
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 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.

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

Re: [tor-bugs] #31957 [Internal Services/Tor Sysadmin Team]: automate upgrades

[Tor Bug Tracker & Wiki]

#31957: automate upgrades
-+-
 Reporter:  anarcat  |  Owner:  hiro
 Type:  project  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tpa-roadmap-february |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 before we close this ticket, we should consider automated reboots as well,
 either as a new ticket, or by documenting the procedure to automate
 reboots now.

 at least the process is not clear to me at all right now: it's taking a
 long time and it's error-prone.

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

Re: [tor-bugs] #32173 [Applications/Tor Browser]: Update signing infrastructure to work with Apple's notarization process

[Tor Bug Tracker & Wiki]

#32173: Update signing infrastructure to work with Apple's notarization process
-+-
 Reporter:  gk   |  Owner:  boklm
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-sign, TorBrowserTeam202002,  |  Actual Points:  1
  ReleaseTrainMigration  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 I synced the current signing scripts to the machine. I'll try playing
 around with this during the 9.5a6 signing dance (next week).

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

Re: [tor-bugs] #32173 [Applications/Tor Browser]: Update signing infrastructure to work with Apple's notarization process

[Tor Bug Tracker & Wiki]

#32173: Update signing infrastructure to work with Apple's notarization process
-+-
 Reporter:  gk   |  Owner:  sysrqb
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-sign, TorBrowserTeam202002,  |  Actual Points:  1
  ReleaseTrainMigration  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

 * owner:  boklm => sysrqb


Comment:

 I'll take this for now.

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

Re: [tor-bugs] #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:
-+

Comment (by cypherpunks):

 Link to the same issue on uMatrix bug tracker:
 https://github.com/uBlockOrigin/uMatrix-issues/issues/224

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

Re: [tor-bugs] #33364 [Circumvention/Snowflake]: Could not connect to the bridge.

[Tor Bug Tracker & Wiki]

#33364: Could not connect to the bridge.
-+
 Reporter:  cypherpunks  |  Owner:  cohosh
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cypherpunks):

 Ticket created: #33405

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

Re: [tor-bugs] #33365 [Circumvention/Snowflake]: Probe Snowflake bridge from proxy 1x a day

[Tor Bug Tracker & Wiki]

#33365: Probe Snowflake bridge from proxy 1x a day
-+---
 Reporter:  cohosh   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  webextension |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+---

Comment (by cypherpunks):

 Can there also be a counter as to how many users have been helped through
 this extension? I have never seen a user connected to mine, so the number
 might as well be zero, for all I know.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 sysrqb):

 * component:  - Select a component => Circumvention/Snowflake


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33405 [- Select a component]: 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   |  Component:  - Select a component
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 Error in Snowflake debug console, caused by a line in vapi-background.js
 in uMatrix:

 {{{Unchecked lastError value: Error: First-Party Isolation is enabled, but
 the required 'firstPartyDomain' attribute was not set.}}}

 The uMatrix setting causing this error is:

 {{{Spoof HTTP referrer string of third-party requests}}}, when set to
 true.

 This is a bug either in Snowflake, or uMatrix.

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

Re: [tor-bugs] #23719 [Applications/Tor Browser]: Make sure WebExtensions are spared from JIT disabling in higher security settings (Medium-High)

[Tor Bug Tracker & Wiki]

#23719: Make sure WebExtensions are spared from JIT disabling in higher security
settings (Medium-High)
-+-
 Reporter:  cypherpunks  |  Owner:  acat
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-performance, |  Actual Points:  0.5
  TorBrowserTeam202002, tbb-9.5a7-want   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

 * keywords:  tbb-performance, GeorgKoppen201911, TorBrowserTeam202002 =>
 tbb-performance, TorBrowserTeam202002, tbb-9.5a7-want


Comment:

 [https://bugzilla.mozilla.org/show_bug.cgi?id=1599226 1599226] landed. We
 can think about backporting this for 9.5a7. I doubt it'll be clean, but
 hopefully we won't hit too many conflicts.

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

Re: [tor-bugs] #31130 [Applications/Tor Browser]: Use Debian 10 for our Android container images

[Tor Bug Tracker & Wiki]

#31130: Use Debian 10 for our Android container images
-+-
 Reporter:  gk   |  Owner:  sisbell
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-rbm, TorBrowserTeam202002R,  |  Actual Points:  1
  ReleaseTrainMigration  |
Parent ID:  #31127   | Points:  0.5
 Reviewer:  gk   |Sponsor:
-+-
Changes (by sysrqb):

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


Comment:

 Thanks! Merged onto master with commit
 `3f341196fba76654999faa42139c5fa46882b527`. I built android-x86_64 twice
 and their hashes matched (as expected), and building linux-x86_64 wasn't
 affected by this patch (as 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] #33081 [Internal Services/Tor Sysadmin Team]: new gnt-fsn node (fsn-node-04)

[Tor Bug Tracker & Wiki]

#33081: new gnt-fsn node (fsn-node-04)
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:  closed
 Priority:  High |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tpa-roadmap-february |  Actual Points:
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

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


Comment:

 fsn-node-04 now 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] #31686 [Internal Services/Tor Sysadmin Team]: retire textile

[Tor Bug Tracker & Wiki]

#31686: retire textile
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  project  | Status:  closed
 Priority:  High |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 i'll note that textile is gone from the robot control panel, which
 confirms its final retirement.

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

Re: [tor-bugs] #33317 [Internal Services/Service - trac]: Add new sponsor 59 to trac

[Tor Bug Tracker & Wiki]

#33317: Add new sponsor 59 to trac
--+
 Reporter:  gaba  |  Owner:  qbi
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by qbi):

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


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

Re: [tor-bugs] #33342 [Applications/Tor Browser]: Disconnect search addon causes error at startup

[Tor Bug Tracker & Wiki]

#33342: Disconnect search addon causes error at startup
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202002  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Thorin):

 FWIW: except for the path and timestamp, on Windows I get the same error
 as gk

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

Re: [tor-bugs] #31239 [Internal Services/Tor Sysadmin Team]: automate installs

[Tor Bug Tracker & Wiki]

#31239: automate installs
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tpa-roadmap-february |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 removed another 4 steps from the common trunk, we're now at 9 steps there,
 which are fairly streamlined and can't be trimmed further without changing
 the design (ie. we need orchestration).

 we're now at this state:

  * new-machine (common trunk): 9 steps
  * new-machine-hetzner-robot: +12 steps (21 total), many of which can be
 merged into hooks next time
  * new-machine-hetzner-cloud: unchanged

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

Re: [tor-bugs] #32914 [Internal Services/Tor Sysadmin Team]: review the puppet bootstrapping process

[Tor Bug Tracker & Wiki]

#32914: review the puppet bootstrapping process
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Minor| Resolution:  fixed
 Keywords:  tpa-roadmap-february |  Actual Points:
Parent ID:  #31239   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

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


Comment:

 tying up loose ends here:

 > that is *mostly* the case with the caveat that we do "--waitforcert" on
 the client which might hang the installer for two minutes of the operator
 doesn't approve the certificate fast enough.

 this works in the bootstrap at least. we might not want to do that in the
 automated systems, but at least the --waitforcert is compatible with
 --test, which i was worried about.

 > i believe i have fixed that by masking the puppet service before
 installing the package, but this requires testing.

 i confirm this works.

 > i am wondering if we should simply skip the "puppet agent -t; ud-
 replicate" stage on the instance... this will eventually converge anyways,
 no?

 i added this as part of the client bootstrap script.

 >  another thing we should check is whether we can hook step 5 in the
 puppet bootstrap (because that's probably why it's there, otherwise it's
 something puppet could do itself):

 I moved this to the hetzner-robot installer and made it a requirement.

 > steps 7 (nevii) and 9 (do more puppet runs) should probably be removed
 on next run.

 done: i confirm that nevii figures it out eventually and step 9 was folded
 in bootstrap.

 i think we're done here. eventually the puppet bootstrap can be merged
 back into the one big installer, but for now it can't as long as we stick
 with the "shell script on server" design.

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

Re: [tor-bugs] #28871 [Metrics/Onionoo]: Relay with 6 weeks downtime only has 6_months and 5_years bandwidth graphs

[Tor Bug Tracker & Wiki]

#28871: Relay with 6 weeks downtime only has 6_months and 5_years bandwidth 
graphs
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

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


Comment:

 Merged, released, and deployed. Closing. 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] #27981 [Metrics/Onionoo]: 3 days young relay is not shown in 1-month graph, but in 6-month graph

[Tor Bug Tracker & Wiki]

#27981: 3 days young relay is not shown in 1-month graph, but in 6-month graph
-+--
 Reporter:  toralf   |  Owner:  metrics-team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

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


Comment:

 Merged, released, and deployed. Closing. 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] #32720 [Core Tor/Tor]: How much bandwidth does a user use to bootstrap and maintain dir info? How has that changed over time?

[Tor Bug Tracker & Wiki]

#32720: How much bandwidth does a user use to bootstrap and maintain dir info? 
How
has that changed over time?
--+
 Reporter:  arma  |  Owner:  nickm
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  prop312-can   |  Actual Points:
Parent ID:  #33049| Points:
 Reviewer:|Sponsor:  Sponsor55-can
--+
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 Travis is passing now.  The appveyor error seems to be referring to a
 version of the code, which has me confused about what appveyor thinks it's
 doing.

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

Re: [tor-bugs] #30899 [Core Tor/sbws]: Include the commit hash in the sbws version

[Tor Bug Tracker & Wiki]

#30899: Include the commit hash in the sbws version
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Major  | Resolution:
 Keywords:  sbws-roadmap   |  Actual Points:
Parent ID: | Points:  1
 Reviewer:  ahf|Sponsor:
---+---
Changes (by juga):

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


Comment:

 https://github.com/torproject/sbws/pull/370
 (i already saw some typos after creating the PR, but well, if the code is
 fine i can fix them afterwards)

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

Re: [tor-bugs] #33384 [Webpages/Support]: Create entry in support.torproject.org for Onion-Location automatic redirects.

[Tor Bug Tracker & Wiki]

#33384: Create entry in support.torproject.org for Onion-Location automatic
redirects.
--+---
 Reporter:  acat  |  Owner:  hiro
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Support  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #21952| Points:
 Reviewer:|Sponsor:  Sponsor27
--+---

Comment (by acat):

 For stable there are no plans yet, for alpha according to
 https://pad.riseup.net/p/tor-browser-release-meeting-keep, not before
 2020.03.10.

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

Re: [tor-bugs] #33377 [Internal Services/Tor Sysadmin Team]: Create email alias to core contributor Narrira (nah)

[Tor Bug Tracker & Wiki]

#33377: Create email alias to core contributor Narrira (nah)
-+
 Reporter:  ggus |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by anarcat):

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


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

Re: [tor-bugs] #33377 [Internal Services/Tor Sysadmin Team]: Create email alias to core contributor Narrira (nah)

[Tor Bug Tracker & Wiki]

#33377: Create email alias to core contributor Narrira (nah)
-+-
 Reporter:  ggus |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 done in commit d251a50d

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33404 [Webpages]: 'No video with supported format and MIME type found.'

[Tor Bug Tracker & Wiki]

#33404: 'No video with supported format and MIME type found.'
+--
 Reporter:  Azali   |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  Webpages
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 Hi i use torbrowser android 9.0.5
 I get a warning when I watch a video
 'No video with supported format and MIME type found.'
 My android: 9
 Plz fix this bug

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

Re: [tor-bugs] #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:
|  needs_review
 Priority:  Medium  |  Milestone:
Component:  Core Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  documentation, tor-client, manpage  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  catalyst, nickm |Sponsor:
+--

Comment (by swati):

 Replying to [comment:5 catalyst]:
 > Replying to [comment:4 nickm]:
 > > It looks like asciidoc on travis is giving these errors:
 > > {{{
 > > asciidoc: ERROR: tor.1.txt: line 14: name section expected
 > > asciidoc: FAILED: tor.1.txt: line 14: section title expected
 > > }}}
 > >
 > > Anything we can do about that?
 >
 > It looks like asciidoc wants a blank line before the `== NAME` section
 header.  I can make that change along with adding a changes file.

 Thanks for doing this, catalyst.

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

Re: [tor-bugs] #33398 [Core Tor/Tor]: Remove documentation for `--dump-config non-builtin` and deprecate it

[Tor Bug Tracker & Wiki]

#33398: Remove documentation for `--dump-config non-builtin` and deprecate it
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  043-can 043-backport  |  Actual Points:
Parent ID:| Points:  .1
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 >  Is there any way the crash can be triggered by another combination of
 options?

 I am pretty sure not.  That's the only place in the code where
 OPTIONS_DUMP_DEFAULTS is used.

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

Re: [tor-bugs] #31180 [Core Tor/Tor]: Remove easy deprecated options in 0.4.4

[Tor Bug Tracker & Wiki]

#31180: Remove easy deprecated options in 0.4.4
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  043-can   |  Actual Points:  .1
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:11 nickm]:
 > I don't think I've got the brainpower to remove
 `ClientPreferIPv6DirPort` right now, and I think we've missed the window
 where it's sensible to try this for 0.4.3.  Let's review what we've got in
 0.4.4, and maybe open a ticket for removing some more deprecated options
 if possible.

 I agree, it probably needs to happen early in 0.4.4. Or at the very least,
 before we do the IPv6 client work in proposal 306.

 Maybe coccinelle could help reduce the workload?
 We could get an initial patch by replacing
 options->ClientPreferIPv6DirPort with 0, and then removing {{{|| 0}}} and
 similar redundant constructs.

 As a second step, we can then simplify or rewrite a bunch of functions,
 but that doesn't need to happen straight away.

 (And now that clients only use ORPorts, their reachability decisions are
 between one IPv4 ORPort, and up to one IPv6 ORPort, which is a lot
 simpler. But that could be a third ticket.)

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

Re: [tor-bugs] #31180 [Core Tor/Tor]: Remove easy deprecated options in 0.4.4

[Tor Bug Tracker & Wiki]

#31180: Remove easy deprecated options in 0.4.4
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  043-can   |  Actual Points:  .1
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 It looks like my fix is wrong: it has chutney failing, which should not
 have happened for this patch. I need to review this much more closely.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
|  needs_review
 Priority:  Medium  |  Milestone:
Component:  Core Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  documentation, tor-client, manpage  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  catalyst, nickm |Sponsor:
+--

Comment (by catalyst):

 Replying to [comment:4 nickm]:
 > It looks like asciidoc on travis is giving these errors:
 > {{{
 > asciidoc: ERROR: tor.1.txt: line 14: name section expected
 > asciidoc: FAILED: tor.1.txt: line 14: section title expected
 > }}}
 >
 > Anything we can do about that?

 It looks like asciidoc wants a blank line before the `== NAME` section
 header.  I can make that change along with adding a changes file.

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

Re: [tor-bugs] #33398 [Core Tor/Tor]: Remove documentation for `--dump-config non-builtin` and deprecate it

[Tor Bug Tracker & Wiki]

#33398: Remove documentation for `--dump-config non-builtin` and deprecate it
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  043-can 043-backport  |  Actual Points:
Parent ID:| Points:  .1
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Seems like a good idea to me,

 Is there any way the crash can be triggered by another combination of
 options?
 (Not including --dump-config non-builtin)

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

Re: [tor-bugs] #33374 [Core Tor/Tor]: Fix unicode warnings in practracker using python 2

[Tor Bug Tracker & Wiki]

#33374: Fix unicode warnings in practracker using python 2
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.3.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  043-backport, consider-backport- |  Actual Points:  0.1
  immediately|
Parent ID:   | Points:  0.1
 Reviewer:  ahf  |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:8 ahf]:
 > Looks good. Didn't know of the `codecs` module, but it looks like it
 behaves similar on Python 3 and 2.

 And it seems to have a very similar interface to python3's open().

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

Re: [tor-bugs] #32910 [Core Tor/Tor]: trace: Add tracepoints and userspace tracer support

[Tor Bug Tracker & Wiki]

#32910: trace: Add tracepoints and userspace tracer support
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tracing   |  Actual Points:
Parent ID:| Points:  3
 Reviewer:  nickm |Sponsor:
--+

Comment (by teor):

 Just to be clear here:
 * it's totally ethical for researchers to use tracing to profile behaviour
 of their own tor clients (for example, path building, or timing behaviour)
 * it is unethical for anyone to release raw, detailed tracing data of
 other users' activity
 * for most things researchers want, PrivCount or another privacy-
 preserving system is their best bet

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

Re: [tor-bugs] #32122 [Core Tor/Tor]: Add tests for the git scripts

[Tor Bug Tracker & Wiki]

#32122: Add tests for the git scripts
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  git-scripts   |  Actual Points:
Parent ID:  #32121| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 There's a detailed test plan here:
 https://trac.torproject.org/projects/tor/ticket/32121#comment:7

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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]: Deploy a Turbo Tunnel–aware Snowflake bridge

[Tor Bug Tracker & Wiki]

#6: Deploy a Turbo Tunnel–aware Snowflake bridge
-+--
 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):

 My observations from running the quic and kcp browsers more or less
 continuously since yesterday.

  * The experience is still pretty hit or miss. Sometimes you get a good
 proxy and cruise on it for a while; other times you get delays of several
 minutes caused by a series of non-working proxies—not slow proxies, but
 ones that never send any downstream data at all. I don't know why so many
 proxies should be broken in this way; for me it must be over 50% of them.
  * I got to the point of continuously tailing both snowflake-client logs
 to get some insight into what was happening.
  * The worst is when a series of bad proxies causes a delay of a few
 minutes with no data transfer; in that case tor gets into a "No running
 bridges" bridges state that it is hard to coax out of. When this happens
 it's not evident in the snowflake-client log; you have to go to
 about:preferences#tor and look at the tor log. It may look like this:
{{{
 [NOTICE] We tried for 15 seconds to connect to '[scrubbed]' using exit
 $3F50D11DE55C028B8F3EFC272BB1CD9138C1F9A4~0x616e6f6e at 178.17.171.78.
 Retrying on a new circuit.
 [NOTICE] We tried for 15 seconds to connect to '[scrubbed]' using exit
 $3F50D11DE55C028B8F3EFC272BB1CD9138C1F9A4~0x616e6f6e at 178.17.171.78.
 Retrying on a new circuit.
 [NOTICE] Delaying directory fetches: No running bridges
 [NOTICE] Application request when we haven't received a consensus with
 exits. Optimistically trying known bridges again.
 [NOTICE] Delaying directory fetches: No running bridges
 [NOTICE] Application request when we haven't received a consensus with
 exits. Optimistically trying known bridges again.
 [NOTICE] Delaying directory fetches: No running bridges
 [NOTICE] Application request when we haven't received a consensus with
 exits. Optimistically trying known bridges again.
}}}
Or this:
{{{
 [NOTICE] We tried for 15 seconds to connect to '[scrubbed]' using exit
 $6B062B0FDFEAC3C6F9203FB9584451E295574DAD~idideditTheconfig at
 51.15.37.97. Retrying on a new circuit.
 [NOTICE] We tried for 15 seconds to connect to '[scrubbed]' using exit
 $7761DDC7EB1BE26D4155F74A15F12C32A36FE0F2~CalyxInstitute09 at
 162.247.74.217. Retrying on a new circuit.
 [NOTICE] Delaying directory fetches: No running bridges
 [NOTICE] Application request when we haven't received a consensus with
 exits. Optimistically trying known bridges again.
}}}
When this happens, I usually have luck in going to
 about:preferences#tor, momentarily switching from snowflake to obfs4, then
 switching back to snowflake. This restarts the snowflake-client process
 and seems to cause tor to have a fresh look at its bridges.
  * I'm not noticing a ton of subjective difference in the feel of the two
 browsers. The main difference I have seen is that the quic one
 occasionally spends a few minutes at 100% CPU: #33401.
  * 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.

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

Re: [tor-bugs] #32121 [Core Tor/Tor]: Refactor some common configs and functions out of the git scripts.

[Tor Bug Tracker & Wiki]

#32121: Refactor some common configs and functions out of the git scripts.
-+
 Reporter:  teor |  Owner:  nickm
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  git-scripts, 044-should  |  Actual Points:  .5
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+

Comment (by teor):

 I'd like to do some backports and test branches with this code, and then
 we can merge.

 We can do the tests in #32122.

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

Re: [tor-bugs] #26578 [Core Tor/Tor]: Do clients request new consensus documents more often than we expect?

[Tor Bug Tracker & Wiki]

#26578: Do clients request new consensus documents more often than we expect?
---+--
 Reporter:  arma   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  040-deferred-20190220  |  Actual Points:
Parent ID:  #32720 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by teor):

 Replying to [comment:9 irl]:
 > Seperate from the load question, is there something obvious we can do to
 improve the metrics we have?

 Run the branch in #32720, as a client, with dormancy off, and see how many
 consensuses tor downloads each day?
 Run 0.3.5 and master (or 0.4.2, if that's easier).

 After the first few hours, you should see a stable rate of consensus
 downloads. Then you can average the consensus downloads per day, and
 update the metrics estimates for consensus downloads per day.

 (I think the branch splits out consensus downloads separate to
 descriptors, but we should check.)

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

Re: [tor-bugs] #7349 [Core Tor/Tor]: Obfsbridges should be able to "disable" their ORPort

[Tor Bug Tracker & Wiki]

#7349: Obfsbridges should be able to "disable" their ORPort
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  project  | Status:  new
 Priority:  Very High|  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge, SponsorZ, tor-pt,|  Actual Points:
  proposal-needed, censorship, sponsor19, 040|
  -roadmap-proposed, anti-censorship-roadmap |
Parent ID:   | Points:  10
 Reviewer:   |Sponsor:
 |  Sponsor28-can
-+-

Comment (by teor):

 Replying to [comment:50 dfiguera]:
 > > Is it an inbound or outbound firewall?
 > The rule to filter the ORPort was applied to ingress.
 > The bridge has permission to open outbound connections to any address.
 >
 > > Bridges need to accept inbound connections to their ORPort from the
 bridge authority (for its
 > > reachability checks), and from other relays (for the bridge's ORPort
 reachability self-treats),
 > > and from clients. (So any address on the Internet.)
 > A client using a bridge needs to connect to that bridge's ORPort and not
 only to the PT port?

 It depends. I think obfs4 bridges are only distributed by BridgeDB as
 obfs4, and not plain bridges.

 > I was trying to make my bridge a little less vulnerable to detection.
 > Thanks for the clarification, I'll keep an eye on tickets related to
 this to see the progress.

 You'll need to allow at least the bridge authority and most relays to
 connect to your ORPort, for the various reachability checks.

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

Re: [tor-bugs] #31011 [Core Tor/Tor]: Make the bridge authority reject private PT addresses when DirAllowPrivateAddresses is 0

[Tor Bug Tracker & Wiki]

#31011: Make the bridge authority reject private PT addresses when
DirAllowPrivateAddresses is 0
--+
 Reporter:  teor  |  Owner:  cjb
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-pt|  Actual Points:
Parent ID:  #31009| Points:  1
 Reviewer:  ahf   |Sponsor:  Sponsor28-can
--+

Comment (by teor):

 Good question!

 It looks like extrainfo documents aren't really parsed by tor right now.
 Instead, they're parsed by BridgeDB and metrics.

 Here's how you can change that:
 1. Add the server transport line to the token table at:
 
https://github.com/torproject/tor/blob/4f02812242d1fd90d859eb98ac3fb1ed182f18cf/src/feature/dirparse/routerparse.c#L127
 2. Add a server transport line variable to the extrainfo struct at:
 
https://github.com/torproject/tor/blob/4f02812242d1fd90d859eb98ac3fb1ed182f18cf/src/feature/nodelist/extrainfo_st.h#L18
 3. Parse the server transport line when tor parses the extrainfo:
 
https://github.com/torproject/tor/blob/4f02812242d1fd90d859eb98ac3fb1ed182f18cf/src/feature/dirparse/routerparse.c#L960
 4. Free the new string when an extrainfo struct is freed.

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

Re: [tor-bugs] #30992 [Core Tor/Tor]: circpadding machines have shutdown sync issues (with intro circ NACKs and other cases)

[Tor Bug Tracker & Wiki]

#30992: circpadding machines have shutdown sync issues (with intro circ NACKs 
and
other cases)
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad circpad-researchers-maybe-   |  Actual Points:
  want 043-should|
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-

Comment (by mikeperry):

 Thanks for the reminder. #32040 seems like it could exacerbate the
 shutdown/restart problem, but I think is a slightly different cause than
 this.

 If we end up needing to bump the padding protocol version, we should fix
 both issues at once. I will have to spend some time pondering what we can
 do with the existing protocol. There may also be a subtle way to fix both
 and still preserve compatibility with relays without bumping padding
 protocol versions on them. We should consider as many of these kinds of
 issues in that analysis.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33403 [Applications/Tor Browser]: Add nightly mar key to tor-browser

[Tor Bug Tracker & Wiki]

#33403: Add nightly mar key to tor-browser
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-rbm, tbb-update,
 Severity:  Normal   |  TorBrowserTeam202002
Actual Points:   |  Parent ID:  #18867
   Points:  .1   |   Reviewer:
  Sponsor:   |
-+-
 In #31988 I created a mar signing key for nightly builds. We should add it
 to tor-browser nightly builds.

 It seems the path used by nightly build is
 `toolkit/mozapps/update/updater/nightly_aurora_level3_primary.der` (and
 `nightly_aurora_level3_secondary.der`).

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

Re: [tor-bugs] #32720 [Core Tor/Tor]: How much bandwidth does a user use to bootstrap and maintain dir info? How has that changed over time?

[Tor Bug Tracker & Wiki]

#32720: How much bandwidth does a user use to bootstrap and maintain dir info? 
How
has that changed over time?
--+
 Reporter:  arma  |  Owner:  nickm
 Type:  task  | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  prop312-can   |  Actual Points:
Parent ID:  #33049| Points:
 Reviewer:|Sponsor:  Sponsor55-can
--+

Comment (by nickm):

 I have the tests passing and safelogging respected.  I'll put this in
 needs_review once CI passes.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33402 [Applications/Tor Browser]: Set app.update.url for nightly builds

[Tor Bug Tracker & Wiki]

#33402: Set app.update.url for nightly builds
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-rbm, tbb-update,
 Severity:  Normal   |  TorBrowserTeam202002
Actual Points:   |  Parent ID:  #18867
   Points:  .1   |   Reviewer:
  Sponsor:   |
-+-
 We won't use the same `app.update.url` for releases and nightly builds. So
 we need to change this pref in the nightly builds.

 https://nightlies.tbb.torproject.org/nightly-updates/updates/ is where the
 updates xml for nightly builds are located.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 dcf):

 I've done some profiling locally and I now think that the high CPU use in
 the quic snowflake-client has nothing to do with the high CPU use in
 proxy-go. I created a separate ticket #33401.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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 "profile001.png" added.

 CPU profile graph

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #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   |   Keywords:  turbotunnel
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 As originally noted at comment:7:ticket:33211, the quic-go turbotunnel
 client sometimes uses 100+% CPU for a few minutes before returning to
 normal operation. It is specific to the quic-go implementation; it doesn't
 happen with the kcp-go implementation nor the non-turbotunnel client.

 As best I can figure, the cause has something to do with timers created
 under `(*session) maybeResetTimer`.

 attachment:profile001.png

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

Re: [tor-bugs] #30992 [Core Tor/Tor]: circpadding machines have shutdown sync issues (with intro circ NACKs and other cases)

[Tor Bug Tracker & Wiki]

#30992: circpadding machines have shutdown sync issues (with intro circ NACKs 
and
other cases)
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad circpad-researchers-maybe-   |  Actual Points:
  want 043-should|
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Could it be related to the erroneous behavior of #32040?

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

Re: [tor-bugs] #30992 [Core Tor/Tor]: circpadding machines have shutdown sync issues (with intro circ NACKs and other cases)

[Tor Bug Tracker & Wiki]

#30992: circpadding machines have shutdown sync issues (with intro circ NACKs 
and
other cases)
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad circpad-researchers-maybe-   |  Actual Points:
  want 043-should|
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-

Comment (by mikeperry):

 I suspect #33354, #33352, and #32140 are all related to the root cause of
 this bug. Still digging.

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

Re: [tor-bugs] #32800 [Internal Services/Tor Sysadmin Team]: Creating some space to host Tor Browser nightly updates

[Tor Bug Tracker & Wiki]

#32800: Creating some space to host Tor Browser nightly updates
-+
 Reporter:  boklm|  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-update, TorBrowserTeam202002 |  Actual Points:
Parent ID:  #18867   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by boklm):

 Replying to [comment:11 boklm]:
 > Should I be using `/usr/share/doc/rsync/scripts/rrsync` instead, or is
 there something else?

 So I used `/usr/share/doc/rsync/scripts/rrsync`, by copying it as
 `/home/boklm/tbb-nightlies/rrsync`, and it seems to be working.

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

Re: [tor-bugs] #33291 [Core Tor/Tor]: Making the tor library size smaller

[Tor Bug Tracker & Wiki]

#33291: Making the tor library size smaller
--+
 Reporter:  gaba  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-size network-team-roadmap-2020Q1  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gaba):

 * cc: dgoulet, ahf (added)
 * keywords:  tor-size => tor-size network-team-roadmap-2020Q1


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

Re: [tor-bugs] #23545 [Applications/Tor Browser]: UX improvement: Tor Browser should handle bogus HSv3 addresses

[Tor Bug Tracker & Wiki]

#23545: UX improvement: Tor Browser should handle bogus HSv3 addresses
-+-
 Reporter:  asn  |  Owner:  brade
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224, ux-team,|  Actual Points:
  034-triage-20180328,   |
  034-removed-20180328,TorBrowserTeam202002  |
Parent ID:  #30022   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by mcs):

 * keywords:  tor-hs, prop224, ux-team, 034-triage-20180328,
 034-removed-20180328 =>
 tor-hs, prop224, ux-team, 034-triage-20180328,
 034-removed-20180328,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

Re: [tor-bugs] #33400 [Core Tor/Tor]: hs-v3: Log why we can't upload a descriptor

[Tor Bug Tracker & Wiki]

#33400: hs-v3: Log why we can't upload a descriptor
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:  0.2
Parent ID:| Points:  0.2
 Reviewer:  asn   |Sponsor:
--+
Changes (by dgoulet):

 * status:  assigned => needs_review


Comment:

 PR: https://github.com/torproject/tor/pull/1760
 Branch: `ticket33400_044_01`

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33400 [Core Tor/Tor]: hs-v3: Log why we can't upload a descriptor

[Tor Bug Tracker & Wiki]

#33400: hs-v3: Log why we can't upload a descriptor
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-hs
Actual Points:  0.2   |  Parent ID:
   Points:  0.2   |   Reviewer:  asn
  Sponsor:|
--+
 We still have report of services that stop working and the logs suggest
 they simply stopped uploading their descriptors.

 We need to know why and thus add logging. TIcket #24346 had an attempt at
 it but it was abandoned. I'm reviving the logging part due to still
 getting reports of the issue.

 Logging the reason is tricky due to the rate and multiple descriptor
 object.

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

Re: [tor-bugs] #31180 [Core Tor/Tor]: Remove easy deprecated options in 0.4.4

[Tor Bug Tracker & Wiki]

#31180: Remove easy deprecated options in 0.4.4
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  043-can   |  Actual Points:  .1
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Oh. But travis is still failing. :p

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

Re: [tor-bugs] #31180 [Core Tor/Tor]: Remove easy deprecated options in 0.4.4 (was: Remove deprecated options in 0.4.3.)

[Tor Bug Tracker & Wiki]

#31180: Remove easy deprecated options in 0.4.4
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  043-can   |  Actual Points:  .1
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_revision => needs_review
 * milestone:  Tor: 0.4.3.x-final => Tor: 0.4.4.x-final


Comment:

 I don't think I've got the brainpower to remove `ClientPreferIPv6DirPort`
 right now, and I think we've missed the window where it's sensible to try
 this for 0.4.3.  Let's review what we've got in 0.4.4, and maybe open a
 ticket for removing some more deprecated options if possible.

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

Re: [tor-bugs] #33398 [Core Tor/Tor]: Remove documentation for `--dump-config non-builtin` and deprecate it

[Tor Bug Tracker & Wiki]

#33398: Remove documentation for `--dump-config non-builtin` and deprecate it
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  043-can 043-backport  |  Actual Points:
Parent ID:| Points:  .1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * keywords:  043-can => 043-can 043-backport
 * cc: ahf, teor (added)
 * points:   => .1
 * milestone:  Tor: 0.4.3.x-final => Tor: 0.4.4.x-final


Comment:

 Investigating, it seems that non-builtin is indeed slightly different from
 short... but only very very slightly.  Here is a command line that gives
 different results with `non-builtin` and `short`:

 {{{
 ./src/app/tor  --dump-config short testingtornetwork 1 dirauthority
 '1.2.3.4:99 abcdabcdabcdabcdabcdabcdabcdabcdabcdabcd '
 extendallowprivateaddresses 0`
 }}}

 With "Short", it gives a reasonable output.  With non-builtin, it crashes.

 Removing the silent-logs code from dump-config, I see that the crash is:
 {{{
 Feb 20 11:02:39.823 [err] config_dump(): Bug: Failed to validate default
 config: TestingV3AuthInitialVotingInterval may only be changed in testing
 Tor networks! (on Tor 0.4.4.0-alpha-dev 7ba7f9c0de9d1b24)
 Feb 20 11:02:39.823 [err] tor_assertion_failed_(): Bug:
 src/lib/confmgt/confmgt.c:1337: config_dump: Assertion 0 failed; aborting.
 (on Tor 0.4.4.0-alpha-dev 7ba7f9c0de9d1b24)
 Feb 20 11:02:39.823 [err] Bug: Tor 0.4.4.0-alpha-dev (git-
 7ba7f9c0de9d1b24): Assertion 0 failed in config_dump at
 src/lib/confmgt/confmgt.c:1337: . Stack trace: (on Tor 0.4.4.0-alpha-dev
 7ba7f9c0de9d1b24)
 Feb 20 11:02:39.823 [err] Bug: ./src/app/tor(log_backtrace_impl+0x31)
 [0x6d3661] (on Tor 0.4.4.0-alpha-dev 7ba7f9c0de9d1b24)
 Feb 20 11:02:39.823 [err] Bug:
 ./src/app/tor(tor_assertion_failed_+0x1b0) [0x6cec3a] (on Tor 0.4.4.0
 -alpha-dev 7ba7f9c0de9d1b24)
 Feb 20 11:02:39.823 [err] Bug: ./src/app/tor(config_dump+0x133)
 [0x6a85e7] (on Tor 0.4.4.0-alpha-dev 7ba7f9c0de9d1b24)
 Feb 20 11:02:39.823 [err] Bug: ./src/app/tor(options_dump+0xab)
 [0x57f955] (on Tor 0.4.4.0-alpha-dev 7ba7f9c0de9d1b24)
 Feb 20 11:02:39.823 [err] Bug: ./src/app/tor() [0x44d4e9] (on Tor
 0.4.4.0-alpha-dev 7ba7f9c0de9d1b24)
 Feb 20 11:02:39.823 [err] Bug: ./src/app/tor(tor_run_main+0x25c)
 [0x44f086] (on Tor 0.4.4.0-alpha-dev 7ba7f9c0de9d1b24)
 Feb 20 11:02:39.823 [err] Bug: ./src/app/tor(tor_main+0x66) [0x44c127]
 (on Tor 0.4.4.0-alpha-dev 7ba7f9c0de9d1b24)
 Feb 20 11:02:39.823 [err] Bug: ./src/app/tor(main+0x20) [0x44be26] (on
 Tor 0.4.4.0-alpha-dev 7ba7f9c0de9d1b24)
 Feb 20 11:02:39.823 [err] Bug:
 /lib64/libc.so.6(__libc_start_main+0xf3) [0x7f2134c7b1a3] (on Tor 0.4.4.0
 -alpha-dev 7ba7f9c0de9d1b24)
 Feb 20 11:02:39.823 [err] Bug: ./src/app/tor(_start+0x2e) [0x44bd4e]
 (on Tor 0.4.4.0-alpha-dev 7ba7f9c0de9d1b24)
 Aborted (core dumped)
 }}}

 This crash behavior has existed since at least 0.3.5.  On 0.2.9, I get a
 different output, but the difference is still not terribly useful.

 I see two options here:
   * Fix `non-builtin`.
   * Deprecate `non-builtin`.

 I favor the option of deprecating non-builtin: nobody has actually run
 into this crash in the last several years, which means that the
 distinction between non-builtin and short is not actually doing us any
 good.

 Adding ahf and teor to this ticket, since they commented on the previous
 --dump-config ticket.

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

Re: [tor-bugs] #33342 [Applications/Tor Browser]: Disconnect search addon causes error at startup

[Tor Bug Tracker & Wiki]

#33342: Disconnect search addon causes error at startup
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202002  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 FWIW, I get something like
 {{{
 1582213850508   addons.xpi  WARNException running bootstrap method
 startup on disconn...@search.mozilla.org: Error: Error while loading
 'jar:file:///home/thomas/Arbeit/Tor/tor-browser-build/tor-browser_sv-
 SE/Browser/browser/omni.ja!/chrome/browser/search-
 extensions/disconnect/manifest.json'
 (NS_ERROR_FILE_NOT_FOUND)(resource://gre/modules/Extension.jsm:513:20) JS
 Stack trace: readJSON/https://trac.torproject.org/projects/tor/ticket/33342#comment:1>
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #32467 [Core Tor/Tor]: Document tor's --dump-config command in the man page

[Tor Bug Tracker & Wiki]

#32467: Document tor's --dump-config command in the man page
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  042-backport-maybe, consider-|  implemented
  backport-immediately, 043-can  |  Actual Points:  0
Parent ID:  #29211   | Points:  0.1
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 I've opened #33398 to address the situation with `non-builtin`

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33399 [Metrics/Onionperf]: Measure static guard nodes with OnionPerf

[Tor Bug Tracker & Wiki]

#33399: Measure static guard nodes with OnionPerf
---+--
 Reporter:  acute  |  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #33325
   Points:  4  |   Reviewer:
  Sponsor: |
---+--
 The specifications for measuring this are as follows:

 - OP should measure one guard or set of guards at a time. It could use
 NumEntryGuards in the torrc file to support more than 1 guard
 - A new guard/set of guards must be chosen after a day of measurement
 - All CBT data must be erased when choosing a new set of guards, after day
 of measurements (at UTC midnight). This could mean erasing or replacing
 the state file for CBT.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33398 [Core Tor/Tor]: Remove documentation for `--dump-config non-builtin` and deprecate it

[Tor Bug Tracker & Wiki]

#33398: Remove documentation for `--dump-config non-builtin` and deprecate it
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  043-can
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 As teor finds in #32467, it is apparently just the same as "short".

 I should confirm that, and act accordingly.

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

Re: [tor-bugs] #33374 [Core Tor/Tor]: Fix unicode warnings in practracker using python 2

[Tor Bug Tracker & Wiki]

#33374: Fix unicode warnings in practracker using python 2
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.3.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  043-backport, consider-backport- |  Actual Points:  0.1
  immediately|
Parent ID:   | Points:  0.1
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by nickm):

 * status:  merge_ready => closed
 * resolution:   => fixed
 * milestone:  Tor: 0.4.4.x-final => Tor: 0.4.3.x-final


Comment:

 Merged to 0.4.3 and forward.

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

Re: [tor-bugs] #33389 [Core Tor/Tor]: Disable routerkeys.c and part of connection_or.c when building without relay mode.

[Tor Bug Tracker & Wiki]

#33389: Disable routerkeys.c and part of connection_or.c when building without
relay mode.
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-design, network-team-roadmap-|  implemented
  2020Q1, 043-deferred   |  Actual Points:  .2
Parent ID:  #31851   | Points:
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 squashed and merged 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] #4631 [Core Tor/Tor]: Idea to make consensus voting more resistant

[Tor Bug Tracker & Wiki]

#4631: Idea to make consensus voting more resistant
-+-
 Reporter:  Sebastian|  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-dirauth-email needs-torspec-   |  implemented
  update tor-dirauth robustness voting   |  Actual Points:  0.2
Parent ID:  #33050   | Points:  0.5
 Reviewer:  nickm|Sponsor:
 |  Sponsor55-can
-+-
Changes (by nickm):

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


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

Re: [tor-bugs] #33396 [Metrics/Onionperf]: Automatically compress Onionperf logs

[Tor Bug Tracker & Wiki]

#33396: Automatically compress Onionperf logs
-+--
 Reporter:  acute|  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionperf|Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-team-roadmap-2020Q1  |  Actual Points:
Parent ID:  #33319   | Points:  1
 Reviewer:   |Sponsor:
-+--
Changes (by gaba):

 * keywords:   => metrics-team-roadmap-2020Q1


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

Re: [tor-bugs] #33395 [Metrics/Onionperf]: Add option to replace the client and server torrc files

[Tor Bug Tracker & Wiki]

#33395: Add option to replace the client and server torrc files
-+--
 Reporter:  acute|  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionperf|Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-team-roadmap-2020Q1  |  Actual Points:  1
Parent ID:  #33319   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by gaba):

 * keywords:   => metrics-team-roadmap-2020Q1


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

Re: [tor-bugs] #33394 [Metrics/Cloud]: Automatically build Onionperf documentation from Git

[Tor Bug Tracker & Wiki]

#33394: Automatically build Onionperf documentation from Git
-+--
 Reporter:  acute|  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Cloud|Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-team-roadmap-2020Q1  |  Actual Points:
Parent ID:  #33321   | Points:  1
 Reviewer:   |Sponsor:
-+--
Changes (by gaba):

 * keywords:   => metrics-team-roadmap-2020Q1


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

Re: [tor-bugs] #33397 [Metrics/Website]: Update metrics-web to only plot "official" data

[Tor Bug Tracker & Wiki]

#33397: Update metrics-web to only plot "official" data
-+--
 Reporter:  acute|  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-team-roadmap-2020Q1  |  Actual Points:
Parent ID:  #33323   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by gaba):

 * keywords:   => metrics-team-roadmap-2020Q1


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

Re: [tor-bugs] #33392 [Metrics/Onionperf]: Add new metadata fields to json output

[Tor Bug Tracker & Wiki]

#33392: Add new metadata fields to json output
-+--
 Reporter:  acute|  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionperf|Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-team-roadmap-2020Q1  |  Actual Points:
Parent ID:  #33323   | Points:  0.5
 Reviewer:   |Sponsor:
-+--
Changes (by gaba):

 * keywords:   => metrics-team-roadmap-2020Q1


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

Re: [tor-bugs] #33393 [Metrics/Onionperf]: Add new metadata fields to tpf output.

[Tor Bug Tracker & Wiki]

#33393: Add new metadata fields to tpf output.
-+--
 Reporter:  acute|  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionperf|Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-team-roadmap-2020Q1  |  Actual Points:
Parent ID:  #33323   | Points:  0.5
 Reviewer:   |Sponsor:
-+--
Changes (by gaba):

 * keywords:   => metrics-team-roadmap-2020Q1


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

Re: [tor-bugs] #30798 [Metrics/Onionperf]: Develop and deploy tgen model resembling ping

[Tor Bug Tracker & Wiki]

#30798: Develop and deploy tgen model resembling ping
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  reopened
 Priority:  High |  Milestone:
Component:  Metrics/Onionperf|Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-team-roadmap-2020Q1  |  Actual Points:
Parent ID:  #33324   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by gaba):

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


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

Re: [tor-bugs] #30798 [Metrics/Onionperf]: Develop and deploy tgen model resembling ping

[Tor Bug Tracker & Wiki]

#30798: Develop and deploy tgen model resembling ping
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:
Component:  Metrics/Onionperf|Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:  metrics-team-roadmap-2020Q1  |  Actual Points:
Parent ID:  #33324   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by gaba):

 * keywords:   => metrics-team-roadmap-2020Q1
 * parent:   => #33324


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

Re: [tor-bugs] #33392 [Metrics/Onionperf]: Add new metadata fields to json output

[Tor Bug Tracker & Wiki]

#33392: Add new metadata fields to json output
---+--
 Reporter:  acute  |  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #33323 | Points:  0.5
 Reviewer: |Sponsor:
---+--
Changes (by gaba):

 * parent:  #33322 => #33323


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

Re: [tor-bugs] #33393 [Metrics/Onionperf]: Add new metadata fields to tpf output.

[Tor Bug Tracker & Wiki]

#33393: Add new metadata fields to tpf output.
---+--
 Reporter:  acute  |  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #33323 | Points:  0.5
 Reviewer: |Sponsor:
---+--
Changes (by gaba):

 * parent:  #33322 => #33323


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

Re: [tor-bugs] #33389 [Core Tor/Tor]: Disable routerkeys.c and part of connection_or.c when building without relay mode.

[Tor Bug Tracker & Wiki]

#33389: Disable routerkeys.c and part of connection_or.c when building without
relay mode.
-+-
 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:  tor-design, network-team-roadmap-|  Actual Points:  .2
  2020Q1, 043-deferred   |
Parent ID:  #31851   | Points:
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by ahf):

 * reviewer:   => ahf


Comment:

 Cool!

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

Re: [tor-bugs] #33389 [Core Tor/Tor]: Disable routerkeys.c and part of connection_or.c when building without relay mode.

[Tor Bug Tracker & Wiki]

#33389: Disable routerkeys.c and part of connection_or.c when building without
relay mode.
-+-
 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:  tor-design, network-team-roadmap-|  Actual Points:  .2
  2020Q1, 043-deferred   |
Parent ID:  #31851   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 >Is there a ticket for the second half of this where the router code is
 removed?

 Not yet, but I hope to get to that later today or next week.

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

Re: [tor-bugs] #33389 [Core Tor/Tor]: Disable routerkeys.c and part of connection_or.c when building without relay mode.

[Tor Bug Tracker & Wiki]

#33389: Disable routerkeys.c and part of connection_or.c when building without
relay mode.
-+-
 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:  tor-design, network-team-roadmap-|  Actual Points:  .2
  2020Q1, 043-deferred   |
Parent ID:  #31851   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 This looks good! Is there a ticket for the second half of this where the
 router code is removed?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33397 [Metrics/Website]: Update metrics-web to only plot "official" data

[Tor Bug Tracker & Wiki]

#33397: Update metrics-web to only plot "official" data
-+--
 Reporter:  acute|  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #33323
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 Update metrics-web to only plot "official" data based on new metadata
 field for existing graphs. This depends on implementations described in
 #33323 and #33391 =>#33393

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

Re: [tor-bugs] #33391 [Metrics/Onionperf]: Add new metadata fields and definitions

[Tor Bug Tracker & Wiki]

#33391: Add new metadata fields and definitions
-+--
 Reporter:  acute|  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionperf|Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-team-roadmap-2020Q1  |  Actual Points:
Parent ID:  #33323   | Points:  1
 Reviewer:   |Sponsor:
-+--
Changes (by gaba):

 * parent:  #33322 => #33323


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33396 [Metrics/Onionperf]: Automatically compress Onionperf logs

[Tor Bug Tracker & Wiki]

#33396: Automatically compress Onionperf logs
---+--
 Reporter:  acute  |  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #33319
   Points:  1  |   Reviewer:
  Sponsor: |
---+--
 Automatically compress Onionperf logs to save space. This could be done as
 part of the log rotation at midnight or separately.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33395 [Metrics/Onionperf]: Add option to replace the client and server torrc files

[Tor Bug Tracker & Wiki]

#33395: Add option to replace the client and server torrc files
---+--
 Reporter:  acute  |  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal |   Keywords:
Actual Points:  1  |  Parent ID:  #33319
   Points: |   Reviewer:
  Sponsor: |
---+--
 Add support for replacing the client and server torrc files on the command
 line when deploying an Onionperf measurement.

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

Re: [tor-bugs] #32910 [Core Tor/Tor]: trace: Add tracepoints and userspace tracer support

[Tor Bug Tracker & Wiki]

#32910: trace: Add tracepoints and userspace tracer support
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tracing   |  Actual Points:
Parent ID:| Points:  3
 Reviewer:  nickm |Sponsor:
--+

Comment (by nickm):

 Issues we talked about on IRC:
   * Maybe we should disambiguate identifiers used as domains and event
 names.  Prefixes, suffices, InitialCaps, and camelCase were all suggested
 as possibilities. So were TOR_TRACE, macros to create a single macro per
 event, and so on.
   * Testing.  How do we verify that this is working and we haven't broken
 it? We need some kind of test that actually makes sure events are
 happening and getting recorded.
   * Documentation. We should make sure that you don't need to know the tor
 source code intimately to understand the event descriptions.
   * Safety. In order to make sure this feature stays safe:
  * Tor should log loudly when it is enabled.
  * There should be clear safety guidelines about how the data it
 generates if used on the public network should be considered NOT safe to
 share, should NOT be backed up, and should be deleted.
  * We should make sure we tell researchers explicitly that if they try
 to use this for science on the public network, they will get data that
 they cannot ethically share, and they should probably look for another
 approach if they're doing science.
  * We should talk with Roger and the research safety board, looking
 for more suggestions, if they have any.

 Smaller issues:
   * This needs a changes file.

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

Re: [tor-bugs] #32910 [Core Tor/Tor]: trace: Add tracepoints and userspace tracer support

[Tor Bug Tracker & Wiki]

#32910: trace: Add tracepoints and userspace tracer support
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tracing   |  Actual Points:
Parent ID:| Points:  3
 Reviewer:  nickm |Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => needs_revision


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

Re: [tor-bugs] #33391 [Metrics/Onionperf]: Add new metadata fields and definitions

[Tor Bug Tracker & Wiki]

#33391: Add new metadata fields and definitions
-+--
 Reporter:  acute|  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionperf|Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-team-roadmap-2020Q1  |  Actual Points:
Parent ID:  #33322   | Points:  1
 Reviewer:   |Sponsor:
-+--
Changes (by gaba):

 * keywords:   => metrics-team-roadmap-2020Q1


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33394 [Metrics/Cloud]: Automatically build Onionperf documentation from Git

[Tor Bug Tracker & Wiki]

#33394: Automatically build Onionperf documentation from Git
---+--
 Reporter:  acute  |  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Cloud  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #33321
   Points:  1  |   Reviewer:
  Sponsor: |
---+--
 The documentation for Onionperf (https://onionperf.torproject.org/) should
 be built automatically from the sources in git.

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

Re: [tor-bugs] #33317 [Internal Services/Service - trac]: Add new sponsor 59 to trac

[Tor Bug Tracker & Wiki]

#33317: Add new sponsor 59 to trac
--+-
 Reporter:  gaba  |  Owner:  qbi
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by gaba):

 * type:  defect => task


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

Re: [tor-bugs] #33391 [Metrics/Onionperf]: Add new metadata fields and definitions

[Tor Bug Tracker & Wiki]

#33391: Add new metadata fields and definitions
---+--
 Reporter:  acute  |  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #33322 | Points:  1
 Reviewer: |Sponsor:
---+--
Changes (by acute):

 * points:   => 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

[tor-bugs] #33393 [Metrics/Onionperf]: Add new metadata fields to tpf output.

[Tor Bug Tracker & Wiki]

#33393: Add new metadata fields to tpf output.
---+--
 Reporter:  acute  |  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #33322
   Points:  0.5|   Reviewer:
  Sponsor: |
---+--
 Add new metadata fields for experimental measurements to the Onionperf tpf
 output.

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

Re: [tor-bugs] #33392 [Metrics/Onionperf]: Add new metadata fields to json output

[Tor Bug Tracker & Wiki]

#33392: Add new metadata fields to json output
---+--
 Reporter:  acute  |  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #33322 | Points:  0.5
 Reviewer: |Sponsor:
---+--
Changes (by acute):

 * points:   => 0.5


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

[tor-bugs] #33392 [Metrics/Onionperf]: Add new metadata fields to json output

[Tor Bug Tracker & Wiki]

#33392: Add new metadata fields to json output
---+--
 Reporter:  acute  |  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #33322
   Points: |   Reviewer:
  Sponsor: |
---+--
 Add new metadata fields for experimental measurements to the onionperf
 json output.

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