Re: [tor-bugs] #29280 [Core Tor/Tor]: Use Chutney in Tor's CI (was: Use Chutney for CI)

[Tor Bug Tracker & Wiki]

#29280: Use Chutney in Tor's CI
-+-
 Reporter:  cohosh   |  Owner:  (none)
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  CI, PTs 029-backport 034-backport|  Actual Points:  1
  035-backport 040-backport, network-team-   |
  roadmap-2019-Q1Q2  |
Parent ID:  #29267   | Points:
 Reviewer:  teor |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] #30035 [Applications/Tor Browser]: unexpected exit on startup

[Tor Bug Tracker & Wiki]

#30035: unexpected exit on startup
--+--
 Reporter:  TDionysus |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  unexpected exit   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * owner:  (none) => tbb-team
 * version:  Tor: unspecified =>
 * component:  - Select a component => Applications/Tor Browser


Comment:

 Are you using an admin account on macOS?
 Are you using an account with parental controls active?

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

Re: [tor-bugs] #29960 [Core Tor/Tor]: Actually check for errors in digest256_to_base64() and callers

[Tor Bug Tracker & Wiki]

#29960: Actually check for errors in digest256_to_base64() and callers
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.2.6-alpha
 Severity:  Normal| Resolution:
 Keywords:  technical-debt, fast-fix  |  Actual Points:  0.4
Parent ID:| Points:  0.2
 Reviewer:  nickm |Sponsor:  Sponsor31-can
--+
Changes (by teor):

 * status:  needs_revision => needs_review
 * type:  defect => enhancement
 * actualpoints:  0.2 => 0.4


Comment:

 I re-did the PR, with asserts for impossible failures. I also ran it
 through chutney, in case I made any mistakes.

 Please review https://github.com/torproject/tor/pull/908

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

Re: [tor-bugs] #30035 [- Select a component]: unexpected exit on startup

[Tor Bug Tracker & Wiki]

#30035: unexpected exit on startup
--+--
 Reporter:  TDionysus |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  - Select a component  |Version:  Tor: unspecified
 Severity:  Major | Resolution:
 Keywords:  unexpected exit   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by TDionysus):

 * Attachment "rep1.png" added.


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

[tor-bugs] #30035 [- Select a component]: unexpected exit on startup

[Tor Bug Tracker & Wiki]

#30035: unexpected exit on startup
--+--
 Reporter:  TDionysus |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Component:  - Select a component
  Version:  Tor: unspecified  |   Severity:  Major
 Keywords:  unexpected exit   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 I have just gotten an apple computer, and have never owned one before.
 when i downloaded and ran tor early yesterday i had no issues. when i open
 in yesterday night and now around midnight here it says upon loading that
 it has unexpectedly exited. I have re downloaded and its the newest on the
 main download page. the logs show nothing and im highly confused as this
 had never happened on any of my other computers.

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

Re: [tor-bugs] #29645 [Core Tor/Tor]: test.exe hangs on Appveyor CI

[Tor Bug Tracker & Wiki]

#29645: test.exe hangs on Appveyor CI
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  asn-merge, tor-ci, tor-windows,  |  Actual Points:  0.4
  tor-test, hang, tor-ci-fail-sometimes, |
  034-backport, 035-backport, 040-backport   |
Parent ID:   | Points:  1
 Reviewer:  nickm|Sponsor:
-+-

Comment (by teor):

 (I had to force-push to change the commit message.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30034 [Core Tor/Tor]: Make the pre-push hook check for fixups on both sides of a merge

[Tor Bug Tracker & Wiki]

#30034: Make the pre-push hook check for fixups on both sides of a merge
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  git-scripts
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Sometimes when I do a change, then merge it forward, the pre-push hook
 doesn't pick up on fixup commits in the merged branch.

 Can we check both sides of a merge during the pre-push hook?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30033 [Core Tor/Tor]: The pre-push hook should call the pre-commit hook on every commit

[Tor Bug Tracker & Wiki]

#30033: The pre-push hook should call the pre-commit hook on every commit
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  git-scripts
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Sometimes when I do a change, then merge it forward, the pre-commit hook
 doesn't pick up style errors. That's because the pre-commit hook uses the
 old version of our maint scripts, but then I merge the changes into a
 version with stricter maint scripts.

 Can we call the pre-commit hook on every pushed commit during the pre-push
 hook?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30032 [Applications/Tor Browser]: Add warning or disable adding additional extensions

[Tor Bug Tracker & Wiki]

#30032: Add warning or disable adding additional extensions
--+--
 Reporter:  legind|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 A few users of the Tor Browser have reached out to the EFF extension
 developers team wanting help with Privacy Badger.  As we've explained in
 the past[1], installing Privacy Badger within Tor Browser can seriously
 impede the anonymity guarantees of TB.  Even extensions which under normal
 circumstances in mainline Firefox would increase privacy can be harmful in
 the TB context - for instance, canvas hash randomizers can move the
 browser from the relatively large anonymity pool of "TB users on Linux" to
 the much smaller pool of "TB users on Linux who have a canvas randomizer",
 since the fact that your canvas is randomized is able to be determined by
 any remote site.  Users of TB are more likely to be power users and
 install additional addons as well.

 Currently, installing an extension in TB is as easy as doing the same in
 Firefox.  We should either disable the ability to install additional
 extensions or add a highly eye-catching warning alerting users to the fact
 that extensions, even ones that are privacy-oriented, can be harmful to
 anonymity.

 1. https://tor.stackexchange.com/questions/15653/why-does-tor-not-pre-
 include-privacy-badger-or-disconnect-add-ons

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

Re: [tor-bugs] #29036 [Core Tor/Tor]: Coverage merge failures cause test_process_slow stderr check to fail

[Tor Bug Tracker & Wiki]

#29036: Coverage merge failures cause test_process_slow stderr check to fail
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Major| Resolution:
 Keywords:  asn-merge, nickm-merge,  |  Actual Points:  0.6
  041-accepted-20190115, regression, tor-ci, |
  029-backport, 034-backport, 035-backport,  |
  040-backport, tor-ci-fail-sometimes|
Parent ID:   | Points:  0.5
 Reviewer:  catalyst |Sponsor:
-+-
Changes (by teor):

 * status:  needs_revision => merge_ready


Comment:

 Ok, I removed the Makefile line that deletes the gcno files.

 Please merge ​https://github.com/torproject/tor/pull/879 to 0.4.0 and
 later.

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

Re: [tor-bugs] #29645 [Core Tor/Tor]: test.exe hangs on Appveyor CI

[Tor Bug Tracker & Wiki]

#29645: test.exe hangs on Appveyor CI
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  asn-merge, tor-ci, tor-windows,  |  Actual Points:  0.4
  tor-test, hang, tor-ci-fail-sometimes, |
  034-backport, 035-backport, 040-backport   |
Parent ID:   | Points:  1
 Reviewer:  nickm|Sponsor:
-+-
Changes (by teor):

 * status:  needs_revision => merge_ready
 * keywords:
 tor-ci, tor-windows, tor-test, hang, tor-ci-fail-sometimes,
 034-backport, 035-backport, 040-backport
 =>
 asn-merge, tor-ci, tor-windows, tor-test, hang, tor-ci-fail-sometimes,
 034-backport, 035-backport, 040-backport
 * actualpoints:  0.3 => 0.4


Comment:

 I fixed the changes file, and merged forward to the other PRs. Let's
 merge!

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

Re: [tor-bugs] #29437 [Core Tor/Stem]: test-stem times out intermittently

[Tor Bug Tracker & Wiki]

#29437: test-stem times out intermittently
---+--
 Reporter:  rl1987 |  Owner:  teor
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-ci-fail-sometimes  |  Actual Points:  0.2
Parent ID: | Points:  0.2
 Reviewer: |Sponsor:
---+--
Changes (by teor):

 * owner:  atagar => teor
 * status:  new => assigned


Comment:

 Fix tags and owner, everything happens in the children now.

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

Re: [tor-bugs] #28170 [Core Tor/Stem]: Test stem pull requests against all supported tor versions, and tor nightly builds

[Tor Bug Tracker & Wiki]

#28170: Test stem pull requests against all supported tor versions, and tor 
nightly
builds
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Stem|Version:
 Severity:  Normal   | Resolution:
 Keywords:  ci, travis, 035-deferred-20190115,   |  Actual Points:
  041-proposed, teor-unreached-2019-03-08|
Parent ID:  #29729   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:   => #29729


Comment:

 We might have diagnosed #29437 faster if we ran Stem CI with python 3.6
 and any supported tor version.

 Once I finish #29729, I can copy chutney's Travis config to a Stem PR, and
 then drop in the stem test commands.

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

Re: [tor-bugs] #29437 [Core Tor/Stem]: test-stem times out intermittently

[Tor Bug Tracker & Wiki]

#29437: test-stem times out intermittently
---+
 Reporter:  rl1987 |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-ci-fail-sometimes  |  Actual Points:  0.2
Parent ID: | Points:  0.2
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * status:  needs_information => new


Comment:

 This ticket can close when its child tickets 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] #30012 [Core Tor/Stem]: When stem receives a signal, log useful information

[Tor Bug Tracker & Wiki]

#30012: When stem receives a signal, log useful information
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * parent:  #29437 =>


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

Re: [tor-bugs] #30012 [Core Tor/Stem]: When stem receives a signal, log useful information

[Tor Bug Tracker & Wiki]

#30012: When stem receives a signal, log useful information
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #29437 | Points:
 Reviewer: |Sponsor:
---+
Changes (by teor):

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


Comment:

 This ticket isn't urgent any more, because we think we have a fix in
 #30021.

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

Re: [tor-bugs] #30011 [Core Tor/Tor]: Kill test-stem if takes more than 9.5 minutes

[Tor Bug Tracker & Wiki]

#30011: Kill test-stem if takes more than 9.5 minutes
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.4-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci-fail-sometimes,   |  Actual Points:  0.3
  035-backport, 040-backport,  asn-merge |
Parent ID:  #29437   | Points:  0.3
 Reviewer:  nickm|Sponsor:
-+-

Comment (by teor):

 I think we should merge this PR in addition to the tor fix in #30021,
 because it gives us useful diagnostics for future stem hangs.

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

Re: [tor-bugs] #30018 [Core Tor/Stem]: Unable to download consensus using an ORPort

[Tor Bug Tracker & Wiki]

#30018: Unable to download consensus using an ORPort
---+
 Reporter:  irl|  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by teor):

 This looks similar to #30021, where Tor 0.2.9 and later, and Stem running
 under Python 3.6, disagree about the state of the link.

 Which python version are you using?
 Try using 3.5 or earlier?

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

Re: [tor-bugs] #29500 [Core Tor/Tor]: Broken circuitpadding unittests on appveyor

[Tor Bug Tracker & Wiki]

#29500: Broken circuitpadding unittests on appveyor
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  asn-merge, nickm-merge, wtf-pad, |  Actual Points:  3.5
  tor-relay, tor-cell, padding, 040-must,|
  040-backport   |
Parent ID:  #28631   | Points:  3
 Reviewer:  nickm, asn, teor |Sponsor:
 |  Sponsor2
-+-
Changes (by teor):

 * keywords:  wtf-pad, tor-relay, tor-cell, padding, 040-must, 040-backport
 =>
 asn-merge, nickm-merge, wtf-pad, tor-relay, tor-cell, padding,
 040-must, 040-backport
 * reviewer:  nickm => nickm, asn, teor


Comment:

 I backported Mike's extra commit to 0.4.0, then applied the same changes
 as my previous 0.4.0 and master PRs. There was one extra data structure
 name change that I needed to undo then re-apply.

 Here are the final pull requests:
 * 0.4.0: https://github.com/torproject/tor/pull/906
 * master: https://github.com/torproject/tor/pull/907

 So I think everything has been reviewed here multiple times, and we should
 just merge. (But I shouldn't merge, because I did the final PRs.)

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

Re: [tor-bugs] #29275 [Obfuscation/Pluggable transport]: Get default bridges checked for reachability by OONI

[Tor Bug Tracker & Wiki]

#29275: Get default bridges checked for reachability by OONI
-+---
 Reporter:  cohosh   |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor19
-+---

Comment (by dcf):

 Replying to [comment:6 phw]:
 > We should be able to see the test results in
 [https://explorer.ooni.torproject.org/country/CN OONI's explorer]. One can
 filter by test name. All "bridge reachability" tests I've seen are quite
 old, though -- from 2014 or 2015. I'll try to find out what's going on
 here.

 "Bridge reachability" is a different test, and as you found hardly run.
 The bridges are actually tested in the "TCP Connect" test. E.g.
 
https://explorer.ooni.torproject.org/measurement/20190107T070320Z_AS4134_d5QVa5d13jHeRFwOVn63qJmX0CXVymh47lFwR27iq8Y2hfqxr3?input=obfs4%20154.35.22.13:6041

 It's only a TCP connect, and not a full bootstrap, but it is run pretty
 frequently.
 https://api.ooni.io/api/v1/files?since=2019-04-01_name=tcp_connect
 finds 454 reports for me currently.

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

Re: [tor-bugs] #30031 [Core Tor/Tor]: Test circuitpadding with zero monotonic time deltas, and fix any bugs

[Tor Bug Tracker & Wiki]

#30031: Test circuitpadding with zero monotonic time deltas, and fix any bugs
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  wtf-pad   |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:  Sponsor2-can
--+--
Changes (by teor):

 * sponsor:   => Sponsor2-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] #25688 [Obfuscation/Snowflake]: proxy-go is still deadlocking occasionally

[Tor Bug Tracker & Wiki]

#25688: proxy-go is still deadlocking occasionally
+--
 Reporter:  dcf |  Owner:  cohosh
 Type:  defect  | Status:  needs_review
 Priority:  Low |  Milestone:
Component:  Obfuscation/Snowflake   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  network-team-roadmap-2019-Q1Q2  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:
+--

Comment (by dcf):

 I was going to quibble about `makePeerConnectionFromOffer` becoming
 blocking, which through `runSession`, will block the main polling loop in
 `main` (if I understand right). But I think this is an architectural
 problem unrelated to the deadlock fix, so let's ignore it. (It seems like
 `makePeerConnectionFromOffer` and `sendAnswer` should run in their own
 goroutine, responsible for a single PeerConnection.)

 Replying to [comment:22 cohosh]:
 > Replying to [comment:21 dcf]:
 > I am ok with this as well, but we should probably be tearing down the
 peer connections properly after a timeout anyway (though maybe go handles
 this on its own eventually?)

 I'm looking at the code and I don't quite get how it's supposed to work.
 The error handlers
 
([https://github.com/cohosh/snowflake/blob/08f5205461573bf8a6e8961540ac620865a3b45c
 /proxy-go/snowflake.go#L302 here]
 
[https://github.com/cohosh/snowflake/blob/08f5205461573bf8a6e8961540ac620865a3b45c
 /proxy-go/snowflake.go#L313 here]
 
[https://github.com/cohosh/snowflake/blob/08f5205461573bf8a6e8961540ac620865a3b45c
 /proxy-go/snowflake.go#L318 here]) call `pc.Destroy()`, and `retToken()`
 
[https://github.com/cohosh/snowflake/blob/08f5205461573bf8a6e8961540ac620865a3b45c
 /proxy-go/snowflake.go#L355 in the caller]. The timeout checker
 
[https://github.com/cohosh/snowflake/blob/08f5205461573bf8a6e8961540ac620865a3b45c
 /proxy-go/snowflake.go#L334 here] calls both `pc.Destroy()` and also
 `retToken()`, which makes sense because it doesn't have a caller to call
 `retToken()`. So that looks good.

 When a PeerConnection ends "naturally", I suppose what happens is that
 
[https://github.com/cohosh/snowflake/blob/08f5205461573bf8a6e8961540ac620865a3b45c
 /proxy-go/snowflake.go#L334 dc.OnClose()] gets called, which calls
 `pc.DeleteDataChannel(dc)`, but not `pc.Destroy()` nor `retToken()`. I can
 understand why `pc.DeleteDataChannel(dc)` gets called here and not in the
 other cases--because in the other cases we don't have a DataChannel yet--
 but then I'm wondering why it doesn't call the other two functions. Are we
 losing a token in this case too?

 I was thinking, what we need is an OnError handler so we can get called
 back when a DataChannel fails to establish. I found
 [https://github.com/keroserene/go-
 webrtc/blob/0c5ebb10a5dd7990a4962b78de27c2a8c735dac0/datachannel.go#L47-L50
 this comment]:
 {{{
 OnError - is not implemented because the underlying Send
 always returns true as specified for SCTP, there is no reasonable
 exposure of other specific errors from the native code, and OnClose
 already covers the bases.
 }}}
 I was curious about what happens in browser WebRTC so I hacked
 [https://developer.mozilla.org/en-
 US/docs/Web/API/WebRTC_API/Simple_RTCDataChannel_sample this demo] and
 [https://github.com/mdn/samples-
 server/tree/49c605fbda926a2dce9955b362233eef673e6090/s/webrtc-simple-
 datachannel code] to comment out [https://github.com/mdn/samples-
 server/blob/49c605fbda926a2dce9955b362233eef673e6090/s/webrtc-simple-
 datachannel/main.js#L60-L62 the onicecandidate callback] in the remote.
 What happens is you get a browser-produced line in the console:
 {{{
 ⚠️ ICE failed, add a STUN server and see about:webrtc for more details
 }}}
 but none of the error callbacks get called, so the application is never
 aware of the failure. (There is a [https://developer.mozilla.org/en-
 US/docs/Web/API/RTCPeerConnection/onicecandidateerror onicecandidateerror]
 callback but apparently nothing implements it.) So it looks like a browser
 is not doing anything fundamentally different, and checking after a
 timeout seems like a reasonable way to do it.

 So I think your patch looks good, if you can
 1. answer whether the `OnClose` path needs to call `retToken()`
 2. move the `time.Minute` value into a commented constant

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

Re: [tor-bugs] #29500 [Core Tor/Tor]: Broken circuitpadding unittests on appveyor

[Tor Bug Tracker & Wiki]

#29500: Broken circuitpadding unittests on appveyor
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:  3.5
  padding, 040-must, 040-backport|
Parent ID:  #28631   | Points:  3
 Reviewer:  nickm|Sponsor:
 |  Sponsor2
-+-
Changes (by teor):

 * keywords:  wtf-pad, tor-relay, tor-cell, padding, 041-must => wtf-pad,
 tor-relay, tor-cell, padding, 040-must, 040-backport
 * actualpoints:  3 => 3.5


Comment:

 Thanks for the patch. I think I can backport it to 0.4.0 without too much
 trouble.

 I closed #29990, and opened #30031 for the remaining zero delta issue.

 I made a list of all the circumstances where we've seen zero monotonic
 time deltas (or negative deltas, before we added the ratchet). I did some
 more analysis, and I think thoses cases are rare. If they become common,
 we should notice, because our monotonic time unit tests in test/util will
 fail.

 So I don't think we need to block WTF-PAD or 041 on that issue.

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

Re: [tor-bugs] #29990 [Core Tor/Tor]: Handle zero monotonic time differences in the circuit padding code

[Tor Bug Tracker & Wiki]

#29990: Handle zero monotonic time differences in the circuit padding code
-+-
 Reporter:  teor |  Owner:
 |  mikeperry
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.0.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding|
Parent ID:  #29500   | Points:  2
 Reviewer:   |Sponsor:
 |  Sponsor2
-+-
Changes (by teor):

 * keywords:
 wtf-pad, tor-relay, tor-cell, padding, 041-must, 040-must,
 040-backport
 => wtf-pad, tor-relay, tor-cell, padding
 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 Mike posted a unit test fix to #29500.

 I summarised the remaining issues in #30031.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30031 [Core Tor/Tor]: Test circuitpadding with zero monotonic time deltas, and fix any bugs

[Tor Bug Tracker & Wiki]

#30031: Test circuitpadding with zero monotonic time deltas, and fix any bugs
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  wtf-pad
Actual Points:|  Parent ID:
   Points:  2 |   Reviewer:
  Sponsor:|
--+--
 Any pre-ratchet monotime increment can be zero or negative, because the
 Windows API and gettimeofday() don't provide monotonic source times.

 So after Tor applies the ratchet, any number of calls to the monotonic
 time functions may return the same value.

 We have seen this happen when:
 * Windows sleeps (see
 https://trac.torproject.org/projects/tor/ticket/23696#comment:13 )
 * macOS has (VM?) time sync issues

 We know it can also happen when:
 * Tor uses gettimeofday() and a ratchet to emulate monotime, and the wall
 clock time goes backwards

 But these circumstances are rare:
 1. unit tests like test_util_monotonic_time() pass on Linux, macOS, and
 Windows CI
 2. Sleeping Windows boxes don't care about padding timing accuracy
 3. macOS VMs are rare
 4. Systems without monotime functions are rare, and clock changes on those
 systems are also rare

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

Re: [tor-bugs] #29500 [Core Tor/Tor]: Broken circuitpadding unittests on appveyor

[Tor Bug Tracker & Wiki]

#29500: Broken circuitpadding unittests on appveyor
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:  3
  padding, 041-must  |
Parent ID:  #28631   | Points:  3
 Reviewer:  nickm|Sponsor:
 |  Sponsor2
-+-
Changes (by mikeperry):

 * status:  assigned => needs_review


Comment:

 Ok, here's a PR to fix the test flapping (I hope -- again I have been
 unable to reproduce this, and not for lack of trying):
 https://github.com/torproject/tor/pull/905

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

Re: [tor-bugs] #29990 [Core Tor/Tor]: Handle zero monotonic time differences in the circuit padding code

[Tor Bug Tracker & Wiki]

#29990: Handle zero monotonic time differences in the circuit padding code
-+-
 Reporter:  teor |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding, 041-must, 040-must, 040-backport  |
Parent ID:  #29500   | Points:  2
 Reviewer:   |Sponsor:
 |  Sponsor2
-+-
Changes (by teor):

 * status:  new => assigned
 * keywords:  wtf-pad, tor-relay, tor-cell, padding, 041-must, 040-backport
 =>
 wtf-pad, tor-relay, tor-cell, padding, 041-must, 040-must,
 040-backport
 * owner:  (none) => mikeperry


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

Re: [tor-bugs] #29500 [Core Tor/Tor]: Broken circuitpadding unittests on appveyor

[Tor Bug Tracker & Wiki]

#29500: Broken circuitpadding unittests on appveyor
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:  3
  padding, 041-must  |
Parent ID:  #28631   | Points:  3
 Reviewer:  nickm|Sponsor:
 |  Sponsor2
-+-
Changes (by teor):

 * keywords:
 wtf-pad, tor-relay, tor-cell, padding, 041-proposed, 040-must, tor-ci-
 fail-sometimes
 => wtf-pad, tor-relay, tor-cell, padding, 041-must
 * owner:  teor => mikeperry
 * version:   => Tor: 0.4.0.1-alpha
 * status:  new => assigned
 * milestone:  Tor: 0.4.0.x-final => Tor: 0.4.1.x-final


Comment:

 Fixing tags: we must fix this issue before we turn on circuitpadding. (Or
 we should document the issues in code comments and the spec, and triage it
 out.)

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

Re: [tor-bugs] #29500 [Core Tor/Tor]: Broken circuitpadding unittests on appveyor

[Tor Bug Tracker & Wiki]

#29500: Broken circuitpadding unittests on appveyor
-+-
 Reporter:  asn  |  Owner:  teor
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:  3
  padding, 041-proposed, 040-must, tor-ci-fail-  |
  sometimes  |
Parent ID:  #28631   | Points:  3
 Reviewer:  nickm|Sponsor:
 |  Sponsor2
-+-
Changes (by teor):

 * status:  needs_revision => new


Comment:

 Replying to [comment:33 mikeperry]:
 > I would request that we not merge hacky changes to the unittests for the
 #29990 workarounds.

 Ok, I'll close my pull requests on this ticket, and mark #29990 as
 040-backport.

 > If we're going to hack this, let's hack it so monotime_init() (or the
 ratchet) has a non-zero value, and then we can go through circpad for the
 rare cases where the difference between monotime_init() and the first
 ratchet update is 0 (or negative), in production (which I still believe
 should be rare/impossible).

 These situations are rare, but they can happen. And they can happen more
 than you think.

 *Any* pre-ratchet monotime update can be zero or negative, because the
 Windows API and gettimeofday() don't provide monotonic source times. So
 any number of calls to the monotonic time functions may return the same
 value.

 Would you like to open a new ticket to test and fix these zero delta
 issues in circuitpad?
 #29990 is now about another bug, and this ticket is full of comments.

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

Re: [tor-bugs] #29990 [Core Tor/Tor]: Handle zero monotonic time differences in the circuit padding code

[Tor Bug Tracker & Wiki]

#29990: Handle zero monotonic time differences in the circuit padding code
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding, 041-must, 040-backport|
Parent ID:  #29500   | Points:  2
 Reviewer:   |Sponsor:
 |  Sponsor2
-+-
Changes (by teor):

 * keywords:  wtf-pad, tor-relay, tor-cell, padding, 041-must => wtf-pad,
 tor-relay, tor-cell, padding, 041-must, 040-backport
 * version:  Tor: unspecified => Tor: 0.4.0.1-alpha


Comment:

 Please base your code on maint-0.4.0, or make a pull request to delete the
 buggy tests from maint-0.4.0.

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

Re: [tor-bugs] #29990 [Core Tor/Tor]: Handle zero monotonic time differences in the circuit padding code

[Tor Bug Tracker & Wiki]

#29990: Handle zero monotonic time differences in the circuit padding code
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding, 041-must  |
Parent ID:  #29500   | Points:  2
 Reviewer:   |Sponsor:
 |  Sponsor2
-+-

Comment (by teor):

 Replying to [comment:6 mikeperry]:
 > Aha, I think I found it! Our mocking forces us to call monotime_init()
 *before* we set the mocked time value. monotime_init() thus stores the
 first ratchet value at whatever the platform is at, and then we set fake
 mocked time to some later value.
 >
 > If monotime_init() gets a value from the host that is **greater** than
 what we choose to mock time at for our unittests, all subsequent
 monotime_abosolute() calls return zero.
 >
 > So, the right way to fix all of this mess is to either fix our mocking
 to allow us to call monotime_init() with a mocked time, or just always set
 our mocked time to some time after whatever monotime_init() stored.

 Oh wow. That's a tricky bug.

 > I am going to attempt the later, to see if it fixes whatever hackintosh
 VM is involved here (I don't have one of those).

 It's just a standard mac, running macOS as host, and macOS inside some
 virtual machine software. You can probably achieve the same thing using:
 * a script that rapidly changes your hardware or software clock, or
 * VMWare, VirtualBox, or qemu with clock skew between guest and host, and
 a VM setting that applies the host time to the guest (and an apparent VM
 bug which causes the time to switch rapidly between host and guest time).

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

Re: [tor-bugs] #29036 [Core Tor/Tor]: Coverage merge failures cause test_process_slow stderr check to fail

[Tor Bug Tracker & Wiki]

#29036: Coverage merge failures cause test_process_slow stderr check to fail
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Major| Resolution:
 Keywords:  asn-merge, nickm-merge,  |  Actual Points:  0.6
  041-accepted-20190115, regression, tor-ci, |
  029-backport, 034-backport, 035-backport,  |
  040-backport, tor-ci-fail-sometimes|
Parent ID:   | Points:  0.5
 Reviewer:  catalyst |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:29 nickm]:
 > Sorry, I think we need a different target name for this new "reset-gcov"
 semantics, if that's what we're going for.  In the current semantics,
 running 'reset-gcov' after a test run resets the coverage, but doesn't
 stop you from running "make check" again.  But if we change it to remove
 the gcno files too, that will means that you need to do a full "make
 clean" and "make" before you can run the tests for coverage again.

 I think I understand better now:
 * we MUST NOT delete gcno files, because they are created when the code is
 compiled
 * we MUST delete gcda files to remove the warning (and make our coverage
 accurate)
 * we MAY delete gcov files, because they take up space in the cache (and
 leaving old files around might make our coverage inaccurate)

 I'll amend that commit to delete gcda and gcov files, but leave gcno
 files.

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

Re: [tor-bugs] #29108 [Core Tor/Tor]: Refactor crypto_digest.c to have fewer ifdefs

[Tor Bug Tracker & Wiki]

#29108: Refactor crypto_digest.c to have fewer ifdefs
-+-
 Reporter:  nickm|  Owner:  rl1987
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  nickm-merge, asn-merge,  |  implemented
  041-proposed, refactor, technical-debt |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:  catalyst |Sponsor:
 |  Sponsor31-can
-+-
Changes (by nickm):

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


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

Re: [tor-bugs] #29108 [Core Tor/Tor]: Refactor crypto_digest.c to have fewer ifdefs

[Tor Bug Tracker & Wiki]

#29108: Refactor crypto_digest.c to have fewer ifdefs
-+-
 Reporter:  nickm|  Owner:  rl1987
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  nickm-merge, asn-merge,  |  Actual Points:
  041-proposed, refactor, technical-debt |
Parent ID:   | Points:  1
 Reviewer:  catalyst |Sponsor:
 |  Sponsor31-can
-+-

Comment (by nickm):

 color-move makes the double-checking pretty nice here.  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] #29036 [Core Tor/Tor]: Coverage merge failures cause test_process_slow stderr check to fail

[Tor Bug Tracker & Wiki]

#29036: Coverage merge failures cause test_process_slow stderr check to fail
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Major| Resolution:
 Keywords:  asn-merge, nickm-merge,  |  Actual Points:  0.6
  041-accepted-20190115, regression, tor-ci, |
  029-backport, 034-backport, 035-backport,  |
  040-backport, tor-ci-fail-sometimes|
Parent ID:   | Points:  0.5
 Reviewer:  catalyst |Sponsor:
-+-
Changes (by nickm):

 * status:  merge_ready => needs_revision


Comment:

 Sorry, I think we need a different target name for this new "reset-gcov"
 semantics, if that's what we're going for.  In the current semantics,
 running 'reset-gcov' after a test run resets the coverage, but doesn't
 stop you from running "make check" again.  But if we change it to remove
 the gcno files too, that will means that you need to do a full "make
 clean" and "make" before you can run the tests for coverage again.

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

Re: [tor-bugs] #29959 [Core Tor/Tor]: Actually include the bandwidth file digest in the vote

[Tor Bug Tracker & Wiki]

#29959: Actually include the bandwidth file digest in the vote
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.0.2-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  040-must, 040-backport, fast-fix,|  Actual Points:  0.2
  nickm-merge|
Parent ID:  #29947   | Points:  0.2
 Reviewer:  asn  |Sponsor:
-+-
Changes (by nickm):

 * 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] #29961 [Core Tor/Tor]: Update the Tor version for bandwidth-file-digest in torspec

[Tor Bug Tracker & Wiki]

#29961: Update the Tor version for bandwidth-file-digest in torspec
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.0.2-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  040-must, 040-backport, fast-fix,|  Actual Points:  0
  tor-spec, nickm-merge  |
Parent ID:  #29959   | Points:  0
 Reviewer:  asn  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Merged parent; merging 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] #29959 [Core Tor/Tor]: Actually include the bandwidth file digest in the vote

[Tor Bug Tracker & Wiki]

#29959: Actually include the bandwidth file digest in the vote
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.0.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  040-must, 040-backport, fast-fix,|  Actual Points:  0.2
  nickm-merge|
Parent ID:  #29947   | Points:  0.2
 Reviewer:  asn  |Sponsor:
-+-

Comment (by nickm):

 Squashed and merged to 0.4.0 and forward.

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

Re: [tor-bugs] #29990 [Core Tor/Tor]: Handle zero monotonic time differences in the circuit padding code

[Tor Bug Tracker & Wiki]

#29990: Handle zero monotonic time differences in the circuit padding code
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding, 041-must  |
Parent ID:  #29500   | Points:  2
 Reviewer:   |Sponsor:
 |  Sponsor2
-+-

Comment (by mikeperry):

 Aha, I think I found it! Our mocking forces us to call monotime_init()
 *before* we set the mocked time value. monotime_init() thus stores the
 first ratchet value at whatever the platform is at, and then we set fake
 mocked time to some later value.

 If monotime_init() gets a value from the host that is **greater** than
 what we choose to mock time at for our unittests, all subsequent
 monotime_abosolute() calls return zero.

 So, the right way to fix all of this mess is to either fix our mocking to
 allow us to call monotime_init() with a mocked time, or just always set
 our mocked time to some time after whatever monotime_init() stored.

 I am going to attempt the later, to see if it fixes whatever hackintosh VM
 is involved here (I don't have one of those).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] [Tor Bug Tracker & Wiki] Batch modify: #29959, #29961, #29036, #29108

[Tor Bug Tracker & Wiki]

Batch modification to #29959, #29961, #29036, #29108 by nickm:


--
Tickets URL: 

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

Re: [tor-bugs] #29990 [Core Tor/Tor]: Handle zero monotonic time differences in the circuit padding code

[Tor Bug Tracker & Wiki]

#29990: Handle zero monotonic time differences in the circuit padding code
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding, 041-must  |
Parent ID:  #29500   | Points:  2
 Reviewer:   |Sponsor:
 |  Sponsor2
-+-

Comment (by mikeperry):

 I do not understand how the host or VM time could have any effect on our
 unittests, which strictly use mocked monotime values. Is something wrong
 with our mocking on some platforms? Or are we just not incrementing our
 mocked values sufficiently in the unittests for the resolution of some
 platforms?

 I do not have these platforms to verify (I assume by mac os VM you mean
 hackintosh?

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

Re: [tor-bugs] #29500 [Core Tor/Tor]: Broken circuitpadding unittests on appveyor

[Tor Bug Tracker & Wiki]

#29500: Broken circuitpadding unittests on appveyor
-+-
 Reporter:  asn  |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:  3
  padding, 041-proposed, 040-must, tor-ci-fail-  |
  sometimes  |
Parent ID:  #28631   | Points:  3
 Reviewer:  nickm|Sponsor:
 |  Sponsor2
-+-

Comment (by mikeperry):

 Replying to [comment:20 teor]:
 > Here are three scenarios where the monotime_diff or monotime_absolute
 functions can return zero:
 > (I'll use monotime_absolute below, because I think that's what you're
 using. But monotime_absolute just calls monotime_diff with the previous
 monotime value.)

 I am still not understanding the issue here. Or I am understanding
 differently than you. Let me try to reply here and say what I think you
 mean/what I think is true.

 > The Ratchet Returns Zero
 >
 > 1. Tor is running on a platform which has monotime API bugs (Windows),
 or Tor is compiled without support for monotime functions (old Linux, old
 macOS, other platforms where we haven't implemented monotime support)
 > 2. Tor calls a monotime_absolute() function, and stores the last
 monotime value

 2. Tor calls a monotime_init() function at startup, and stores the FIRST
 monotime value.

 > 3. Any amount of time elapses
 > 4. Tor calls a monotime_absolute() function, and Windows experiences its
 monotime bug, or the user has changed the wall clock time backwards
 > 5. Tor emulates monotonic time using a ratchet. The ratchet stores an
 internal correction factor for future monotonic times, and returns the
 same value as it previously returned
 > 6. The monotime_absolute() function gets the same value for the previous
 and current times. It returns zero.

 6. If wall clock time moved back to a time period **earlier than
 monotime_init() AND does this before Tor stores a ratchet value**, then
 monotime_absolute() function gets the same value for the previous and
 current times. It returns zero.

 > Low Resolution Timers in the OS
 >
 > 1. Tor is running on a platform with low-resolution timers
 > 2. Tor calls a monotime_absolute() function, and stores the last
 monotime value

 2. Tor calls monotime_init() function at startup, and stores the FIRST
 monotime value.

 > 3. A small amount of time elapses, which is lower than the timer
 resolution
 > 4. Tor calls a monotime_absolute() function, which gets the same
 monotime value as the previous call to the low-resolution timer
 > 5. The monotime_absolute() function gets the same value for the previous
 and current times. It returns zero.

 5. The monotime_absolute() function gets the same time value as
 monotime_init(), because less than the timer resolution amount of time has
 elapsed since monotime_init() was called. Then, and only then, it returns
 0.

 > Low Resolution Timer APIs in Tor
 >
 > 1. Tor is running on any platform
 > 2. Tor calls a monotime_absolute() function with low-resolution units
 (seconds, milliseconds, or microseconds) and stores the last monotime
 value

 2. Tor calls monotime_init() function at startup, and stores an
 initialization time in low-resolution units.

 > 3. A small amount of time elapses, which is less than one unit
 > 4. Tor calls a monotime_absolute() function, which gets a monotime value
 which is greater than the previous call to the low-resolution timer, but
 less than one unit away from the previous timer.
 > 5. The monotime_absolute() function gets less than one unit's difference
 between the previous and current times. It divides by the unit conversion
 factor, and returns zero. (These functions truncate, rather than
 rounding.)

 5. The monotime_absolute() function gets the same time value as
 monotime_init(), because less than the timer resolution amount of time has
 elapsed since monotime_init() was called. Then, and only then, it returns
 0.

 In all but the first case (monotime Windows bugs), the
 monotime_absolute_usec() functions cannot return 0 after more than the
 time resolution period has passed since monotime_init(). Even in the first
 case, monotime_absolute_usec() cannot return 0 unless the clock moves
 backwards **before the ratchet value is stored**. In all other cases, the
 ratchet value should be stored as a non-zero value and all subsequent
 

Re: [tor-bugs] #30030 [Webpages/Website]: When downloading tor-browser alpha for windows redirected to broken page

[Tor Bug Tracker & Wiki]

#30030: When downloading tor-browser alpha for windows redirected to broken page
--+
 Reporter:  pospeselr |  Owner:  hiro
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by hiro):

 * 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] #30011 [Core Tor/Tor]: Kill test-stem if takes more than 9.5 minutes (was: Kill test-stem if takes more than 15 minutes)

[Tor Bug Tracker & Wiki]

#30011: Kill test-stem if takes more than 9.5 minutes
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.4-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci-fail-sometimes,   |  Actual Points:  0.3
  035-backport, 040-backport,  asn-merge |
Parent ID:  #29437   | Points:  0.3
 Reviewer:  nickm|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] #29822 [Internal Services/Tor Sysadmin Team]: prometheus server cannot reach build-arm* boxes

[Tor Bug Tracker & Wiki]

#29822: prometheus server cannot reach build-arm* boxes
-+-
 Reporter:  anarcat  |  Owner:  weasel
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Minor| Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29681   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 also note that I researched possible alternatives to VPNs for NAT bypass,
 and they were not quite satisfactory:

  * pagekite: required setting up a server on the prometheus server and
 clients on all affected boxes, may be more work than IPsec
  * PushProx: not packaged in Debian, no stable release, also requires
 clients on all affected boxes and extra server

 This leaves us with other NAT bypass mechanisms as alternatives, namely
 Tor hidden services, wireguard, openvpn or tinc. For now, let's see if we
 can make the current solution work correctly.

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

Re: [tor-bugs] #29277 [Obfuscation/Pluggable transport]: Look into getting default Tor bridges scanned by external reachability tests

[Tor Bug Tracker & Wiki]

#29277: Look into getting default Tor bridges scanned by external reachability
tests
-+---
 Reporter:  cohosh   |  Owner:  phw
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  augur, measurement   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor19
-+---
Changes (by phw):

 * owner:  (none) => phw
 * keywords:   => augur, measurement
 * 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] #29277 [Obfuscation/Pluggable transport]: Look into getting default Tor bridges scanned by external reachability tests

[Tor Bug Tracker & Wiki]

#29277: Look into getting default Tor bridges scanned by external reachability
tests
-+---
 Reporter:  cohosh   |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Pluggable transport  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor19
-+---

Comment (by phw):

 Today, Roya visited as during our weekly anti-censorship team meeting and
 we briefly touched based on getting reachability scans going. David
 pointed out that OONI's list of [https://github.com/OpenObservatory/ooni-
 resources/blob/master/bridge_reachability/tor-bridges-ip-port.csv default
 bridges (among other things)] would be a great way to get started.

 Roya's system has ~50,000 vantage points in 42 "non-free countries"
 (according to Freedom House's definition) plus a sample of other
 countries. Roya also wanted to know how often we want these measurements
 run.  "At least once a day" seems like a good answer for now.

 For now, I think we should:
 1. Get an initial scan going, and see what we can learn from it.
 2. Compare the scan results to OONI's data and hope that both systems
 agree.

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

Re: [tor-bugs] #29822 [Internal Services/Tor Sysadmin Team]: prometheus server cannot reach build-arm* boxes

[Tor Bug Tracker & Wiki]

#29822: prometheus server cannot reach build-arm* boxes
-+-
 Reporter:  anarcat  |  Owner:  weasel
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Minor| Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29681   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * owner:  anarcat => weasel


Comment:

 i have tried setting up ipsec on nbg1 and it mostly works when connecting
 to the other TPO boxes. i've documented what I did in
 [https://help.torproject.org/tsa/howto/ipsec/ the wiki] but mostly I have
 deployed everything through puppet following the existing configs and
 rebooted the monitoring server. i then ran puppet on all the other puppet
 nodes and things generally seem to work.

 unfortunately, this doesn't bypass NAT: I cannot ping the ARM boxes behind
 the microtik server. I assume I also need the `local peers` configuration
 that is deployed on the other hosts.

 I have tried adding the following static configuration:

 {{{
 conn hetzner-nbg1-01.torproject.org-mikrotik.sbg.torproject.org
   ike = aes128-sha256-modp3072
   #type = tunnel

   left   = 195.201.139.202
   leftsubnet = 195.201.139.202/32, 172.30.142.0/24

   right = 141.201.12.27
   rightallowany = yes
   rightid = mikrotik.sbg.torproject.org
   rightsubnet = 172.30.115.0/24

   auto = route

   forceencaps = yes
   dpdaction = hold
 }}}

 I made up `172.30.142.0/24` because I didn't know what to put there.
 trying to raise that interface fails:

 {{{
 root@hetzner-nbg1-01:/etc/ipsec.conf.d# ipsec reload
 Reloading strongSwan IPsec configuration...
 root@hetzner-nbg1-01:/etc/ipsec.conf.d# ipsec up hetzner-
 nbg1-01.torproject.org-mikrotik.sbg.torproject.org
 retransmit 3 of request with message ID 0
 sending packet: from 195.201.139.202[500] to 141.201.12.27[500] (1300
 bytes)
 retransmit 4 of request with message ID 0
 sending packet: from 195.201.139.202[500] to 141.201.12.27[500] (1300
 bytes)
 retransmit 5 of request with message ID 0
 sending packet: from 195.201.139.202[500] to 141.201.12.27[500] (1300
 bytes)
 giving up after 5 retransmits
 establishing IKE_SA failed, peer not responding
 establishing connection 'hetzner-nbg1-01.torproject.org-
 mikrotik.sbg.torproject.org' failed
 }}}

 It looks like the microtik server refuses to talk to us somehow. I have
 also tried to connect to it as documented in tor-passwords, to no avail:

 {{{
 Authenticated to kvm4.torproject.org ([2a01:4f8:10b:239f::2]:22).
 debug1: channel_connect_stdio_fwd mikrotik.sbg.torproject.org:22
 debug1: channel 0: new [stdio-forward]
 debug1: getpeername failed: Bad file descriptor
 debug1: Requesting no-more-sessi...@openssh.com
 debug1: Entering interactive session.
 debug1: pledge: network
 debug1: client_input_global_request: rtype hostkeys...@openssh.com
 want_reply 0
 channel 0: open failed: connect failed: Connection timed out
 stdio forwarding failed
 ssh_exchange_identification: Connection closed by remote host
 "ssh -v4 -J kvm4.torproject.org ad...@mikrotik.sbg.torproject.org" took 2
 mins 12 secs
 }}}

 So it seems I have a part of the configuration missing, namely the
 Microtik server bits, and I don't seem to have the access to perform that.

 Reassigning to weasel so he can hold my hand for that last step. :)

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

Re: [tor-bugs] #29663 [Internal Services/Services Admin Team]: Deploy /etc/puppet as a role account

[Tor Bug Tracker & Wiki]

#29663: Deploy /etc/puppet as a role account
-+-
 Reporter:  ln5  |  Owner:  anarcat
 Type:  enhancement  | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

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


Comment:

 this was obviously naive, on hetzner-hel1-01:

 {{{
 Error: /Stage[main]/Ssl/File[/etc/ssl/torproject-
 auto/serverkeys/thishost.key]: Could not evaluate: Could not retrieve file
 metadata for puppet:///modules/ssl/certs/hetzner-
 hel1-01.torproject.org.key: Error 500 on SERVER: Server Error: Permission
 denied @ rb_sysopen -
 /srv/puppet.torproject.org/stages/production/modules/ssl/files/certs
 /hetzner-hel1-01.torproject.org.key
 }}}

 Those files are now:

 {{{
 -rw-rw-r-- 1 root adm  5550 mar 13 16:05 hetzner-
 nbg1-01.torproject.org.crt
 -rw--w 1 root adm  1675 mar 13 16:05 hetzner-
 nbg1-01.torproject.org.key
 }}}

 Not sure what the permissions were before, but I'll grant a+r.

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

Re: [tor-bugs] #29663 [Internal Services/Services Admin Team]: Deploy /etc/puppet as a role account

[Tor Bug Tracker & Wiki]

#29663: Deploy /etc/puppet as a role account
-+-
 Reporter:  ln5  |  Owner:  anarcat
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

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


Comment:

 i did a push and it worked. considering that all files are now owned by
 root, if there was a problem it would have failed so I'll assume we're
 good from here on.

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

Re: [tor-bugs] #29663 [Internal Services/Services Admin Team]: Deploy /etc/puppet as a role account

[Tor Bug Tracker & Wiki]

#29663: Deploy /etc/puppet as a role account
-+-
 Reporter:  ln5  |  Owner:  anarcat
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * owner:  (none) => anarcat
 * status:  new => assigned


Comment:

 just had this problem:

 {{{
 anarcat@pauli:/etc/puppet/modules/ipsec/misc$ git pull
 Mise à jour a4dea802..d9e168b5
 error: unable to unlink old 'modules/ipsec/misc/config.yaml': Permission
 non accordée
 anarcat@pauli:/etc/puppet/modules/ipsec/misc$ ls -al
 total 12
 drwxrwxr-x 2 weasel weasel 4096 mai  3  2018 .
 drwxr-xr-x 5 weasel weasel 4096 jui 27  2017 ..
 -rw-rw-r-- 1 weasel weasel 1076 mai  3  2018 config.yaml
 }}}

 I am not sure that we need a role to fix this problem. Git should be able
 to set the proper permissions everywhere with the `sharedMode` variable,
 so I did the following:

 {{{
 sudo chown -R root:adm /etc/puppet
 sudo chown :puppet /etc/puppet/secret
 sudo chmod -R g+w /etc/puppet
 sudo chmod g-w /etc/puppet/secret
 git -C /etc/puppet config core.sharedRepository group
 git -C /srv/puppet.torproject.org/git/tor-puppet.git/ config
 core.sharedRepository group
 }}}

 Hopefully this will fix the problem indefinitely.

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

Re: [tor-bugs] #30030 [Webpages/Website]: When downloading tor-browser alpha for windows redirected to broken page

[Tor Bug Tracker & Wiki]

#30030: When downloading tor-browser alpha for windows redirected to broken page
--+--
 Reporter:  pospeselr |  Owner:  hiro
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Description changed by pospeselr:

Old description:

> Download happens but redirect page is broken.

New description:

 Download happens but redirect page is broken.

 url: https://www.torproject.org/download/alpha/%7B%7B%20'/thank-
 you'|url(alt=this.alt)%20%7D%7D

--

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

Re: [tor-bugs] #30030 [Webpages/Website]: When downloading tor-browser alpha for windows redirected to broken page

[Tor Bug Tracker & Wiki]

#30030: When downloading tor-browser alpha for windows redirected to broken page
--+--
 Reporter:  pospeselr |  Owner:  hiro
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by pospeselr):

 * Attachment "not-found.png" added.


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

[tor-bugs] #30030 [Webpages/Website]: When downloading tor-browser alpha for windows redirected to broken page

[Tor Bug Tracker & Wiki]

#30030: When downloading tor-browser alpha for windows redirected to broken page
--+--
 Reporter:  pospeselr |  Owner:  hiro
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Download happens but redirect page is broken.

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

Re: [tor-bugs] #29269 [Obfuscation/BridgeDB]: Evaluation of bridge statistics

[Tor Bug Tracker & Wiki]

#29269: Evaluation of bridge statistics
--+---
 Reporter:  cohosh|  Owner:  nickm
 Type:  task  | Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:  bridges, statistics   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor19
--+---
Changes (by irl):

 * cc: metrics-team (added)


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

Re: [tor-bugs] #29269 [Obfuscation/BridgeDB]: Evaluation of bridge statistics

[Tor Bug Tracker & Wiki]

#29269: Evaluation of bridge statistics
--+---
 Reporter:  cohosh|  Owner:  nickm
 Type:  task  | Status:  accepted
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:  bridges, statistics   |  Actual Points:
Parent ID:| 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] #27503 [Applications/Tor Browser]: Disabling accessibility on Windows breaks screen readers

[Tor Bug Tracker & Wiki]

#27503: Disabling accessibility on Windows breaks screen readers
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-8.0-issues, tbb-regression,  |  Actual Points:
  GeorgKoppen201903, tbb-8.5-must,   |
  TorBrowserTeam201904   |
Parent ID:   | Points:
 Reviewer:  boklm|Sponsor:
-+-

Comment (by pospeselr):

 I've built and tested 64 bit as well and see the same behavior as
 described above in 64-bit Windows 10 with (ie able to read page contents
 via mouse-over using NVDA)

 Here's the current changeset used to build the above nightlies (literally
 just the current patch from the Mozilla bug)

 https://gitweb.torproject.org/user/richard/tor-
 browser.git/commit/?h=bug_27503_v2

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

Re: [tor-bugs] #29768 [Applications/Tor Browser]: Introduce new features to users in Tor Browser

[Tor Bug Tracker & Wiki]

#29768: Introduce new features to users in Tor Browser
-+-
 Reporter:  antonela |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201904, tbb-8.5-must-  |  Actual Points:
  alpha, TorBrowserTeam201904|
Parent ID:  #25658   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 I wonder what we mean by adding "New" to the pane if we keep the old text
 because that pane and the functionality behind that feature aren't
 actually new. So, hrm...

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

Re: [tor-bugs] #29768 [Applications/Tor Browser]: Introduce new features to users in Tor Browser

[Tor Bug Tracker & Wiki]

#29768: Introduce new features to users in Tor Browser
-+-
 Reporter:  antonela |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201904, tbb-8.5-must-  |  Actual Points:
  alpha, TorBrowserTeam201904|
Parent ID:  #25658   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:39 mcs]:
 > Switching status to "needs information" to solicit reactions to my
 comment:37 (proposed changes to the regular/new user onboarding).

 I am fine leaving that Note out if we think it's too risky space-wise.

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

Re: [tor-bugs] #10338 [Internal Services/Tor Sysadmin Team]: [hw14] Upgrade Tor's virtual machine infrastructure

[Tor Bug Tracker & Wiki]

#10338: [hw14] Upgrade Tor's virtual machine infrastructure
-+-
 Reporter:  phobos   |  Owner:  tpa
 Type:  project  | Status:  closed
 Priority:  Medium   |  Milestone:  Upgrade Tor's VM
Component:  Internal Services/Tor|  Infrastructure
  Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  sysadmin sysupgrade  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * 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] #29768 [Applications/Tor Browser]: Introduce new features to users in Tor Browser

[Tor Bug Tracker & Wiki]

#29768: Introduce new features to users in Tor Browser
-+-
 Reporter:  antonela |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201904, tbb-8.5-must-  |  Actual Points:
  alpha, TorBrowserTeam201904|
Parent ID:  #25658   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * keywords:  TorBrowserTeam201903R, tbb-8.5-must-alpha,
 TorBrowserTeam201904 => TorBrowserTeam201904, tbb-8.5-must-alpha,
 TorBrowserTeam201904
 * status:  needs_review => needs_information


Comment:

 Switching status to "needs information" to solicit reactions to my
 comment:37 (proposed changes to the regular/new user onboarding).

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

Re: [tor-bugs] #29387 [Internal Services/Tor Sysadmin Team]: Publish our puppet repository

[Tor Bug Tracker & Wiki]

#29387: Publish our puppet repository
-+-
 Reporter:  ln5  |  Owner:  anarcat
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 so concretely, the '''TL;DR:''' of what I am proposing is this:

  1. convert everything to hiera (#30020) - this requires creating `roles`
 for each machine (more or less)
  2. move current `modules/` into `profiles/` and audit for private data
  3. move any private data into `hiera/`
  4. move `3rdparty` modules into `modules/`
  5. publish everything but `hiera/` as a new repository

 '''Final picture'''

 Once this is done, the final picture will look like this in `/etc/puppet`:

  * `hiera/` - private data. `machine -> role` assignements, secret stuff
 like the alias file, machine location, price and other similar metadata
 and details (see also #29816)
  * `modules/` - equivalent of the current `3rdparty/` directory: fully
 public, reusable code that's aimed at collaboration. mostly code from the
 Puppet forge or our own repository if no equivalent there
  * `profiles/` - magic sauce on top of 3rd party `modules/`, already
 created a few `modules/profiles/` for grafana and prometheus, the profiles
 configure official 3rd party classes with our site-specific criteria
  * `roles/` - abstract classes that regroup a few profiles. for example
 `roles::monitoring` could currently include `profiles::nagiosmaster`,
 `profiles::prometheus::server` and `profiles::grafana` as an
 implementation

 This could all be done in the current repository, without creating a new
 clean history one, but it would prepare us for that final step. And that
 step would simply be to move `modules/`, `profiles/`, and `roles/` into a
 public repository, while keeping `hiera/` private in its own repository.

 '''Alternative proposal'''

 The alternative approach is simply to create an entirely new repository
 that is identical to the current one, minus the `virtual` aliases file.
 But then I don't know where I would put the alias file, and I think it
 would be a missed opportunity to follow the industry's best practices I
 documented earlier in this ticket.

 '''Further discussion'''

 I would love to get feedback on this before I foray any further into this
 maze. For now I think it's safe to keep going on the Hiera conversion, as
 I discussed this with weasel and it seems to be consensual. But it seems
 the other ideas here (namely to use this opportunity to reshuffle the
 repository structure) seem to be less consensual.

 Also note that I kept trocla out of the picture for now. We could keep
 using the current `hkdf` in this system, but it would be the last function
 left in the `puppetmaster` module, from what I can tell, which is another
 reason why I'm tempted to replace it as well.

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

Re: [tor-bugs] #24622 [Applications/Tor Browser]: Torcrazybutton can't decipher website s3.amazonaws.com

[Tor Bug Tracker & Wiki]

#24622: Torcrazybutton can't decipher website s3.amazonaws.com
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-7.0-issues, tbb-regression,  |  Actual Points:
  tbb-linkability, GeorgKoppen201903,|
  TorBrowserTeam201904   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:40 acat]:
 > Firefox computes the firstPartyDomain with
 `Services.eTLD.getBaseDomainFromHost('s3.amazonaws.com')`, and that one
 throws an error with top-level domains (like s3.amazonaws.com) as defined
 in mozilla public suffix list https://publicsuffix.org/list/. And I assume
 if there's an exception then it gets set to an empty string (unless it's
 about:*, etc.).
 >
 > Which means that all domains here will go to the same catch-all circuit:
 https://gitweb.torproject.org/tor-
 browser.git/tree/netwerk/dns/effective_tld_names.dat?h=tor-
 browser-60.6.1esr-8.0-1-build1. So urls like http://mycd.eu,
 http://s3.amazonaws.com/whatever, https://ownprovider.com/en/Main, ...,
 will go to the same catch-all circuit with the current firstPartyDomain
 implementation. The same happens with any random domain like
 http://foobarfoo. Also note the list in the repo is not up to date with
 https://publicsuffix.org/list/public_suffix_list.dat.
 >
 > Shouldn't firstPartyDomain be the first-level domain on those cases
 (instead of empty string), or am I missing some reason why this is not a
 good idea?
 >

 Interesting. My intuition goes with you here and I'd assume that's a bug.
 Could you file a bug at Mozilla's bug tracker blocking
 https://bugzilla.mozilla.org/show_bug.cgi?id=126? We could ask :ethan
 to help us finding someone at Mozilla who'd have an opinion about that.

 Meanwhile, feel free to work on a patch implementing your suggestion. We
 should take it for Tor Browser at least.

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

Re: [tor-bugs] #26491 [Applications/Tor Browser]: Onion+cert UI text is black with Tor Browser 8.0a9 - it should be green

[Tor Bug Tracker & Wiki]

#26491: Onion+cert UI text is black with Tor Browser 8.0a9 - it should be green
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff60-esr, ux-team |  Actual Points:
Parent ID:  #30025| Points:
 Reviewer:|Sponsor:  Sponsor27
--+---
Changes (by pili):

 * parent:   => #30025


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

Re: [tor-bugs] #25025 [Webpages/Styleguide]: Add icon for next-generation onions in the style guide

[Tor Bug Tracker & Wiki]

#25025: Add icon for next-generation onions in the style guide
-+---
 Reporter:  ahf  |  Owner:  antonela
 Type:  defect   | Status:  assigned
 Priority:  Low  |  Milestone:
Component:  Webpages/Styleguide  |Version:
 Severity:  Minor| Resolution:
 Keywords:  ux-team, tor-hs  |  Actual Points:
Parent ID:  #30024   | Points:
 Reviewer:   |Sponsor:  Sponsor27
-+---
Changes (by pili):

 * parent:   => #30024


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

Re: [tor-bugs] #27657 [Applications/Tor Browser]: Show .onion icon on Identity drop down?

[Tor Bug Tracker & Wiki]

#27657: Show .onion icon on Identity drop down?
--+---
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:  #30025| Points:
 Reviewer:|Sponsor:  Sponsor27
--+---
Changes (by pili):

 * parent:   => #30025


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

Re: [tor-bugs] #24622 [Applications/Tor Browser]: Torcrazybutton can't decipher website s3.amazonaws.com

[Tor Bug Tracker & Wiki]

#24622: Torcrazybutton can't decipher website s3.amazonaws.com
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-7.0-issues, tbb-regression,  |  Actual Points:
  tbb-linkability, GeorgKoppen201903,|
  TorBrowserTeam201904   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by acat):

 Firefox computes the firstPartyDomain with
 `Services.eTLD.getBaseDomainFromHost('s3.amazonaws.com')`, and that one
 throws an error with top-level domains (like s3.amazonaws.com) as defined
 in mozilla public suffix list https://publicsuffix.org/list/. And I assume
 if there's an exception then it gets set to an empty string (unless it's
 about:*, etc.).

 Which means that all domains here will go to the same catch-all circuit:
 https://gitweb.torproject.org/tor-
 browser.git/tree/netwerk/dns/effective_tld_names.dat?h=tor-
 browser-60.6.1esr-8.0-1-build1. So urls like http://mycd.eu,
 http://s3.amazonaws.com/whatever, https://ownprovider.com/en/Main, ...,
 will go to the same catch-all circuit with the current firstPartyDomain
 implementation. The same happens with any random domain like
 http://foobarfoo. Also note the list in the repo is not up to date with
 https://publicsuffix.org/list/public_suffix_list.dat.

 Shouldn't firstPartyDomain be the first-level domain on those cases
 (instead of empty string), or am I missing some reason why this is not a
 good idea?

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

 * parent:   => #30029


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30029 [Applications/Tor Browser]: Objective 2, Activity 5: POC for Human-memorable addresses for .onion services

[Tor Bug Tracker & Wiki]

#30029: Objective 2, Activity 5: POC for Human-memorable addresses for .onion
services
--+--
 Reporter:  pili  |  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor27 |
--+--
 This is the parent ticket to hold any tickets under this activity,
 including:
 - Evaluating using HTTPS-Everywhere.
 - Evaluating using HTTPS-Everywhere’s Update Channels feature to add
 custom onion rulesets that can be updated automatically.
 - Evaluating adding a designated file extension handler in Tor Browser to
 handle HTTPS-Everywhere rulesets.
 - Evaluating enhancing the UI of HTTPS-Everywhere so that it educates
 users on how onion update channels 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] #29822 [Internal Services/Tor Sysadmin Team]: prometheus server cannot reach build-arm* boxes

[Tor Bug Tracker & Wiki]

#29822: prometheus server cannot reach build-arm* boxes
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Minor| Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29681   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * parent:   => #29681


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

Re: [tor-bugs] #30028 [Internal Services/Tor Sysadmin Team]: additional prometheus/grafana exporters/dashboards

[Tor Bug Tracker & Wiki]

#30028: additional prometheus/grafana exporters/dashboards
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  project  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29681   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * owner:  tpa => anarcat
 * status:  new => assigned


Old description:

> our munin replacement is not entirely complete, as there are key parts of
> the infrastructure that are not monitored. here's a short inventory of
> what I found in #29681:
>
> '''email servers monitoring (eugeni, etc? postfix)'''
>
> * [https://github.com/kumina/postfix_exporter in debian],
> [https://github.com/kumina/postfix_exporter/issues/21 possible dashboard]
> * another approach: [https://github.com/cherti/mailexporter email
> delivery tests]
>
> '''mailman monitoring'''
>
> no known exporter or dashboard
>
> '''databases'''
>
> * [https://github.com/wrouesnel/postgres_exporter/ postgres exporter in
> debian], [https://github.com/wrouesnel/postgres_exporter/issues/218 no
> offocial dashboard], but
> [https://grafana.com/dashboards?dataSource=prometheus=postgres
> many possible dashboards]
> * [https://github.com/prometheus/mysqld_exporter mysqld exporter in
> debian] - [https://grafana.com/dashboards/625 possible dashboard]
> [https://github.com/percona/grafana-dashboards another from  percona],
> [https://github.com/prometheus/mysqld_exporter/issues/286 not officially
> documented]
>
> '''DNS / bind'''
>
> - [https://github.com/digitalocean/bind_exporter/ in debian],
> [https://grafana.com/dashboards/1666 official dashboard]
>
> '''GitLab'''
>
> there is
> [https://docs.gitlab.com/ee/administration/monitoring/prometheus/ builtin
> support for prometheus] that has to be
> [https://docs.gitlab.com/ee/administration/monitoring/prometheus/gitlab_metrics.html
> configured]
>
> those are the other missing things I found during the audit performed
> while removing Munin:
>
>  * '''spamassassin''': ham/spam/total counts, looks for `spamd:
> ((processing|checking) message|identified spam|clean message)` in
> mail.log, could be replaced with [https://github.com/google/mtail ​mtail]
>  * '''postgres-wal-traffic_''': should be covered by the
> postgres_exporter mentioned above, otherwise hook `psql -p "$port" --no-
> align --command 'SELECT * FROM pg_current_xlog_insert_location()'
> --tuples-only --quiet | tr -d /,` into the node_exporter
>  * '''ksm stats''': extra memory statistics, might not be very important
>  * '''haproxy''': https://github.com/prometheus/haproxy_exporter
>  * '''per VM disk usage''': see  #29816
>  * '''vsftpd''': custom mtail plugin, no known exporter or dashboard
>
> See the full review in #29682 for details on those.

New description:

 our munin replacement is not entirely complete, as there are key parts of
 the infrastructure that are not monitored. here's a short inventory of
 what I found in #29681:

 '''email servers monitoring (eugeni, etc? postfix)'''

 * [https://github.com/kumina/postfix_exporter in debian],
 [https://github.com/kumina/postfix_exporter/issues/21 possible dashboard]
 * another approach: [https://github.com/cherti/mailexporter email delivery
 tests]

 '''mailman monitoring'''

 no known exporter or dashboard

 '''databases'''

 * [https://github.com/wrouesnel/postgres_exporter/ postgres exporter in
 debian], [https://github.com/wrouesnel/postgres_exporter/issues/218 no
 offocial dashboard], but
 [https://grafana.com/dashboards?dataSource=prometheus=postgres many
 possible dashboards]
 * [https://github.com/prometheus/mysqld_exporter mysqld exporter in
 debian] - [https://grafana.com/dashboards/625 possible dashboard]
 [https://github.com/percona/grafana-dashboards another from  percona],
 [https://github.com/prometheus/mysqld_exporter/issues/286 not officially
 documented]

 '''DNS / bind'''

 - [https://github.com/digitalocean/bind_exporter/ in debian],
 [https://grafana.com/dashboards/1666 official dashboard]

 '''GitLab'''

 there is [https://docs.gitlab.com/ee/administration/monitoring/prometheus/
 builtin support for prometheus] that has to be
 
[https://docs.gitlab.com/ee/administration/monitoring/prometheus/gitlab_metrics.html
 configured]

 those are the other missing things I found during the audit performed
 while removing Munin:

  * '''spamassassin''': ham/spam/total counts, looks for `spamd:
 ((processing|checking) message|identified spam|clean 

Re: [tor-bugs] #30028 [Internal Services/Tor Sysadmin Team]: additional prometheus/grafana exporters/dashboards

[Tor Bug Tracker & Wiki]

#30028: additional prometheus/grafana exporters/dashboards
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29681   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 out of those, I think we can consider the issue complete when we have
 those monitored:

  * bind
  * postfix
  * spamassassin
  * postgresql

 everything else is sugar on top we can add as needed eventually or that is
 covered by other tickets.

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

[tor-bugs] #30028 [Internal Services/Tor Sysadmin Team]: additional prometheus/grafana exporters/dashboards

[Tor Bug Tracker & Wiki]

#30028: additional prometheus/grafana exporters/dashboards
-+
 Reporter:  anarcat  |  Owner:  tpa
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #29681
   Points:   |   Reviewer:
  Sponsor:   |
-+
 our munin replacement is not entirely complete, as there are key parts of
 the infrastructure that are not monitored. here's a short inventory of
 what I found in #29681:

 '''email servers monitoring (eugeni, etc? postfix)'''

 * [https://github.com/kumina/postfix_exporter in debian],
 [https://github.com/kumina/postfix_exporter/issues/21 possible dashboard]
 * another approach: [https://github.com/cherti/mailexporter email delivery
 tests]

 '''mailman monitoring'''

 no known exporter or dashboard

 '''databases'''

 * [https://github.com/wrouesnel/postgres_exporter/ postgres exporter in
 debian], [https://github.com/wrouesnel/postgres_exporter/issues/218 no
 offocial dashboard], but
 [https://grafana.com/dashboards?dataSource=prometheus=postgres many
 possible dashboards]
 * [https://github.com/prometheus/mysqld_exporter mysqld exporter in
 debian] - [https://grafana.com/dashboards/625 possible dashboard]
 [https://github.com/percona/grafana-dashboards another from  percona],
 [https://github.com/prometheus/mysqld_exporter/issues/286 not officially
 documented]

 '''DNS / bind'''

 - [https://github.com/digitalocean/bind_exporter/ in debian],
 [https://grafana.com/dashboards/1666 official dashboard]

 '''GitLab'''

 there is [https://docs.gitlab.com/ee/administration/monitoring/prometheus/
 builtin support for prometheus] that has to be
 
[https://docs.gitlab.com/ee/administration/monitoring/prometheus/gitlab_metrics.html
 configured]

 those are the other missing things I found during the audit performed
 while removing Munin:

  * '''spamassassin''': ham/spam/total counts, looks for `spamd:
 ((processing|checking) message|identified spam|clean message)` in
 mail.log, could be replaced with [https://github.com/google/mtail ​mtail]
  * '''postgres-wal-traffic_''': should be covered by the postgres_exporter
 mentioned above, otherwise hook `psql -p "$port" --no-align --command
 'SELECT * FROM pg_current_xlog_insert_location()' --tuples-only --quiet |
 tr -d /,` into the node_exporter
  * '''ksm stats''': extra memory statistics, might not be very important
  * '''haproxy''': https://github.com/prometheus/haproxy_exporter
  * '''per VM disk usage''': see  #29816
  * '''vsftpd''': custom mtail plugin, no known exporter or dashboard

 See the full review in #29682 for details on those.

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

Re: [tor-bugs] #13410 [Applications/Tor Browser]: Disable self-signed certificate warnings when visiting .onion sites

[Tor Bug Tracker & Wiki]

#13410: Disable self-signed certificate warnings when visiting .onion sites
--+
 Reporter:  tom   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:  #30025| Points:
 Reviewer:|Sponsor:  Sponsor27-must
--+
Changes (by pili):

 * parent:   => #30025


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

Re: [tor-bugs] #19251 [Applications/Tor Browser]: TorBrowser might want to have an error page specific to when .onion links fail

[Tor Bug Tracker & Wiki]

#19251: TorBrowser might want to have an error page specific to when .onion 
links
fail
--+
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:  #30025| Points:
 Reviewer:|Sponsor:  Sponsor27-must
--+
Changes (by pili):

 * parent:   => #30025


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30027 [Community/Tor Browser Manual]: tb-manual: Titles should not be capitalized in the CSS

[Tor Bug Tracker & Wiki]

#30027: tb-manual: Titles should not be capitalized in the CSS
--+---
 Reporter:  emmapeel  |  Owner:  phoul
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Community/Tor Browser Manual  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 Different languages have different rules for capitalization.

 We should propose the string in all caps to translate and let translators
 decide on how to write it on their different languages.

 For example, https://tb-manual.torproject.org/el/ should not capitalize
 the titles, as this is not done in Greek.

 thanks papassadrian for the report!

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

Re: [tor-bugs] #27636 [Applications/Tor Browser]: .onion indicator for non-self-signed but non-trusted sites

[Tor Bug Tracker & Wiki]

#27636: .onion indicator for non-self-signed but non-trusted sites
--+
 Reporter:  o--   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:  #30025| Points:
 Reviewer:|Sponsor:  Sponsor27-must
--+
Changes (by pili):

 * parent:   => #30025


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

Re: [tor-bugs] #29684 [Internal Services/Tor Sysadmin Team]: setup a grafana server somewhere

[Tor Bug Tracker & Wiki]

#29684: setup a grafana server somewhere
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:  #29681   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

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


Comment:

 i have moved the authentication questions into #30023 and docker
 deployment info #30026 so I believe we can close this ticket for now.

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

[tor-bugs] #30026 [Internal Services/Tor Sysadmin Team]: move grafana in a docker container

[Tor Bug Tracker & Wiki]

#30026: move grafana in a docker container
-+
 Reporter:  anarcat  |  Owner:  tpa
 Type:  project  | Status:  new
 Priority:  Low  |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major|   Keywords:
Actual Points:   |  Parent ID:  #29681
   Points:   |   Reviewer:
  Sponsor:   |
-+
 the summary of the "do we use grafana" and "docker vs debian" discussion
 held in #29684 is basically: "deploy grafana using Docker". We currently
 deploy it using Debian packages, so we need to flip that over to the
 container world.

 Because things are working well now and I'd like to finish the deployment,
 I'm splitting that out into a separate ticket for now.

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

[tor-bugs] #30025 [Applications/Tor Browser]: Objective 2, Activity 4: Better client-side errors

[Tor Bug Tracker & Wiki]

#30025: Objective 2, Activity 4: Better client-side errors
--+--
 Reporter:  pili  |  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor27 |
--+--
 This is the parent ticket to hold any tickets under this activity,
 including:
 - Improving Tor Browser behavior when an onion site supports HTTPS but the
 HTTPS is not from an approved certificate.
 - Fixing inconsistent messages we are showing to users accessing .onion
 sites with self-signed certificates-
 - Improving Tor Browser’s user experience and error messages when a .onion
 link fails.
 - Providing more informative error messages back to the user to better
 indicate whether the issue was on the service-side, on the client-side, or
 on the network-side.

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

Re: [tor-bugs] #21952 [Applications/Tor Browser]: .Onion everywhere?: increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: .Onion everywhere?: increasing the use of onion services through 
automatic
redirects and aliasing
--+
 Reporter:  linda |  Owner:  tbb-team
 Type:  project   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team, tor-hs   |  Actual Points:
Parent ID:  #30024| Points:
 Reviewer:|Sponsor:  Sponsor27-must
--+
Changes (by pili):

 * parent:   => #30024


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

Re: [tor-bugs] #27590 [Applications/Tor Browser]: Display .onion alt-svc route in the circuit display

[Tor Bug Tracker & Wiki]

#27590: Display .onion alt-svc route in the circuit display
--+
 Reporter:  mahrud|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-circuit-display, ux-team  |  Actual Points:
Parent ID:  #30024| Points:
 Reviewer:|Sponsor:  Sponsor27-must
--+
Changes (by pili):

 * parent:   => #30024


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

Re: [tor-bugs] #27502 [Applications/Tor Browser]: Prioritize .onion hosts in AltSvc?

[Tor Bug Tracker & Wiki]

#27502: Prioritize .onion hosts in AltSvc?
--+
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #30024| Points:
 Reviewer:|Sponsor:  Sponsor27-must
--+
Changes (by pili):

 * parent:   => #30024


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #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|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor27 |
--+--
 This is the parent ticket to hold any tickets under this activity,
 including:
 - Investigate the ideal browser user experience for when such a
 redirection takes place, to minimize user confusion.
 - Build the code necessary to optimally support this experience on Tor
 Browser such as prioritizing .onion addresses when Alt-Svc is used.
 - Correctly display the .onion Alt-Svc circuit path on the circuit
 display.
 - Educate the user on how the redirection takes place, so that users get
 more familiar with the concept of onion services. We will employ
 appropriate “stop-and-learn” techniques to inform our users of the
 benefits of onion services and how they should be used.
 - Continue work on our  Onion-Location proposal which gives the user the
 option to choose whether or not onion redirect should take place.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #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   |   Keywords:
Actual Points:   |  Parent ID:  #29681
   Points:   |   Reviewer:
  Sponsor:   |
-+
 the grafana server is now setup (#29684) but there are still issues
 regarding authentication. we might want to grant access to other users
 than the admin one, for example.

 the original idea was to do the same "anonymous authentication" setup than
 for Prometheus, except something came up during deployment that made me
 question that strategy. it was raised while considering deployment of
 third-party exporters:

 > something regarding authentication came up through a third-party scraper
 deployment, in #29863. there were concerns the node exporter would leak
 information that could be exploited for a side-channel attacks. the node
 exporter is firewalled, but then all that data is then made available on
 the prometheus server protected only by a trivial password. they will make
 an assessment of the exposed data and see if the additional authentication
 burden is worth the risk.

 if we do not go with "anon" authentication, we could connect the Grafana
 server with LDAP, but then it means it might go down if the LDAP server
 crashes, which is a problem for a monitoring server, obviously.

 in any case, users need to be configured through Puppet, which they
 currently are not. this is partly related to secrets management and
 generation in Puppet, which is also discussed in #30009.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] [Tor Bug Tracker & Wiki] Batch modify: #29357, #29668, #30021, #29108

[Tor Bug Tracker & Wiki]

Batch modification to #29357, #29668, #30021, #29108 by nickm:


Comment:
batch-modify: asn has offered to merge these tomorrow, so removing them from 
teor's plate.  Teor -- you can merge these anyway if you are blocked on any of 
them and it would save you time to do so.

--
Tickets URL: 

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

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

[Tor Bug Tracker & Wiki]

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

 * parent:   => #30022


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30022 [Applications/Tor Browser]: Objective 2, Activity 2: Notify users about typo errors when entering .onion addresses

[Tor Bug Tracker & Wiki]

#30022: Objective 2, Activity 2: Notify users about typo errors when entering
.onion addresses
--+--
 Reporter:  pili  |  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor27 |
--+--
 This is the parent ticket to hold any tickets under this activity,
 including:

 - Using the address format of onion services v3 that allows us to detect
 typos.
 - Experimenting with the optimal user experience for this error case, e.g.
 offering a retry-button after explaining what went wrong.
 - Implementing a special error page that tells the user the problem is a
 typo in the address.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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]: Improve TBB UI of hidden service client authorization

[Tor Bug Tracker & Wiki]

#14389: Improve 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
-+-
Changes (by pili):

 * parent:   => #3


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

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

[Tor Bug Tracker & Wiki]

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

 * parent:   => #3


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  hs-auth   |  Actual Points:
Parent ID:  #3| Points:
 Reviewer:|Sponsor:  Sponsor27-must
--+
Changes (by pili):

 * parent:   => #3


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

Re: [tor-bugs] #29357 [Core Tor/Tor]: add an ActiveOnStartup config option

[Tor Bug Tracker & Wiki]

#29357: add an ActiveOnStartup config option
-+-
 Reporter:  mcs  |  Owner:  nickm
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-needs, 040-proposed, 040-must,   |  Actual Points:  .1
  asn-merge teor-merge   |
Parent ID:   | Points:  .5
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by nickm):

 * keywords:  tbb-needs, 040-proposed, 040-must => tbb-needs, 040-proposed,
 040-must, asn-merge teor-merge


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

Re: [tor-bugs] #29241 [Core Tor/Tor]: NSS SSL_ExportKeyingMaterial failing

[Tor Bug Tracker & Wiki]

#29241: NSS SSL_ExportKeyingMaterial failing
-+-
 Reporter:  sysrqb   |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression, 035-backport?,   |  Actual Points:  1.5
  040-must, spec teor-merge  |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  regression, 035-backport?, 040-must, spec => regression,
 035-backport?, 040-must, spec teor-merge


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

Re: [tor-bugs] #29668 [Core Tor/Tor]: Drop thread_fast_rng during postfork; improve thread_fast_rng fork-safety

[Tor Bug Tracker & Wiki]

#29668: Drop thread_fast_rng during postfork; improve thread_fast_rng 
fork-safety
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  High  |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  asn-merge teor-merge  |  Actual Points:  .2
Parent ID:| Points:  .1
 Reviewer:  ahf   |Sponsor:  SponsorV
--+
Changes (by nickm):

 * keywords:   => asn-merge teor-merge


Comment:

 CI passed; force-pushed a squashed version.

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

Re: [tor-bugs] #30021 [Core Tor/Tor]: Do not cache cipher list classification if cipher list is not yet available.

[Tor Bug Tracker & Wiki]

#30021: Do not cache cipher list classification if cipher list is not yet
available.
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci-fail-sometimes, ci, stem, |  Actual Points:  .5
  ssl, 029-backport 034-backport 035-backport,   |
  asn-merge, teor-merge  |
Parent ID:  #29437   | Points:
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by nickm):

 * keywords:
 tor-ci-fail-sometimes, ci, stem, ssl, 029-backport 034-backport
 035-backport, asn-merge
 =>
 tor-ci-fail-sometimes, ci, stem, ssl, 029-backport 034-backport
 035-backport, asn-merge, teor-merge


Comment:

 whoever gets to this first should give it a merge IMO :)

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

Re: [tor-bugs] #30021 [Core Tor/Tor]: Do not cache cipher list classification if cipher list is not yet available.

[Tor Bug Tracker & Wiki]

#30021: Do not cache cipher list classification if cipher list is not yet
available.
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci-fail-sometimes, ci, stem, |  Actual Points:  .5
  ssl, 029-backport 034-backport 035-backport,   |
  asn-merge  |
Parent ID:  #29437   | Points:
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by nickm):

 * keywords:
 tor-ci-fail-sometimes, ci, stem, ssl, 029-backport 034-backport
 035-backport
 =>
 tor-ci-fail-sometimes, ci, stem, ssl, 029-backport 034-backport
 035-backport, asn-merge


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

Re: [tor-bugs] #9316 [Obfuscation/BridgeDB]: BridgeDB should export statistics

[Tor Bug Tracker & Wiki]

#9316: BridgeDB should export statistics
-+-
 Reporter:  asn  |  Owner:  dgoulet
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/BridgeDB |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics, bridgedb, network-team- |  Actual Points:
  roadmap-2019-Q1Q2  |
Parent ID:  #19332   | Points:  3
 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] #29279 [Obfuscation/Obfsproxy]: Reach out to NGOs to test obfs4 reachability

[Tor Bug Tracker & Wiki]

#29279: Reach out to NGOs to test obfs4 reachability
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  task | Status:
 |  assigned
 Priority:  Very High|  Milestone:
Component:  Obfuscation/Obfsproxy|Version:
 Severity:  Normal   | Resolution:
 Keywords:  NGO, community, network-team-|  Actual Points:
  roadmap-2019-Q1Q2  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor19
-+-

Comment (by cohosh):

 Here's some preliminary results after 3 days of testing.

 The bridges ndnop3 and ndnop4 were used in previous testing so it's likely
 they became blocked long before this test for other reasons.

 So far the private bridges we set up for these tests have not been blocked
 and the throughput is not being throttled.

 [[Image(obfs4-reachability-2019-04-04.pdf)]]

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

Re: [tor-bugs] #29279 [Obfuscation/Obfsproxy]: Reach out to NGOs to test obfs4 reachability

[Tor Bug Tracker & Wiki]

#29279: Reach out to NGOs to test obfs4 reachability
-+-
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  task | Status:
 |  assigned
 Priority:  Very High|  Milestone:
Component:  Obfuscation/Obfsproxy|Version:
 Severity:  Normal   | Resolution:
 Keywords:  NGO, community, network-team-|  Actual Points:
  roadmap-2019-Q1Q2  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor19
-+-
Changes (by cohosh):

 * Attachment "obfs4-reachability-2019-04-04.pdf" 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] #29768 [Applications/Tor Browser]: Introduce new features to users in Tor Browser

[Tor Bug Tracker & Wiki]

#29768: Introduce new features to users in Tor Browser
-+-
 Reporter:  antonela |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201903R, tbb-8.5   |  Actual Points:
  -must-alpha, TorBrowserTeam201904  |
Parent ID:  #25658   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dunqan):

 Replying to [comment:36 mcs]:

 Gotcha, thanks mcs!

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