Re: [tor-bugs] #30051 [Core Tor/Tor]: Add practracker as a pre-commit and pre-push git hook for frequent coders

[Tor Bug Tracker & Wiki]

#30051: Add practracker as a pre-commit and pre-push git hook for frequent 
coders
-+-
 Reporter:  teor |  Owner:  rl1987
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  practracker tech-debt tor-ci git-|  Actual Points:
  scripts tor-ci-fail-sometimes  |
Parent ID:  #29792   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  Sponsor31-must
-+-
Changes (by rl1987):

 * status:  needs_revision => needs_review


Comment:

 https://github.com/torproject/tor/pull/967

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

Re: [tor-bugs] #15125 [Obfuscation/meek]: meek-client-torbrowser does not use signals well (was: meek-client-wrapper does not use signals well)

[Tor Bug Tracker & Wiki]

#15125: meek-client-torbrowser does not use signals well
--+--
 Reporter:  infinity0 |  Owner:  dcf
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * status:  new => needs_review


Comment:

 I came around to the timer idea. #25613 rewrites the way that child
 processes are handled in a way that I think addresses this ticket.
   https://gitweb.torproject.org/pluggable-
 transports/meek.git/log/?h=bug25613&id=36d06b5f9a0d0c4a7aa251f33460886f68a2ab22
 Namely these commits:
 * [https://gitweb.torproject.org/pluggable-
 
transports/meek.git/commit/?h=bug25613&id=adf41cd3adf6e3884626b6b7e4c7f131660343dd
 Be more careful about terminating meek-client.]
 * [https://gitweb.torproject.org/pluggable-
 
transports/meek.git/commit/?h=bug25613&id=1b3a72f3c7208dd7c0471bb3e9077667091874c8
 Be more careful about terminating Firefox.]
 * [https://gitweb.torproject.org/pluggable-
 
transports/meek.git/commit/?h=bug25613&id=36d06b5f9a0d0c4a7aa251f33460886f68a2ab22
 Terminate firefox and meek-client simultaneously.]
 The main differences compared to what has already been discussed on this
 ticket are that there are separate `terminatePTCmd` and `terminateCmd`
 functions (`terminatePTCmd` closes stdin, `terminateCmd` does not),
 separate implementations for Windows and non-Windows (Windows doesn't send
 SIGTERM, and its `terminateCmd` kill the process immediately, without any
 timer, and the two terminations run in parallel, not in series.

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

Re: [tor-bugs] #25613 [Obfuscation/meek]: Close child's stdout to signal exit in meek-client-torbrowser

[Tor Bug Tracker & Wiki]

#25613: Close child's stdout to signal exit in meek-client-torbrowser
--+--
 Reporter:  dcf   |  Owner:  dcf
 Type:  enhancement   | Status:  needs_review
 Priority:  Low   |  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * status:  new => needs_review


Comment:

 Branch bug25613 refactors the way that meek-client-torbrowser handles its
 client processes.
   https://gitweb.torproject.org/pluggable-
 transports/meek.git/log/?h=bug25613&id=36d06b5f9a0d0c4a7aa251f33460886f68a2ab22
   https://gitweb.torproject.org/pluggable-
 
transports/meek.git/diff/?h=bug25613&id=36d06b5f9a0d0c4a7aa251f33460886f68a2ab22&id2=29797a33ecee1c6fc4882fc2b6beabcd64f554ce

 [https://gitweb.torproject.org/pluggable-
 
transports/meek.git/commit/?h=bug25613&id=adf41cd3adf6e3884626b6b7e4c7f131660343dd
 This] is the commit that touches meek-client. We get a handle to the
 child's stdin:
 {{{
 // ptCmd is a *exec.Cmd augmented with an io.WriteCloser for its stdin,
 which we
 // can close to instruct the PT subprocess to terminate.
 type ptCmd struct {
 *exec.Cmd
 StdinCloser io.WriteCloser
 }
 }}}
 then close it as the first step of terminating the process.
 {{{
 err := cmd.StdinCloser.Close()
 }}}

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

Re: [tor-bugs] #30235 [Core Tor/Tor]: Tor hangs when asked to change DisableAllSwap over the control port

[Tor Bug Tracker & Wiki]

#30235: Tor hangs when asked to change DisableAllSwap over the control port
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.4.8-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-ci-fail-sometimes  |  Actual Points:  0.2
Parent ID:  #29437 | Points:  1
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * cc: nickm (added)


Comment:

 Nick might have some idea of what is going wrong 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] #30235 [Core Tor/Tor]: Tor hangs when asked to change DisableAllSwap over the control port (was: Tor hangs when asked to change User and DisableAllSwap over the control port)

[Tor Bug Tracker & Wiki]

#30235: Tor hangs when asked to change DisableAllSwap over the control port
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.4.8-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-ci-fail-sometimes  |  Actual Points:  0.2
Parent ID:  #29437 | Points:  1
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * actualpoints:   => 0.2


Old description:

> {{{
> self.assertRaisesWith(stem.InvalidArguments, "DisableAllSwap, User
> cannot be changed while tor's running", controller.set_options, {'User':
> 'atagar', 'DisableAllSwap': '1'})
> }}}
>
> We don't know why, because we don't have the tor logs or backtrace
> (#30234).

New description:

 {{{
 self.assertRaisesWith(stem.InvalidArguments, "DisableAllSwap, User
 cannot be changed while tor's running", controller.set_options, {'User':
 'atagar', 'DisableAllSwap': '1'})
 }}}
 or
 {{{
   File
 "/home/travis/build/tlyu/tor/stem/test/integ/control/controller.py", line
 793, in test_set_conf_when_immutable
 self.assertRaisesWith(stem.InvalidArguments, "DisableAllSwap cannot be
 changed while tor's running", controller.set_conf, 'DisableAllSwap', '1')
 }}}

 We don't know why, because we don't have the tor logs or backtrace
 (#30234).

--

Comment:

 DisableAllSwap causes this error by itself:
 {{{
   File
 "/home/travis/build/tlyu/tor/stem/test/integ/control/controller.py", line
 793, in test_set_conf_when_immutable
 self.assertRaisesWith(stem.InvalidArguments, "DisableAllSwap cannot be
 changed while tor's running", controller.set_conf, 'DisableAllSwap', '1')
 }}}
 https://travis-ci.org/tlyu/tor/jobs/521994718#L3565

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

Re: [tor-bugs] #29017 [Core Tor/Tor]: PaddingStatistics should be disabled when ExtraInfoStatistics is 0

[Tor Bug Tracker & Wiki]

#29017: PaddingStatistics should be disabled when ExtraInfoStatistics is 0
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  fast-fix, 035-backport,  |  Actual Points:  1.3
  034-backport, postfreeze-ok, 040-can,  |
  dgoulet-merge, 033-backport-unreached, |
  network-team-roadmap-2019-Q1Q2, consider-  |
  backport-after-0404|
Parent ID:   | Points:  0.2
 Reviewer:  nickm|Sponsor:
 |  SponsorV-can
-+-

Comment (by arma):

 Replying to [ticket:29017 teor]:
 > As far as I can tell, PaddingStatistics are collected on bridges, but
 the man page says "Relays only."

 For the historical record: bridge relays are a kind of relay, so "relays
 only" includes bridges.

 (If we want to change this terminology, that's fine, but I bet there will
 be plenty more places, from way back, where it's used this way.)

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

Re: [tor-bugs] #30023 [Internal Services/Tor Sysadmin Team]: improve grafana authentication

[Tor Bug Tracker & Wiki]

#30023: improve grafana authentication
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 i am not familiar with configuring prometheus to fetch metrics from proxy.
 if I understand you correctly, there's a `proxy_url` setting that can be
 added to do that? I cannot confirm that, in any case.

 but sure, that could be possible. i am not sure how that relates to this
 ticket, however, which is specifically about Grafana authentication, not
 really about how Prometheus talks with its exporters, for which there is
 no ticket right now - I thought we had resolved that by selecting only a
 subset of metrics, but I haven't followed the entire conversation in
 #29863. What I saw on IRC was specifically that question:

 >  In IRC it also sounded like there was little-to-no authentication on
 the server that displays these metrics after scraping. Is that the case?

 So I thought we were talking about the "server that displays the metrics",
 ie. Grafana (or the Prometheus frontend), which is why I pointed you here.

 But yes, we have a similar problem with the exporters: in theory, someone
 could do IP spoofing and bypass those firewalls to scrape the metrics off.
 In practice, those stunts are actually quite hard to pull because you need
 to do pretty hardcore stuff like BGP hijacking, because of TCP
 negociations (at least, as far as I understand it, correct me if I'm
 wrong). But I'm not sure the prize (metrics) would be worth the trouble
 (upsetting the internet's routing table).

 As for the specific solution proposed here, I'd be tempted to simply add
 HTTPS and username/password authentication, as it's something I understand
 better and it doesn't require the Tor network to be operational. I always
 feel a little ackward using Tor to monitor internal infrastructure - I'm
 all for eating our own dogfood, but when it comes to monitoring, I feel a
 little less comfortable and prefer redundancy. ;)

 That said, the idea of setting up a secondary server would be that other
 kind of tricks could be tried by other teams, so I don't want to be
 blocking nice initiatives like this. This is just my grain of salt which I
 hope will be useful!

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

Re: [tor-bugs] #28698 [Core Tor/Tor]: When circuit times are fixed, they can't be "relaxed"

[Tor Bug Tracker & Wiki]

#28698: When circuit times are fixed, they can't be "relaxed"
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.7-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  easy, log, intro, fast-fix,  |  Actual Points:  0.2
  035-backport?, consider-backport-after-0404|
Parent ID:   | Points:  0.2
 Reviewer:  mikeperry|Sponsor:
-+-
Changes (by teor):

 * status:  merge_ready => closed
 * version:   => Tor: 0.2.4.7-alpha
 * resolution:   => fixed
 * actualpoints:   => 0.2


Comment:

 Merged to 0.3.5 and merged forward.

 Merged #23790, #29665, #29017, #27199, #29144, #13221, #28698.

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

Re: [tor-bugs] #30243 [Core Tor/Stem]: Stem's tests use fixed ports for tor, which may already be in use

[Tor Bug Tracker & Wiki]

#30243: Stem's tests use fixed ports for tor, which may already be in use
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-ci-single-failure  |  Actual Points:
Parent ID:  #29437 | Points:
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * keywords:  tor-ci-fail-sometimes => tor-ci-single-failure


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

Re: [tor-bugs] #29017 [Core Tor/Tor]: PaddingStatistics should be disabled when ExtraInfoStatistics is 0

[Tor Bug Tracker & Wiki]

#29017: PaddingStatistics should be disabled when ExtraInfoStatistics is 0
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  fast-fix, 035-backport,  |  Actual Points:  1.3
  034-backport, postfreeze-ok, 040-can,  |
  dgoulet-merge, 033-backport-unreached, |
  network-team-roadmap-2019-Q1Q2, consider-  |
  backport-after-0404|
Parent ID:   | Points:  0.2
 Reviewer:  nickm|Sponsor:
 |  SponsorV-can
-+-
Changes (by teor):

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


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

Re: [tor-bugs] #23790 [Core Tor/Tor]: rend_service_prune_list_impl_() doesn't copy over desc_is_dirty when copying intro points

[Tor Bug Tracker & Wiki]

#23790: rend_service_prune_list_impl_() doesn't copy over desc_is_dirty when
copying intro points
-+-
 Reporter:  jl   |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:  fixed
 Keywords:  029-backport, 031-unreached- |  Actual Points:  0.1
  backport, consider-backport-after-0404 |
Parent ID:   | Points:  0.1
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-can
-+-
Changes (by teor):

 * status:  merge_ready => closed
 * version:  Tor: 0.3.1.7 => Tor: unspecified
 * resolution:   => fixed


Comment:

 Merged PR 772 into 0.2.9, and merged forward to 0.3.4 using an "ours"
 merge to avoid carrying forward any changes. (We already merged a
 different fix into 0.3.2 and later.)

 Merged #23790, #29665, #29017, #27199, #29144, #13221, #28698.

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

Re: [tor-bugs] #27199 [Core Tor/Tor]: panic inside rust extern "C" function is undefined behavior

[Tor Bug Tracker & Wiki]

#27199: panic inside rust extern "C" function is undefined behavior
-+-
 Reporter:  cyberpunks   |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  nickm-merge, rust, 034-backport, |  Actual Points:  0.1
  035-backport, 040-backport, 041-proposed, 033  |
  -backport-unreached, consider-backport-|
  after-0404 |
Parent ID:   | Points:  0.1
 Reviewer:  teor |Sponsor:
 |  SponsorV-can
-+-
Changes (by teor):

 * status:  merge_ready => closed
 * resolution:   => fixed
 * milestone:  Tor: 0.3.5.x-final => Tor: 0.3.4.x-final


Comment:

 Merged to 0.3.4, 0.3.5, and merged forward.

 Merged #23790, #29665, #29017, #27199, #29144, #13221, #28698.

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

Re: [tor-bugs] #13221 [Core Tor/Tor]: Misleading error messages about bind_ipv4_only and bind_ipv6_only?

[Tor Bug Tracker & Wiki]

#13221: Misleading error messages about bind_ipv4_only and bind_ipv6_only?
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.3.9-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  041-proposed, tor-client, easy,  |  Actual Points:  .1
  logging, message, usability, 035-backport, |
  040-backport, consider-backport-after-0404 |
Parent ID:   | Points:  .1
 Reviewer:  teor |Sponsor:
-+-
Changes (by teor):

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


Comment:

 Merged to 0.3.5 and merged forward.

 Merged #23790, #29665, #29017, #27199, #29144, #13221, #28698.

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

Re: [tor-bugs] #29144 [Core Tor/Tor]: Log the correct "auto" port number for listening sockets

[Tor Bug Tracker & Wiki]

#29144: Log the correct "auto" port number for listening sockets
-+-
 Reporter:  kjak |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  041-proposed, 035-backport,  |  Actual Points:  0.1
  040-backport, consider-backport-after-0404 |
Parent ID:   | Points:  0.1
 Reviewer:  catalyst |Sponsor:
-+-
Changes (by teor):

 * status:  merge_ready => closed
 * version:   => Tor: 0.3.5.1-alpha
 * resolution:   => fixed
 * actualpoints:   => 0.1


Comment:

 Merged to 0.3.5 and merged forward.

 Merged #23790, #29665, #29017, #27199, #29144, #13221, #28698.

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

Re: [tor-bugs] #29017 [Core Tor/Tor]: PaddingStatistics should be disabled when ExtraInfoStatistics is 0

[Tor Bug Tracker & Wiki]

#29017: PaddingStatistics should be disabled when ExtraInfoStatistics is 0
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  fast-fix, 035-backport,  |  Actual Points:  1.3
  034-backport, postfreeze-ok, 040-can,  |
  dgoulet-merge, 033-backport-unreached, |
  network-team-roadmap-2019-Q1Q2, consider-  |
  backport-after-0404|
Parent ID:   | Points:  0.2
 Reviewer:  nickm|Sponsor:
 |  SponsorV-can
-+-
Changes (by teor):

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


Comment:

 Merged to 0.3.4 and merged forward.

 Merged #23790, #29665, #29017, #27199, #29144, #13221, #28698.

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

Re: [tor-bugs] #29665 [Core Tor/Tor]: hs: circuit_expire_old_circuits_serverside() should check for RP circuits

[Tor Bug Tracker & Wiki]

#29665: hs: circuit_expire_old_circuits_serverside() should check for RP 
circuits
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.1.26
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, tor-relay, 029-backport, |  Actual Points:  0.1
  034-backport, 035-backport, 040-backport,  |
  consider-backport-after-0404   |
Parent ID:   | Points:  0.1
 Reviewer:  asn  |Sponsor:
-+-
Changes (by teor):

 * status:  merge_ready => closed
 * version:   => Tor: 0.2.1.26
 * resolution:   => fixed
 * milestone:  Tor: 0.3.5.x-final => Tor: 0.3.4.x-final


Comment:

 Merged to PR 792 0.2.9, merged PR 791 to 0.3.4 then "ours" merge from
 0.2.9 to avoid conflicts, then merged forward.

 Merged #23790, #29665, #29017, #27199, #29144, #13221, #28698.

 Hi asn, if you're doing multiple branches, please merge forward, then
 edit?
 It makes the backport merge easier.

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

Re: [tor-bugs] #13221 [Core Tor/Tor]: Misleading error messages about bind_ipv4_only and bind_ipv6_only?

[Tor Bug Tracker & Wiki]

#13221: Misleading error messages about bind_ipv4_only and bind_ipv6_only?
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.3.9-alpha
 Severity:  Normal   | Resolution:
 Keywords:  041-proposed, tor-client, easy,  |  Actual Points:  .1
  logging, message, usability, 035-backport, |
  040-backport, consider-backport-after-0404 |
Parent ID:   | Points:  .1
 Reviewer:  teor |Sponsor:
-+-
Changes (by teor):

 * keywords:
 041-proposed, tor-client, easy, logging, message, usability, 029
 -backport-maybe, 034-backport-maybe, 035-backport, 040-backport,
 consider-backport-after-0404
 =>
 041-proposed, tor-client, easy, logging, message, usability,
 035-backport, 040-backport, consider-backport-after-0404


Comment:

 UX issues only go back to the latest LTS.

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

Re: [tor-bugs] #30235 [Core Tor/Tor]: Tor hangs when asked to change User and DisableAllSwap over the control port

[Tor Bug Tracker & Wiki]

#30235: Tor hangs when asked to change User and DisableAllSwap over the control
port
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.4.8-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-ci-fail-sometimes  |  Actual Points:
Parent ID:  #29437 | Points:  1
 Reviewer: |Sponsor:
---+

Comment (by teor):

 The failure doesn't happen all the time, but when it does, it's in the
 same place:
 {{{
 self.assertRaisesWith(stem.InvalidArguments, "DisableAllSwap, User
 cannot be changed while tor's running", controller.set_options, {'User':
 'atagar', 'DisableAllSwap': '1'})
 }}}
 https://travis-ci.org/torproject/tor/jobs/521109187#L3568https://travis-
 ci.org/torproject/tor/jobs/521109187#L3568

 I wonder if:
 * Tor successfully does DisableAllSwap?
 * Switching to `User atagar` succeeds? (It shouldn't: that user doesn't
 exist in Travis)

 I also wonder if there's some race condition between Tor and stem.

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

Re: [tor-bugs] #30051 [Core Tor/Tor]: Add practracker as a pre-commit and pre-push git hook for frequent coders

[Tor Bug Tracker & Wiki]

#30051: Add practracker as a pre-commit and pre-push git hook for frequent 
coders
-+-
 Reporter:  teor |  Owner:  rl1987
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  practracker tech-debt tor-ci git-|  Actual Points:
  scripts tor-ci-fail-sometimes  |
Parent ID:  #29792   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  Sponsor31-must
-+-
Changes (by teor):

 * priority:  Medium => High
 * keywords:  practracker tech-debt tor-ci git-scripts => practracker tech-
 debt tor-ci git-scripts tor-ci-fail-sometimes
 * sponsor:   => Sponsor31-must


Comment:

 CI sometimes fails because we don't check practracker before pushing.

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

Re: [tor-bugs] #28223 [Core Tor/Tor]: Unparseable microdescriptor on public relay

[Tor Bug Tracker & Wiki]

#28223: Unparseable microdescriptor on public relay
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  040-roadmap-proposed, regression?,   |  Actual Points:  .2
  035-can, postfreeze-ok,|
  040-deferred-20190220, asn-merge   |
Parent ID:   | Points:  .2
 Reviewer:  teor |Sponsor:
-+-

Comment (by teor):

 Actually, let's get #30051 done, so we do practracker as a pre-push hook.
 Once all the mergers have the pre-push hook, we won't fail CI master any
 more.

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

Re: [tor-bugs] #30051 [Core Tor/Tor]: Add practracker as a pre-commit and pre-push git hook for frequent coders (was: Add practracker as a post-commit git hook for frequent coders)

[Tor Bug Tracker & Wiki]

#30051: Add practracker as a pre-commit and pre-push git hook for frequent 
coders
-+-
 Reporter:  teor |  Owner:  rl1987
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  practracker tech-debt tor-ci git-|  Actual Points:
  scripts|
Parent ID:  #29792   | Points:  1
 Reviewer:  asn  |Sponsor:
-+-

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

Re: [tor-bugs] #29880 [Core Tor/Tor]: Write a script to update practracker on multiple branches

[Tor Bug Tracker & Wiki]

#29880: Write a script to update practracker on multiple branches
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  042-must, tor-merge-scripts, tor-ci  |  Actual Points:
Parent ID:  #29792   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor31-can
-+-
Changes (by teor):

 * parent:   => #29792


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

Re: [tor-bugs] #28223 [Core Tor/Tor]: Unparseable microdescriptor on public relay

[Tor Bug Tracker & Wiki]

#28223: Unparseable microdescriptor on public relay
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  040-roadmap-proposed, regression?,   |  Actual Points:  .2
  035-can, postfreeze-ok,|
  040-deferred-20190220, asn-merge   |
Parent ID:   | Points:  .2
 Reviewer:  teor |Sponsor:
-+-

Comment (by teor):

 I pushed an extra commit bffba9d26 to master to accept the following
 practracker change:
 {{{
 -problem function-size
 /src/feature/dirparse/microdesc_parse.c:microdescs_parse_from_string() 154
 +problem function-size
 /src/feature/dirparse/microdesc_parse.c:microdescs_parse_from_string() 169
 }}}

 Let's work out how to solve this merge-forward and practracker fails
 issue.
 Requiring a master merge for each backport is one solution (#29881).

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

Re: [tor-bugs] #30243 [Core Tor/Stem]: Stem's tests use fixed ports for tor, which may already be in use

[Tor Bug Tracker & Wiki]

#30243: Stem's tests use fixed ports for tor, which may already be in use
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-ci-fail-sometimes  |  Actual Points:
Parent ID:  #29437 | Points:
 Reviewer: |Sponsor:
---+

Comment (by teor):

 Replying to [comment:1 atagar]:
 > Hi teor. Sure, we could use a random port if you'd like. I'll do so when
 I have some time (though happy to prioritize if this is urgent at all).

 I have only ever seen it once, so we can do it eventually.

 It probably happened due to a simultaneous #30235. So let's focus on
 #30235 and tor's logs.

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

Re: [tor-bugs] #30234 [Core Tor/Tor]: Get a stacktrace from tor processes launched by stem

[Tor Bug Tracker & Wiki]

#30234: Get a stacktrace from tor processes launched by stem
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.4.8-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-ci-fail-sometimes  |  Actual Points:
Parent ID:  #29437 | Points:  0.5
 Reviewer: |Sponsor:
---+

Comment (by teor):

 Replying to [comment:3 atagar]:
 > > Do stem's tests log all Tor output to a file?
 >
 > Do you mean tor's stdout? If so then nope, but we can add that if you'd
 find it useful. The only logging available via our tests is the '--log
 [runlevel]' argument which provides stem's logging information. In
 particular I use '--log trace' when troubleshooting difficult issues.

 We'll need Tor's logs, so we can see Tor's log messages and stacktraces. I
 don't mind if they go to a file, or to stdout, or stderr. We just need to
 be able to get them out of 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] #30218 [Metrics/CollecTor]: Add bandwidth files archiving to CollecTor

[Tor Bug Tracker & Wiki]

#30218: Add bandwidth files archiving to CollecTor
-+-
 Reporter:  irl  |  Owner:
 |  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/CollecTor|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth,tor-dirauth,metrics-  |  Actual Points:
  roadmap-2019-q2|
Parent ID:  #21378   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:2 irl]:
 > We are trying to build more robust archiving solutions to avoid missing
 data, and having a window of only a few minutes in which the data is going
 to be available for certain doesn't help towards that goal. We really
 should have a "current" URL that keeps a copy of the bandwidth file that
 was used for at least as long as the consensus is fresh.

 I agree. We have ticket #27047 for this feature, but it's not on our
 roadmap right now.

 Unfortunately, we've had to minimise non-sponsored work in 2019.

 Is there a current sponsor that wants us to do #27047?
 Or should we ask the grants team to find grants for bandwidth authority
 work?

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

Re: [tor-bugs] #30243 [Core Tor/Stem]: Stem's tests use fixed ports for tor, which may already be in use

[Tor Bug Tracker & Wiki]

#30243: Stem's tests use fixed ports for tor, which may already be in use
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-ci-fail-sometimes  |  Actual Points:
Parent ID:  #29437 | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Hi teor. Sure, we could use a random port if you'd like. I'll do so when I
 have some time (though happy to prioritize if this is urgent 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] #30234 [Core Tor/Tor]: Get a stacktrace from tor processes launched by stem

[Tor Bug Tracker & Wiki]

#30234: Get a stacktrace from tor processes launched by stem
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.4.8-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-ci-fail-sometimes  |  Actual Points:
Parent ID:  #29437 | Points:  0.5
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 > Do stem's tests log all Tor output to a file?

 Do you mean tor's stdout? If so then nope, but we can add that if you'd
 find it useful. The only logging available via our tests is the '--log
 [runlevel]' argument which provides stem's logging information. In
 particular I use '--log trace' when troubleshooting difficult issues.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30243 [Core Tor/Stem]: Stem's tests use fixed ports for tor, which may already be in use

[Tor Bug Tracker & Wiki]

#30243: Stem's tests use fixed ports for tor, which may already be in use
---+---
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:  tor-ci-fail-sometimes
Actual Points: |  Parent ID:  #29437
   Points: |   Reviewer:
  Sponsor: |
---+---
 Can stem choose a random (ideally unused) port instead?
 I thought Travis should virtualise all the ports, but maybe that doesn't
 work as well as it should?

 {{{
 ==
 FAIL: test_launch_tor_with_config_via_stdin
 --
 Traceback (most recent call last):
   File "/home/travis/build/torproject/tor/stem/stem/util/test_tools.py",
 line 152, in 
 self.method = lambda test: self.result(test)  # method that can be
 mixed into TestCases
   File "/home/travis/build/torproject/tor/stem/stem/util/test_tools.py",
 line 227, in result
 test.fail(self._result.msg)
 AssertionError: Traceback (most recent call last):
   File "/home/travis/build/torproject/tor/stem/stem/util/test_tools.py",
 line 169, in _wrapper
 runner(*args) if args else runner()
   File "/home/travis/build/torproject/tor/stem/test/integ/process.py",
 line 502, in test_launch_tor_with_config_via_stdin
 completion_percent = 5
   File "/home/travis/build/torproject/tor/stem/stem/process.py", line 285,
 in launch_tor_with_config
 return launch_tor(tor_cmd, ['-f', '-'], None, completion_percent,
 init_msg_handler, timeout, take_ownership, close_output, stdin =
 config_str)
   File "/home/travis/build/torproject/tor/stem/stem/process.py", line 158,
 in launch_tor
 raise OSError('Process terminated: %s' % last_problem)
 OSError: Process terminated: Failed to bind one of the listener ports.
 --
 Ran 22 tests in 11.493s
 FAILED (failures=1)
 }}}
 https://travis-ci.org/torproject/tor/jobs/521109161#L3633

 I've only seen this error once.
 So if it doesn't happen again, maybe we should just write it off as a
 once-off thing.

 (Also, it might happen a lot more often when a tor process has hung due to
 #30235.)

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

Re: [tor-bugs] #30234 [Core Tor/Tor]: Get a stacktrace from tor processes launched by stem

[Tor Bug Tracker & Wiki]

#30234: Get a stacktrace from tor processes launched by stem
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.4.8-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-ci-fail-sometimes  |  Actual Points:
Parent ID:  #29437 | Points:  0.5
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * owner:  atagar => (none)
 * status:  needs_information => assigned
 * component:  Core Tor/Stem => Core Tor/Tor


Comment:

 I think we need to fix this by changing Tor's Travis CI config.

 Do stem's tests log all Tor output to a file?

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

Re: [tor-bugs] #30235 [Core Tor/Tor]: Tor hangs when asked to change User and DisableAllSwap over the control port

[Tor Bug Tracker & Wiki]

#30235: Tor hangs when asked to change User and DisableAllSwap over the control
port
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.2.4.8-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-ci-fail-sometimes  |  Actual Points:
Parent ID:  #29437 | Points:  1
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * status:  needs_information => assigned
 * owner:  atagar => (none)
 * component:  Core Tor/Stem => Core Tor/Tor


Comment:

 Replying to [comment:1 atagar]:
 > Hi teor. Does this assertion failure consistently repro? If so then
 please tell me the tor commit id I should test against and I'll give this
 a whirl.

 No, it doesn't, unfortunately.

 So far, we've only been able to reproduce it in Travis, in about 1/10
 builds:
 https://travis-ci.org/torproject/tor/jobs/521109187#L3568

 But I think it's probably a Tor bug, so I'll move it to that 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] #29494 [Core Tor/Tor]: Optimize interaction between circuitmux and circuitpadding

[Tor Bug Tracker & Wiki]

#29494: Optimize interaction between circuitmux and circuitpadding
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, network-team-   |  Actual Points:
  roadmap-2019-Q1Q2  |
Parent ID:  #28634   | Points:  5
 Reviewer:   |Sponsor:
 |  Sponsor2
-+-
Changes (by mikeperry):

 * parent:   => #28634


Comment:

 This is not strictly needed for #28634 or 041, but it will change all of
 our padding vs non-padding relative timing delays, which may affect
 classifier accuracy. For apples-to-apples comparisons for future
 attacks+defenses wrt #28634. we should get this in at the same time as it
 lands.

 So yes, I agree. 041.

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

Re: [tor-bugs] #30023 [Internal Services/Tor Sysadmin Team]: improve grafana authentication

[Tor Bug Tracker & Wiki]

#30023: improve grafana authentication
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cohosh):

 * cc: cohosh (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] #30023 [Internal Services/Tor Sysadmin Team]: improve grafana authentication

[Tor Bug Tracker & Wiki]

#30023: improve grafana authentication
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cohosh):

 I don't know enough about LDAP to comment on that solution, but it seems
 plausible. My understanding is that we will eventually have alerts? That
 might make LDAP going offline less of an issue IIUC.

 >
 > The way this would work is we would give you an onion name and an auth
 cookie. You put those in [https://www.torproject.org/docs/tor-
 manual#HidServAuth HidServAuth] in torrc as
 > {{{
 > HidServAuth .onion authcookieauthcookie
 > }}}
 > Then, instead of configuring prometheus to fetch from
 !http://snowflake.bamsoftware.com:9100/, you configure it to fetch from
 !http://.onion:9100/ with a `proxy_url` of
 !socks5://127.0.0.1:9050/.
 >
 > On the server side, we would add [https://www.torproject.org/docs/tor-
 manual#HiddenServiceAuthorizeClient HiddenServiceAuthorizeClient] to
 torrc:
 > {{{
 > HiddenServiceDir /var/lib/tor/prometheus_node_exporter
 > HiddenServicePort 9100 127.0.0.1:9100
 > HiddenServiceAuthorizeClient basic prometheus
 > }}}
 > and then get the auth cookie from
 /var/lib/tor/prometheus_node_exporter/hostname.

 To pull from the conversation in #29863, how difficult would it be to go
 the Onion Service route?

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

Re: [tor-bugs] #29863 [Obfuscation/Snowflake]: Add disk space monitoring for snowflake infrastructure

[Tor Bug Tracker & Wiki]

#29863: Add disk space monitoring for snowflake infrastructure
---+--
 Reporter:  cohosh |  Owner:  (none)
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords:  snowflake  |  Actual Points:
Parent ID:  #30152 | Points:
 Reviewer: |Sponsor:  Sponsor19
---+--

Comment (by cohosh):

 Replying to [comment:17 cohosh]:
 > In IRC it also sounded like there was little-to-no authentication on the
 server that displays these metrics after scraping.  Is that the case?

 anarcat has opened this ticket: #30023 to deal with authentication on the
 graphana server. It's also worth noting that snowflake as well as other
 third-party services TPO decides to monitor will be on the same server.

 We can move the discussion on authentication to that 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] #28780 [Core Tor/Tor]: circpadding: Add machine flag for not closing circuit if machine is active

[Tor Bug Tracker & Wiki]

#28780: circpadding: Add machine flag for not closing circuit if machine is 
active
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:  6
  padding, 041-proposed, network-team-   |
  roadmap-2019-Q1Q2  |
Parent ID:  #28634   | Points:  5
 Reviewer:   |Sponsor:
 |  Sponsor2
-+-
Changes (by mikeperry):

 * status:  needs_revision => needs_review
 * actualpoints:   => 6


Comment:

 Ok, I added a test for circuits_expire_old_circuits_clientside(), and also
 realized that we want to mark the circuit dirty if it wasn't already, so
 that we use the dirtiness timers instead of the idle ones (we want to
 mimic an in-use/used circuit for this).

 All this and more at https://github.com/torproject/tor/pull/966

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

Re: [tor-bugs] #30241 [Applications/Tor Browser]: Bump snowflake to d11e55aabe for 30125

[Tor Bug Tracker & Wiki]

#30241: Bump snowflake to d11e55aabe for 30125
--+--
 Reporter:  cohosh|  Owner:  tbb-team
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  snowflake, TorBrowserTeam201904R  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by boklm):

 * status:  needs_review => closed
 * keywords:  snowflake, TorBrowserTeam201904 => snowflake,
 TorBrowserTeam201904R
 * resolution:   => fixed


Comment:

 Thanks. This is now commit 2bb302e119da53c81297e66ca36de0b599f4f7fa on
 master. I modified the commit subject to include the bug number.

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

Re: [tor-bugs] #29734 [Obfuscation/Snowflake]: Broker should receive country stats information from Proxy and Client

[Tor Bug Tracker & Wiki]

#29734: Broker should receive country stats information from Proxy and Client
-+
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Snowflake|Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, geoip, stats  |  Actual Points:  2
Parent ID:  #29207   | Points:  1
 Reviewer:  ahf  |Sponsor:  Sponsor19
-+
Changes (by cohosh):

 * cc: irl, karsten (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] #21315 [Obfuscation/Snowflake]: publish some realtime stats from the broker?

[Tor Bug Tracker & Wiki]

#21315: publish some realtime stats from the broker?
---+---
 Reporter:  arma   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #29461 | Points:
 Reviewer: |Sponsor:  Sponsor19
---+---
Changes (by phw):

 * cc: phw (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] #30241 [Applications/Tor Browser]: Bump snowflake to d11e55aabe for 30125

[Tor Bug Tracker & Wiki]

#30241: Bump snowflake to d11e55aabe for 30125
-+-
 Reporter:  cohosh   |  Owner:  tbb-team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, TorBrowserTeam201904  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cohosh):

 * status:  needs_revision => needs_review


Comment:

 Ah, here you go.

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

Re: [tor-bugs] #30241 [Applications/Tor Browser]: Bump snowflake to d11e55aabe for 30125

[Tor Bug Tracker & Wiki]

#30241: Bump snowflake to d11e55aabe for 30125
-+-
 Reporter:  cohosh   |  Owner:  tbb-team
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, TorBrowserTeam201904  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cohosh):

 * Attachment "0001-bump-snowflake-version-to-d11e55aabe.patch" added.


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

Re: [tor-bugs] #26608 [Applications/Tor Browser]: investigate

[Tor Bug Tracker & Wiki]

#26608: investigate  
-+-
 Reporter:  mcs  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-linkability, ff60-esr,   |  Actual Points:
  TorBrowserTeam201904   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by acat):

 AFAIK this is controlled via `network.preload` pref and it is still false
 in current nightly (68). So I would assume that it will be still disabled
 for next ESR release.

 In any case, I enabled the pref in current Tor Browser and tested
 different kinds of 'link-rel preloads' (audio, video, script, style,
 fetch...), and could not find a way to make them bypass the FPI.

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

Re: [tor-bugs] #30241 [Applications/Tor Browser]: Bump snowflake to d11e55aabe for 30125

[Tor Bug Tracker & Wiki]

#30241: Bump snowflake to d11e55aabe for 30125
-+-
 Reporter:  cohosh   |  Owner:  tbb-team
 Type:  task | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, TorBrowserTeam201904  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * keywords:  snowflake => snowflake, TorBrowserTeam201904
 * status:  needs_review => needs_revision


Comment:

 This looks good to me too.

 cohosh: Can you post this patch as a git patch file (made from a git
 commit with `git format-patch`), or alternatively a link to a git branch?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30242 [Applications/Tor Browser]: Impossible to change circuit for a site when its SSL certificate is invalid

[Tor Bug Tracker & Wiki]

#30242: Impossible to change circuit for a site when its SSL certificate is 
invalid
-+-
 Reporter:  pf.team  |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  High |  Component:  Applications/Tor
 |  Browser
  Version:   |   Severity:  Normal
 Keywords:  ssl tbb-8.0-issues tor-  |  Actual Points:
  circuit tbb-circuit-display|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
 When accessing a website that uses SSL and the browser raises a
 certificate error (certificate expired, doesn't match domain name etc) the
 user no longer can change the circuit by using the "New Circuit for this
 Site" button. Even if you press it, the browser still keeps using the old
 circuit.

 This is not just an interface error - the circuit remains unchanged, we've
 managed to reproduce this problem while dumping incoming traffic on one of
 our own services, and after the button was pressed, the requests still
 came from the same exit node.

 What is especially important, is that a certificate error may arise not
 only due to actual problems with certificate on the destination server,
 but also because the exit node is compromised and tries to conduct a Man-
 in-the-Middle attack. We observed cases when, with Tor Browser version 6
 and 7, the certificate error went away after changing the circuit, which
 points to the exit node itself being compromised.

 This issue does not allow the user to circumvent a potentially compromised
 exit node to exchange information safely, and forces users to either
 abandon their attempts altogether, accept the incorrect certificate and be
 compromised or go through the process of resetting the identity (that
 still works, but any and all sessions etc are lost, obviously).

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

Re: [tor-bugs] #30241 [Applications/Tor Browser]: Bump snowflake to d11e55aabe for 30125

[Tor Bug Tracker & Wiki]

#30241: Bump snowflake to d11e55aabe for 30125
--+--
 Reporter:  cohosh|  Owner:  tbb-team
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  snowflake |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * status:  new => needs_review


Comment:

 Looks right to me.

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

Re: [tor-bugs] #29203 [Core Tor/Tor]: Add a way to specify machines as reduced circuit padding

[Tor Bug Tracker & Wiki]

#29203: Add a way to specify machines as reduced circuit padding
--+
 Reporter:  mikeperry |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  wtf-pad   |  Actual Points:  0.33
Parent ID:| Points:  4
 Reviewer:|Sponsor:  Sponsor2
--+
Changes (by mikeperry):

 * status:  needs_revision => needs_review


Comment:

 CI issues fixed in PR. Also spec changes at
 https://github.com/torproject/torspec/pull/78

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

Re: [tor-bugs] #30014 [Webpages/Website]: No links to signature files for Tor Browser

[Tor Bug Tracker & Wiki]

#30014: No links to signature files for Tor Browser
--+--
 Reporter:  pf.team   |  Owner:  antonela
 Type:  defect| Status:  reopened
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #29901| Points:
 Reviewer:|Sponsor:
--+--
Changes (by pf.team):

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


Comment:

 We're grateful that you've added links to signatures on the download page,
 but we couldn't help but notice that a button labeled "Sig" may be
 interpreted incorrectly by an inexperienced user, since it simply leads to
 a page with some unfamiliar symbols on it without any instructions on what
 to do with them.

 To make some sense out of it, said user would have to find a link at the
 bottom of the downloads page, which is not visible right away on an
 average screen. Meaning that most users will probably never reach that
 point, and even if they do, they may not make a connection between this
 link and all these "Sig" buttons.

 The instructions themselves don't say where exactly to obtain these
 signatures, and don't mention these "Sig" buttons at all. This is also a
 problem, because unlike the installation files themselves, the "Sig"
 button does not lead to a file download prompt on an average browser.

 If this situation is left "as is", most users will still fail to verify
 their installation files with the signatures provided. We think that it
 would be best to do something similar to the old version, where links to
 installation files for various operating systems were accompanied both by
 links to signatures and a link to the instructions on how to verify them.

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

Re: [tor-bugs] #28693 [Core Tor/Tor]: Add an option to disable circuit padding

[Tor Bug Tracker & Wiki]

#28693: Add an option to disable circuit padding
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:  0.33
  padding, 041-must  |
Parent ID:  #28634   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor2
-+-
Changes (by mikeperry):

 * status:  needs_revision => needs_review


Comment:

 CI issues fixed in the PR.

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

Re: [tor-bugs] #30173 [Core Tor/Tor]: Ensure circuit padding can be safely disabled from consensus

[Tor Bug Tracker & Wiki]

#30173: Ensure circuit padding can be safely disabled from consensus
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:  0.33
  padding, 041-proposed  |
Parent ID:  #28634   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor2-can
-+-
Changes (by mikeperry):

 * status:  needs_revision => needs_review


Comment:

 Ok the CI issues were a couple test-only memory leaks and a handful of
 practracker issues, none of which appeared locally for me for some reason.

 Fixed in the PR.

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

Re: [tor-bugs] #28232 [Applications/GetTor]: Revive GetTor

[Tor Bug Tracker & Wiki]

#28232: Revive GetTor
-+---
 Reporter:  traumschule  |  Owner:  (none)
 Type:  project  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  gettor-roadmap   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor19-can
-+---
Changes (by gaba):

 * keywords:  gettor => gettor-roadmap
 * sponsor:  Sponsor19 => Sponsor19-can


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

Re: [tor-bugs] #28005 [HTTPS Everywhere/EFF-HTTPS Everywhere]: Officially support onions in HTTPS-Everywhere

[Tor Bug Tracker & Wiki]

#28005: Officially support onions in HTTPS-Everywhere
-+-
 Reporter:  asn  |  Owner:  legind
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  HTTPS Everywhere/EFF-HTTPS   |Version:
  Everywhere |
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs https-everywhere tor-ux   |  Actual Points:
Parent ID:  #30029   | Points:  20
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by gaba):

 * cc: gaba (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] #14744 [Applications/GetTor]: Automate upload of latest Tor Browser to cloud services

[Tor Bug Tracker & Wiki]

#14744: Automate upload of latest Tor Browser to cloud services
-+---
 Reporter:  ilv  |  Owner:  (none)
 Type:  defect   | Status:  assigned
 Priority:  High |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  gettor-roadmap   |  Actual Points:
Parent ID:  #8542| Points:
 Reviewer:   |Sponsor:  Sponsor19-can
-+---
Changes (by gaba):

 * status:  reopened => assigned
 * owner:  ilv => (none)
 * sponsor:   => Sponsor19-can
 * keywords:   => gettor-roadmap


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

Re: [tor-bugs] #27330 [Applications/GetTor]: @get_tor on twitter not responding

[Tor Bug Tracker & Wiki]

#27330: @get_tor on twitter not responding
-+---
 Reporter:  steph|  Owner:  (none)
 Type:  defect   | Status:  assigned
 Priority:  High |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  gettor-roadmap   |  Actual Points:
Parent ID:  #28231   | Points:
 Reviewer:   |Sponsor:  Sponsor19-can
-+---
Changes (by gaba):

 * owner:  ilv => (none)
 * 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] #27330 [Applications/GetTor]: @get_tor on twitter not responding

[Tor Bug Tracker & Wiki]

#27330: @get_tor on twitter not responding
-+---
 Reporter:  steph|  Owner:  ilv
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  gettor-roadmap   |  Actual Points:
Parent ID:  #28231   | Points:
 Reviewer:   |Sponsor:  Sponsor19-can
-+---
Changes (by gaba):

 * status:  assigned => 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] #28231 [Applications/GetTor]: Provide more Gettor distribution methods

[Tor Bug Tracker & Wiki]

#28231: Provide more Gettor distribution methods
-+---
 Reporter:  traumschule  |  Owner:  ilv
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  gettor-roadmap   |  Actual Points:
Parent ID:  #28232   | Points:
 Reviewer:   |Sponsor:  Sponsor19-can
-+---
Changes (by gaba):

 * keywords:   => gettor-roadmap
 * sponsor:   => Sponsor19-can


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

Re: [tor-bugs] #27330 [Applications/GetTor]: @get_tor on twitter not responding

[Tor Bug Tracker & Wiki]

#27330: @get_tor on twitter not responding
-+---
 Reporter:  steph|  Owner:  ilv
 Type:  defect   | Status:  assigned
 Priority:  High |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  gettor-roadmap   |  Actual Points:
Parent ID:  #28231   | Points:
 Reviewer:   |Sponsor:  Sponsor19-can
-+---
Changes (by gaba):

 * keywords:   => gettor-roadmap
 * sponsor:   => Sponsor19-can


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

Re: [tor-bugs] #8542 [Applications/GetTor]: More options on how to get the bundles

[Tor Bug Tracker & Wiki]

#8542: More options on how to get the bundles
-+--
 Reporter:  mrphs|  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  gettor-roadmap   |  Actual Points:
Parent ID:  #28232   | Points:
 Reviewer:   |Sponsor:  Sponsor8-can
-+--
Changes (by gaba):

 * keywords:   => gettor-roadmap
 * sponsor:   => Sponsor8-can


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

Re: [tor-bugs] #10692 [Applications/GetTor]: GetTor needs official two-factor-enabled dropbox and google accounts

[Tor Bug Tracker & Wiki]

#10692: GetTor needs official two-factor-enabled dropbox and google accounts
-+---
 Reporter:  mrphs|  Owner:  (none)
 Type:  defect   | Status:  reopened
 Priority:  High |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  gettor-roadmap   |  Actual Points:
Parent ID:  #8542| Points:
 Reviewer:   |Sponsor:  Sponsor19-can
-+---
Changes (by gaba):

 * cc: ioerror (removed)
 * keywords:   => gettor-roadmap
 * sponsor:   => Sponsor19-can


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

Re: [tor-bugs] #28152 [Applications/GetTor]: Gettor code refactor with Python Twisted

[Tor Bug Tracker & Wiki]

#28152: Gettor code refactor with Python Twisted
-+---
 Reporter:  ilv  |  Owner:  ilv
 Type:  enhancement  | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Major| Resolution:
 Keywords:  gettor-roadmap   |  Actual Points:
Parent ID:  #28232   | Points:
 Reviewer:   |Sponsor:  Sponsor19
-+---
Changes (by gaba):

 * keywords:   => gettor-roadmap
 * sponsor:   => Sponsor19


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

Re: [tor-bugs] #30125 [Obfuscation/Snowflake]: Port server's log sanitization to client, broker, and proxy-go

[Tor Bug Tracker & Wiki]

#30125: Port server's log sanitization to client, broker, and proxy-go
---+-
 Reporter:  dcf|  Owner:  cohosh
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor19
---+-
Changes (by cohosh):

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


Comment:

 > For the client, we'll need a Tor Browser ticket to pick up the upgrade.
 A sample ticket and patch that can serve as a template is #26795. I know
 you are interested in the reproducible build and this would be a good
 introduction to rbm if you haven't used it yet. Basically, you just need
 to edit projects/snowflake/config and update git_hash, then run make
 testbuild to make sure it still builds, then open a ticket in the
 Applications/Tor Browser component.

 Opened #30241 and attached a patch. I had to add some additional lines to
 `projects/snowflake/build` because of some changes we made in factoring
 out libraries since the last update.

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

Re: [tor-bugs] #30241 [Applications/Tor Browser]: Bump snowflake to d11e55aabe for 30125

[Tor Bug Tracker & Wiki]

#30241: Bump snowflake to d11e55aabe for 30125
--+--
 Reporter:  cohosh|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  snowflake |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cohosh):

 * Attachment "Bug-30241-Bump-snowflake-to-d11e55aabe-for-30125.patch"
 added.


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

[tor-bugs] #30241 [Applications/Tor Browser]: Bump snowflake to d11e55aabe for 30125

[Tor Bug Tracker & Wiki]

#30241: Bump snowflake to d11e55aabe for 30125
--+---
 Reporter:  cohosh|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  snowflake
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 This sanitizes client logs to not record proxy IP addresses and also
 removes the unneeded SDP stanzas from logs.

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

Re: [tor-bugs] #30235 [Core Tor/Stem]: Tor hangs when asked to change User and DisableAllSwap over the control port

[Tor Bug Tracker & Wiki]

#30235: Tor hangs when asked to change User and DisableAllSwap over the control
port
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Stem  |Version:  Tor: 0.2.4.8-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-ci-fail-sometimes  |  Actual Points:
Parent ID:  #29437 | Points:  1
 Reviewer: |Sponsor:
---+
Changes (by atagar):

 * status:  new => needs_information


Comment:

 Hi teor. Does this assertion failure consistently repro? If so then please
 tell me the tor commit id I should test against and I'll give this a
 whirl.

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

Re: [tor-bugs] #30234 [Core Tor/Stem]: Get a stacktrace from tor processes launched by stem

[Tor Bug Tracker & Wiki]

#30234: Get a stacktrace from tor processes launched by stem
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Stem  |Version:  Tor: 0.2.4.8-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-ci-fail-sometimes  |  Actual Points:
Parent ID:  #29437 | Points:  0.5
 Reviewer: |Sponsor:
---+
Changes (by atagar):

 * status:  new => needs_information


Comment:

 Hi teor. Happy to help but I'm a bit unsure what the ask is from me on
 this.

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

Re: [tor-bugs] #30240 [Core Tor/RPM packaging]: Tor should ship docker images of onion services (and other services)

[Tor Bug Tracker & Wiki]

#30240: Tor should ship docker images of onion services (and other services)
-+-
 Reporter:  asn  |  Owner:  hiviah
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/RPM packaging   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs docker sysadmin   |  Actual Points:
  infrastructure |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by asn):

 * owner:  (none) => hiviah
 * component:  Applications => Core Tor/RPM packaging


Old description:

> Seems like people are interested in docker images of Tor relays, or onion
> services (or even bridgedb). We should consider providing docker images
> for the people who want to use them.
>
> Here is a recent attempt by Alessandro Fiori:
> https://lists.torproject.org/pipermail/tor-dev/2019-March/013756.html
>
> and there have been previous attempts as well here:
> https://blog.jessfraz.com/post/running-a-tor-relay-with-docker/ (tor
> relay)
>
> https://www.andreafortuna.org/2018/11/05/easily-setup-a-onion-service-
> using-docker/
> https://0day.work/dockerized-tor-onion-services-with-vanity-v3-tor-
> addresses/ (onion services)
>
> We should figure out how to make these unofficial attempt useful to other
> people by legitimizing them and offering them to people in a useful way.

New description:

 Seems like people are interested in docker images of Tor relays, or onion
 services (or even bridgedb). We should consider providing docker images
 for the people who want to use them.

 Here is a recent attempt by Alessandro Fiori:
 https://lists.torproject.org/pipermail/tor-dev/2019-March/013756.html

 and there have been previous attempts as well here:
 https://blog.jessfraz.com/post/running-a-tor-relay-with-docker/ (tor
 relay)

 Also see this page for an organized version of infrastructure related
 projects:
 https://trac.torproject.org/projects/tor/wiki/community/relay_infrastructure

 https://www.andreafortuna.org/2018/11/05/easily-setup-a-onion-service-
 using-docker/
 https://0day.work/dockerized-tor-onion-services-with-vanity-v3-tor-
 addresses/ (onion services)

 We should figure out how to make these unofficial attempt useful to other
 people by legitimizing them and offering them to people in a useful way.

--

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

[tor-bugs] #30240 [Applications]: Tor should ship docker images of onion services (and other services)

[Tor Bug Tracker & Wiki]

#30240: Tor should ship docker images of onion services (and other services)
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:   |Version:
  Applications   |   Keywords:  tor-hs docker sysadmin
 Severity:  Normal   |  infrastructure
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Seems like people are interested in docker images of Tor relays, or onion
 services (or even bridgedb). We should consider providing docker images
 for the people who want to use them.

 Here is a recent attempt by Alessandro Fiori:
 https://lists.torproject.org/pipermail/tor-dev/2019-March/013756.html

 and there have been previous attempts as well here:
 https://blog.jessfraz.com/post/running-a-tor-relay-with-docker/ (tor
 relay)

 https://www.andreafortuna.org/2018/11/05/easily-setup-a-onion-service-
 using-docker/
 https://0day.work/dockerized-tor-onion-services-with-vanity-v3-tor-
 addresses/ (onion services)

 We should figure out how to make these unofficial attempt useful to other
 people by legitimizing them and offering them to people in a useful way.

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

Re: [tor-bugs] #30239 [Applications/Tor Browser]: TBA: Gracefully handle auto-restart after crash

[Tor Bug Tracker & Wiki]

#30239: TBA: Gracefully handle auto-restart after crash
--+--
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by sysrqb):

 For comparison:

 Inducing crash when app is in the foreground:
 {{{
 16:45:42.208  3366  3672 I ActivityManager: Killing
 18191:org.torproject.torbrowser_alpha/u0a163 (adj 200): crash
 16:45:42.209  3366  3672 W ActivityManager: Scheduling restart of crashed
 service
 org.torproject.torbrowser_alpha/org.torproject.android.service.TorService
 in 1000ms
 16:45:42.210  3366  3672 W ActivityManager: Scheduling restart of crashed
 service
 org.torproject.torbrowser_alpha/org.mozilla.gecko.media.MediaControlService
 in 11000ms
 16:45:42.223  3366  3672 I ActivityManager: START u0
 {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER]
 flg=0x1030
 cmp=org.torproject.torbrowser_alpha/org.mozilla.gecko.BrowserApp (has
 extras)} from uid 10163
 16:45:42.393  3366  3385 I zygote64: Successfully killed process cgroup
 uid 10163 pid 18191 in 183ms
 16:45:42.401  3366  3852 I ActivityManager: Start proc
 7967:org.torproject.torbrowser_alpha/u0a163 for activity
 org.torproject.torbrowser_alpha/org.mozilla.gecko.BrowserApp
 16:45:42.421  3366  3383 W ActivityManager: Stopping service due to app
 idle: u0a163 -12h38m17s389ms
 org.torproject.torbrowser_alpha/org.torproject.android.service.TorService
 16:45:42.557  7967  7967 I GeckoApplication: zerdatime 1133026572 -
 application start
 16:45:42.597  7967  7967 D GeckoMemoryMonitor: onTrimMemory() notification
 received with level 5
 16:45:42.597  7967  7967 D GeckoMemoryMonitor: increasing memory pressure
 to 2
 16:45:42.677  7967  7987 D GeckoSharedPrefs: Current version = 2, prefs
 version = 2
 16:45:42.900  7967  7967 D GeckoThread: State changed to LAUNCHED
 16:45:42.901  7967  7991 I GeckoThread: preparing to run Gecko
 16:45:42.902  7967  7991 D GeckoThread: State changed to MOZGLUE_READY
 16:45:42.915  7967  7991 E GeckoLibLoad: Load sqlite start
 }}}

 Inducing crash when app is in the background:
 {{{
 16:48:45.775  3366 32292 I ActivityManager: Killing
 7967:org.torproject.torbrowser_alpha/u0a163 (adj 200): crash
 16:48:45.776  3366 32292 W ActivityManager: Scheduling restart of crashed
 service
 org.torproject.torbrowser_alpha/org.mozilla.gecko.media.MediaControlService
 in 1000ms
 16:48:45.776  3366 32292 W ActivityManager: Scheduling restart of crashed
 service
 org.torproject.torbrowser_alpha/org.torproject.android.service.TorService
 in 1000ms
 16:48:45.854  3366  5727 I WindowManager: WIN DEATH: Window{117bf63 u0
 org.torproject.torbrowser_alpha/org.mozilla.gecko.BrowserApp}
 16:48:45.865  3366  3385 I zygote64: Successfully killed process cgroup
 uid 10163 pid 7967 in 88ms
 16:48:46.793  3366  3383 I ActivityManager: Start proc
 8338:org.torproject.torbrowser_alpha/u0a163 for service
 org.torproject.torbrowser_alpha/org.torproject.android.service.TorService
 16:48:46.883  8338  8338 I GeckoApplication: zerdatime 1133210899 -
 application start
 16:48:46.905  8338  8338 D GeckoMemoryMonitor: onTrimMemory() notification
 received with level 5
 16:48:46.905  8338  8338 D GeckoMemoryMonitor: increasing memory pressure
 to 2
 16:48:46.910  8338  8338 W orbrowser_alpha: type=1400 audit(0.0:467): avc:
 denied { setattr } for name="libTor.so" dev="dm-2" ino=392562
 scontext=u:r:untrusted_app:s0:c512,c768
 tcontext=u:object_r:apk_data_file:s0 tclass=file permissive=0
 16:48:46.917  8338  8338 I TorService: onCreate end
 16:48:46.930  8338  8338 D Orbot   : Got null onStartCommand() intent
 16:48:47.039  8338  8354 D torResources: deleting existing torrc.custom
 16:48:59.927  3946  3946 D ServiceStateProvider: subId=1


 16:50:24.837  3366  1981 I ActivityManager: START u0
 {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER]
 flg=0x1020 cmp=org.torproject.torbrowser_alpha/.App
 bnds=[237,1607][448,1807] (has extras)} from uid 10031
 16:50:24.897  3366  3379 I ActivityManager: START u0
 {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER]
 flg=0x20
 cmp=org.torproject.torbrowser_alpha/org.mozilla.gecko.BrowserApp
 bnds=[237,1607][448,1807] (has extras)} from uid 10163
 16:50:24.952  8338  8353 D GeckoSharedPrefs: Current version = 2, prefs
 version = 2
 16:50:24.960  8338  8338 D GeckoThread: State changed to LAUNCHED
 16:50:24.961  8338  8469 I GeckoThread: preparing to run Gecko
 16:50:24.962  8338  8469 D GeckoThread: State changed to M

[tor-bugs] #30239 [Applications/Tor Browser]: TBA: Gracefully handle auto-restart after crash

[Tor Bug Tracker & Wiki]

#30239: TBA: Gracefully handle auto-restart after crash
--+
 Reporter:  sysrqb|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-mobile
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Sometimes Android kills background/idle applications (arbitrarily) as a
 way of freeing memory needed by active/foreground apps or need by other
 system services. In some cases, the app is automatically restarted after
 some time period. Tor Browser on Android does not handle this well. When
 the app is opened, after it is "restarted", the user is shown a blank,
 purple screen. This leads me to think it is loading the TorBootstrap
 fragment, but it doesn't render (?).

 {{{
 13:59:19.189  3366  8097 I WindowManager: WIN DEATH: Window{bfd4312 u0
 org.torproject.torbrowser_alpha/org.mozilla.gecko.BrowserApp}
 13:59:19.223  3366  3380 I ActivityManager: Process
 org.torproject.torbrowser_alpha (pid 18467) has died: prcp FGS
 13:59:19.223  3366  3380 W ActivityManager: Scheduling restart of crashed
 service
 org.torproject.torbrowser_alpha/org.mozilla.gecko.media.MediaControlService
 in 23746ms
 13:59:19.223  3366  3380 W ActivityManager: Scheduling restart of crashed
 service
 org.torproject.torbrowser_alpha/org.torproject.android.service.TorService
 in 23746ms
 13:59:43.190  3366  3383 I ActivityManager: Start proc
 32619:org.torproject.torbrowser_alpha/u0a163 for service
 org.torproject.torbrowser_alpha/org.torproject.android.service.TorService

 15:46:44.817  3366  5721 I ActivityManager: START u0
 {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER]
 flg=0x1020 cmp=org.torproject.torbrowser_alpha/.App
 bnds=[237,1607][448,1807] (has extras)} from uid 10031
 15:46:44.966  3366  5711 I ActivityManager: START u0
 {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER]
 flg=0x20
 cmp=org.torproject.torbrowser_alpha/org.mozilla.gecko.BrowserApp
 bnds=[237,1607][448,1807] (has extras)} from uid 10163

 15:46:45.058 32619 32641 D GeckoSharedPrefs: Current version = 2, prefs
 version = 2
 }}}

 I can reproduce this by inducing a crash while the app is in the
 background (open torbrowser, then switch to another app, and then induce
 the crash, then reopen the torbrowser).

 {{{
 $ adb shell am crash org.torproject.torbrowser_alpha
 }}}

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

Re: [tor-bugs] #29819 [Core Tor/Tor]: Seccomp: sandbox crash on rt_sigaction with libseccomp 0.2.4

[Tor Bug Tracker & Wiki]

#29819: Seccomp: sandbox crash on rt_sigaction with libseccomp 0.2.4
---+
 Reporter:  toralf |  Owner:  nickm
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor   |Version:  Tor: unspecified
 Severity:  Normal | Resolution:
 Keywords:  crash, linux, sandbox  |  Actual Points:
Parent ID: | Points:  0.2
 Reviewer: |Sponsor:
---+

Comment (by toralf):

 I applied the 2.4.0..2.4.1 diff here at a stable Gentoo hardened and got
 not
 {{{
 t44 /etc/portage/patches/sys-libs/libseccomp-2.4.0 # tail -f
 /tmp/notice.log
 Apr 18 16:40:34.000 [notice] Bootstrapped 20% (onehop_create):
 Establishing an encrypted directory connection
 Apr 18 16:40:34.000 [notice] Bootstrapped 25% (requesting_status): Asking
 for networkstatus consensus
 Apr 18 16:40:34.000 [notice] Bootstrapped 30% (loading_status): Loading
 networkstatus consensus
 Apr 18 16:40:34.000 [notice] I learned some more directory information,
 but not enough to build a circuit: We have no usable consensus.
 Apr 18 16:40:34.000 [notice] Bootstrapped 40% (loading_keys): Loading
 authority key certs
 Apr 18 16:40:34.000 [warn] Could not open "/var/lib/tor/data/unverified-
 microdesc-consensus" for mmap(): Permission denied
 Apr 18 16:40:34.000 [notice] I learned some more directory information,
 but not enough to build a circuit: We have no usable consensus.
 Apr 18 16:40:44.000 [notice] Application request when we haven't used
 client functionality lately. Optimistically trying directory fetches
 again.
 Apr 18 16:40:47.000 [notice] Application request when we haven't used
 client functionality lately. Optimistically trying directory fetches
 again.
 Apr 18 16:40:47.000 [notice] Application request when we haven't used
 client functionality lately. Optimistically trying directory fetches
 again.
 }}}
 The perms are:
 {{{
 t44 /etc/portage/patches/sys-libs/libseccomp-2.4.0 # ls -l
 /var/lib/tor/data/
 total 12108
 -rw--- 1 tor tor   20442 Apr 18 16:40 cached-certs
 -rw--- 1 tor tor 2110905 Apr 18 16:16 cached-microdesc-consensus
 -rw--- 1 tor tor 5965233 Apr 11 18:20 cached-microdescs
 -rw--- 1 tor tor 2163133 Apr 18 16:17 cached-microdescs.new
 -rw--- 1 tor tor  32 Apr 18 16:40 control_auth_cookie
 drwx-- 1 tor tor 224 Aug 18  2017 keys
 -rw--- 1 tor tor   0 Apr 18 16:40 lock
 -rw--- 1 tor tor   12212 Apr 18 16:40 state
 -rw--- 1 tor tor 2111522 Apr 18 16:40 unverified-microdesc-consensus
 }}}

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

Re: [tor-bugs] #30218 [Metrics/CollecTor]: Add bandwidth files archiving to CollecTor

[Tor Bug Tracker & Wiki]

#30218: Add bandwidth files archiving to CollecTor
-+-
 Reporter:  irl  |  Owner:
 |  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/CollecTor|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth,tor-dirauth,metrics-  |  Actual Points:
  roadmap-2019-q2|
Parent ID:  #21378   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by irl):

 We are trying to build more robust archiving solutions to avoid missing
 data, and having a window of only a few minutes in which the data is going
 to be available for certain doesn't help towards that goal. We really
 should have a "current" URL that keeps a copy of the bandwidth file that
 was used for at least as long as the consensus is fresh.

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

Re: [tor-bugs] #18098 [Core Tor/Tor]: prop224: Implement tor-genkey tool for offline HS key creation

[Tor Bug Tracker & Wiki]

#18098: prop224: Implement tor-genkey tool for offline HS key creation
---+---
 Reporter:  dgoulet|  Owner:  haxxpop
 Type:  enhancement| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, 040-deferred-20190220  |  Actual Points:
Parent ID:  #14389 | Points:  6
 Reviewer: |Sponsor:  Sponsor27-can
---+---
Changes (by mcs):

 * cc: brade, mcs (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] #18098 [Core Tor/Tor]: prop224: Implement tor-genkey tool for offline HS key creation

[Tor Bug Tracker & Wiki]

#18098: prop224: Implement tor-genkey tool for offline HS key creation
---+---
 Reporter:  dgoulet|  Owner:  haxxpop
 Type:  enhancement| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, 040-deferred-20190220  |  Actual Points:
Parent ID:  #14389 | Points:  6
 Reviewer: |Sponsor:  Sponsor27-can
---+---
Changes (by asn):

 * parent:   => #14389


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

Re: [tor-bugs] #18098 [Core Tor/Tor]: prop224: Implement tor-genkey tool for offline HS key creation

[Tor Bug Tracker & Wiki]

#18098: prop224: Implement tor-genkey tool for offline HS key creation
---+---
 Reporter:  dgoulet|  Owner:  haxxpop
 Type:  enhancement| Status:
   |  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, 040-deferred-20190220  |  Actual Points:
Parent ID: | Points:  6
 Reviewer: |Sponsor:  Sponsor27-can
---+---
Changes (by asn):

 * sponsor:  SponsorR-can => Sponsor27-can


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

Re: [tor-bugs] #29787 [Metrics/Onionperf]: Enumerate possible failure cases and include failure information in .tpf output

[Tor Bug Tracker & Wiki]

#29787: Enumerate possible failure cases and include failure information in .tpf
output
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by acute):

 Replying to [comment:18 karsten]:
 > Hey, that's cool, thanks for finding that last remaining bug! (Do you
 think we could move that discussion to another ticket; it seems important
 to get that fixed, but it's not directly related to figure out in what
 ways OnionPerf measurements can fail.)

 This issue has been filed under bug #30238.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30238 [Metrics/Onionperf]: OnionPerf json analysis file is different than the one recreated from logs

[Tor Bug Tracker & Wiki]

#30238: OnionPerf json analysis file is different than the one recreated from 
logs
+---
 Reporter:  acute   |  Owner:  metrics-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  Metrics/Onionperf
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
 OP creates json analysis files at midnight from the logs collected on the
 respective day. Recreating the json analysis file from the logs collected
 on 01-13-19 on op-ab yields a different result than the json analysis
 created by onionperf at the time of analysis. We should investigate why OP
 was cut short in the middle of the analysis for that particular day (my
 file is 16MB, op-ab's is 7.7MB). When I recreate any of the other json
 files from their respective logs (have tried for ~10 other days), the
 contents and sizes match up.

 We should prevent this  from happening as we may use the json logs for
 analysis.

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

Re: [tor-bugs] #29374 [Metrics/Onionperf]: Analysis files sometimes present negative numbers in the payload_progress field

[Tor Bug Tracker & Wiki]

#29374: Analysis files sometimes present negative numbers in the 
payload_progress
field
---+--
 Reporter:  irl|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords:  acute-2019-q1-planned  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by acute):

 Replying to [comment:5 karsten]:
 > Interesting! I didn't know that OnionPerf only looks at `[transfer-*]`
 log lines. This is also good to know for #29787, just in case we need
 information from other log lines to further identify the failure case. And
 I'd be curious how we match these log lines to Tor controller event logs
 if we don't know the source port. But this can all be part of #29787.

 Agreed!

 >For this ticket, how about we leave out `payload_progress` for
 measurements where are unable to extract that information from log lines
 we parse.
 >And step 2 could easily happen as a separate enhancement ticket to be
 done in the future. What do you think?

 Do you mean that for now we should change the parser to leave the field
 out entirely in cases where the transfer does not complete? Also, +1 to
 discussing the parser refactoring in a new 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] #30024 [Applications/Tor Browser]: Objective 2, Activity 3: Notify users if a current website they are visiting on Tor Browser has an onion service version

[Tor Bug Tracker & Wiki]

#30024: Objective 2, Activity 3: Notify users if a current website they are
visiting on Tor Browser has an onion service version
--+
 Reporter:  pili  |  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor27-must
--+

Comment (by asn):

 Right now this task has no blockers on the network-team since the TB team
 has inherited the Onion-Location proposal. It's all TB/UX work here, and
 network-team can be used for reviewing.

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

Re: [tor-bugs] #30000 [Applications/Tor Browser]: Objective 2, Activity 1: Integrating client-side authorization to onion services v3

[Tor Bug Tracker & Wiki]

#3: Objective 2, Activity 1: Integrating client-side authorization to onion
services v3
--+
 Reporter:  pili  |  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201904  |  Actual Points:
Parent ID:| Points:  network-team:
  |  12-22
 Reviewer:|Sponsor:  Sponsor27-must
--+
Changes (by asn):

 * points:  3 => network-team: 12-22


Comment:

 Updating points for network team. See #14389.

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

Re: [tor-bugs] #14389 [Core Tor/Tor]: little-t-tor: Provide support for better TBB UI of hidden service client authorization

[Tor Bug Tracker & Wiki]

#14389: little-t-tor: Provide support for better TBB UI of hidden service client
authorization
-+-
 Reporter:  asn  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tbb-usability, ux-team, hs-  |  Actual Points:
  auth   |
Parent ID:  #30237   | Points:  12-22
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by asn):

 * points:   => 12-22


Comment:

 Here are the tasks that need to happen from the network-team side here:

 - How does TB learn that a page needs client auth? It's likely there is no
 proper way for the TB to learn that a page needs client auth, that won't
 generate a huge log file error dump or extra HSDir queries. This is
 related to comment:15 and comment:27. We should figure out the right
 interface here. This might even be related to the error interface we've
 been discussing in #30022 since there is no standard way to carry errors
 from Tor to TBB right now. (points: 9)

 - Network-team needs to help TB/UX team with the proper UX for v3 client
 auth. This ticket contains mockups and info about v2, but v3 is different.
 In particular, in v3, the client needs to input two keys (x25519/ed25519)
 to Tor for client auth to work, or it can load the keys from a .key file.
 We should figure out how that should work in general. e.g. inputting two
 keys is messy and confusing. perhaps we can unite them into a single
 string? (points: 3)

 - In v3 client auth, clients can generate public keypairs that they pass
 to the onion service. We currently have some super hacky scripts to do
 that (e.g. https://github.com/pastly/python-
 snippits/blob/master/src/tor/x25519-gen.py), but we've been discussing
 writing a proper tor-keygen program to do that. Interfacing (the
 nonexistent) tor-keygen with TB and making the UX will certainly be some
 effort. This might be an optional part of this deliverable for later if we
 have time (points: 10).

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

Re: [tor-bugs] #14389 [Core Tor/Tor]: little-t-tor: Provide support for better TBB UI of hidden service client authorization

[Tor Bug Tracker & Wiki]

#14389: little-t-tor: Provide support for better TBB UI of hidden service client
authorization
-+-
 Reporter:  asn  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tbb-usability, ux-team, hs-  |  Actual Points:
  auth   |
Parent ID:  #30237   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by asn):

 * component:  Applications/Tor Browser => Core Tor/Tor


Comment:

 Hello, I repurposed this ticket to be about the network-team-side of the
 Sponsor27 deliverable, because it contains too many useful little-t-tor
 information from our discussion with Arthur 4 years ago. The respective
 TB-side ticket is #30237.

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

Re: [tor-bugs] #14389 [Applications/Tor Browser]: little-t-tor: Provide support for better TBB UI of hidden service client authorization

[Tor Bug Tracker & Wiki]

#14389: little-t-tor: Provide support for better TBB UI of hidden service client
authorization
-+-
 Reporter:  asn  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tbb-usability, ux-team, hs-  |  Actual Points:
  auth   |
Parent ID:  #30237   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by asn):

 * parent:  #3 => #30237


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

Re: [tor-bugs] #14389 [Applications/Tor Browser]: little-t-tor: Provide support for better TBB UI of hidden service client authorization

[Tor Bug Tracker & Wiki]

#14389: little-t-tor: Provide support for better TBB UI of hidden service client
authorization
-+-
 Reporter:  asn  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tbb-usability, ux-team, hs-  |  Actual Points:
  auth   |
Parent ID:  #30237   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Description changed by asn:

Old description:

> The current hidden service spec allows clients to authenticate themselves
> using auth-cookies. The future proposal 224 will allow clients to
> authenticate using username/password or pubkey.
>
> Currently users have to edit their torrc and add HidServAuth lines for
> the hidden services that require authorization. In the future, it would
> be nicer if TBB had an interface for users to type in their authorization
> credentials.
>
> Tor knows whether an HS needs authorization, because the intro list is
> encrypted. Tor would have to somehow transfer this knowledge to TBB, so
> that the browser can present a nice UI that the user can fill on the go.
>
> Furthermore, with the future username/password authorization and this UI
> improvement, it won't be necessary for people to write on their torrc
> which hidden services they visit and what's their auth-cookie.
>
> This is a ticket about finding out what mods need to happen in
> little-t-tor, and coordinating the development of this feature.

New description:

 **This is the network-team-side of ticket #30237.
 **
 The current hidden service spec allows clients to authenticate themselves
 using auth-cookies. The future proposal 224 will allow clients to
 authenticate using username/password or pubkey.

 Currently users have to edit their torrc and add HidServAuth lines for the
 hidden services that require authorization. In the future, it would be
 nicer if TBB had an interface for users to type in their authorization
 credentials.

 Tor knows whether an HS needs authorization, because the intro list is
 encrypted. Tor would have to somehow transfer this knowledge to TBB, so
 that the browser can present a nice UI that the user can fill on the go.

 Furthermore, with the future username/password authorization and this UI
 improvement, it won't be necessary for people to write on their torrc
 which hidden services they visit and what's their auth-cookie.

 This is a ticket about finding out what mods need to happen in
 little-t-tor, and coordinating the development of this feature.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30237 [Applications/Tor Browser]: Tor Browser: Improve TBB UI of hidden service client authorization

[Tor Bug Tracker & Wiki]

#30237: Tor Browser: Improve TBB UI of hidden service client authorization
--+
 Reporter:  asn   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
  |  TorBrowserTeam201904
Actual Points:|  Parent ID:  #3
   Points:|   Reviewer:
  Sponsor:  Sponsor27-must|
--+
 This is the parent ticket for Sponsor27 Objective1 Activity1  about
 improving the UI of client authorization.

 This used to be #14389, but it contained too many network-team-specific
 information so I repurposed #14389 to be about the network-team side of
 things, and please use this ticket for the Tor Browser side of things.

 Resources about setting up client auth:
 https://2019.www.torproject.org/docs/tor-onion-
 service.html.en#CookieAuthentication
 https://lists.torproject.org/pipermail/tor-
 project/2019-January/002180.html
 and
 
https://github.com/torproject/tor/blob/7741b21d0e3afbfc6d60a852fce6992724c4ae71/doc/tor.1.txt#L3021
 and
 
https://github.com/torproject/tor/blob/7741b21d0e3afbfc6d60a852fce6992724c4ae71/doc/tor.1.txt#L1122

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

Re: [tor-bugs] #14389 [Applications/Tor Browser]: little-t-tor: Provide support for better TBB UI of hidden service client authorization (was: Improve TBB UI of hidden service client authorization)

[Tor Bug Tracker & Wiki]

#14389: little-t-tor: Provide support for better TBB UI of hidden service client
authorization
-+-
 Reporter:  asn  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tbb-usability, ux-team, hs-  |  Actual Points:
  auth   |
Parent ID:  #3   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-

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

Re: [tor-bugs] #27680 [Core Tor/Tor]: Explain how to use auth cookie for onion services

[Tor Bug Tracker & Wiki]

#27680: Explain how to use auth cookie for onion services
--+
 Reporter:  traumschule   |  Owner:  traumschule
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  hs-auth   |  Actual Points:
Parent ID:  #3| Points:
 Reviewer:  asn   |Sponsor:  Sponsor27-must
--+
Changes (by asn):

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


Comment:

 It now works: https://2019.www.torproject.org/docs/tor-onion-
 service.html.en#CookieAuthentication

 Thanks hiro!

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

Re: [tor-bugs] #30149 [Core Tor/Tor]: Fix "medium" and "low" impact coverity false positives outside of tests.

[Tor Bug Tracker & Wiki]

#30149: Fix "medium" and "low" impact coverity false positives outside of tests.
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  asn-merge coverity technical-debt|  Actual Points:  .1
  defensive-programming  |
Parent ID:  #30146   | Points:
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by asn):

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


Comment:

 Merged to master.

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

Re: [tor-bugs] #28223 [Core Tor/Tor]: Unparseable microdescriptor on public relay

[Tor Bug Tracker & Wiki]

#28223: Unparseable microdescriptor on public relay
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  040-roadmap-proposed, regression?,   |  Actual Points:  .2
  035-can, postfreeze-ok,|
  040-deferred-20190220, asn-merge   |
Parent ID:   | Points:  .2
 Reviewer:  teor |Sponsor:
-+-
Changes (by asn):

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


Comment:

 Merged to 040 and onwards.

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

Re: [tor-bugs] #30114 [Core Tor/Tor]: Also fetch tor-github when we git-pull-all.sh

[Tor Bug Tracker & Wiki]

#30114: Also fetch tor-github when we git-pull-all.sh
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor:
  |  0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  git-scripts, fast-fix, asn-merge  |  Actual Points:  0.1
Parent ID:| Points:  0.1
 Reviewer:  nickm |Sponsor:
--+
Changes (by asn):

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


Comment:

 Merged to master.

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

Re: [tor-bugs] #29209 [Core Tor/Tor]: Reduce visibility of more data type internals

[Tor Bug Tracker & Wiki]

#29209: Reduce visibility of more data type internals
+--
 Reporter:  nickm   |  Owner:  (none)
 Type:  task| Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt refactoring  |  Actual Points:  3.5
Parent ID:  | Points:  15
 Reviewer:  nickm   |Sponsor:  Sponsor31-can
+--

Comment (by asn):

 I opened #30236 for the crypt_path case.

 I agree that the private approach I took is suboptimal. Here are some
 thoughts about the options above:
 - Option1: I find usin the downcast approach a bit of an overkill here,
 but it might be the right way forward.
 - Option2: I think I like this, it seems quite simple. The only negative
 is that there is no warning if someone uses the private field outside of a
 private file, but I don't think people will attempt to do that with that
 name and macro (and appropriate docs).
 - Option3: I don't think I like this because `#define b PRIV(b)` might
 hijack lots of stuff. So for example, in the crypt_path_t.crypto case we
 would have to do `#define crypto PRIV(crypto)` and that would hijack all
 the cryptos in the file. Also it would be bad form to not capitalize
 `crypto` in that case, and ugly if we did.
 - Option4: This also seems like a plausible one. I'm not sure what `pvt`
 is there tho. I like the fact that it throws a message.

 I think right now I'm leaning more towards option2 for being the most
 lightweight one and easy to understand. What do you think?

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

Re: [tor-bugs] #30236 [Core Tor/Tor]: Encapsulate details about crypt_path_t data structure

[Tor Bug Tracker & Wiki]

#30236: Encapsulate details about crypt_path_t data structure
+--
 Reporter:  asn |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt refactoring  |  Actual Points:
Parent ID:  #29209  | Points:
 Reviewer:  |Sponsor:
+--
Description changed by asn:

Old description:



New description:

 Child ticket of #29209: see
 https://trac.torproject.org/projects/tor/ticket/29209#comment:3 for more
 details.

--

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

Re: [tor-bugs] #30236 [Core Tor/Tor]: Encapsulate details about crypt_path_t data structure

[Tor Bug Tracker & Wiki]

#30236: Encapsulate details about crypt_path_t data structure
+--
 Reporter:  asn |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt refactoring  |  Actual Points:
Parent ID:  #29209  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by asn):

 Child ticket of #29209: see
 https://trac.torproject.org/projects/tor/ticket/29209#comment:3 for more
 details.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30236 [Core Tor/Tor]: Encapsulate details about crypt_path_t data structure

[Tor Bug Tracker & Wiki]

#30236: Encapsulate details about crypt_path_t data structure
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  technical-debt refactoring
Actual Points:|  Parent ID:  #29209
   Points:|   Reviewer:
  Sponsor:|
--+


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

Re: [tor-bugs] #30074 [Community/Translations]: Clarify what is the plan with bn, bn-BD, bn-IN, that are now different versions in Mozilla l10n

[Tor Bug Tracker & Wiki]

#30074: Clarify what is the plan with bn, bn-BD, bn-IN, that are now different
versions in Mozilla l10n
+--
 Reporter:  emmapeel|  Owner:  emmapeel
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Community/Translations  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  l10n, localization  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Description changed by emmapeel:

Old description:

> There used to be a time when there was no bn in Mozilla. There was only
> bn-BD.
>
> Now, there is bn, bn-BD, bn-IN.
>
> We only have bn in Transifex and most translators say 'it is almost the
> same'.
>
> This ticket is here to take a decision about that.

New description:

 There used to be a time when there was no bn in Mozilla. There was only
 bn-BD.

 Now, there is bn, bn-BD, bn-IN.

 * We only have bn in Transifex and most translators say 'it is almost the
 same'.
 * We haven't got an alpha now because of #29257 but it will be called bn-
 BD
 * The translators are quite active and our documentation is already
 translated, they are translating only one language as bn in Transifex.

 This ticket is here to take a decision about 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] #29844 [Community/Translations]: Make sure that all torbutton branches give AB-CD instead of AB_CD

[Tor Bug Tracker & Wiki]

#29844: Make sure that all torbutton branches give AB-CD instead of AB_CD
+--
 Reporter:  emmapeel|  Owner:  gk
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Community/Translations  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by emmapeel):

 * owner:  emmapeel => gk


Comment:

 I think this ticket can be closed now.

 I reassign to you in case you want to have a look before.

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

Re: [tor-bugs] #28780 [Core Tor/Tor]: circpadding: Add machine flag for not closing circuit if machine is active

[Tor Bug Tracker & Wiki]

#28780: circpadding: Add machine flag for not closing circuit if machine is 
active
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding, 041-proposed, network-team-   |
  roadmap-2019-Q1Q2  |
Parent ID:  #28634   | Points:  5
 Reviewer:   |Sponsor:
 |  Sponsor2
-+-

Comment (by asn):

 Hm, PR#933 is completely independent from #28634. I took your branch
 (PR#644) and I rebased it to origin/master and added a fixup commit.

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

Re: [tor-bugs] #29940 [Community/Translations]: merges in transifex

[Tor Bug Tracker & Wiki]

#29940: merges in transifex
+--
 Reporter:  emmapeel|  Owner:  emmapeel
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Community/Translations  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  l10n|  Actual Points:
Parent ID:  #29844  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by emmapeel):

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


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

Re: [tor-bugs] #29940 [Community/Translations]: merges in transifex

[Tor Bug Tracker & Wiki]

#29940: merges in transifex
+--
 Reporter:  emmapeel|  Owner:  emmapeel
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Community/Translations  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  l10n|  Actual Points:
Parent ID:  #29844  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by emmapeel):

 OK! pt, es and hr are sorted out.

 * pt is not there anymore, we have pt-PT and pt-BR now.

 * hr is hr, not hr-HR

 * (es is going to be offered as es_ES on our torbutton repos, although is
 mapping to es in Transifex. This situation has not changed, we have only
 deleted a ghost es_ES in Transifex with no translations)

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

Re: [tor-bugs] #30074 [Community/Translations]: Clarify what is the plan with bn, bn-BD, bn-IN, that are now different versions in Mozilla l10n

[Tor Bug Tracker & Wiki]

#30074: Clarify what is the plan with bn, bn-BD, bn-IN, that are now different
versions in Mozilla l10n
+--
 Reporter:  emmapeel|  Owner:  emmapeel
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Community/Translations  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  l10n, localization  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by emmapeel):

 * status:  new => assigned
 * keywords:  l10n => l10n, localization
 * parent:  #29940 =>


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

Re: [tor-bugs] #29734 [Obfuscation/Snowflake]: Broker should receive country stats information from Proxy and Client

[Tor Bug Tracker & Wiki]

#29734: Broker should receive country stats information from Proxy and Client
-+
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Snowflake|Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, geoip, stats  |  Actual Points:  2
Parent ID:  #29207   | Points:  1
 Reviewer:  ahf  |Sponsor:  Sponsor19
-+

Comment (by dcf):

 Oh and it looks like country stats don't get incremented whenever
 `GetCountryByAddr` doesn't find a match. I'm afraid this will make
 analysis difficult if a large fraction of proxies aren't covered by the
 geoip database, or the database is improperly installed, or something.
 Could we count them with a country code of `"??"` or something?

 
https://github.com/cohosh/snowflake/blob/fb01c2d1c9d402cc4d96f01df2e6fb6cb37bc9a6/broker/geoip.go#L213
 `GetCountryByAddr` returns `(string, error)`, but failure to find an entry
 in a database is not really an "error". It makes it seem like there are
 three return stats possible (found, not found, error) when really there
 are only two (found, not found). How about changing the signature to
 {{{
 func GetCountryByAddr(table GeoIPTable, ip net.IP) (string, bool)
 }}}
 where the second return value is an `ok` flag, like when indexing a map or
 reading from a channel. The caller can then do the `"??"` substitution
 whenever `!ok`.

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

Re: [tor-bugs] #29734 [Obfuscation/Snowflake]: Broker should receive country stats information from Proxy and Client

[Tor Bug Tracker & Wiki]

#29734: Broker should receive country stats information from Proxy and Client
-+
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Snowflake|Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, geoip, stats  |  Actual Points:  2
Parent ID:  #29207   | Points:  1
 Reviewer:  ahf  |Sponsor:  Sponsor19
-+
Changes (by dcf):

 * status:  needs_review => needs_revision


Comment:

 I have just a few further changes to recommend.

 *
 
https://github.com/cohosh/snowflake/blob/fb01c2d1c9d402cc4d96f01df2e6fb6cb37bc9a6/broker/broker.go#L221
   {{{
 strings.Split(r.RemoteAddr, ":")[0]
   }}}
   This will fail for IPv6 addresses. Better to use net.SplitHostPort and
 check the error return. The host–port splitting could also happen inside
 of `Metrics.UpdateCountryStats`.
 *
 
https://github.com/cohosh/snowflake/blob/fb01c2d1c9d402cc4d96f01df2e6fb6cb37bc9a6/broker/geoip.go#L196
   {{{
 _, err = io.WriteString(hash, scanner.Text())
   }}}
   A better way to do this may be to do `hashedFile :=
 io.TeeReader(geoipFile, hash)` and then `scanner :=
 bufio.NewScanner(hashedFile)` so that the hash is calculated as a side
 effect of reading the file. There's no need to handle errors when writing
 to a `hash.Hash` because it is documented to never error.
 *
 
https://github.com/cohosh/snowflake/blob/fb01c2d1c9d402cc4d96f01df2e6fb6cb37bc9a6/broker/geoip.go#L14
   {{{
 Recognized line formats for IPv4 are:
 INTIPLOW,INTIPHIGH,CC
 and
 "INTIPLOW","INTIPHIGH","CC","CC3","COUNTRY NAME"
   }}}
   It looks like the code doesn't recognize the 5-element syntax, so it
 should be omitted here, or, if it's a common format, documented as not
 being supported.

 Replying to [comment:22 cohosh]:
 > Replying to [comment:18 dcf]:
 > > * Is there any way to disable the geoip feature, if I don't have the
 necessary files, other than by providing an invalid path? Maybe we don't
 care to provide a way to disable the feature and it's the operator's
 responsibility to provide some kind of geoip files; but in that case, it
 may be better to exit with an error if the files cannot be read, rather
 than logging the error and continuing on. It is perhaps surprising that
 you can explicitly ask for a certain file on the command line with
 `-geoipdb path`, and the broker will run even if the path cannot be read.
 > > *  It looks to me like if a geoip lookup fails, it is silently
 ignored—this could be misleading. It would be good to distinguish three
 cases: geoip file present and lookup found a country code; geoip file
 present but lookup found nothing; geoip file absent so no lookup is
 possible.
 > Added a -disablegeoip option that will not load geoip tables and will
 not return an error if UpdateCountryStats fails. Otherwise
 UpdateCountryStats will return an error if it fails and loading the table
 will panic if the file does not exist or if it is incorrectly formatted.

 Okay. Let's replace the panic with a `log.Fatal` so the failure gets
 logged.

 > > * The `parseEntry` functions need error checking on `geoipStringToIP`
 and `net.ParseIP`, or else they will store a `nil` that will result in a
 panic later on.
 
[https://github.com/cohosh/snowflake/blob/4de81ed039ce28264a98a040a0fde2237844e779/broker/geoip.go#L93
 This error] will be more useful if it includes a line number. Let me
 suggest a different factoring of the geoip parsing code. Have `parseEntry`
 be a plain function, not a method on `GeoIPv4Table`, and have it return
 `(GeoIPEntry, error)` rather than inserting into the table itself.
 GeoIPLoadFile can do the entry insertion, count lines and annotate the
 error result from `parseEntry`.
 > The difficulty in refactoring it this way is that ipv4 and ipv6 tables
 have differently formated entries that need to be parse differently.
 > I added error checking to parseEntry and have it return `(GeoIPEntry,
 error)` as suggested, but leave it as a method on GeoIPv4Table and
 GeoIPv6Table.

 I didn't explain this well. I meant that there should be separate
 functions for the two formats e.g. `parseEntryIPv4` and `parseEntryIPv6`.
 The existing `parseEntry` methods never refer to `table`, so they don't
 need to be methods. But leaving them as methods is fine too.

 IMO annotating the error message with the problematic line should be done
 in `GeoIPLoadFile`, not in `parseEntry`. This will eliminate the
 duplication of the common `"Provided geoip file is incorrectly formatted"`
 string and ensure that all the error paths get annotated. What I mean is,
 in the `scanner.Scan()` loop, you can replace `return err` with `return
 fmt.Errorf("Provided