Re: [tor-bugs] #26972 [Core Tor/Tor]: Create CI task to ensure that all Rust files have been formatted with rustfmt

[Tor Bug Tracker & Wiki]

#26972: Create CI task to ensure that all Rust files have been formatted with
rustfmt
--+
 Reporter:  chelseakomlo  |  Owner:  teor
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:
--+

Comment (by cypherpunks3):

 Replying to [comment:5 teor]:
 > The travis build failed, due to old autoconf macros:
 > https://travis-ci.org/teor2345/tor/builds/412925525

 According to the log, the source of the warning is configure.ac, and use
 of AC_WARN which none of the patches touched, or used? How would you begin
 to fix that?

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

Re: [tor-bugs] #23588 [Core Tor/Tor]: Write fascist_firewall_choose_address_ls() and use it in hs_get_extend_info_from_lspecs()

[Tor Bug Tracker & Wiki]

#23588: Write fascist_firewall_choose_address_ls() and use it in
hs_get_extend_info_from_lspecs()
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23493   | Points:  1
 Reviewer:  teor |Sponsor:
-+-

Comment (by neel):

 I have updated my comments and pushed it to b23588a.

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

Re: [tor-bugs] #23588 [Core Tor/Tor]: Write fascist_firewall_choose_address_ls() and use it in hs_get_extend_info_from_lspecs()

[Tor Bug Tracker & Wiki]

#23588: Write fascist_firewall_choose_address_ls() and use it in
hs_get_extend_info_from_lspecs()
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23493   | Points:  1
 Reviewer:  teor |Sponsor:
-+-

Comment (by teor):

 Hi, the code looks good, but a few comments need updating.

 Reminder: please add extra commits to b23588a. When you push b23588a to
 your github, the pull request will update automatically.

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

Re: [tor-bugs] #26972 [Core Tor/Tor]: Create CI task to ensure that all Rust files have been formatted with rustfmt

[Tor Bug Tracker & Wiki]

#26972: Create CI task to ensure that all Rust files have been formatted with
rustfmt
--+
 Reporter:  chelseakomlo  |  Owner:  teor
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:
--+

Comment (by teor):

 If you have GitHub, you can open a pull request at
 https://github.com/torproject/tor and Travis will run automatically.

 Or you can set up travis on your own GitHub using these instructions:
 https://gitweb.torproject.org/tor.git/tree/doc/HACKING/HelpfulTools.md#n7

 If you're using Travis integration with another git repository, please let
 us know where it is.

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

Re: [tor-bugs] #26972 [Core Tor/Tor]: Create CI task to ensure that all Rust files have been formatted with rustfmt

[Tor Bug Tracker & Wiki]

#26972: Create CI task to ensure that all Rust files have been formatted with
rustfmt
--+
 Reporter:  chelseakomlo  |  Owner:  teor
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:
--+

Comment (by teor):

 Hi,

 The travis build failed, due to old autoconf macros:
 https://travis-ci.org/teor2345/tor/builds/412925525

 Please fix the build, and check that it works on Travis.

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

Re: [tor-bugs] #24629 [Core Tor/Tor]: Activate osx builds on travis, at low priority

[Tor Bug Tracker & Wiki]

#24629: Activate osx builds on travis, at low priority
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  not-just-linux, tor-ci, teor-was-|  Actual Points:
  assigned, 034-triage-20180328, |
  034-removed-20180328, 034-backport,|
  035-removed-20180711, fast-fix |
Parent ID:   | Points:  0.5
 Reviewer:  catalyst |Sponsor:
-+-

Comment (by teor):

 Travis updated their default macOS image to macOS 10.13 / Xcode 9.4 last
 Tuesday 31 July:
 https://blog.travis-ci.com/2018-07-19-xcode9-4-default-announce

 So I restarted the build of travis-osx-v9, and it seems to be fine:
 https://travis-ci.org/teor2345/tor/builds/408771608

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

Re: [tor-bugs] #27048 [Metrics/Consensus Health]: Bandwidth scanner graphs are empty

[Tor Bug Tracker & Wiki]

#27048: Bandwidth scanner graphs are empty
--+--
 Reporter:  teor  |  Owner:  tom
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * status:  closed => reopened
 * resolution:  duplicate =>
 * parent:  #27051 =>


Comment:

 Bandwidth authorities can change over time, so the stem attribute is
 deprecated.

 Instead, we should fix consensus-health to check each vote for measured
 bandwidths:
 https://trac.torproject.org/projects/tor/ticket/27051#comment:1

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

Re: [tor-bugs] #27052 [Core Tor]: document rust/protover and rust/crypto

[Tor Bug Tracker & Wiki]

#27052: document rust/protover and rust/crypto
--+
 Reporter:  cypherpunks3  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust, doc |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_review => new
 * type:  task => enhancement


Comment:

 I don't see any branch or patch here.

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

Re: [tor-bugs] #26843 [Applications/Tor Browser]: TBA: Investigate how Mozilla Fennec provides localization

[Tor Bug Tracker & Wiki]

#26843: TBA: Investigate how Mozilla Fennec provides localization
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:  #26782| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sysrqb):

 Okay. So, [https://searchfox.org/mozilla-
 central/source/build/docs/locales.rst there's a doc for this].
 Specifically, the mozilla build system clones [https://hg.mozilla.org
 /l10n-central l10n-central] and creates the localization package from
 there. I haven't look at the logic used for this, yet.

 We'll want to clone l10n-central separately, and add the location into
 `.mozconfig-android`:
 {{{
 ac_add_options --with-l10n-base=/make/this/a/absolute/path
 }}}

 The specific locale is repackaged using:
 {{{

   ./mach build installers-$AB_CD
 }}}

 The doc says:
 {{{
 You should find a re-packaged build at ``OBJDIR/dist/``, and a
 runnable binary in ``OBJDIR/dist/l10n-stage/``.
 }}}

 Running the `installers-` build target (by default):
 {{{
 The ``installers`` target runs quite a few things for you, including
 getting
 the repository for the requested locale from
 https://hg.mozilla.org/l10n-central/. It will clone them into
 ``~/.mozbuild/l10n-central``.
 }}}

 Multilocale packages are created using:
 {{{
   export MOZ_CHROME_MULTILOCALE="de it zh-TW"
   for AB_CD in $MOZ_CHROME_MULTILOCALE; do
  ./mach build chrome-$AB_CD
   done

   AB_CD=multi ./mach package
 }}}

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

Re: [tor-bugs] #27022 [Webpages/Website]: Please change contact/apply email in new job postings (for bookkeeper, grant writer, and grants manager)

[Tor Bug Tracker & Wiki]

#27022: Please change contact/apply email in new job postings (for bookkeeper,
grant writer, and grants manager)
--+
 Reporter:  ewyatt|  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 hiro, is this another one where you did some things but then never updated
 the 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] #27056 [Core Tor/Tor]: sigusr2 only increases log verbosity to info, not debug

[Tor Bug Tracker & Wiki]

#27056: sigusr2 only increases log verbosity to info, not debug
-+-
 Reporter:  drjohnson1984|  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.7
 Severity:  Normal   | Resolution:
 Keywords:  logging sigusr2 034-backport |  Actual Points:
  033-backport regression|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  new => needs_information


Comment:

 I just tried to reproduce this, and it switched to debug-level logging for
 me, both on 0.3.3 and on master.

 Can you give some more information about the setup that you have here, and
 some instructions for reproducing this issue?

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

Re: [tor-bugs] #27056 [Core Tor/Tor]: sigusr2 only increases log verbosity to info, not debug

[Tor Bug Tracker & Wiki]

#27056: sigusr2 only increases log verbosity to info, not debug
-+-
 Reporter:  drjohnson1984|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.7
 Severity:  Normal   | Resolution:
 Keywords:  logging sigusr2 034-backport |  Actual Points:
  033-backport regression|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  logging sigusr2 => logging sigusr2 034-backport 033-backport
 regression
 * milestone:   => Tor: 0.3.5.x-final


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

Re: [tor-bugs] #22729 [Core Tor/Tor]: Revisit relay read/write history resolution (for onion services)

[Tor Bug Tracker & Wiki]

#22729: Revisit relay read/write history resolution (for onion services)
---+---
 Reporter:  mikeperry  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, guard-discovery-stats  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by mikeperry):

 * component:  Core Tor/TorDNSEL => Core Tor/Tor


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

Re: [tor-bugs] #25440 [Core Tor/Tor]: Broken openat syscall in Sandbox mode

[Tor Bug Tracker & Wiki]

#25440: Broken openat syscall in Sandbox mode
-+-
 Reporter:  ageisp0lis   |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  sandbox, 033-must, regression,   |  Actual Points:
  033-triage-20180326, 033-included-20180326,|
  033-backport, AffectsTails,|
  034-deferred-20180602, 035-removed-20180711|
  029-backport 032-backport  |
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

 * keywords:
 sandbox, 033-must, regression, 033-triage-20180326,
 033-included-20180326, 033-backport, AffectsTails,
 034-deferred-20180602, 035-removed-20180711
 =>
 sandbox, 033-must, regression, 033-triage-20180326,
 033-included-20180326, 033-backport, AffectsTails,
 034-deferred-20180602, 035-removed-20180711 029-backport 032-backport


Comment:

 (Otherwise this looks fine to me.  It appears that the bug is present in
 0.2.9 and later, so we'll want to backport to maint-0.2.9 when we take
 it.)

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

Re: [tor-bugs] #25440 [Core Tor/Tor]: Broken openat syscall in Sandbox mode

[Tor Bug Tracker & Wiki]

#25440: Broken openat syscall in Sandbox mode
-+-
 Reporter:  ageisp0lis   |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  sandbox, 033-must, regression,   |  Actual Points:
  033-triage-20180326, 033-included-20180326,|
  033-backport, AffectsTails,|
  034-deferred-20180602, 035-removed-20180711|
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
-+-

Comment (by nickm):

 What would you think about using "unsigned int" instead of "uint32_t"?
 That way, if the "int fd" argument to openat() ever becomes 64-bit, the
 unsigned cast should still do the right thing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27056 [Core Tor/Tor]: sigusr2 only increases log verbosity to info, not debug

[Tor Bug Tracker & Wiki]

#27056: sigusr2 only increases log verbosity to info, not debug
---+-
 Reporter:  drjohnson1984  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Low|  Milestone:
Component:  Core Tor/Tor   |Version:  Tor: 0.3.3.7
 Severity:  Normal |   Keywords:  logging sigusr2
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 In version 0.3.3.7 on linux, when you hit the tor process with sigusr2, it
 should switch to debug-level logging.  It goes to info-level verbosity,
 but not debug.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27055 [Metrics/CollecTor]: Find out why syncing descriptors from collector2.tp.o did not time out

[Tor Bug Tracker & Wiki]

#27055: Find out why syncing descriptors from collector2.tp.o did not time out
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 On August 4, collector.tp.o attempted to fetch remote files from
 collector2.tp.o during its normal sync run. However, this process stalled,
 because of an unknown problem on collector2.tp.o. The effect was that
 neither of the two downloaded consensuses and we missed almost an entire
 day of consensuses. (We got them back from friendly relay operators in the
 end, but that should not become the new way of feeding the archive with
 data.)

 From the log:

 {{{
 2018-08-04 17:37:17,556 INFO o.t.m.c.c.CollecTorMain:75 Starting sync-run
 of module relaydescs of CollecTor.
 2018-08-04 17:37:17,556 INFO o.t.m.c.s.SyncManager:57 Collecting Relay
 from collector2.torproject.org ...
 2018-08-04 17:37:17,556 INFO o.t.d.i.DescriptorIndexCollector:46 Starting
 descriptor collection.
 2018-08-04 17:37:17,556 INFO o.t.d.i.DescriptorIndexCollector:62 Indexing
 local directory /srv/collector.torproject.org/collector/sync/Relay-
 collector2.torproject.org.
 2018-08-04 17:37:17,562 INFO o.t.d.i.DescriptorIndexCollector:73 Fetching
 remote index file https://collector2.torproject.org/index/index.json.
 2018-08-04 17:37:18,053 INFO o.t.d.i.DescriptorIndexCollector:82 Fetching
 remote files from https://collector2.torproject.org.
 [...]
 2018-08-05 18:27:13,331 INFO o.t.d.i.DescriptorIndexCollector:88 Deleting
 extraneous files from local directory sync/Relay-
 collector2.torproject.org.
 2018-08-05 18:27:13,375 INFO o.t.d.i.DescriptorIndexCollector:93 Finished
 descriptor collection.
 }}}

 I'm not sure what to do here. The log doesn't reveal anything obviously
 going wrong. I didn't look at the code yet, so maybe there's an obvious
 way to prevent such issues in the future. Hmm.

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

Re: [tor-bugs] #27054 [Internal Services/Service - git]: Please let mikeperry push to the research-web git repo

[Tor Bug Tracker & Wiki]

#27054: Please let mikeperry push to the research-web git repo
-+-
 Reporter:  arma |  Owner:  tor-gitadm
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 done!

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

Re: [tor-bugs] #23512 [Core Tor/Tor]: Bandwidth stats watermark can be induced using OOM killer

[Tor Bug Tracker & Wiki]

#23512: Bandwidth stats watermark can be induced using OOM killer
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bug-bounty, congestion-attack,   |  Actual Points:
  research, watermark, tor-stats, guard- |
  discovery-stats, 034-triage-20180328,  |
  034-removed-20180328   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-

Comment (by Jaym):

 Hello,

 Sorry about that. Previous url was used for the anonymous submission. Here
 is the code: https://github.com/frochet/dropping_on_the_edge

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

Re: [tor-bugs] #23512 [Core Tor/Tor]: Bandwidth stats watermark can be induced using OOM killer

[Tor Bug Tracker & Wiki]

#23512: Bandwidth stats watermark can be induced using OOM killer
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bug-bounty, congestion-attack,   |  Actual Points:
  research, watermark, tor-stats, guard- |
  discovery-stats, 034-triage-20180328,  |
  034-removed-20180328   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-

Comment (by mikeperry):

 So, for reference, the final version of the paper, at
 https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf,
 says this on page 7, Section 4.3.1:
 {{{
 This buffering fills the memory until circuit_handle_oom () is called to
 kill the circuits and recover the memory from its queues. In the mean-
 time, the cell payload is counted in the read statistics and ignored in
 the write statistics.
 }}}

 This makes it sound like asn's proposed fix in the description should
 actually be correct, and that arma's comment may have been based on an
 earlier paper revision.

 Sure would be nice to get that github url back to actually reproduce some
 science here..

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

Re: [tor-bugs] #23512 [Core Tor/Tor]: Bandwidth stats watermark can be induced using OOM killer

[Tor Bug Tracker & Wiki]

#23512: Bandwidth stats watermark can be induced using OOM killer
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bug-bounty, congestion-attack,   |  Actual Points:
  research, watermark, tor-stats, guard- |
  discovery-stats, 034-triage-20180328,  |
  034-removed-20180328   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-

Comment (by arma):

 Replying to [comment:7 Jaym]:
 > I also added chutney experiments to observe the difference in read/write
 that can be reproduced with this code
 (https://github.com/popets18dropping/code_and_data/tree/master/hs_drop_attack).

 Looks like this url is 404? Is there a more permanent url? 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] #22729 [Core Tor/TorDNSEL]: Revisit relay read/write history resolution (for onion services)

[Tor Bug Tracker & Wiki]

#22729: Revisit relay read/write history resolution (for onion services)
---+---
 Reporter:  mikeperry  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/TorDNSEL  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, guard-discovery-stats  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by mikeperry):

 For reference, we did in fact raise our stats reporting interval to 24
 hours for bandwidth stats. This ticket is about determining if that is
 enough.

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

Re: [tor-bugs] #26497 [Core Tor/Tor]: set CARGO_HOME correctly or stop using it

[Tor Bug Tracker & Wiki]

#26497: set CARGO_HOME correctly or stop using it
-+-
 Reporter:  catalyst |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-ci, 035-removed-20180711,  |  Actual Points:
  035-roadmap-proposed   |
Parent ID:  #24629   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by catalyst):

 Also src/test/test_rust.sh should probably `cd
 ${abs_top_buildir}/src/rust` like the src/rust/tor_rust/include.am rules
 do, for consistency.  It's probably not too necessary, though.

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

Re: [tor-bugs] #25696 [Applications/Tor Browser]: Design of alpha onboarding for Tor Browser for Android

[Tor Bug Tracker & Wiki]

#25696: Design of alpha onboarding for Tor Browser for Android
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-mobile, |  Actual Points:
  TorBrowserTeam201808   |
Parent ID:  #26531   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by sysrqb):

 Replying to [comment:18 brade]:
 > What is your plan / strategy for localizing the onboarding strings?
 Localization is still an open issue for onboarding within the desktop
 version; our plan is to add the strings to a new file within Torbutton and
 modify the Firefox onboarding code to pull the strings from there (which
 is the strategy we have used on desktop for similar situations).

 This seems like the most scalable solution. igt0's patch in comment:17
 adds the strings in the `android_strings.dtd` file, but we'll likely be
 happier if we keep localizable string for desktop and android in the same
 place - especially for the identical strings we use in both places. Using
 android_string.dtd may be the easiest solution for the first alpha (and
 not provide localized strings), and then we can move the strings into
 torbutton when we're ready for releasing localized versions of TBA.

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

Re: [tor-bugs] #27053 [Core Tor/Stem]: Check controller's event error handling

[Tor Bug Tracker & Wiki]

#27053: Check controller's event error handling
---+
 Reporter:  atagar |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Hi Mike. When our caller's handler raises an exception it should be
 ignored by Stem. Presently it breaks the event thread and that is
 **definitely** wrong.

 Stem intends to provide the following contract...

 * Users should not need to know about Stem's internal event thread and it
 should **never** fail. If it does that's my bug.

 * When a listener is subscribed it should **always** be invoked when a
 validly formatted event of that type is received.

 * What the listener does (and if it fails) is of no interest to Stem.

 Unfortunately I need to carve out one exception for that last point: if
 the called function hangs then that **will** break our event thread. To
 protect us from that I could invoke handlers in subthreads like we do for
 status changed listeners...

 
https://stem.torproject.org/api/control.html#stem.control.BaseController.add_status_listener

 ... but unlike status changes events are numerous enough that guardrails
 like that would be costly.

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

Re: [tor-bugs] #25696 [Applications/Tor Browser]: Design of alpha onboarding for Tor Browser for Android

[Tor Bug Tracker & Wiki]

#25696: Design of alpha onboarding for Tor Browser for Android
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-mobile, |  Actual Points:
  TorBrowserTeam201808   |
Parent ID:  #26531   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by antonela):

 Thanks emmapeel!

 igt0/sysrqb: could you give emmapeel access to the repo?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27054 [Internal Services/Service - git]: Please let mikeperry push to the research-web git repo

[Tor Bug Tracker & Wiki]

#27054: Please let mikeperry push to the research-web git repo
-+
 Reporter:  arma |  Owner:  tor-gitadm
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256


 Please let mikeperry push to the research-web git repo.

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQIcBAEBCAAGBQJbaI+3AAoJEMIYUlgZ94RRKPAQAKBBbiNWVKocUIrAJCHn4AE+
 oGjYKFYk7hGXzfrlP842itBfJ/tyM5hEv0/Mlm+2n8MEsG+kgsIx4HVQ09HaHVBe
 skKRs8vU0dpD+aGLlipAMVwZ7vaOW2y+qZcVGdfEoFSx+bVMAZOyFaQdL1tey1hJ
 z0OYNVL+xfsUqqVnpQZ99z9dMlyRDVdDcRXPctzwfxAGXX/VUD6vRdQbS+6uQSSo
 Dif+z1BXiPALdOfhQBqF+uUr3uACiVySoz8r5xJgnw+ygDSOckUnfcx+aFaaOFGH
 T+V/FofYto1pXKw41jqBHW/zxGQFdFn4Forz4uMsmMduZ/rsdFjV6QaxnyEZzMa8
 IEvfVNjQHRgnwXXW+Jelx5HB9JorEdFCK0PCHzhn08/k2k0kIcX2LFUpd5YRLqMT
 cJE51xY7dAjOPKrWLllomIadymUWgOhuWIq24yjvOQDUQ5uNepzHnSjBcVUfj+FJ
 z42/CKeqGFoFPFo6fDqi+7VF9wCUg28Exp/tWo64QHFzGXPYUT6HyYw5Tewj565A
 plPW5Uke83f8T9vYkzr0mwKnOtu+GoZkgFemOW7wrdclCuGScSKEtkdoadc0P+0w
 aXdfFKLCkAnBmCWFz51DXAS1DlRKwhZVuZ0cu2FI52n7nDtlTZC1qi1ThLEpQT19
 5C99btpV1+mJlIGyTjap
 =2nCv
 -END PGP SIGNATURE-
 }}}

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

Re: [tor-bugs] #27053 [Core Tor/Stem]: Check controller's event error handling

[Tor Bug Tracker & Wiki]

#27053: Check controller's event error handling
---+
 Reporter:  atagar |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by mikeperry):

 Related: if a controller itself messes up handling an event callback and
 throws an arbitrary exception, it should have a way to know that this
 happened, so it can decide to exit. Or perhaps equivalently for my
 purposes: if stem just exits the program in this case.

 Without this, controllers that are supposed to be long-lived might sit
 around in a zombie-state where users think they are running, but they
 actually are not reacting to anything.

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

Re: [tor-bugs] #27040 [Core Tor/Tor]: [warn] We don't have a consensus, so we can't perform v2 rendezvous operations.

[Tor Bug Tracker & Wiki]

#27040: [warn] We don't have a consensus, so we can't perform v2 rendezvous
operations.
+--
 Reporter:  arma|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.5.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Minor   | Resolution:
 Keywords:  fast-fix easy 034-backport  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * keywords:   => fast-fix easy 034-backport
 * milestone:   => Tor: 0.3.5.x-final


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

Re: [tor-bugs] #27052 [Core Tor]: document rust/protover and rust/crypto

[Tor Bug Tracker & Wiki]

#27052: document rust/protover and rust/crypto
--+
 Reporter:  cypherpunks3  |  Owner:  (none)
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust, doc |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  new => needs_review
 * milestone:   => Tor: 0.3.5.x-final


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

Re: [tor-bugs] #26464 [Core Tor/Tor]: Static cross-compiling for Windows is broken

[Tor Bug Tracker & Wiki]

#26464: Static cross-compiling for Windows is broken
-+
 Reporter:  Hello71  |  Owner:  Hello71
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-triaged-in-20180711  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
-+
Changes (by nickm):

 * reviewer:  catalyst => nickm


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

Re: [tor-bugs] #27039 [Metrics/Relay Search]: Relay Search graphs missing

[Tor Bug Tracker & Wiki]

#27039: Relay Search graphs missing
--+--
 Reporter:  starlight |  Owner:  irl
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by kat5):

 Here's the script output:

 kat@arbour:~/tor/relayops/tshirts$ ./tshirt.py
 097CD81AB87D2F5DDB2538CF1221D978044F3323
 Fetched bandwidth document
 Fetched uptime document
 Fetched details document
 Traceback (most recent call last):
   File "./tshirt.py", line 197, in 
 check_tshirt(search_query)
   File "./tshirt.py", line 183, in check_tshirt
 uptime_percent = get_uptime_percent(uptime_data[i])
   File "./tshirt.py", line 149, in get_uptime_percent
 return round(calculate_2mo_avg(response, 'uptime') * 100, 2)
   File "./tshirt.py", line 102, in calculate_2mo_avg
 first = datetime.strptime(data['first'], "%Y-%m-%d %H:%M:%S")
 TypeError: strptime() argument 1 must be string, not int
 kat@arbour:~/tor/relayops/tshirts$

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27053 [Core Tor/Stem]: Check controller's event error handling

[Tor Bug Tracker & Wiki]

#27053: Check controller's event error handling
---+
 Reporter:  atagar |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Major  |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 Mike had a great question: 'what happens to events if there's an error?'.
 On reflection the answer is: nothing good.

 Our handle_event method parses events without any kind of error
 handling...

 https://gitweb.torproject.org/stem.git/tree/stem/control.py#n3876

 This would in turn break our event handling thread. Instead we should
 direct malformed events into a 'broken event' queue.

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

Re: [tor-bugs] #27039 [Metrics/Relay Search]: Relay Search graphs missing

[Tor Bug Tracker & Wiki]

#27039: Relay Search graphs missing
--+--
 Reporter:  starlight |  Owner:  metrics-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by irl):

 The t-shirt script is also broken, likely for the same reason.

 https://gitweb.torproject.org/metrics-tasks.git/tree/task-9889/tshirt.py

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

Re: [tor-bugs] #27039 [Metrics/Relay Search]: Relay Search graphs missing

[Tor Bug Tracker & Wiki]

#27039: Relay Search graphs missing
--+--
 Reporter:  starlight |  Owner:  irl
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by irl):

 * status:  new => accepted
 * owner:  metrics-team => irl


Comment:

 Will try to look at this tomorrow with other relay search tickets.

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

Re: [tor-bugs] #27033 [- Select a component]: Usability Research: Tor Launcher

[Tor Bug Tracker & Wiki]

#27033: Usability Research: Tor Launcher
+--
 Reporter:  nyinz   |  Owner:  nyinz
 Type:  project | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  - Select a component|Version:
 Severity:  Normal  | Resolution:
 Keywords:  user-demographics, ux-team  |  Actual Points:
Parent ID:  #27010  | Points:
 Reviewer:  antonela|Sponsor:
+--
Description changed by antonela:

Old description:

> Methodology:  See in attached files
> Where: Tor Meetup in Mumbai, India
> Participants: Five (5)
> Methodology: Interview and Survey
>
> **Results**
> 1. Summary of demographics
> 2. What users said
> 3. Conclusion
> 4. Recommendations
>
> **1.**
>
> - The group consisted of 5 male users aged 20-50.
> - Most of the users described themselves as and day to day tech users who
> use Tor just on specific situations.
>
> **2.**
>
> Q1 Do you think you would need to click on Configure to connect to Tor?
>
> - Most users answered ‘NO’ to this question and understand that there was
> no need to configure at this point.
>
> Q2 What do the checked options do?
>
> - All users relate checked options with checking for censorship in their
> country. Most of them understood that these options are used for
> connecting to the bridge.
>
> Q3 Describe in your words how a bridge will help users.
>
> - Most of the users understand a bridge as a function that helps them
> bypass censored material.
> - Users did not go deep into how the bridge actually works to help users.
> - Quote: “It can help to change the way I am currently connecting on Tor”
>
> Q4 If Tor is censored in India, what bridge would you use?
>
> - Most users say they would pick a bridge at random.
> - Most of them hesitated for a few seconds. It seems that users cannot
> tell the advantage of one bridge over another and therefore decide to go
> with an option.
> - Quotes: “...I would choose at random” “I don’t know. I would probably
> brute force try” In Fact! “I would try all of them until something works”
>
> Q5 Have you ever had to configure a proxy? Would you know how to look for
> Internet settings in another browser? Can you check your system’s network
> settings?
>
> - All the users answered yes to all parts.
> - This was not a difficult question for them. They gave their answers
> promptly and seem to understand the concepts of configuration and system
> settings.
>
> **3.**
>
> This was an all-male user group, therefore they represent only a portion
> of the users of Tor who use it in specific situations. They are all
> consumers of technology and understand the basic terms referred to in the
> questionnaire, such as configure/censorship/proxy/bridge.
> However, when it comes down to engaging with the website settings, in
> particular choosing a bridge, users are not yet well informed and require
> creative assistance.
>
> **4.**
> - Increase opportunities for interaction with users of other
> genders/gender identities.
> - Review existing content about bridges, for instance, consider naming
> bridges according to their specific functionality.

New description:

 Methodology:
 
[https://trac.torproject.org/projects/tor/attachment/ticket/27033/User%20testing%20Tor%20Launcher%20Methodology.pdf
 See Attachments]
 Where: Tor Meetup in Mumbai, India
 Participants: Five (5)

 **Results**
 1. Summary of demographics
 2. What users said
 3. Conclusion
 4. Recommendations

 **1.**

 - The group consisted of 5 male users aged 20-50.
 - Most of the users described themselves as and day to day tech users who
 use Tor just on specific situations.

 **2.**

 Q1 Do you think you would need to click on Configure to connect to Tor?

 - Most users answered ‘NO’ to this question and understand that there was
 no need to configure at this point.

 Q2 What do the checked options do?

 - All users relate checked options with checking for censorship in their
 country. Most of them understood that these options are used for
 connecting to the bridge.

 Q3 Describe in your words how a bridge will help users.

 - Most of the users understand a bridge as a function that helps them
 bypass censored material.
 - Users did not go deep into how the bridge actually works to help users.
 - Quote: “It can help to change the way I am currently connecting on Tor”.

 Q4 If Tor is censored in India, what bridge would you use?

 - Most users say they would pick a bridge at random.
 - Most of them hesitated for a few seconds. It seems that users cannot
 tell the advantage of one bridge over another and therefore decide to go
 with an option.
 - Quotes: “...I would choose at random” “I don’t know. I would probably
 brute force try” In Fact! “I would try all of them until something works”.

 

Re: [tor-bugs] #27040 [Core Tor/Tor]: [warn] We don't have a consensus, so we can't perform v2 rendezvous operations.

[Tor Bug Tracker & Wiki]

#27040: [warn] We don't have a consensus, so we can't perform v2 rendezvous
operations.
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 I think the request proceeded.

 Wouldn't it be cool to have a unit test (or maybe this is more like a
 chutney test) to verify that it does work, and keeps 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] #27040 [Core Tor/Tor]: [warn] We don't have a consensus, so we can't perform v2 rendezvous operations.

[Tor Bug Tracker & Wiki]

#27040: [warn] We don't have a consensus, so we can't perform v2 rendezvous
operations.
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by asn):

 Yes, I think we can safely demote that log message to info.

 BTW, does the request proceeds after the bootstrap completes, or do you
 need to do the request again?

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

Re: [tor-bugs] #27033 [- Select a component]: Usability Research: Tor Launcher

[Tor Bug Tracker & Wiki]

#27033: Usability Research: Tor Launcher
+--
 Reporter:  nyinz   |  Owner:  nyinz
 Type:  project | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  - Select a component|Version:
 Severity:  Normal  | Resolution:
 Keywords:  user-demographics, ux-team  |  Actual Points:
Parent ID:  #27010  | Points:
 Reviewer:  antonela|Sponsor:
+--
Description changed by antonela:

Old description:

> Methodology:  See in attached files
> Where: Tor Meetup in Mumbai, India
> Participants: Five (5)
> Methodology: Survey
>
> **Results**
> 1. Summary of demographics
> 2. What users said
> 3. Conclusion
> 4. Recommendations
>
> **1.**
>
> - The group consisted of 5 male users aged 20-50.
> - Most of the users described themselves as and day to day tech users who
> use Tor just on specific situations.
>
> **2.**
>
> Q1 Do you think you would need to click on Configure to connect to Tor?
>
> - Most users answered ‘NO’ to this question and understand that there was
> no need to configure at this point.
>
> Q2 What do the checked options do?
>
> - All users relate checked options with checking for censorship in their
> country. Most of them understood that these options are used for
> connecting to the bridge.
>
> Q3 Describe in your words how a bridge will help users.
>
> - Most of the users understand a bridge as a function that helps them
> bypass censored material.
> - Users did not go deep into how the bridge actually works to help users.
> - Quote: “It can help to change the way I am currently connecting on Tor”
>
> Q4 If Tor is censored in India, what bridge would you use?
>
> - Most users say they would pick a bridge at random.
> - Most of them hesitated for a few seconds. It seems that users cannot
> tell the advantage of one bridge over another and therefore decide to go
> with an option.
> - Quotes: “...I would choose at random” “I don’t know. I would probably
> brute force try” In Fact! “I would try all of them until something works”
>
> Q5 Have you ever had to configure a proxy? Would you know how to look for
> Internet settings in another browser? Can you check your system’s network
> settings?
>
> - All the users answered yes to all parts.
> - This was not a difficult question for them. They gave their answers
> promptly and seem to understand the concepts of configuration and system
> settings.
>
> **3.**
>
> This was an all-male user group, therefore they represent only a portion
> of the users of Tor who use it in specific situations. They are all
> consumers of technology and understand the basic terms referred to in the
> questionnaire, such as configure/censorship/proxy/bridge.
> However, when it comes down to engaging with the website settings, in
> particular choosing a bridge, users are not yet well informed and require
> creative assistance.
>
> **4.**
> - Increase opportunities for interaction with users of other
> genders/gender identities.
> - Review existing content about bridges, for instance, consider naming
> bridges according to their specific functionality.

New description:

 Methodology:  See in attached files
 Where: Tor Meetup in Mumbai, India
 Participants: Five (5)
 Methodology: Interview and Survey

 **Results**
 1. Summary of demographics
 2. What users said
 3. Conclusion
 4. Recommendations

 **1.**

 - The group consisted of 5 male users aged 20-50.
 - Most of the users described themselves as and day to day tech users who
 use Tor just on specific situations.

 **2.**

 Q1 Do you think you would need to click on Configure to connect to Tor?

 - Most users answered ‘NO’ to this question and understand that there was
 no need to configure at this point.

 Q2 What do the checked options do?

 - All users relate checked options with checking for censorship in their
 country. Most of them understood that these options are used for
 connecting to the bridge.

 Q3 Describe in your words how a bridge will help users.

 - Most of the users understand a bridge as a function that helps them
 bypass censored material.
 - Users did not go deep into how the bridge actually works to help users.
 - Quote: “It can help to change the way I am currently connecting on Tor”

 Q4 If Tor is censored in India, what bridge would you use?

 - Most users say they would pick a bridge at random.
 - Most of them hesitated for a few seconds. It seems that users cannot
 tell the advantage of one bridge over another and therefore decide to go
 with an option.
 - Quotes: “...I would choose at random” “I don’t know. I would probably
 brute force try” In Fact! “I would try all of them until something works”

 Q5 Have you ever had to configure a proxy? Would you know how to look for
 Internet settings 

Re: [tor-bugs] #27033 [- Select a component]: Usability Research: Tor Launcher

[Tor Bug Tracker & Wiki]

#27033: Usability Research: Tor Launcher
+--
 Reporter:  nyinz   |  Owner:  nyinz
 Type:  project | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  - Select a component|Version:
 Severity:  Normal  | Resolution:
 Keywords:  user-demographics, ux-team  |  Actual Points:
Parent ID:  #27010  | Points:
 Reviewer:  antonela|Sponsor:
+--
Description changed by antonela:

Old description:

> Methodology:  See in attached files
> Where: Tor Meetup in Mumbai, India
> Participants: Five (5)
> Methodology: Survey
>
> **Results**
> 1. Summary of demographics
> 2. What users said
> 3. Conclusion
> 4. Recommendations
>
> **1.**
> - The group consisted of 5 male users aged 20-50.
> - Most of the users described themselves as and day to day tech users who
> use Tor just on specific situations.
>
> **2.**
> Q1 Do you think you would need to click on Configure to connect to Tor?
>
> - Most users answered ‘NO’ to this question and understand that there was
> no need to configure at this point.
>
> Q2 What do the checked options do?
>
> - All users relate checked options with checking for censorship in their
> country. Most of them understood that these options are used for
> connecting to the bridge.
>
> Q3 Describe in your words how a bridge will help users.
>
> - Most of the users understand a bridge as a function that helps them
> bypass censored material.
> - Users did not go deep into how the bridge actually works to help users.
> - Quote: “It can help to change the way I am currently connecting on Tor”
>
> Q4 If Tor is censored in India, what bridge would you use?
>
> - Most users say they would pick a bridge at random.
> - Most of them hesitated for a few seconds. It seems that users cannot
> tell the advantage of one bridge over another and therefore decide to go
> with an option.
> - Quotes: “...I would choose at random” “I don’t know. I would probably
> brute force try” In Fact! “I would try all of them until something works”
>
> Q5 Have you ever had to configure a proxy? Would you know how to look for
> Internet settings in another browser? Can you check your system’s network
> settings?
>
> - All the users answered yes to all parts.
> - This was not a difficult question for them. They gave their answers
> promptly and seem to understand the concepts of configuration and system
> settings.
>
> **3.**
> This was an all-male user group, therefore they represent only a portion
> of the users of Tor who use it in specific situations. They are all
> consumers of technology and understand the basic terms referred to in the
> questionnaire, such as configure/censorship/proxy/bridge.
> However, when it comes down to engaging with the website settings, in
> particular choosing a bridge, users are not yet well informed and require
> creative assistance.
>
> **4.**
> - Increase opportunities for interaction with users of other
> genders/gender identities.
> - Review existing content about bridges, for instance, consider naming
> bridges according to their specific functionality.

New description:

 Methodology:  See in attached files
 Where: Tor Meetup in Mumbai, India
 Participants: Five (5)
 Methodology: Survey

 **Results**
 1. Summary of demographics
 2. What users said
 3. Conclusion
 4. Recommendations

 **1.**

 - The group consisted of 5 male users aged 20-50.
 - Most of the users described themselves as and day to day tech users who
 use Tor just on specific situations.

 **2.**

 Q1 Do you think you would need to click on Configure to connect to Tor?

 - Most users answered ‘NO’ to this question and understand that there was
 no need to configure at this point.

 Q2 What do the checked options do?

 - All users relate checked options with checking for censorship in their
 country. Most of them understood that these options are used for
 connecting to the bridge.

 Q3 Describe in your words how a bridge will help users.

 - Most of the users understand a bridge as a function that helps them
 bypass censored material.
 - Users did not go deep into how the bridge actually works to help users.
 - Quote: “It can help to change the way I am currently connecting on Tor”

 Q4 If Tor is censored in India, what bridge would you use?

 - Most users say they would pick a bridge at random.
 - Most of them hesitated for a few seconds. It seems that users cannot
 tell the advantage of one bridge over another and therefore decide to go
 with an option.
 - Quotes: “...I would choose at random” “I don’t know. I would probably
 brute force try” In Fact! “I would try all of them until something works”

 Q5 Have you ever had to configure a proxy? Would you know how to look for
 Internet settings in another browser? 

Re: [tor-bugs] #27033 [- Select a component]: Usability Research: Tor Launcher

[Tor Bug Tracker & Wiki]

#27033: Usability Research: Tor Launcher
+--
 Reporter:  nyinz   |  Owner:  nyinz
 Type:  project | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  - Select a component|Version:
 Severity:  Normal  | Resolution:
 Keywords:  user-demographics, ux-team  |  Actual Points:
Parent ID:  #27010  | Points:
 Reviewer:  antonela|Sponsor:
+--
Changes (by antonela):

 * parent:   => #27010


Old description:

> Methodology:  See in attached files
> Where: Tor Meetup in Mumbai, India
> Participants: Five (5)
> Methodology: Survey
>
> **Results**
> 1. Summary of demographics
> 2. What users said
> 3. Conclusion
> 4. Recommendations
>
> **1.**
> ==
> - The group consisted of 5 male users aged 20-50.
> - Most of the users described themselves as and day to day tech users who
> use Tor just on specific situations.
>
> **2.**
> ==
> Q1 Do you think you would need to click on Configure to connect to Tor?
>
> - Most users answered ‘NO’ to this question and understand that there was
> no need to configure at this point.
>
> Q2 What do the checked options do?
>
> - All users relate checked options with checking for censorship in their
> country. Most of them understood that these options are used for
> connecting to the bridge.
>
> Q3 Describe in your words how a bridge will help users.
>
> - Most of the users understand a bridge as a function that helps them
> bypass censored material.
> - Users did not go deep into how the bridge actually works to help users.
> - Quote: “It can help to change the way I am currently connecting on Tor”
>
> Q4 If Tor is censored in India, what bridge would you use?
>
> - Most users say they would pick a bridge at random.
> - Most of them hesitated for a few seconds. It seems that users cannot
> tell the advantage of one bridge over another and therefore decide to go
> with an option.
> - Quotes: “...I would choose at random” “I don’t know. I would probably
> brute force try” In Fact! “I would try all of them until something works”
>
> Q5 Have you ever had to configure a proxy? Would you know how to look for
> Internet settings in another browser? Can you check your system’s network
> settings?
>
> - All the users answered yes to all parts.
> - This was not a difficult question for them. They gave their answers
> promptly and seem to understand the concepts of configuration and system
> settings.
>
> **3.**
> ==
> This was an all-male user group, therefore they represent only a portion
> of the users of Tor who use it in specific situations. They are all
> consumers of technology and understand the basic terms referred to in the
> questionnaire, such as configure/censorship/proxy/bridge.
> However, when it comes down to engaging with the website settings, in
> particular choosing a bridge, users are not yet well informed and require
> creative assistance.
>
> **4.**
> ==
> - Increase opportunities for interaction with users of other
> genders/gender identities.
> - Review existing content about bridges, for instance, consider naming
> bridges according to their specific functionality.

New description:

 Methodology:  See in attached files
 Where: Tor Meetup in Mumbai, India
 Participants: Five (5)
 Methodology: Survey

 **Results**
 1. Summary of demographics
 2. What users said
 3. Conclusion
 4. Recommendations

 **1.**
 - The group consisted of 5 male users aged 20-50.
 - Most of the users described themselves as and day to day tech users who
 use Tor just on specific situations.

 **2.**
 Q1 Do you think you would need to click on Configure to connect to Tor?

 - Most users answered ‘NO’ to this question and understand that there was
 no need to configure at this point.

 Q2 What do the checked options do?

 - All users relate checked options with checking for censorship in their
 country. Most of them understood that these options are used for
 connecting to the bridge.

 Q3 Describe in your words how a bridge will help users.

 - Most of the users understand a bridge as a function that helps them
 bypass censored material.
 - Users did not go deep into how the bridge actually works to help users.
 - Quote: “It can help to change the way I am currently connecting on Tor”

 Q4 If Tor is censored in India, what bridge would you use?

 - Most users say they would pick a bridge at random.
 - Most of them hesitated for a few seconds. It seems that users cannot
 tell the advantage of one bridge over another and therefore decide to go
 with an option.
 - Quotes: “...I would choose at random” “I don’t know. I would probably
 brute force try” In Fact! “I would try all of them until something works”

 Q5 Have you ever had to configure a proxy? Would you know how to look for
 

Re: [tor-bugs] #20537 [Community/Tor Browser Manual]: Tor Browser User Manual needs meta section

[Tor Bug Tracker & Wiki]

#20537: Tor Browser User Manual needs meta section
--+--
 Reporter:  weasel|  Owner:  Jaruga
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Community/Tor Browser Manual  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by Jaruga):

 * status:  new => accepted
 * owner:  Kelley => Jaruga
 * component:  Community/Training => Community/Tor Browser Manual
 * cc: t0mmy (added)


Comment:

 Good idea! Tommy & I will work on a implementation this 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] #27033 [- Select a component]: Usability Research: Tor Launcher

[Tor Bug Tracker & Wiki]

#27033: Usability Research: Tor Launcher
+--
 Reporter:  nyinz   |  Owner:  nyinz
 Type:  project | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  - Select a component|Version:
 Severity:  Normal  | Resolution:
 Keywords:  user-demographics, ux-team  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  antonela|Sponsor:
+--
Changes (by antonela):

 * status:  new => assigned
 * component:  Community/Outreach => - Select a component
 * owner:  alison => nyinz
 * keywords:   => user-demographics, ux-team
 * reviewer:   => antonela


Old description:

> Methodology:
> **See in attached files**
>
> Where: **Tor Meetup in Mumbai, India
> **
> Participants: Five (**5**)
>
> Results:
> **1.Summary of demographics
> 2.What users said
> 3.Conclusion
> 4.Recommendations**
>
> **1.**
> ==
> The group consisted of 5 male users aged 20-50
> Most of the users described themselves as and day to day tech users who
> use Tor just on specific situations
>
> **2.**
> ==
> **Q1** Do you think you would need to click on Configure to connect to
> Tor?
>
> Most users answered ‘NO’ to this question and understand that there was
> no need to configure at this point
>
> **Q2** What do the checked options do?
>
> All users relate checked options with checking for censorship in their
> country. Most of them understood that these options are used for
> connecting to the bridge
>
> **Q3** Describe with your words how a bridge will help users.
>
> Most of the users understand a bridge as a function that helps them
> bypass censored material. Quote:
> “It can help to change the way I am currently connecting on Tor”
> Users did not go deep into how the bridge actually works to help users
>
> **Q4** If Tor is censored in India, what bridge would you use?
>
> Most users say they would pick a bridge at random.
> Quotes:
> “...I would choose at random”
> “I don’t know. I would probably brute force try” In Fact! “I would try
> all of them until something works”
> Most of them hesitated for a few seconds. It seems that users cannot tell
> the advantage of one bridge over another and therefore decide to go with
> any option
>
> **Q5** Have you ever had to configure a proxy? Would you know how to look
> for Internet settings in another browser? Can you check your system’s
> network settings?
>
> All the users answered yes to all parts.
> This was not a difficult question for them. They gave their answers
> promptly and seem to understand the concepts of configuration and system
> settings
>
> **3.**
> ==
> This was an all male user group, therefore they represent only a portion
> of the users of Tor who use it in specific situations. They are all
> consumers of technology and understand the basic terms referred to in the
> questionnaire, such as: configure/censorship/proxy/bridge
> However, when it comes down to engaging with the website settings, in
> particular choosing a bridge, users are not yet well informed and require
> creative assistance
>
> **4.**
> ==
> -Increase opportunities for interaction with users of other
> genders/gender identities
> -Review existing content about bridges for instance, consider naming
> bridges according to their specific functionality.

New description:

 Methodology:  See in attached files
 Where: Tor Meetup in Mumbai, India
 Participants: Five (5)
 Methodology: Survey

 **Results**
 1. Summary of demographics
 2. What users said
 3. Conclusion
 4. Recommendations

 **1.**
 ==
 - The group consisted of 5 male users aged 20-50.
 - Most of the users described themselves as and day to day tech users who
 use Tor just on specific situations.

 **2.**
 ==
 Q1 Do you think you would need to click on Configure to connect to Tor?

 - Most users answered ‘NO’ to this question and understand that there was
 no need to configure at this point.

 Q2 What do the checked options do?

 - All users relate checked options with checking for censorship in their
 country. Most of them understood that these options are used for
 connecting to the bridge.

 Q3 Describe in your words how a bridge will help users.

 - Most of the users understand a bridge as a function that helps them
 bypass censored material.
 - Users did not go deep into how the bridge actually works to help users.
 - Quote: “It can help to change the way I am currently connecting on Tor”

 Q4 If Tor is censored in India, what bridge would you use?

 - Most users say they would pick a bridge at random.
 - Most of them hesitated for a few seconds. It seems that users cannot
 tell the advantage of one bridge over another and therefore decide to go
 with an option.
 - Quotes: “...I would choose at random” “I don’t know. I would probably
 

Re: [tor-bugs] #27032 [- Select a component]: Usability Research: Tor Users Demographics - Applications

[Tor Bug Tracker & Wiki]

#27032: Usability Research: Tor Users Demographics - Applications
+--
 Reporter:  nyinz   |  Owner:  nyinz
 Type:  project | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  - Select a component|Version:
 Severity:  Normal  | Resolution:
 Keywords:  user-demographics, ux-team  |  Actual Points:
Parent ID:  #27010  | Points:
 Reviewer:  antonela|Sponsor:
+--
Changes (by antonela):

 * owner:  alison => nyinz
 * status:  new => assigned


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

Re: [tor-bugs] #27051 [Core Tor/Stem]: Stem: is_bandwidth_authority broken

[Tor Bug Tracker & Wiki]

#27051: Stem: is_bandwidth_authority broken
---+-
 Reporter:  tom|  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  wontfix
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by atagar):

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


Comment:

 Yup! Feel free to reopen if you have any other questions.

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

Re: [tor-bugs] #26972 [Core Tor/Tor]: Create CI task to ensure that all Rust files have been formatted with rustfmt

[Tor Bug Tracker & Wiki]

#26972: Create CI task to ensure that all Rust files have been formatted with
rustfmt
--+
 Reporter:  chelseakomlo  |  Owner:  teor
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:
--+

Comment (by cypherpunks3):

 Replying to [comment:3 teor]:

 Rebased the branch and filed #27052.

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

Re: [tor-bugs] #27032 [- Select a component]: Usability Research: Tor Users Demographics - Applications

[Tor Bug Tracker & Wiki]

#27032: Usability Research: Tor Users Demographics - Applications
+
 Reporter:  nyinz   |  Owner:  alison
 Type:  project | Status:  new
 Priority:  Medium  |  Milestone:
Component:  - Select a component|Version:
 Severity:  Normal  | Resolution:
 Keywords:  user-demographics, ux-team  |  Actual Points:
Parent ID:  #27010  | Points:
 Reviewer:  antonela|Sponsor:
+
Changes (by antonela):

 * component:  Community/Outreach => - Select a component


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

Re: [tor-bugs] #27031 [- Select a component]: Usability Research: Tor Users Demographics

[Tor Bug Tracker & Wiki]

#27031: Usability Research: Tor Users Demographics
--+
 Reporter:  nyinz |  Owner:  alison
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:  User Demographics |  Actual Points:
Parent ID:  #27010| Points:
 Reviewer:|Sponsor:
--+
Changes (by antonela):

 * component:  Community/Outreach => - Select a component


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27052 [Core Tor]: document rust/protover and rust/crypto

[Tor Bug Tracker & Wiki]

#27052: document rust/protover and rust/crypto
--+---
 Reporter:  cypherpunks3  |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor  |Version:
 Severity:  Normal|   Keywords:  rust, doc
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 And add `#![deny(missing_docs)]` to the top of the files to enforce it.

 Attempted in
 
[https://gitweb.torproject.org/tor.git/commit/?id=af182d4ab51d6a1a70559bbdcd4ab842aa855684
 af182d4ab51d6a1a70559bbdcd4ab842aa855684] and
 
[https://gitweb.torproject.org/tor.git/commit/?id=b6059297d7cb76f0e00e2098e38d6677d3033340
 b6059297d7cb76f0e00e2098e38d6677d3033340] but forgot the exclamation
 point.

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

Re: [tor-bugs] #27045 [Applications/Tor Browser]: Add option for firefox incremental builds

[Tor Bug Tracker & Wiki]

#27045: Add option for firefox incremental builds
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by boklm):

 * cc: pospeselr (added)


Comment:

 Branch `bug_27045_v2` has a patch adding an option to specify a directory
 containing the firefox sources to use:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_27045_v2=0db721026831589e87634ff104920b2afd5b1839

 You should define `var/ffdev_dir` in `rbm.local.conf` to select your
 firefox sources directory. You can then run `make testbuild-ffdev-
 windows-i686` to do a windows-i686 build.

 pospeselr: could you check if that works for you?

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

Re: [tor-bugs] #25696 [Applications/Tor Browser]: Design of alpha onboarding for Tor Browser for Android

[Tor Bug Tracker & Wiki]

#25696: Design of alpha onboarding for Tor Browser for Android
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-mobile, |  Actual Points:
  TorBrowserTeam201808   |
Parent ID:  #26531   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by emmapeel):

 * cc: emmapeel (added)


Comment:

 I agree that localization of the onboarding strings is very important, as
 the more confused the user, the more important the native language to help
 him/her understand what is going on.

 I imagine I can take mobile/android/base/locales/en-US/android_strings.dtd
 and start with the localization.

 Is there any problem with that?

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

Re: [tor-bugs] #26992 [Core Tor/Tor]: Add intro point IPv6 address to service descriptors

[Tor Bug Tracker & Wiki]

#26992: Add intro point IPv6 address to service descriptors
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, 034-triage-20180328, |
  034-removed-20180328   |
Parent ID:  #23576   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by asn):

 * reviewer:   => asn


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

Re: [tor-bugs] #27034 [Core Tor/Tor]: Clarification on 'GETINFO exit-policy/*'s valid 'non-transient internal errors'

[Tor Bug Tracker & Wiki]

#27034: Clarification on 'GETINFO exit-policy/*'s valid 'non-transient internal
errors'
--+
 Reporter:  atagar|  Owner:  rl1987
 Type:  defect| Status:  needs_review
 Priority:  Low   |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  mikeperry |Sponsor:
--+
Changes (by asn):

 * reviewer:   => mikeperry


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

Re: [tor-bugs] #26947 [Core Tor/Tor]: Add function for reporting the tor version in tor_api.h

[Tor Bug Tracker & Wiki]

#26947: Add function for reporting the tor version in tor_api.h
--+
 Reporter:  hellais   |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #25510| Points:
 Reviewer:  ahf   |Sponsor:  Sponsor8
--+
Changes (by asn):

 * reviewer:   => ahf


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

Re: [tor-bugs] #26948 [Core Tor/Tor]: tor_run_main crashes when called a second time with --version

[Tor Bug Tracker & Wiki]

#26948: tor_run_main crashes when called a second time with --version
+--
 Reporter:  hellais |  Owner:  nickm
 Type:  defect  | Status:
|  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.5.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  034-backport fast-fix 033-backport  |  Actual Points:
Parent ID:  #25510  | Points:
 Reviewer:  ahf |Sponsor:
+--
Changes (by asn):

 * reviewer:   => ahf


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

Re: [tor-bugs] #26818 [Core Tor/Tor]: Use NSS for RSA

[Tor Bug Tracker & Wiki]

#26818: Use NSS for RSA
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-roadmap-subticket, 035-triaged-  |  Actual Points:
  in-20180711|
Parent ID:  #26631   | Points:
 Reviewer:  catalyst |Sponsor:
 |  Sponsor8-can
-+-
Changes (by asn):

 * reviewer:   => catalyst


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

Re: [tor-bugs] #25440 [Core Tor/Tor]: Broken openat syscall in Sandbox mode

[Tor Bug Tracker & Wiki]

#25440: Broken openat syscall in Sandbox mode
-+-
 Reporter:  ageisp0lis   |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  sandbox, 033-must, regression,   |  Actual Points:
  033-triage-20180326, 033-included-20180326,|
  033-backport, AffectsTails,|
  034-deferred-20180602, 035-removed-20180711|
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
-+-
Changes (by asn):

 * reviewer:   => nickm


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

Re: [tor-bugs] #26588 [Core Tor/Tor]: Prune INSTALL file

[Tor Bug Tracker & Wiki]

#26588: Prune INSTALL file
--+--
 Reporter:  Hello71   |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.05
 Reviewer:  mikeperry |Sponsor:
--+--
Changes (by asn):

 * reviewer:   => mikeperry


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

Re: [tor-bugs] #25573 [Core Tor/Tor]: Track half-closed stream IDs

[Tor Bug Tracker & Wiki]

#25573: Track half-closed stream IDs
+--
 Reporter:  mikeperry   |  Owner:  (none)
 Type:  defect  | Status:
|  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  guard-discovery-stats 034-backport  |  Actual Points:
Parent ID:  #25574  | Points:
 Reviewer:  teor|Sponsor:
|  SponsorV-can
+--
Changes (by asn):

 * reviewer:   => teor


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

Re: [tor-bugs] #23576 [Core Tor/Tor]: Make service_intro_point_new() take a node instead of an extend_info

[Tor Bug Tracker & Wiki]

#23576: Make service_intro_point_new() take a node instead of an extend_info
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:
  ipv6, 034-triage-20180328, |
  034-removed-20180328, fast-fix |
Parent ID:  #23493   | Points:  1
 Reviewer:  asn  |Sponsor:
-+-
Changes (by asn):

 * reviewer:   => asn


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

Re: [tor-bugs] #24204 [Core Tor/Tor]: Improve the in-process Tor API: create owning control port

[Tor Bug Tracker & Wiki]

#24204: Improve the in-process Tor API: create owning control port
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, s8-api,  |  Actual Points:
  034-triage-20180328, 035-roadmap-subtask   |
Parent ID:  #25510   | Points:
 Reviewer:  ahf  |Sponsor:
 |  Sponsor8-can
-+-
Changes (by asn):

 * reviewer:   => ahf


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

Re: [tor-bugs] #18642 [Core Tor/Tor]: Teach the OOM handler about the DNS cache

[Tor Bug Tracker & Wiki]

#18642: Teach the OOM handler about the DNS cache
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dos, oom, tor-relay, dns, 035|  Actual Points:
  -triaged-in-20180711   |
Parent ID:   | Points:  1
 Reviewer:  nickm|Sponsor:
 |  SponsorV-can
-+-
Changes (by asn):

 * reviewer:   => nickm


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

Re: [tor-bugs] #27038 [Applications/Tor Browser]: Green Lock for .onion websites

[Tor Bug Tracker & Wiki]

#27038: Green Lock for .onion websites
--+---
 Reporter:  joeyyy589 |  Owner:  tbb-team
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by mcs):

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


Comment:

 Resolved as a duplicate of #23247.

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

Re: [tor-bugs] #23247 [Applications/Tor Browser]: Communicating security expectations for .onion: what to say about different padlock states for .onion services

[Tor Bug Tracker & Wiki]

#23247: Communicating security expectations for .onion: what to say about 
different
padlock states for .onion services
-+-
 Reporter:  isabela  |  Owner:
 |  pospeselr
 Type:  project  | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ux-team, tor-hs, |  Actual Points:
  TorBrowserTeam201806R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 #27038 is a duplicate.

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

Re: [tor-bugs] #26994 [Core Tor/Tor]: Solaris 10: test_bwmgt.c compile error with tor-0.3.4.5-rc

[Tor Bug Tracker & Wiki]

#26994: Solaris 10: test_bwmgt.c compile error with tor-0.3.4.5-rc
-+-
 Reporter:  Knut |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.5-rc
 Severity:  Normal   | Resolution:
 Keywords:  tor-test, solaris, regression,   |  implemented
  035-must 034-backport  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 I've merged the fix that Teor describes (rename SEC to BW_SEC in
 test_bwmgt.c) as a54e94878a438a269659387b9e6eea84f7e12771.  It should
 appear in 0.3.4.6-rc.

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

Re: [tor-bugs] #25696 [Applications/Tor Browser]: Design of alpha onboarding for Tor Browser for Android

[Tor Bug Tracker & Wiki]

#25696: Design of alpha onboarding for Tor Browser for Android
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-mobile, |  Actual Points:
  TorBrowserTeam201808   |
Parent ID:  #26531   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by brade):

 What is your plan / strategy for localizing the onboarding strings?
 Localization is still an open issue for onboarding within the desktop
 version; our plan is to add the strings to a new file within Torbutton and
 modify the Firefox onboarding code to pull the strings from there (which
 is the strategy we have used on desktop for similar situations).

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

Re: [tor-bugs] #26994 [Core Tor/Tor]: Solaris 10: test_bwmgt.c compile error with tor-0.3.4.5-rc

[Tor Bug Tracker & Wiki]

#26994: Solaris 10: test_bwmgt.c compile error with tor-0.3.4.5-rc
-+-
 Reporter:  Knut |  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.5-rc
 Severity:  Normal   | Resolution:
 Keywords:  tor-test, solaris, regression,   |  Actual Points:
  035-must 034-backport  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_information => accepted
 * keywords:  tor-test, solaris, regression, 035-must => tor-test, solaris,
 regression, 035-must 034-backport
 * owner:  (none) => nickm


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

Re: [tor-bugs] #25696 [Applications/Tor Browser]: Design of alpha onboarding for Tor Browser for Android

[Tor Bug Tracker & Wiki]

#25696: Design of alpha onboarding for Tor Browser for Android
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-mobile, |  Actual Points:
  TorBrowserTeam201808   |
Parent ID:  #26531   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by igt0):

 * status:  assigned => needs_review


Comment:

 Implement alpha onboarding:
 https://trac.torproject.org/projects/tor/attachment/ticket/25696/0001-Bug-25696
 -Implement-alpha-onboarding-for-Tor-Browser.patch

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

Re: [tor-bugs] #25696 [Applications/Tor Browser]: Design of alpha onboarding for Tor Browser for Android

[Tor Bug Tracker & Wiki]

#25696: Design of alpha onboarding for Tor Browser for Android
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  defect   | Status:
 |  assigned
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-mobile, |  Actual Points:
  TorBrowserTeam201808   |
Parent ID:  #26531   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by igt0):

 * Attachment "0001-Bug-25696-Implement-alpha-onboarding-for-Tor-
 Browser.patch" added.

 Patch - r0

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

Re: [tor-bugs] #27051 [Core Tor/Stem]: Stem: is_bandwidth_authority broken

[Tor Bug Tracker & Wiki]

#27051: Stem: is_bandwidth_authority broken
---+
 Reporter:  tom|  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by teor):

 tom, the is_bandwidth_authority attribute is deprecated:
 
https://gitweb.torproject.org/stem.git/commit/stem/directory.py?id=6e40a303a96fccd2db3e0370efc3d7d4c54d82a4

 So you should fix consensus-health to check each vote for measured
 bandwidths instead.

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

Re: [tor-bugs] #27035 [Applications/Tor Browser]: Error when loading Tor Browser

[Tor Bug Tracker & Wiki]

#27035: Error when loading Tor Browser
--+--
 Reporter:  paulscupoflinux   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:  Tor: unspecified
 Severity:  Major | Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mcs):

 * status:  new => closed
 * resolution:   => not a bug


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

Re: [tor-bugs] #26965 [Internal Services/Tor Sysadmin Team]: Please create build in Jenkins for support.torproject.org and support-staging.torproject.org

[Tor Bug Tracker & Wiki]

#26965: Please create build in Jenkins for support.torproject.org and support-
staging.torproject.org
-+-
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by hiro):

 * owner:  (none) => tpa
 * component:  Internal Services/Services Admin Team => Internal
 Services/Tor Sysadmin Team


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

Re: [tor-bugs] #26965 [Internal Services/Tor Sysadmin Team]: Please create build in Jenkins for support.torproject.org and support-staging.torproject.org

[Tor Bug Tracker & Wiki]

#26965: Please create build in Jenkins for support.torproject.org and support-
staging.torproject.org
-+-
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hiro):

 Lektor pkg is now in testing

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

Re: [tor-bugs] #26793 [Internal Services/Service - git]: Create /pluggable-transports/httpsproxy repo

[Tor Bug Tracker & Wiki]

#26793: Create /pluggable-transports/httpsproxy repo
-+-
 Reporter:  dcf  |  Owner:  tor-gitadm
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:  httpsproxy pt|  Actual Points:
Parent ID:  #26923   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hiro):

 Sorry I did create this on the 26th of July but forgot to update this
 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] #26974 [Internal Services/Service - git]: Create git repository user/sisbell/tor-browser-build

[Tor Bug Tracker & Wiki]

#26974: Create git repository user/sisbell/tor-browser-build
-+-
 Reporter:  sisbell  |  Owner:  tor-gitadm
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:   |  Actual Points:
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by hiro):

 * status:  new => 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] #27048 [Metrics/Consensus Health]: Bandwidth scanner graphs are empty

[Tor Bug Tracker & Wiki]

#27048: Bandwidth scanner graphs are empty
--+---
 Reporter:  teor  |  Owner:  tom
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:  #27051| Points:
 Reviewer:|Sponsor:
--+---
Changes (by teor):

 * status:  new => closed
 * resolution:   => duplicate
 * parent:   => #27051


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

Re: [tor-bugs] #27048 [Metrics/Consensus Health]: Bandwidth scanner graphs are empty

[Tor Bug Tracker & Wiki]

#27048: Bandwidth scanner graphs are empty
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by tom):

 This is caused by #27051

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27051 [Core Tor/Stem]: Stem: is_bandwidth_authority broken

[Tor Bug Tracker & Wiki]

#27051: Stem: is_bandwidth_authority broken
---+
 Reporter:  tom|  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 {{{
 >>> import stem.descriptor.remote
 >>>
 stem.descriptor.remote.get_authorities().items()[0][1].is_bandwidth_authority
 False
 >>> stem.descriptor.remote.get_authorities().items()[0][1].nickname
 'maatuska'
 }}}

 From

 > commit 1c030e32539d1e10facbb2684c65103bca45b966 (HEAD -> master,
 origin/master, origin/HEAD)
 > Author: Damian Johnson 
 > Date:   Sun Aug 5 18:42:19 2018 -0700

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

Re: [tor-bugs] #27050 [Metrics/Onionoo]: Reverse DNS lookups are still slow

[Tor Bug Tracker & Wiki]

#27050: Reverse DNS lookups are still slow
-+--
 Reporter:  irl  |  Owner:  irl
 Type:  defect   | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

 * status:  new => accepted
 * cc: metrics-team (added)
 * owner:  metrics-team => irl


Comment:

 I am looking at 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

[tor-bugs] #27050 [Metrics/Onionoo]: Reverse DNS lookups are still slow

[Tor Bug Tracker & Wiki]

#27050: Reverse DNS lookups are still slow
-+--
 Reporter:  irl  |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 It would appear that only new relays are looked up. Any relay that already
 exists with a `NodeStatus` is not looked up. I believe this is due to
 incorrectly recording the last lookup time even where no lookup has
 actually occurred.

 The lack of a reverse DNS record and the failure of a lookup (including
 running out of time before even getting to it) all count as success and a
 lookup time will be recorded. This prevents the lookup being attempted
 again for another 12 hours.

 I hadn't spotted this when testing locally as I'd always set
 `RDNS_LOOKUP_MAX_AGE_MILLIS` to `0L` to ensure that every relay was looked
 up every time.

 This has happened this way as I had tried to maintain backwards-bug-
 compatibility with the old field that returned an IP address in cases
 where the lookup did not find an error but also did not find a domain. The
 implementation wasn't strict enough in its bug compatibility because it
 returned an IP address also in error conditions.

 I wonder if it is worth spending time to fix this here, or instead
 removing the `host_name` field (which is optional in the spec, and we did
 deprecate on July 16th) and so not requiring the returning of IP addresses
 at all.

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

Re: [tor-bugs] #12412 [Applications/Orbot]: Orbot broke using TransPort

[Tor Bug Tracker & Wiki]

#12412: Orbot broke using TransPort
-+-
 Reporter:  isis |  Owner:  n8fr8
 Type:  defect   | Status:  new
 Priority:  Immediate|  Milestone:
Component:  Applications/Orbot   |Version:
 Severity:  Blocker  | Resolution:
 Keywords:  orbot-14.0.3.1, orbot-14.0.4, wtf,   |  Actual Points:
  software-engineering   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by SolarElite):

 [[Image()]]

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

Re: [tor-bugs] #27027 [Community/Relays]: TorRelayGuide/NetBSD: set ORPort to 443 where that works out of the box

[Tor Bug Tracker & Wiki]

#27027: TorRelayGuide/NetBSD: set ORPort to 443 where that works out of the box
---+--
 Reporter:  nusenu |  Owner:  egypcio
 Type:  enhancement| Status:  reopened
 Priority:  Medium |  Milestone:
Component:  Community/Relays   |Version:
 Severity:  Normal | Resolution:
 Keywords:  bsd netbsd tdp torbsd  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by egypcio):

 Replying to [comment:7 Toni Bordelo]:

 Hi Toni,

 I see you requested to reopen this ticket. Are you missing something on
 that wiki page? `ORPort 443` is set and the config works as expected for
 NetBSD.

 Please tell us if we missed something, so we fix it.

 Thank you for having a look into it.

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

Re: [tor-bugs] #26901 [Metrics/Onionoo]: Mention that a DNSSEC-validating resolver is used for reverse DNS lookups (was: use a DNSSEC validating resolver while doing DNS lookups for onionoo)

[Tor Bug Tracker & Wiki]

#26901: Mention that a DNSSEC-validating resolver is used for reverse DNS 
lookups
-+--
 Reporter:  nusenu   |  Owner:  irl
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

 * status:  new => accepted
 * owner:  metrics-team => irl


Old description:

> onionoo does DNS lookups for some fields, please use a DNSSEC validating
> resolver.
>
> I don't think it is necessary to add new fields but lets
> add it to the description of the _host_names fields

New description:

 onionoo does DNS lookups for some fields, please use a DNSSEC validating
 resolver.

 I don't think it is necessary to add new fields but lets
 add it to the description of the _host_names fields

 Edit: We already do this, but we still should add some text to the spec.

--

Comment:

 We actually already do this. (:

 The hosts have a local unbound stub resolver installed and this is used by
 Onionoo when performing lookups.

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

Re: [tor-bugs] #27048 [Metrics/Consensus Health]: Bandwidth scanner graphs are empty

[Tor Bug Tracker & Wiki]

#27048: Bandwidth scanner graphs are empty
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by juga):

 * cc: juga (added)


Comment:

 Add myself in CC

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

Re: [tor-bugs] #21994 [Metrics/Consensus Health]: Consensus Health: what is the distribution of a bandwidth authority's measurements?

[Tor Bug Tracker & Wiki]

#21994: Consensus Health: what is the distribution of a bandwidth authority's
measurements?
--+-
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  new
 Priority:  Very Low  |  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by juga):

 * cc: juga (added)


Comment:

 Add myself in CC

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

Re: [tor-bugs] #27049 [Core Tor/Tor]: "No circuits are opened" messages with onion services

[Tor Bug Tracker & Wiki]

#27049: "No circuits are opened" messages with onion services
--+
 Reporter:  mikeperry |  Owner:  mikeperry
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  033-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:   => Tor: 0.3.5.x-final


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

Re: [tor-bugs] #26913 [Core Tor/Tor]: DataDirectoryGroupReadable enabled does not have effect

[Tor Bug Tracker & Wiki]

#26913: DataDirectoryGroupReadable enabled does not have effect
-+-
 Reporter:  maha |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.9
 Severity:  Normal   | Resolution:
 Keywords:  regression, 035-roadmap-proposed,|  Actual Points:
  033-backport, 034-backport |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_information => new


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

Re: [tor-bugs] #26497 [Core Tor/Tor]: set CARGO_HOME correctly or stop using it

[Tor Bug Tracker & Wiki]

#26497: set CARGO_HOME correctly or stop using it
-+-
 Reporter:  catalyst |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, tor-ci, 035-removed-20180711,  |  Actual Points:
  035-roadmap-proposed   |
Parent ID:  #24629   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:   => #24629


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

Re: [tor-bugs] #27049 [Core Tor/Tor]: "No circuits are opened" messages with onion services

[Tor Bug Tracker & Wiki]

#27049: "No circuits are opened" messages with onion services
--+
 Reporter:  mikeperry |  Owner:  mikeperry
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  033-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:1 mikeperry]:
 > https://github.com/torproject/tor/pull/263

 Please `make check-changes`:
 {{{
 ./changes/bug27409:
 bug number 27409 does not appear
 }}}

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

Re: [tor-bugs] #26972 [Core Tor/Tor]: Create CI task to ensure that all Rust files have been formatted with rustfmt

[Tor Bug Tracker & Wiki]

#26972: Create CI task to ensure that all Rust files have been formatted with
rustfmt
--+
 Reporter:  chelseakomlo  |  Owner:  teor
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:
--+
Changes (by teor):

 * status:  assigned => needs_revision
 * reviewer:   => teor
 * type:  task => enhancement


Comment:

 Replying to [comment:2 cypherpunks3]:
 > Can someone check out the branch 'rustfmt-travis' at
 https://gitgud.io/onionk/tor.git ?

 Thanks for this patch!

 The changes look like they should work, but we could tweak a few things to
 follow Tor's standards.

 Here are the changes I'd like to see:
 * open a separate ticket for deny(missing_docs), so we don't forget to fix
 the docs
 * make `cargo fmt --all -- --check` into `make check-rustfmt`. When tor is
 configured with Rust, and rustfmt-preview is installed, run `make check-
 rustfmt` during `make check-spaces`.
 * add a `make rustfmt` target, and tell developers about it if `make
 check-rustfmt` fails.

 (If we make these changes, we won't have to add a separate check to
 travis.)

 > But there's a bug upstream in rustfmt, which happens when it's
 configured with max_width=80 (like it is in `src/rust/.rustfmt.toml`).

 I'm not sure about the impact of the bug.
 Does it produce ugly formatting, or is the syntax incorrect?

 Do you think we should give up on max_width=80?
 We can reconsider wrapping to 80 characters when stable supports wrapping
 comments.

 If we want to match Tor's C files, we should be wrapping to 79 characters:
 https://gitweb.torproject.org/tor.git/tree/doc/HACKING/CodingStandards.md#n177

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

Re: [tor-bugs] #25381 [Core Tor/Tor]: Add crypto_rand_double_sign() in C and Rust

[Tor Bug Tracker & Wiki]

#25381: Add crypto_rand_double_sign() in C and Rust
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, privcount, review-|  Actual Points:  1
  group-34, 034-triage-20180328, |
  034-removed-20180328, rust |
Parent ID:  #26637   | Points:  2
 Reviewer:  isis |Sponsor:
 |  SponsorV-can
-+-

Comment (by teor):

 Replying to [comment:16 cypherpunks3]:
 > It looks like branch rust-rand-f64-v4 was deleted, and there's no other
 branches starting with rust-* in the repo
 https://github.com/teor2345/tor.git
 >
 > Is it still needs_revision if there's nothing left to revise or pick up
 where it left off?

 I archived my old tor repository, so I could fork
 https://github.com/torproject/tor.git
 (GitHub doesn't support pull requests unless the repositories share a
 common fork ancestor.)

 The branch is still at:
 https://github.com/teor2345/tor-old/tree/rust-rand-f64-v4

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

Re: [tor-bugs] #26970 [Core Tor/Tor]: Privcount: plan the modules and components

[Tor Bug Tracker & Wiki]

#26970: Privcount: plan the modules and components
-+-
 Reporter:  teor |  Owner:  teor
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  privcount, 035-roadmap-master, 035   |  Actual Points:
  -triaged-in-20180711, rust |
Parent ID:  #25669   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:1 chelseakomlo]:
 > Ok, here are a few questions/clarifications:
 >
 > 1. Tor main codebase will include:
 > - The Rust "Data Collector" module
 > - Tools for creating/validating configuration.
 > Question: Will the configuration management tooling also be in Rust? Or
 will this be part
 of tor's existing configuration validation/etc?

 The configuration tool will probably be written in Rust, because the
 underlying config parser will be a rust module. We expect to maintain a
 small number (1-5) of configurations for the public tor network, at most
 one per supported tor release:

 
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases

 I don't think there is any value in letting relay operators configure
 their own statistics in detail, because each statistic requires
 accompanying Tor code. And letting operators configure noise amounts is
 dangerous to users. (But we might need some way of activating new
 statistics for testing.)

 > Will this configuration management be the same as for the Tally
 Reporter?

 I expect that Tally Reporters will use the same config format, and support
 the same small number of configurations as Tor.

 > 2. A separate pure-Rust binary
 > - This will be the "Tally Reporter"
 > Question: Will this binary be a sidecar to Tor relays, or will this be
 stand-alone (like a bwauth)?

 There will be a small number of tally reporters (5-9) for the public tor
 network. They will be standalone, like bandwidth authorities or CollecTor
 instances. Tally reporters do not need to be run on directory authorities.
 They take counters from relays, and publish aggregate results for metrics
 to consume.

 > How will this communicate with the Rust module in core tor?

 The Data Collector Rust module will produce the counters document format:
 https://gitweb.torproject.org/torspec.git/tree/proposals/288-privcount-
 with-shamir.txt#n222

 And then these documents will be uploaded to the Tally Reporters using a
 mechanism that we'll specify in a future proposal.

 For example, relays could upload counters documents to directory
 authorities, like they currently upload descriptors and extra-info
 documents:

 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n344

 Then Tally Reporters would download and process the counters documents.

 > Maybe the first step is to separate out these components (if they aren't
 already, apologies if I missed that)?

 Most of the modules and components don't exist yet.

 So I think we should design the modules that belong in the Data Collector
 and Tally Reporter, and see which ones will be shared.

 > The pure-Rust binary will be much easier, and reviewing it will be
 different than reviewing components that will integrate with C (for
 example, logging will be different, etc).

 > Maybe then the second step is to work on integrating the Rust "Data
 Collector" into core tor, and there we can do a review for the FFI layer,
 etc?

 I agree. I want to clean up the privcount_shamir code (it will be a shared
 module), and write the noise module. Then I think we will have enough code
 to integrate a simple counter into core Tor.

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

Re: [tor-bugs] #26919 [Metrics/Onionoo]: Remove fingerprint parameter

[Tor Bug Tracker & Wiki]

#26919: Remove fingerprint parameter
-+---
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_information
 Priority:  Medium   |  Milestone:  Onionoo 1.17.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 So, first result from looking at the logs is that there are still requests
 coming in with the "fingerprint" parameter. We can't say how many, just
 that there's at least 1 per hour. Hmm, this makes this decision a bit
 harder, because we cannot just say it was unused anyway. However, I'd
 still want to take out that parameter and simplify the underlying code.

 How about we wait for feedback from the announcement to take it out in
 about a month, and if nobody shows up with a valid use case that we still
 want to support (and that we did not think of yet), we stick to the plan
 and remove it?

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

Re: [tor-bugs] #12095 [Community/Translations]: Remove dead Transifex teams from translation.git branches

[Tor Bug Tracker & Wiki]

#12095: Remove dead Transifex teams from translation.git branches
+--
 Reporter:  phoul   |  Owner:  emmapeel
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Community/Translations  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by emmapeel):

 bn-BD is not dead, bn is.

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

Re: [tor-bugs] #27047 [Core Tor/Tor]: Authorities should keep recent consensuses, votes, and bandwidth files

[Tor Bug Tracker & Wiki]

#27047: Authorities should keep recent consensuses, votes, and bandwidth files
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth, tor-dirauth, needs-  |  Actual Points:
  design |
Parent ID:  #25925   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by karsten):

 * cc: metrics-team (added)


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

Re: [tor-bugs] #12556 [Community/Translations]: Translation

[Tor Bug Tracker & Wiki]

#12556: Translation
+
 Reporter:  danfong |  Owner:  phoul
 Type:  project | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Community/Translations  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by emmapeel):

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


Comment:

 Because of the way we distributed our releases, it was very difficult to
 add new languages until now.

 In the next months we will provide the Tor Browser in all the languages
 with a complete translation. This is already happening in the Tor Browser
 alpha:

 https://www.torproject.org/projects/torbrowser.html.en#downloads-alpha

 where a zh_TW version is already available.

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

Re: [tor-bugs] #25459 [Metrics/Statistics]: Add graph that compares total consensus weights across bandwidth authorities

[Tor Bug Tracker & Wiki]

#25459: Add graph that compares total consensus weights across bandwidth
authorities
+--
 Reporter:  teor|  Owner:  metrics-team
 Type:  enhancement | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by teor):

 * cc: juga (added)


Comment:

 No worries!

 Please let juga know if there is anything they can do to help with these
 graphs (for example, reviewing the 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] #25459 [Metrics/Statistics]: Add graph that compares total consensus weights across bandwidth authorities

[Tor Bug Tracker & Wiki]

#25459: Add graph that compares total consensus weights across bandwidth
authorities
+--
 Reporter:  teor|  Owner:  metrics-team
 Type:  enhancement | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by karsten):

 Replying to [comment:11 teor]:
 > Replying to [comment:10 karsten]:
 > > Sounds good. Blocking on #21378, but once the data is available in
 CollecTor, let's make a new graph.
 >
 > I don't think archiving bandwidth files (#21378) is blocking this
 ticket.

 Uhm, you're right. We can start working on this ticket as time permits.
 Sorry for the confusion!

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