[tor-bugs] #33165 [Metrics/Analysis]: Number of direct users mysteriously spikes in US & NL

[Tor Bug Tracker & Wiki]

#33165: Number of direct users mysteriously spikes in US & NL
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  task | Status:  new
 Priority:  Medium   |  Component:  Metrics/Analysis
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 [[Image(https://metrics.torproject.org/userstats-relay-
 country.png?start=2019-11-08=2020-02-06=us=off)]]


 [[Image(https://metrics.torproject.org/userstats-relay-
 country.png?start=2019-11-08=2020-02-06=nl=off)]]


 Seems to follow the same pattern as well. I've checked the other top 10
 countries but none seems to be affected by 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] #32255 [Applications/Tor Browser]: Missing ORIGIN header breaks CORS in Tor Browser 9.0

[Tor Bug Tracker & Wiki]

#32255: Missing ORIGIN header breaks CORS in Tor Browser 9.0
-+-
 Reporter:  complexparadox   |  Owner:  acat
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-9.0-issues, tbb-9.0.1-can, tbb-  |  Actual Points:
  regression, TorBrowserTeam201911R, 9.5a3,  |
  9.0.5, tbb-backported  |
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

 * keywords:
 tbb-9.0-issues, tbb-9.0.1-can, tbb-regression, TorBrowserTeam201911R,
 tbb-backport
 =>
 tbb-9.0-issues, tbb-9.0.1-can, tbb-regression, TorBrowserTeam201911R,
 9.5a3, 9.0.5, tbb-backported


Comment:

 Backported on `tor-browser-68.4.1esr-9.0-1` as
 `5526a109e6266ce31f8014912d5b91b154736ef6`.

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

Re: [tor-bugs] #32132 [Applications/Tor Browser]: Re-enable jemalloc for Windows users

[Tor Bug Tracker & Wiki]

#32132: Re-enable jemalloc for Windows users
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201910R,   |  Actual Points:  0.1
  GeorgKoppen201910, tbb-rbm, 9.5a1, 9.0.5,  |
  tbb-backported |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

 * keywords:  TorBrowserTeam201910R, GeorgKoppen201910, tbb-rbm, tbb-
 backport =>
 TorBrowserTeam201910R, GeorgKoppen201910, tbb-rbm, 9.5a1, 9.0.5, tbb-
 backported


Comment:

 Backported as commit `153b7d9b25f10f983f7577fb00d8e4c594e06738` on
 maint-9.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] #32891 [Applications/Tor Browser]: Set up default bridge in Denmark

[Tor Bug Tracker & Wiki]

#32891: Set up default bridge in Denmark
-+-
 Reporter:  phw  |  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-bridges, TorBrowserTeam202001R,  |  implemented
  9.5a5, 9.0.5   |  Actual Points:
Parent ID:   | Points:  0.2
 Reviewer:  boklm|Sponsor:
-+-
Changes (by sysrqb):

 * keywords:  tbb-bridges, TorBrowserTeam202001R, 9.5a5, 9.0.4 => tbb-
 bridges, TorBrowserTeam202001R, 9.5a5, 9.0.5


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

Re: [tor-bugs] #32053 [Applications/Tor Browser]: Tor Browser bundles based on Firefox 68 ESR are not reproducible (LLVM optimization issue)

[Tor Bug Tracker & Wiki]

#32053: Tor Browser bundles based on Firefox 68 ESR are not reproducible (LLVM
optimization issue)
-+-
 Reporter:  gk   |  Owner:  gk
 Type:  defect   | Status:  closed
 Priority:  Immediate|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:  fixed
 Keywords:  tbb-9.0-must, tbb-9.0-issues, tbb-   |  Actual Points:  14.5
  regression, tbb-9.0.1-can, |
  TorBrowserTeam201912R, GeorgKoppen201912,  |
  9.0.5, 9.5a4, tbb-backported   |
Parent ID:   | Points:
 Reviewer:  boklm|Sponsor:
-+-
Changes (by sysrqb):

 * keywords:
 tbb-9.0-must, tbb-9.0-issues, tbb-regression, tbb-9.0.1-can,
 TorBrowserTeam201912R, GeorgKoppen201912, tbb-backport
 =>
 tbb-9.0-must, tbb-9.0-issues, tbb-regression, tbb-9.0.1-can,
 TorBrowserTeam201912R, GeorgKoppen201912, 9.0.5, 9.5a4, tbb-backported


Comment:

 Replying to [comment:58 boklm]:
 > Thanks, I merged it to master as commit
 5cafc16c0e5af59f95f685025b487b306c10bd01. I'm adding the tbb-backport
 keyword as we probably want to backport this to the stable branch.

 Backported as commit `0fbb6fa8a942e8243130f8c68616a28d4181a090`.

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

Re: [tor-bugs] #30237 [Applications/Tor Browser]: Tor Browser: Improve TBB UI of hidden service client authorization

[Tor Bug Tracker & Wiki]

#30237: Tor Browser: Improve TBB UI of hidden service client authorization
-+-
 Reporter:  asn  |  Owner:  mcs
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  network-team-roadmap-september,  |  implemented
  TorBrowserTeam202001R network-team-roadmap-|  Actual Points:  16.1
  2020Q1, 9.5a5  |
Parent ID:  #3   | Points:  17
 Reviewer:  pospeselr, sysrqb|Sponsor:
 |  Sponsor27-must
-+-
Changes (by sysrqb):

 * keywords:
 network-team-roadmap-september, TorBrowserTeam202001R network-team-
 roadmap-2020Q1
 =>
 network-team-roadmap-september, TorBrowserTeam202001R network-team-
 roadmap-2020Q1, 9.5a5


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

Re: [tor-bugs] #32891 [Applications/Tor Browser]: Set up default bridge in Denmark

[Tor Bug Tracker & Wiki]

#32891: Set up default bridge in Denmark
-+-
 Reporter:  phw  |  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-bridges, TorBrowserTeam202001R,  |  implemented
  9.5a5, 9.0.4   |  Actual Points:
Parent ID:   | Points:  0.2
 Reviewer:  boklm|Sponsor:
-+-
Changes (by sysrqb):

 * keywords:  tbb-bridges, TorBrowserTeam202001R => tbb-bridges,
 TorBrowserTeam202001R, 9.5a5, 9.0.4


Comment:

 Replying to [comment:8 sysrqb]:
 > Replying to [comment:7 boklm]:
 > > Replying to [comment:4 phw]:
 > > > * My task/32891 branch [https://github.com/NullHypothesis/tor-
 browser-build/commit/21faabfdbf08dbf25ff1fcf77c54d684b15c6fa1 has a patch]
 for tor-browser-build.
 > >
 > > This looks good to me. I merged the patch to master with commit
 `215aed39ee177bd0a371e8e4b6d7de3fcf69ffed`, and cherry-picked it to
 `maint-9.0` as commit `82672d50af26c862214f3c1c2670897f94a9dbf9`.
 > >
 > > > * My task/32891 branch [https://github.com/NullHypothesis/tor-
 android-service/commit/694ef51f3a59c39c74bd22d1a1ee48f4b91d235f has a
 patch] for tor-android-service.
 > >
 > > This looks good to me too, however I don't have write access on this
 repository, so someone else (sysrqb?) will have to push it.
 >
 > Thanks! Merged this as `18ba7d2780b1d5194cc5854d703655f6c9d3d196`.
 And merged on maint-9.0 as commit
 `0d50bcb46dc0ec08c7076d26da3eb561ba10d6b1`.

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

Re: [tor-bugs] #32767 [Applications/Tor Browser]: Remove Disconnect search as it is discontinued

[Tor Bug Tracker & Wiki]

#32767: Remove Disconnect search as it is discontinued
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam202001R, 9.5a5  |  Actual Points:  0.25
Parent ID:| Points:  0.25
 Reviewer:  boklm |Sponsor:
--+--
Changes (by sysrqb):

 * keywords:  TorBrowserTeam202001R => TorBrowserTeam202001R, 9.5a5
 * status:  needs_review => closed
 * resolution:   => fixed


Comment:

 Replying to [comment:5 acat]:
 > Replying to [comment:4 sysrqb]:
 > > Can you create this as a fixup! on "Omnibox: Add DDG, Startpage,
 Disconnect, Youtube, Twitter; remove Amazon, eBay, bing"
 (`1d63bba60069585d820b5ae7508ed69fb36f92c0`) instead of a new commit? Are
 all modifications from that original commit?
 > Yes, all are modifications from that commit. Done as a fixup in
 ​https://github.com/acatarineu/tor-browser/commit/32767+1.

 Thanks! Merged as `bfe5efa2e8eaac36bc9930fa1437b1a70045532b`.

 >
 > We might want to reword this and the test commit in the next rebase,
 since Disconnect is not there anymore.

 That's a good point, I'll try remember this during the rebase.

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

Re: [tor-bugs] #31395 [Applications/Tor Browser]: Remove inline

[Tor Bug Tracker & Wiki]

#31395: Remove inline 

Re: [tor-bugs] #32132 [Applications/Tor Browser]: Re-enable jemalloc for Windows users

[Tor Bug Tracker & Wiki]

#32132: Re-enable jemalloc for Windows users
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201910R,   |  Actual Points:  0.1
  GeorgKoppen201910, tbb-rbm, tbb-backport   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 When?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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-location: increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: Onion-location: increasing the use of onion services through automatic
redirects and aliasing
-+-
 Reporter:  linda|  Owner:  acat
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tor-hs, network-team-   |  Actual Points:  9
  roadmap-november, tbb-9.5, |
  TorBrowserTeam202001R, network-team-roadmap-   |
  2020Q1 |
Parent ID:  #30024   | Points:  6
 Reviewer:  pospeselr, mcs, brade|Sponsor:
 |  Sponsor27-must
-+-

Comment (by sysrqb):

 Replying to [comment:99 acat]:
 > Replying to [comment:98 pospeselr]:
 > > Regarding servers sending 3XX responses with {{{Onion-Location}}} sans
 {{{Location}}}: I think that the browser should only transparently treat
 {{{Onion-Location}}} as if it were {{{Location}}} if the user has the auto
 onion redirect pref on. If that pref is on, I think we should look for
 {{{Onion-Location}}} first in the case of 3XX redirects and then fallback
 to {{{Location}}}.
 >
 > For the cases where there needs to be a redirect in any case, having
 both `Onion-Location` and `Location` in a 30X works fine I think. And the
 priority you suggest looks like the right one.

 Maybe we should specify that `Onion-Location` should only be used with
 `300 Multiple Choices`? If a server sends `301 Moved Permanently`, `307
 Temporary Redirect`, or `308 Permanent Redirect`, then that seems like it
 implies the user-agent should redirect to the provided location without
 user intervention.

 I prefer we explicitly define which conditions cause a redirect verses
 cause the badge UI. A response with code `308` and `Onion-Location` is
 saying "This resource is not at the URL you requested anymore, please load
 it from this onion location, but only if the user chooses to use the new
 location (onion address). Meanwhile, please enjoy the page I just was
 permanently moved", right?

 >
 > The problem I see is when there would be no need to redirect
 [snip]
 >
 > So I think making `Onion-Location` (or an equivalent header with a
 different name) behaviour independent of the status code of the response
 is preferable, but I might be missing something.

 Yeah, I think we are experiencing some scope-creep here :) But maybe this
 is okay. We should resolve any confusion or ambiguity for how this should
 be used and the expected behavior before we merge this.

 > Replying to [ticket:21952 linda]:
 >>  ilf is experimenting with automatically redirecting Tor users to
 .onion versions of websites that they visit (because they want more people
 to visit onion sites and they will do so if it is painless to them). But
 when users were redirected automatically to an onion site, they freaked
 out about it because they didn't know what happened, didn't know what
 onion sites were, and the "https" was dropped.

 The original idea was only intended as an alternative for simply and
 forcefully redirecting all users to an onion address (based on exit node
 IP address). Making this opt-in may make this less scary and an
 "educational experience". My understanding is this directly changes the
 behavior of `307`and `308`, but I am concerned this is not the best
 behavior.

 >
 > Thinking about adoption, also note that the current implementation
 (ignoring response code) could allow achieving the same via a `http://some.onion;>` HTML tag, in case
 adding headers is more difficult for website owners than adding meta tags
 in the page content.

 This is a neat 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] #33159 [Core Tor/Tor]: Write a proposal for monitoring IPv6

[Tor Bug Tracker & Wiki]

#33159: Write a proposal for monitoring IPv6
--+
 Reporter:  teor  |  Owner:  teor
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6  |  Actual Points:
Parent ID:  #33052| Points:  2
 Reviewer:|Sponsor:  Sponsor55-must
--+

Comment (by teor):

 We should also consider changes to Relay Search, consensus-health, or the
 metrics graphs, to encourage IPv6 deployment, and improve the KPIs for
 this 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] #33103 [Core Tor/Tor]: LeakSanitizer is kicking in with tor being on 39c5e1b84994c2f226a8530b930f215cc5ffb877 when closing Tor Browser

[Tor Bug Tracker & Wiki]

#33103: LeakSanitizer is kicking in with tor being on
39c5e1b84994c2f226a8530b930f215cc5ffb877 when closing Tor Browser
-+-
 Reporter:  gk   |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression leak 043-must |  Actual Points:  .1
  BugSmashFund   |
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
-+-
Changes (by teor):

 * keywords:  regression leak 043-must => regression leak 043-must
 BugSmashFund
 * reviewer:   => teor
 * status:  needs_review => merge_ready


Comment:

 Looks good to me!

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

Re: [tor-bugs] #30638 [Core Tor/Tor]: Test banning ed25519 keys in the approved-routers file on moria1

[Tor Bug Tracker & Wiki]

#30638: Test banning ed25519 keys in the approved-routers file on moria1
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, 042-deferred-20190918   |  Actual Points:
  043-should |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * owner:  arma => (none)


Comment:

 #30642 adds an ed25519_identity file to relay data directories. It's
 waiting for review.

 So here's how we can move forward:
 * a relay operator runs that branch on their relay,
 * turns that file into a reject line,
 * sends it to arma, and
 * checks that moria1 excludes their relay.

 I'll un-assign this ticket, so we assign it to a network team staff member
 to make this happen.

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

Re: [tor-bugs] #30638 [Core Tor/Tor]: Test banning ed25519 keys in the approved-routers file on moria1

[Tor Bug Tracker & Wiki]

#30638: Test banning ed25519 keys in the approved-routers file on moria1
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, 042-deferred-20190918   |  Actual Points:
  043-should |
Parent ID:   | Points:  1
 Reviewer:  arma |Sponsor:
-+-
Changes (by teor):

 * status:  assigned => new
 * reviewer:   => arma


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

Re: [tor-bugs] #33164 [Core Tor/Tor]: Update torspec reindex.py for Python 3

[Tor Bug Tracker & Wiki]

#33164: Update torspec reindex.py for Python 3
-+-
 Reporter:  teor |  Owner:  teor
 Type:  task | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  043-should, torspec, python  |  Actual Points:  0.1
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  assigned => needs_review


Old description:

> We need to update torspec's proposals/reindex.py for Python 3.
>
> As a consequence, proposal titles are required to be UTF-8.

New description:

 We need to update torspec's proposals/reindex.py for Python 3.

 As a consequence, proposal must be encoded in UTF-8.

--

Comment:

 See my PR:
 * torspec: https://github.com/torproject/torspec/pull/106

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33164 [Core Tor/Tor]: Update torspec reindex.py for Python 3

[Tor Bug Tracker & Wiki]

#33164: Update torspec reindex.py for Python 3
--+-
 Reporter:  teor  |  Owner:  teor
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  043-should, torspec, python
Actual Points:  0.1   |  Parent ID:
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+-
 We need to update torspec's proposals/reindex.py for Python 3.

 As a consequence, proposal titles are required to be UTF-8.

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

Re: [tor-bugs] #32921 [Core Tor/Tor]: Code and script changes to run clang-format without breaking checkSpaces or coccinelle

[Tor Bug Tracker & Wiki]

#32921: Code and script changes to run clang-format without breaking 
checkSpaces or
coccinelle
+
 Reporter:  nickm   |  Owner:  nickm
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  style, 043-can  |  Actual Points:  1.5
Parent ID:  #29226  | Points:
 Reviewer:  catalyst|Sponsor:
+

Comment (by catalyst):

 Replying to [comment:13 nickm]:
 > I don't object to any of those changes.  Would you prefer I wait till
 you've reviewed the rest of the branch for me to make them, or go ahead
 and update the branch?
 Please go ahead and update the branch.  Force-pushing the branch is ok
 with me.

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

Re: [tor-bugs] #32921 [Core Tor/Tor]: Code and script changes to run clang-format without breaking checkSpaces or coccinelle

[Tor Bug Tracker & Wiki]

#32921: Code and script changes to run clang-format without breaking 
checkSpaces or
coccinelle
+
 Reporter:  nickm   |  Owner:  nickm
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  style, 043-can  |  Actual Points:  1.5
Parent ID:  #29226  | Points:
 Reviewer:  catalyst|Sponsor:
+

Comment (by nickm):

 I don't object to any of those changes.  Would you prefer I wait till
 you've reviewed the rest of the branch for me to make them, or go ahead
 and update the branch?

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

Re: [tor-bugs] #32921 [Core Tor/Tor]: Code and script changes to run clang-format without breaking checkSpaces or coccinelle

[Tor Bug Tracker & Wiki]

#32921: Code and script changes to run clang-format without breaking 
checkSpaces or
coccinelle
+
 Reporter:  nickm   |  Owner:  nickm
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  style, 043-can  |  Actual Points:  1.5
Parent ID:  #29226  | Points:
 Reviewer:  catalyst|Sponsor:
+

Comment (by catalyst):

 Also, we still haven't decided on the minimum required version of clang-
 format.  If the minimum required version isn't the default clang-format on
 our CI platforms, we might need to parameterize the clang-format
 executable name in the helper script to deal with that.

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

Re: [tor-bugs] #32921 [Core Tor/Tor]: Code and script changes to run clang-format without breaking checkSpaces or coccinelle

[Tor Bug Tracker & Wiki]

#32921: Code and script changes to run clang-format without breaking 
checkSpaces or
coccinelle
+
 Reporter:  nickm   |  Owner:  nickm
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  style, 043-can  |  Actual Points:  1.5
Parent ID:  #29226  | Points:
 Reviewer:  catalyst|Sponsor:
+

Comment (by catalyst):

 Proposed changes based on mailing list responses and meetings:

 * change to `IndentCaseLabels: false` due to lack of objections

 * catalyst will investigate whether Emacs can be easily convinced to
 produce the results of `AlignEscapedNewlines: Left` (maybe we can also
 decide to leave existing ones alone with `AlignEscapedNewlines:
 DontAlign`? but maybe instead that puts space-backslash at the end of the
 each line's visible text. I haven't checked.)

 * retain `KeepEmptyLinesAtTheStartOfBlocks: false` (no other opinions
 about changing it, and my preference isn't very strong)

 * change to `SpaceAfterLogicalNot: false` (it removes the need for at
 least one other change on the PR that compensates for the introduced
 space, and brings us closer to KNF)

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

Re: [tor-bugs] #32363 [Core Tor/Tor]: tor_inet_aton parsing of IPv4 literals is too lax

[Tor Bug Tracker & Wiki]

#32363: tor_inet_aton parsing of IPv4 literals is too lax
+--
 Reporter:  liberat |  Owner:  neel
 Type:  enhancement | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  BugSmashFund, extra-review  |  Actual Points:
Parent ID:  | Points:  0.2
 Reviewer:  nickm   |Sponsor:
+--
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 Okay.  In that case, I think we can call this merge-ready for 0.4.4

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

Re: [tor-bugs] #33103 [Core Tor/Tor]: LeakSanitizer is kicking in with tor being on 39c5e1b84994c2f226a8530b930f215cc5ffb877 when closing Tor Browser

[Tor Bug Tracker & Wiki]

#33103: LeakSanitizer is kicking in with tor being on
39c5e1b84994c2f226a8530b930f215cc5ffb877 when closing Tor Browser
--+
 Reporter:  gk|  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression leak 043-must  |  Actual Points:  .1
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  accepted => needs_review
 * actualpoints:   => .1


Comment:

 One-line fix in branch `ticket33103`; PR at
 https://github.com/torproject/tor/pull/1708

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

Re: [tor-bugs] #30638 [Core Tor/Tor]: Test banning ed25519 keys in the approved-routers file on moria1

[Tor Bug Tracker & Wiki]

#30638: Test banning ed25519 keys in the approved-routers file on moria1
-+-
 Reporter:  teor |  Owner:  arma
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, 042-deferred-20190918   |  Actual Points:
  043-should |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 If somebody gives me an approved-routers line to add, I can add it. And
 then you can observe the resulting votes and decide whether it worked the
 way you want?

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

Re: [tor-bugs] #33163 [Core Tor/Chutney]: Update list of Tor versions in Chutney's Travis CI

[Tor Bug Tracker & Wiki]

#33163: Update list of Tor versions in Chutney's Travis CI
--+
 Reporter:  teor  |  Owner:  teor
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  chutney-ci|  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by teor):

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


Comment:

 CI has passed, and this is a routine change, so I merged it.

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

Re: [tor-bugs] #31020 [Core Tor/Fallback Scripts]: Validate the fallback scripts CI output using grep and stem

[Tor Bug Tracker & Wiki]

#31020: Validate the fallback scripts CI output using grep and stem
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback, fallback-ci, 044-should  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * keywords:  fallback, fallback-ci, 043-must => fallback, fallback-ci,
 044-should


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

Re: [tor-bugs] #32672 [Core Tor/Tor]: Reject 0.2.9 and 0.4.0 in dirserv_rejects_tor_version() [DO NOT MERGE BEFORE FEB 2020]

[Tor Bug Tracker & Wiki]

#32672: Reject 0.2.9 and 0.4.0 in dirserv_rejects_tor_version() [DO NOT MERGE
BEFORE FEB 2020]
-+-
 Reporter:  teor |  Owner:  neel
 Type:  task | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  044-should, 043-backport,|  Actual Points:
  041-backport, 042-backport, consider-  |
  backport-after-authority-test, fast-fix,   |
  network-health |
Parent ID:   | Points:  0.5
 Reviewer:  teor |Sponsor:
-+-
Changes (by teor):

 * keywords:
 044-should, 043-backport, 041-backport, 042-backport, consider-
 backport-after-authority-test, fast-fix, network-health 043-should
 =>
 044-should, 043-backport, 041-backport, 042-backport, consider-
 backport-after-authority-test, fast-fix, network-health


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

Re: [tor-bugs] #32753 [Core Tor/Tor]: Tor should lower-case its BridgeDistribution string

[Tor Bug Tracker & Wiki]

#32753: Tor should lower-case its BridgeDistribution string
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  consider-backport-after-0432,|  Actual Points:
  035-backport 041-backport 042-backport easy|
  anticensorship-wants fast-fix  |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor28
-+-
Changes (by teor):

 * keywords:
 consider-backport-after-0432, 035-backport 041-backport 042-backport
 easy anticensorship-wants fast-fix 043-should
 =>
 consider-backport-after-0432, 035-backport 041-backport 042-backport
 easy anticensorship-wants fast-fix


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

Re: [tor-bugs] #32673 [Core Tor/Tor]: 'buf_read_from_tls()' can return the wrong error code

[Tor Bug Tracker & Wiki]

#32673: 'buf_read_from_tls()' can return the wrong error code
-+-
 Reporter:  opara|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.4-rc
 Severity:  Normal   | Resolution:
 Keywords:  tor-tls, tor-security, consider- |  Actual Points:  .1
  backport-if-needed, consider-backport- |
  after-0433, 035-backport, 040-backport,|
  041-backport, 042-backport fast-fix|
Parent ID:   | Points:  1
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by teor):

 * keywords:
 tor-tls, tor-security, consider-backport-if-needed, consider-backport-
 after-0433, 035-backport, 040-backport, 041-backport, 042-backport
 fast-fix 043-should
 =>
 tor-tls, tor-security, consider-backport-if-needed, consider-backport-
 after-0433, 035-backport, 040-backport, 041-backport, 042-backport
 fast-fix


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

Re: [tor-bugs] #33093 [Core Tor/Tor]: Use IF_BUG_ONCE in buf_flush_to_tls()

[Tor Bug Tracker & Wiki]

#33093: Use IF_BUG_ONCE in buf_flush_to_tls()
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  assert, tor-connection security-low  |  Actual Points:  .1
  consider-backport-after-0433 035-backport  |
  041-backport 042-backport  |
Parent ID:   | Points:
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by teor):

 * keywords:
 assert, tor-connection security-low consider-backport-after-0433
 043-must 035-backport 041-backport 042-backport
 =>
 assert, tor-connection security-low consider-backport-after-0433
 035-backport 041-backport 042-backport


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

Re: [tor-bugs] #33095 [Core Tor/Tor]: Don't say "future instances of this warning will be suppressed" when we don't mean it.

[Tor Bug Tracker & Wiki]

#33095: Don't say "future instances of this warning will be suppressed" when we
don't mean it.
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  consider-backport-after-0433 |  Actual Points:
  041-backport 042-backport  |
Parent ID:   | Points:  .1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  consider-backport-after-0433 041-backport 042-backport
 043-should => consider-backport-after-0433 041-backport 042-backport


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

Re: [tor-bugs] #33075 [Core Tor/Tor]: Travis: Remove stem from the list of allow_failure jobs

[Tor Bug Tracker & Wiki]

#33075: Travis: Remove stem from the list of allow_failure jobs
-+-
 Reporter:  teor |  Owner:  teor
 Type:  task | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci, consider-backport-   |  Actual Points:  0.1
  after-0433, 035-backport, 040-backport,|
  041-backport, 042-backport |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:
 043-should, tor-ci, consider-backport-after-0433, 035-backport,
 040-backport, 041-backport, 042-backport
 =>
 tor-ci, consider-backport-after-0433, 035-backport, 040-backport,
 041-backport, 042-backport


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

Re: [tor-bugs] #32334 [Core Tor/Tor]: do not throw enable_tool_name_check error when compiling for Android and iOS

[Tor Bug Tracker & Wiki]

#32334: do not throw enable_tool_name_check error when compiling for Android and
iOS
--+--
 Reporter:  eighthave |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  Android, iOS  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * keywords:  Android, iOS, 043-should => Android, iOS


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

Re: [tor-bugs] #32335 [Core Tor/Tor]: Set up a .github repository on GitHub

[Tor Bug Tracker & Wiki]

#32335: Set up a .github repository on GitHub
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  task  | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-github, 043-deferred  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:  catalyst  |Sponsor:
--+--
Changes (by teor):

 * status:  needs_information => needs_revision


Comment:

 Replying to [comment:6 teor]:
 > I asked for some specific changes to CONTRIBUTING and SUPPORT to allow
 multiple projects.

 It's still not clear that the Tor GitHub has multiple projects and teams.

 Let's add a sentence at the start that says we have multiple teams, and
 link to the list of teams on our wiki:
 https://trac.torproject.org/projects/tor/wiki/org/teams

 After this PR merges, other teams can:
 * add their own sections to CONTRIBUTING and SUPPORT, or
 * override CONTRIBUTING and SUPPORT in their own repositories.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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: #32564, #28992, #32718, #33103, ...

[Tor Bug Tracker & Wiki]

Batch modification to #32564, #28992, #32718, #33103, #33119, #33120, #33137, 
#33148 by nickm:
priority to High

Comment:
Mark 043-must tickets as high priority

--
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] #33103 [Core Tor/Tor]: LeakSanitizer is kicking in with tor being on 39c5e1b84994c2f226a8530b930f215cc5ffb877 when closing Tor Browser

[Tor Bug Tracker & Wiki]

#33103: LeakSanitizer is kicking in with tor being on
39c5e1b84994c2f226a8530b930f215cc5ffb877 when closing Tor Browser
--+
 Reporter:  gk|  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  regression leak 043-must  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:  (none) => nickm
 * status:  new => accepted


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

Re: [tor-bugs] #33045 [Core Tor/Tor]: Increase the number of Tor network relays that support IPv6

[Tor Bug Tracker & Wiki]

#33045: Increase the number of Tor network relays that support IPv6
--+
 Reporter:  gaba  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor55-must
--+

Comment (by teor):

 Replying to [comment:8 nusenu]:
 > Replying to [comment:7 teor]:
 > > nusenu, you're also using some different calculations from the grant:
 > > * you're calculating Guard IPv6 consensus weight fraction
 >
 > I don't know about the grant but I can explain what my value says, it is
 not what you think it is.
 >
 > I'm not looking at cw fraction to calculate the "Guard: 29.06%" line
 above.
 >
 > I take and sum up onionoo's guard_probability [1] value of relays that
 have an IPv6 OrPort.
 > The guard_probability of relays having the exit flag is always 0, with
 one exception:
 > If the relay has the Exit and BadExit flags, in this specific but rare
 case the exit
 > relay can have a non-zero guard probability.

 Great, so we're using similar calculations.

 > > * the grant uses Guard-but-not-Exit IPv6 consensus weight fraction
 >
 > If the grant is about supporting Tor clients only (which I hope it is
 not since I thought client-to-guard supports IPv6 already) than it seems
 odd
 > to use cw fraction instead of "what fraction of guard capacity is
 reachable via IPv6?" metrics.

 The grant is about increasing the number of relays on IPv6, so that it's
 safer for clients to use IPv6:
 https://trac.torproject.org/projects/tor/wiki/org/sponsors/Sponsor55

 > [1]
 https://metrics.torproject.org/onionoo.html#details_relay_guard_probability

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

Re: [tor-bugs] #32372 [Core Tor/Tor]: Add a practracker mode that only regenerates over-broad exceptions

[Tor Bug Tracker & Wiki]

#32372: Add a practracker mode that only regenerates over-broad exceptions
--+
 Reporter:  teor  |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  043-should|  Actual Points:  .2
Parent ID:| Points:  1
 Reviewer:  ahf   |Sponsor:
--+
Changes (by ahf):

 * reviewer:   => ahf


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

Re: [tor-bugs] #33029 [Core Tor/Tor]: dir-auth: Dir auths should resume sending 503's but never to relays or other dir auths

[Tor Bug Tracker & Wiki]

#33029: dir-auth: Dir auths should resume sending 503's but never to relays or
other dir auths
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth 043-should?  |  Actual Points:
Parent ID:  #33018   | Points:  0.4
 Reviewer:  nickm, armadev   |Sponsor:
-+
Changes (by teor):

 * reviewer:  nickm, teor, armadev => nickm, armadev


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

Re: [tor-bugs] #33072 [Core Tor/Tor]: When under load, give 503 aggressively for dirport requests without compression

[Tor Bug Tracker & Wiki]

#33072: When under load, give 503 aggressively for dirport requests without
compression
---+---
 Reporter:  nickm  |  Owner:  dgoulet
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-health 043-should  |  Actual Points:
Parent ID:  #33018 | Points:
 Reviewer:  nickm, arma|Sponsor:
---+---
Changes (by teor):

 * reviewer:  nickm, teor, arma => nickm, arma


Comment:

 I've been tracking these changes, they look good to me.

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

Re: [tor-bugs] #33029 [Core Tor/Tor]: dir-auth: Dir auths should resume sending 503's but never to relays or other dir auths

[Tor Bug Tracker & Wiki]

#33029: dir-auth: Dir auths should resume sending 503's but never to relays or
other dir auths
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth 043-should?  |  Actual Points:
Parent ID:  #33018   | Points:  0.4
 Reviewer:  nickm, armadev   |Sponsor:
-+

Comment (by teor):

 I've been tracking these changes, they look good to me.

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

Re: [tor-bugs] #32363 [Core Tor/Tor]: tor_inet_aton parsing of IPv4 literals is too lax

[Tor Bug Tracker & Wiki]

#32363: tor_inet_aton parsing of IPv4 literals is too lax
+--
 Reporter:  liberat |  Owner:  neel
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  BugSmashFund, extra-review  |  Actual Points:
Parent ID:  | Points:  0.2
 Reviewer:  nickm   |Sponsor:
+--

Comment (by teor):

 Replying to [comment:15 nickm]:
 > > Now with the last changes, we do use the heap quite a bit with the
 smartlist_t so why would we prefer not using the heap in the first place?
 Does it still matter now?
 >
 > It doesn't matter except to the extent that it slows us down... we
 should keep an eye on profiles after we merge this.
 >
 > > Can we add a smartlist_core dependency to lib/net ?
 >
 > Yes: to see why, run `./scripts/maint/practracker/includes.py
 --toposort` for a topological sort of our current modules from lowest to
 highest level.  It appears that `net` is already much higher than
 smartlist_core.
 >
 > One thing I want to think about, though: do we care about the
 fingerprinting issue?  That is, this patch will create a class of
 addresses that some clients will parse and some clients will reject.  Is
 that a security issue to worry about, or are we cool here?

 Authorities canonicalise addresses before they create the microdesc
 consensus and microdescriptors, so the only affected clients are bridge
 clients. (Bridge clients download relay descriptors.)

 And for clients that use full relay descriptors on the public network,
 authorities will stop voting for those relays pretty soon.

 So I don't think this has a significant impact.

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

Re: [tor-bugs] #30067 [Core Tor/sbws]: Update sbws' travis config, based on chutney's travis config

[Tor Bug Tracker & Wiki]

#30067: Update sbws' travis config, based on chutney's travis config
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  High |  Milestone:  sbws:
 |  1.2.x-final
Component:  Core Tor/sbws|Version:
 Severity:  Major| Resolution:
 Keywords:  sbws-ci, teor-backlog, sbws-roadmap  |  Actual Points:
Parent ID:  #33121   | Points:  1
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Sorry, I let the list of tor versions get out of date in chutney. I was
 waiting for 0.4.0 to be unsupported on 2 February.

 I've fixed it in #33163, here is the latest list:
 https://github.com/torproject/chutney/pull/50

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

Re: [tor-bugs] #33163 [Core Tor/Chutney]: Update list of Tor versions in Chutney's Travis CI

[Tor Bug Tracker & Wiki]

#33163: Update list of Tor versions in Chutney's Travis CI
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:  chutney-ci|  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * status:  assigned => needs_review


Old description:

> * 0.2.9 and 0.4.0 are unsupported
> * 0.4.2 is stable
> * we're missing nightly, for some strange reason

New description:

 * 0.2.9 and 0.4.0 are unsupported
 * 0.4.2 is stable

--

Comment:

 See my PR:
 * chutney master: https://github.com/torproject/chutney/pull/50

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33163 [Core Tor/Chutney]: Update list of Tor versions in Chutney's Travis CI

[Tor Bug Tracker & Wiki]

#33163: Update list of Tor versions in Chutney's Travis CI
--+
 Reporter:  teor  |  Owner:  teor
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:  chutney-ci
Actual Points:|  Parent ID:
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+
 * 0.2.9 and 0.4.0 are unsupported
 * 0.4.2 is stable
 * we're missing nightly, for some strange reason

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

Re: [tor-bugs] #32230 [Core Tor/Tor]: configure summary is confusing or incorrect

[Tor Bug Tracker & Wiki]

#32230: configure summary is confusing or incorrect
---+
 Reporter:  teor   |  Owner:  dgoulet
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.4.3.1-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-build, 044-should  |  Actual Points:
Parent ID: | Points:  0.5
 Reviewer:  teor   |Sponsor:
---+
Changes (by teor):

 * status:  merge_ready => needs_revision


Comment:

 Fixed and merged to master; leaving open for further fixes in 0.4.4.

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

Re: [tor-bugs] #32230 [Core Tor/Tor]: configure summary is confusing or incorrect

[Tor Bug Tracker & Wiki]

#32230: configure summary is confusing or incorrect
---+
 Reporter:  teor   |  Owner:  dgoulet
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor   |Version:  Tor: 0.4.3.1-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-build, 044-should  |  Actual Points:
Parent ID: | Points:  0.5
 Reviewer:  teor   |Sponsor:
---+
Changes (by teor):

 * keywords:   => tor-build, 044-should
 * status:  needs_revision => merge_ready
 * version:  Tor: unspecified => Tor: 0.4.3.1-alpha
 * milestone:  Tor: unspecified => Tor: 0.4.3.x-final


Comment:

 Ok, let's merge what we have in 0.4.3, and then see if we can do better in
 0.4.4 ?

 We need to fix a typo in the changes file, the configure summary was only
 released in 0.4.3.1-alpha.

 Then we can merge this PR:
 * 0.4.3 (master): ​https://github.com/torproject/tor/pull/1701

 But keep the ticket open.

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

Re: [tor-bugs] #32335 [Core Tor/Tor]: Set up a .github repository on GitHub

[Tor Bug Tracker & Wiki]

#32335: Set up a .github repository on GitHub
--+---
 Reporter:  teor  |  Owner:  (none)
 Type:  task  | Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-github, 043-deferred  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:  catalyst  |Sponsor:
--+---
Changes (by catalyst):

 * status:  merge_ready => needs_information


Comment:

 Replying to [comment:16 teor]:
 > Sure, let's send out an email to tor-project, or the internal list?
 Sent an email to the internal list a little while ago.

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

Re: [tor-bugs] #32860 [Core Tor]: Bridge Dockerfile for Raspberry Pi 3

[Tor Bug Tracker & Wiki]

#32860: Bridge Dockerfile for Raspberry Pi 3
---+---
 Reporter:  qdii   |  Owner:  phw
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  docker, s30-o24a2  |  Actual Points:
Parent ID:  #31281 | Points:  0.5
 Reviewer:  cohosh |Sponsor:  Sponsor30-can
---+---
Changes (by phw):

 * status:  assigned => needs_review
 * reviewer:   => cohosh


Comment:

 Here's a merge request that implements qdii's suggestion:
 https://dip.torproject.org/torproject/anti-censorship/docker-
 obfs4-bridge/merge_requests/1

 Once this is merged, we can take care of the cross-architecture builds
 over at #33088.

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

Re: [tor-bugs] #33045 [Core Tor/Tor]: Increase the number of Tor network relays that support IPv6

[Tor Bug Tracker & Wiki]

#33045: Increase the number of Tor network relays that support IPv6
--+
 Reporter:  gaba  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor55-must
--+

Comment (by nusenu):

 Replying to [comment:7 teor]:
 > nusenu, you're also using some different calculations from the grant:
 > * you're calculating Guard IPv6 consensus weight fraction

 I don't know about the grant but I can explain what my value says, it is
 not what you think it is.

 I'm not looking at cw fraction to calculate the "Guard: 29.06%" line
 above.

 I take and sum up onionoo's guard_probability [1] value of relays that
 have an IPv6 OrPort.
 The guard_probability of relays having the exit flag is always 0, with one
 exception:
 If the relay has the Exit and BadExit flags, in this specific but rare
 case the exit
 relay can have a non-zero guard probability.

 > * the grant uses Guard-but-not-Exit IPv6 consensus weight fraction

 If the grant is about supporting Tor clients only (which I hope it is not
 since I thought client-to-guard supports IPv6 already) than it seems odd
 to use cw fraction instead of "what fraction of guard capacity is
 reachable via IPv6?" metrics.


 [1]
 https://metrics.torproject.org/onionoo.html#details_relay_guard_probability

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

Re: [tor-bugs] #30767 [Applications/Tor Browser]: Custom obfs4 bridge does not work on Tor Browser for Android

[Tor Bug Tracker & Wiki]

#30767: Custom obfs4 bridge does not work on Tor Browser for Android
-+-
 Reporter:  gk   |  Owner:  sisbell
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-parity, tbb-mobile,  |  Actual Points:
  TorBrowserTeam202001R  |
Parent ID:  #31284   | Points:  0.5
 Reviewer:  sysrqb   |Sponsor:
 |  Sponsor30-can
-+-

Comment (by sysrqb):

 Replying to [comment:25 sisbell]:
 > Replying to [comment:24 sysrqb]:
 > > Replying to [comment:19 sisbell]:
 > > > I made the following changes:
 > > > * We no longer filter bridges based on type
 > > > * Write out UseBridges, only if explicitly set
 > > >
 > > > The filter part was supporting a filter feature from orbot that I
 don't think was fully baked since it only supported an either/or meek/obfs
 option. Filtering is a useful option but we should open an issue for that
 and come up with a more general solution. This is a breaking change with
 Orbot.
 > > >
 > > >
 
https://github.com/sisbell/Tor_Onion_Proxy_Library/commit/d05797385127876889d6d7a8e8fc8cc45d8cccdd
 > >
 > > This patch should unconditionally call `transportPluginObfs()` and
 `transportPluginMeek()` in `configurePluggableTransportsFromSettings()`
 after it checks that the file exists and is executable. We don't care if
 the transport is part of the `supportedBridges` list because they aren't
 related.
 > >
 > > I also mentioned earlier that we can simply combine the
 `transportPlugin*()` methods, and that can output a single line containing
 all of the transports (`ClientTransportPlugin meek_lite,obfs3,obfs4
 exec`).
 > If we don't need to check the supported bridges, then collapsing the
 transport line is super easy. I'll make these changes.

 Great, thanks. I pushed a branch with a possible fixup commit. Feel free
 to use it or not.
 https://gitweb.torproject.org/user/sysrqb/tor-onion-proxy-
 library.git/commit/?h=bug30767=63fad679212838268935b45f12ec3f9ab61a4e5f

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

Re: [tor-bugs] #33088 [Circumvention]: Offer obfs4 docker image for additional architectures

[Tor Bug Tracker & Wiki]

#33088: Offer obfs4 docker image for additional architectures
---+---
 Reporter:  phw|  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Circumvention  |Version:
 Severity:  Normal | Resolution:
 Keywords:  docker, s30-o24a2  |  Actual Points:
Parent ID:  #31281 | Points:  1
 Reviewer: |Sponsor:  Sponsor30-can
---+---

Comment (by phw):

 On Linux, cross-architecture builds for docker are currently still an
 experimental feature that's provided by the "buildx" module. I'll briefly
 summarise how I got this module to run.

 On my Debian buster, I installed the `docker-ce-cli` package and linked
 the module /usr/libexec/docker/cli-plugins/docker-buildx to ~/.docker/cli-
 plugins/docker-buildx. I then enabled experimental features by writing the
 following to the file /etc/docker/daemon.json:
 {{{
 {
 "experimental": true
 }
 }}}
 Next, I restarted the docker service by running `sudo service docker
 restart`. Finally, I had to export the environment variable
 `DOCKER_CLI_EXPERIMENTAL=enabled`. Once all of that was done, I was able
 to use experimental features:
 {{{
 $ docker version -f '{{.Server.Experimental}}'
 true
 }}}
 ...and in particular, the buildx plugin. I stumbled upon a
 [https://mirailabs.io/blog/multiarch-docker-with-buildx/ useful blog post]
 that provides an overview of this process.

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

Re: [tor-bugs] #30767 [Applications/Tor Browser]: Custom obfs4 bridge does not work on Tor Browser for Android

[Tor Bug Tracker & Wiki]

#30767: Custom obfs4 bridge does not work on Tor Browser for Android
-+-
 Reporter:  gk   |  Owner:  sisbell
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-parity, tbb-mobile,  |  Actual Points:
  TorBrowserTeam202001R  |
Parent ID:  #31284   | Points:  0.5
 Reviewer:  sysrqb   |Sponsor:
 |  Sponsor30-can
-+-

Comment (by sisbell):

 Replying to [comment:24 sysrqb]:
 > Replying to [comment:19 sisbell]:
 > > I made the following changes:
 > > * We no longer filter bridges based on type
 > > * Write out UseBridges, only if explicitly set
 > >
 > > The filter part was supporting a filter feature from orbot that I
 don't think was fully baked since it only supported an either/or meek/obfs
 option. Filtering is a useful option but we should open an issue for that
 and come up with a more general solution. This is a breaking change with
 Orbot.
 > >
 > >
 
https://github.com/sisbell/Tor_Onion_Proxy_Library/commit/d05797385127876889d6d7a8e8fc8cc45d8cccdd
 >
 > This patch should unconditionally call `transportPluginObfs()` and
 `transportPluginMeek()` in `configurePluggableTransportsFromSettings()`
 after it checks that the file exists and is executable. We don't care if
 the transport is part of the `supportedBridges` list because they aren't
 related.
 >
 > I also mentioned earlier that we can simply combine the
 `transportPlugin*()` methods, and that can output a single line containing
 all of the transports (`ClientTransportPlugin meek_lite,obfs3,obfs4
 exec`).
 If we don't need to check the supported bridges, then collapsing the
 transport line is super easy. I'll make these changes.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33162 [Community]: Create a "torproject" Docker organisation

[Tor Bug Tracker & Wiki]

#33162: Create a "torproject" Docker organisation
---+---
 Reporter:  phw|  Owner:  phw
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Community  |Version:
 Severity:  Normal |   Keywords:  docker, trademark
Actual Points: |  Parent ID:
   Points:  0.5|   Reviewer:
  Sponsor: |
---+---
 We should create an organisation account on hub.docker.com to publish our
 official Docker images; for example our
 [https://dip.torproject.org/torproject/anti-censorship/docker-obfs4-bridge
 obfs4 bridge image]. Unfortunately, the organisation "torproject" already
 exists and it's not clear who owns it.

 [https://hub.docker.com/support/doc/how-can-i-claim-ownership-of-an-
 existing-docker-id Docker's FAQ says]:
 > All Docker IDs are first come, first serve except for companies that
 have a US Trademark on a username.
 >
 > If you have a US Trademark claim on a name, open a support ticket and
 include:
 >
 > * The username you wish to claim
 > * Proof of US Trademark on the username
 [[br]]
 I filed a support ticket referencing the two trademarks that Tor has
 registered in the U.S.: 3,465,433 and 3,465,432. I'll update this ticket
 once I hear back. If Docker's support is unable to help us, we should ask
 around (e.g., on the tor-project@ list) if anyone knows who owns the
 "torproject" account.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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/Tor]: test-stem times out intermittently

[Tor Bug Tracker & Wiki]

#29437: test-stem times out intermittently
-+-
 Reporter:  rl1987   |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.8-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-ci-fail-sometimes stem-wants |  Actual Points:  0.4
  043-should |
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 We've been running with this change on master for over a week, with no
 apparent stem timeouts.  Closing this ticket.

 (Dear future developers: if you are seeing a stem timeout, please consider
 how long it has been since the last time we saw one.  If it has been a
 super long time, maybe you are seeing a new bug in Tor or stem rather than
 this bug once again, and you should open a new ticket rather than
 reopening this one?)

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

Re: [tor-bugs] #30695 [Core Tor/Tor]: Consider running tor's stem CI job in --target ONLINE mode, maybe with chutney

[Tor Bug Tracker & Wiki]

#30695: Consider running tor's stem CI job in --target ONLINE mode, maybe with
chutney
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * parent:  #29437 =>


Comment:

 removing parent

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

Re: [tor-bugs] #33075 [Core Tor/Tor]: Travis: Remove stem from the list of allow_failure jobs

[Tor Bug Tracker & Wiki]

#33075: Travis: Remove stem from the list of allow_failure jobs
-+-
 Reporter:  teor |  Owner:  teor
 Type:  task | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  043-should, tor-ci, consider-|  Actual Points:  0.1
  backport-after-0433, 035-backport, |
  040-backport, 041-backport, 042-backport   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * parent:  #29437 =>


Comment:

 removing parent

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

Re: [tor-bugs] #30901 [Core Tor/Tor]: Add control port trace logging to tor

[Tor Bug Tracker & Wiki]

#30901: Add control port trace logging to tor
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci-fail-sometimes, network-  |  Actual Points:  1.8
  team-roadmap-2020Q1 044-should |
Parent ID:   | Points:  1
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

 * parent:  #29437 =>


Comment:

 removing parent

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

Re: [tor-bugs] #33137 [Core Tor/Tor]: Resolve TROVE-2020-003

[Tor Bug Tracker & Wiki]

#33137: Resolve TROVE-2020-003
---+
 Reporter:  nickm  |  Owner:  asn
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  043-must security  |  Actual Points:
Parent ID: | Points:  1-5?
 Reviewer: |Sponsor:
---+
Changes (by nickm):

 * owner:  (none) => asn
 * status:  new => assigned
 * points:   => 1-5?


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

Re: [tor-bugs] #32363 [Core Tor/Tor]: tor_inet_aton parsing of IPv4 literals is too lax

[Tor Bug Tracker & Wiki]

#32363: tor_inet_aton parsing of IPv4 literals is too lax
+--
 Reporter:  liberat |  Owner:  neel
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  BugSmashFund, extra-review  |  Actual Points:
Parent ID:  | Points:  0.2
 Reviewer:  nickm   |Sponsor:
+--

Comment (by nickm):

 > Now with the last changes, we do use the heap quite a bit with the
 smartlist_t so why would we prefer not using the heap in the first place?
 Does it still matter now?

 It doesn't matter except to the extent that it slows us down... we should
 keep an eye on profiles after we merge this.

 > Can we add a smartlist_core dependency to lib/net ?

 Yes: to see why, run `./scripts/maint/practracker/includes.py --toposort`
 for a topological sort of our current modules from lowest to highest
 level.  It appears that `net` is already much higher than smartlist_core.

 One thing I want to think about, though: do we care about the
 fingerprinting issue?  That is, this patch will create a class of
 addresses that some clients will parse and some clients will reject.  Is
 that a security issue to worry about, or are we cool here?

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

Re: [tor-bugs] #32929 [Core Tor/Tor]: Tor Manual: Split Node options into their own subsection

[Tor Bug Tracker & Wiki]

#32929: Tor Manual: Split Node options into their own subsection
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  documentation tor-client manpage |  Actual Points:
  easy 043-can extra-review  |
Parent ID:  #4310| Points:  0.5
 Reviewer:  catalyst, nickm  |Sponsor:
-+-

Comment (by swati):

 Replying to [comment:9 catalyst]:
 > Replying to [comment:8 swati]:
 > > Taylor, I changed the section title to 'Node Selection Options', and
 also added some introductory text. Please review.
 >
 > Thanks!
 >
 > Please also move NodeFamily to this section, as you asked about before.
 >
 > Minor: I think the two sentences of introductory text should be a single
 paragraph, and only the sentence immediately preceding the list of options
 should have a colon at the end.

 Done both! Combined the text in the introductory paras, and added the
 NodeFamily option in this section.

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

Re: [tor-bugs] #32928 [Core Tor/Tor]: Tor Manual: Split Circuit Timeout options into their own subsection

[Tor Bug Tracker & Wiki]

#32928: Tor Manual: Split Circuit Timeout options into their own subsection
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  documentation tor-client manpage |  Actual Points:
  easy 043-can extra-review  |
Parent ID:  #4310| Points:  0.5
 Reviewer:  catalyst, nickm  |Sponsor:
-+-

Comment (by nickm):

 Replying to [comment:10 swati]:
 > Replying to [comment:8 catalyst]:
 > > Replying to [comment:6 swati]:
 > > > Thanks, Taylor. Regarding your comment about renaming the section to
 'Circuit Timeout Options', I see that I have added DormantClientTimeout
 and DormantTimeoutDisabledByIdleStreams options to this section. Are these
 two circuit options as well?
 > >
 > > I see. I think you're right there. They're client options that aren't
 directly related to circuit timeouts. They might belong in a separate
 section about Dormant mode?
 > >
 > Currently, there are only four Dormant mode options in the manual -
 DormantCanceledByStartup, DormantOnFirstStartup, DormantClientTimeout and
 DormantTimeoutDisabledByIdleStreams. Do you think we can have a separate
 section for dormant mode with just these four options? If yes, I'll put
 them out from here and create a new section.

 I think that's a fine 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] #32928 [Core Tor/Tor]: Tor Manual: Split Circuit Timeout options into their own subsection

[Tor Bug Tracker & Wiki]

#32928: Tor Manual: Split Circuit Timeout options into their own subsection
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  documentation tor-client manpage |  Actual Points:
  easy 043-can extra-review  |
Parent ID:  #4310| Points:  0.5
 Reviewer:  catalyst, nickm  |Sponsor:
-+-

Comment (by nickm):

 Replying to [comment:8 catalyst]:
 > Replying to [comment:6 swati]:
 > > Thanks, Taylor. Regarding your comment about renaming the section to
 'Circuit Timeout Options', I see that I have added DormantClientTimeout
 and DormantTimeoutDisabledByIdleStreams options to this section. Are these
 two circuit options as well?
 >
 > I see. I think you're right there. They're client options that aren't
 directly related to circuit timeouts. They might belong in a separate
 section about Dormant mode?

 [...]

 For what it's worth, I agree with catalyst in their assessment of the
 options discussed in the comment above.

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

Re: [tor-bugs] #33099 [Metrics/Consensus Health]: Turn time_to_report_half_network into days, hours, minutes, and seconds

[Tor Bug Tracker & Wiki]

#33099: Turn time_to_report_half_network into days, hours, minutes, and seconds
--+
 Reporter:  teor  |  Owner:  tom
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Metrics/Consensus Health  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by tom):

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


Comment:

 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] #33119 [Core Tor/Tor]: Resolve TROVE-2020-001

[Tor Bug Tracker & Wiki]

#33119: Resolve TROVE-2020-001
--+
 Reporter:  nickm |  Owner:  ahf
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  043-must  |  Actual Points:
Parent ID:| Points:  1-5?
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:  (none) => ahf
 * status:  new => assigned
 * points:   => 1-5?


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

Re: [tor-bugs] #33120 [Core Tor/Tor]: Resolve TROVE-2020-002

[Tor Bug Tracker & Wiki]

#33120: Resolve TROVE-2020-002
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  043-must  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:  (none) => nickm
 * status:  new => accepted
 * points:   => 1


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

Re: [tor-bugs] #28704 [Applications/Tor Browser]: Compile Tor and dependencies on our own for Android

[Tor Bug Tracker & Wiki]

#28704: Compile Tor and dependencies on our own for Android
-+-
 Reporter:  gk   |  Owner:  sisbell
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, tbb-parity, |  Actual Points:
  TorBrowserTeam202001   |
Parent ID:   | Points:  0
 Reviewer:   |Sponsor:
-+-

Comment (by eighthave):

 I think it makes sense to ship PTs as individual shared libraries, but I
 think that trying to use ''libssl.so'' will be painful.  We've tried that
 in the past, and from that experience, committed to always statically
 linking those kinds of deps in.  I guess it could be worth the pain if PTs
 also need ''libssl.so'' or other libs that are linked into ''libtor.so''.

 Also, I don't remember the details, but Android does add the app's lib dir
 to the loading path, and adds it before ''/system/lib''.  But that is
 probably only for libraries that are loaded from Java.  "Native code"
 probably needs to handle that manually.

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

Re: [tor-bugs] #28992 [Core Tor/Tor]: Bug: ../src/feature/hs/hs_client.c:571: send_introduce1: Non-fatal assertion !(ip == NULL) failed.

[Tor Bug Tracker & Wiki]

#28992: Bug: ../src/feature/hs/hs_client.c:571: send_introduce1: Non-fatal
assertion !(ip == NULL) failed.
-+-
 Reporter:  traumschule  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, 043-must, 035-backport,  |  Actual Points:
  041-backport, 042-backport |
Parent ID:   | Points:  0.1
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-can
-+-
Changes (by dgoulet):

 * status:  needs_review => accepted
 * owner:  (none) => dgoulet


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

Re: [tor-bugs] #28992 [Core Tor/Tor]: Bug: ../src/feature/hs/hs_client.c:571: send_introduce1: Non-fatal assertion !(ip == NULL) failed.

[Tor Bug Tracker & Wiki]

#28992: Bug: ../src/feature/hs/hs_client.c:571: send_introduce1: Non-fatal
assertion !(ip == NULL) failed.
-+-
 Reporter:  traumschule  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, 043-must, 035-backport,  |  Actual Points:
  041-backport, 042-backport |
Parent ID:   | Points:  0.1
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-can
-+-
Changes (by dgoulet):

 * status:  accepted => needs_review


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

Re: [tor-bugs] #28992 [Core Tor/Tor]: Bug: ../src/feature/hs/hs_client.c:571: send_introduce1: Non-fatal assertion !(ip == NULL) failed.

[Tor Bug Tracker & Wiki]

#28992: Bug: ../src/feature/hs/hs_client.c:571: send_introduce1: Non-fatal
assertion !(ip == NULL) failed.
-+-
 Reporter:  traumschule  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, 043-must, 035-backport,  |  Actual Points:
  041-backport, 042-backport |
Parent ID:   | Points:  0.1
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-can
-+-
Changes (by dgoulet):

 * status:  needs_revision => needs_review


Comment:

 Done! See fixup.

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

Re: [tor-bugs] #30067 [Core Tor/sbws]: Update sbws' travis config, based on chutney's travis config

[Tor Bug Tracker & Wiki]

#30067: Update sbws' travis config, based on chutney's travis config
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  High |  Milestone:  sbws:
 |  1.2.x-final
Component:  Core Tor/sbws|Version:
 Severity:  Major| Resolution:
 Keywords:  sbws-ci, teor-backlog, sbws-roadmap  |  Actual Points:
Parent ID:  #33121   | Points:  1
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by juga):

 * reviewer:   => ahf


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

Re: [tor-bugs] #33160 [Applications/Tor Browser]: Mouse location error on page

[Tor Bug Tracker & Wiki]

#33160: Mouse location error on page
--+--
 Reporter:  findletoni|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 I don't see an issue with mouse on this website with Tor Browser 9.0.4 on
 Linux.

 Do you know which version started showing this issue?

 You can download older versions from https://archive.torproject.org/tor-
 package-archive/torbrowser/ if you want to try them.

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

Re: [tor-bugs] #32709 [Core Tor/Tor]: hsv3: Support onionbalance keys when handling INTRO2 cells

[Tor Bug Tracker & Wiki]

#32709: hsv3: Support onionbalance keys when handling INTRO2 cells
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs scaling onionbalance tor- |  Actual Points:
  spec network-team-roadmap-2020Q1 044-must  |
Parent ID:  #26768   | Points:  5
 Reviewer:  nickm, dgoulet   |Sponsor:
 |  Sponsor27-must
-+-

Comment (by dgoulet):

 Some comments on the PR.

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

Re: [tor-bugs] #30067 [Core Tor/sbws]: Update sbws' travis config, based on chutney's travis config

[Tor Bug Tracker & Wiki]

#30067: Update sbws' travis config, based on chutney's travis config
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  High |  Milestone:  sbws:
 |  1.2.x-final
Component:  Core Tor/sbws|Version:
 Severity:  Major| Resolution:
 Keywords:  sbws-ci, teor-backlog, sbws-roadmap  |  Actual Points:
Parent ID:  #33121   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by juga):

 * status:  assigned => needs_review


Comment:

 https://github.com/torproject/sbws/pull/363

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

Re: [tor-bugs] #33160 [Applications/Tor Browser]: Mouse location error on page

[Tor Bug Tracker & Wiki]

#33160: Mouse location error on page
--+--
 Reporter:  findletoni|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


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

Re: [tor-bugs] #31069 [Webpages/Support]: Create onion auth entry in support.torproject.org

[Tor Bug Tracker & Wiki]

#31069: Create onion auth entry in support.torproject.org
--+---
 Reporter:  antonela  |  Owner:  ggus
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Support  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #3| Points:
 Reviewer:  antonela, stephw  |Sponsor:  Sponsor27
--+---

Comment (by mcs):

 Once the content exists, we need to remember to update Tor Browser to
 point to it; see ticket:30237#comment:55

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33161 [Core Tor]: Latest version for buster on Raspberry Pi fails to start

[Tor Bug Tracker & Wiki]

#33161: Latest version for buster on Raspberry Pi fails to start
---+--
 Reporter:  tescophil  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Component:  Core Tor
  Version:  0.4.2.6|   Severity:  Normal
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 Upgraded my raspberry pi running Rasbian to the latest 'buster' release
 and tor will not start up. Could not find the error I see in the logs
 listed anywhere else, so raising this ticket:

 my sources file looks like this

 {{{
 deb http://raspbian.raspberrypi.org/raspbian/ buster main contrib non-free
 rpi
 deb http://deb.torproject.org/torproject.org buster main
 }}}

 After apt-get update and apt-get upgrade tor will not start.

 {{{
 Feb  5 14:47:42 raspberrypi systemd[1]: Starting Anonymizing overlay
 network for TCP...
 Feb  5 14:47:42 raspberrypi systemd[1]: tor@default.service: Control
 process exited, code=killed, status=4/ILL
 Feb  5 14:47:42 raspberrypi systemd[1]: tor@default.service: Failed with
 result 'signal'.
 Feb  5 14:47:42 raspberrypi systemd[1]: Failed to start Anonymizing
 overlay network for TCP.
 Feb  5 14:47:42 raspberrypi systemd[1]: tor@default.service: Service
 RestartSec=100ms expired, scheduling restart.
 Feb  5 14:47:42 raspberrypi systemd[1]: tor@default.service: Scheduled
 restart job, restart counter is at 1.
 Feb  5 14:47:42 raspberrypi systemd[1]: Stopped Anonymizing overlay
 network for TCP.
 Feb  5 14:47:42 raspberrypi systemd[1]: Starting Anonymizing overlay
 network for TCP...
 Feb  5 14:47:42 raspberrypi systemd[1]: tor@default.service: Control
 process exited, code=killed, status=4/ILL
 Feb  5 14:47:42 raspberrypi systemd[1]: tor@default.service: Failed with
 result 'signal'.
 Feb  5 14:47:42 raspberrypi systemd[1]: Failed to start Anonymizing
 overlay network for TCP.
 Feb  5 14:47:43 raspberrypi systemd[1]: tor@default.service: Service
 RestartSec=100ms expired, scheduling restart.
 Feb  5 14:47:43 raspberrypi systemd[1]: tor@default.service: Scheduled
 restart job, restart counter is at 2.
 Feb  5 14:47:43 raspberrypi systemd[1]: Stopped Anonymizing overlay
 network for TCP.
 Feb  5 14:47:43 raspberrypi systemd[1]: Starting Anonymizing overlay
 network for TCP...
 Feb  5 14:47:43 raspberrypi systemd[1]: tor@default.service: Control
 process exited, code=killed, status=4/ILL
 Feb  5 14:47:43 raspberrypi systemd[1]: tor@default.service: Failed with
 result 'signal'.
 Feb  5 14:47:43 raspberrypi systemd[1]: Failed to start Anonymizing
 overlay network for TCP.
 Feb  5 14:47:43 raspberrypi systemd[1]: tor@default.service: Service
 RestartSec=100ms expired, scheduling restart.
 Feb  5 14:47:43 raspberrypi systemd[1]: tor@default.service: Scheduled
 restart job, restart counter is at 3.
 Feb  5 14:47:43 raspberrypi systemd[1]: Stopped Anonymizing overlay
 network for TCP.
 Feb  5 14:47:43 raspberrypi systemd[1]: Starting Anonymizing overlay
 network for TCP...
 Feb  5 14:47:43 raspberrypi systemd[1]: tor@default.service: Control
 process exited, code=killed, status=4/ILL
 Feb  5 14:47:43 raspberrypi systemd[1]: tor@default.service: Failed with
 result 'signal'.
 Feb  5 14:47:43 raspberrypi systemd[1]: Failed to start Anonymizing
 overlay network for TCP.
 Feb  5 14:47:44 raspberrypi systemd[1]: tor@default.service: Service
 RestartSec=100ms expired, scheduling restart.
 Feb  5 14:47:44 raspberrypi systemd[1]: tor@default.service: Scheduled
 restart job, restart counter is at 4.
 Feb  5 14:47:44 raspberrypi systemd[1]: Stopped Anonymizing overlay
 network for TCP.
 Feb  5 14:47:44 raspberrypi systemd[1]: Starting Anonymizing overlay
 network for TCP...
 Feb  5 14:47:44 raspberrypi systemd[1]: tor@default.service: Control
 process exited, code=killed, status=4/ILL
 Feb  5 14:47:44 raspberrypi systemd[1]: tor@default.service: Failed with
 result 'signal'.
 Feb  5 14:47:44 raspberrypi systemd[1]: Failed to start Anonymizing
 overlay network for TCP.
 Feb  5 14:47:44 raspberrypi systemd[1]: tor@default.service: Service
 RestartSec=100ms expired, scheduling restart.
 Feb  5 14:47:44 raspberrypi systemd[1]: tor@default.service: Scheduled
 restart job, restart counter is at 5.
 Feb  5 14:47:44 raspberrypi systemd[1]: Stopped Anonymizing overlay
 network for TCP.
 Feb  5 14:47:44 raspberrypi systemd[1]: tor@default.service: Start request
 repeated too quickly.
 Feb  5 14:47:44 raspberrypi systemd[1]: tor@default.service: Failed with
 result 'signal'.
 Feb  5 14:47:44 raspberrypi systemd[1]: Failed to start Anonymizing
 overlay network for TCP.
 }}}

 Version

 {{{
 pi@raspberrypi:~ $ apt-cache policy tor
 tor:
   Installed: 0.4.2.6-1~d10.buster+1
   Candidate: 0.4.2.6-1~d10.buster+1
   Version table:
  *** 0.4.2.6-1~d10.buster+1 500
 500 http://deb.torproject.org/torproject.org buster/main 

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:  brade
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-usability, tor-hs,  |  Actual Points:  6.5
  TorBrowserTeam202001   |
Parent ID:  #3   | Points:  8
 Reviewer:  pospeselr, acat  |Sponsor:
 |  Sponsor27-must
-+-

Comment (by mcs):

 Replying to [comment:36 mcs]:
 > We will capture a log and email it to you and dgoulet (Kathy and I don't
 want to leak private .onion addresses publicly in this ticket). The
 "remove from about:preferences" part means that Tor Browser's new key
 management UI was used to remove a permanent key. From tor's perspective,
 this means that an `ONION_CLIENT_AUTH_REMOVE` command was received on the
 control port.

 This issue is being handled in #33148.

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

Re: [tor-bugs] #30727 [Core Tor/sbws]: Make sbws vote for all measured relays, even if they are not Running / not in the consensus

[Tor Bug Tracker & Wiki]

#30727: Make sbws vote for all measured relays, even if they are not Running / 
not
in the consensus
-+-
 Reporter:  teor |  Owner:  juga
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:  sbws:
 |  1.1.0
 Severity:  Critical | Resolution:  fixed
 Keywords:  must-keep-3-torflow-blocker, sbws-   |  Actual Points:
  majority-blocker, sbws-roadmap |
Parent ID:  #33121   | Points:
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by juga):

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


Comment:

 Merged!

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

Re: [tor-bugs] #33072 [Core Tor/Tor]: When under load, give 503 aggressively for dirport requests without compression

[Tor Bug Tracker & Wiki]

#33072: When under load, give 503 aggressively for dirport requests without
compression
---+---
 Reporter:  nickm  |  Owner:  dgoulet
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  network-health 043-should  |  Actual Points:
Parent ID:  #33018 | Points:
 Reviewer:  nickm, teor, arma  |Sponsor:
---+---
Changes (by dgoulet):

 * status:  needs_revision => needs_review


Comment:

 Ok so I talked with nickm and to keep this in 043 (and possibly backport),
 I went with a more simple approach with minimal code change.

 I have added the `AuthDirRejectUncompressedRequests 0|1` option that will
 unconditionally reject uncompressed requests if set. It would be off by
 default in 043 stable (and possible backports).

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

Re: [tor-bugs] #30767 [Applications/Tor Browser]: Custom obfs4 bridge does not work on Tor Browser for Android

[Tor Bug Tracker & Wiki]

#30767: Custom obfs4 bridge does not work on Tor Browser for Android
-+-
 Reporter:  gk   |  Owner:  sisbell
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-parity, tbb-mobile,  |  Actual Points:
  TorBrowserTeam202001R  |
Parent ID:  #31284   | Points:  0.5
 Reviewer:  sysrqb   |Sponsor:
 |  Sponsor30-can
-+-
Changes (by sysrqb):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:19 sisbell]:
 > I made the following changes:
 > * We no longer filter bridges based on type
 > * Write out UseBridges, only if explicitly set
 >
 > The filter part was supporting a filter feature from orbot that I don't
 think was fully baked since it only supported an either/or meek/obfs
 option. Filtering is a useful option but we should open an issue for that
 and come up with a more general solution. This is a breaking change with
 Orbot.
 >
 >
 
https://github.com/sisbell/Tor_Onion_Proxy_Library/commit/d05797385127876889d6d7a8e8fc8cc45d8cccdd

 This patch should unconditionally call `transportPluginObfs()` and
 `transportPluginMeek()` in `configurePluggableTransportsFromSettings()`
 after it checks that the file exists and is executable. We don't care if
 the transport is part of the `supportedBridges` list because they aren't
 related.

 I also mentioned earlier that we can simply combine the
 `transportPlugin*()` methods, and that can output a single line containing
 all of the transports (`ClientTransportPlugin meek_lite,obfs3,obfs4
 exec`).

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

Re: [tor-bugs] #32230 [Core Tor/Tor]: configure summary is confusing or incorrect

[Tor Bug Tracker & Wiki]

#32230: configure summary is confusing or incorrect
--+--
 Reporter:  teor  |  Owner:  dgoulet
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:  teor  |Sponsor:
--+--
Changes (by dgoulet):

 * keywords:  043-must =>
 * milestone:  Tor: 0.4.3.x-final => Tor: unspecified


Comment:

 I've tried for 5 min to add that value and the m4 world is not allowing me
 for some reasons. I think because the moon is unaligned and too much
 voodoo with autoconf/m4...

 I'll drop this for now, I can't spent more time on this :S.

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

Re: [tor-bugs] #33003 [Applications/Tor Browser]: Tor browser / Firefox telemetry data

[Tor Bug Tracker & Wiki]

#33003: Tor browser / Firefox telemetry data
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeamTriaged |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 Yeah ungoogled-chromium is faster than fatfox. Devs should try 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

[tor-bugs] #33160 [Webpages]: Mouse location error on page

[Tor Bug Tracker & Wiki]

#33160: Mouse location error on page
--+--
 Reporter:  findletoni|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  Webpages
  Version:  Tor: unspecified  |   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 At www.torontosun.com the location of the mouse is not handled correctly.
 This issue is not reproduced on the latest Firefox releases, only n the
 current Tor browser for Linux Min 18.3. The net result is that some
 buttons, links and clicks on images do not work. Buttons do not take focus
 when the mouse pointer is over the buttons. This error appeared in the
 most recent build of Tor and appears to be site specific.

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

Re: [tor-bugs] #33157 [Circumvention/Snowflake]: Client generates SDP with "IN IP4 0.0.0.0", causing proxy to send "client_ip=0.0.0.0" and bridge to send "USERADDR 0.0.0.0:1"

[Tor Bug Tracker & Wiki]

#33157: Client generates SDP with "IN IP4 0.0.0.0", causing proxy to send
"client_ip=0.0.0.0" and bridge to send "USERADDR 0.0.0.0:1"
-+
 Reporter:  dcf  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by cohosh):

 Possible related: #19026

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

Re: [tor-bugs] #31081 [Core Tor/Tor]: GETCONF allows zero arguments, contrary to spec

[Tor Bug Tracker & Wiki]

#31081: GETCONF allows zero arguments, contrary to spec
---+
 Reporter:  catalyst   |  Owner:  (none)
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  tor-control, tor-spec  |  Actual Points:  0.1
Parent ID: | Points:  1
 Reviewer:  teor   |Sponsor:
---+
Changes (by nickm):

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


Comment:

 Looks good to me too; merged to torspec.

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

Re: [tor-bugs] #32791 [Core Tor/Tor]: Check all of Tor's python scripts run under python 3

[Tor Bug Tracker & Wiki]

#32791: Check all of Tor's python scripts run under python 3
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  043-should, tor-python-3  |  Actual Points:  0.1
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 merged it; thanks!

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

Re: [tor-bugs] #30318 [Applications/Tor Browser]: Integrate snowflake into mobile Tor Browser alpha

[Tor Bug Tracker & Wiki]

#30318: Integrate snowflake into mobile Tor Browser alpha
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:  #19001| Points:
 Reviewer:|Sponsor:  Sponsor28-must
--+
Changes (by gaba):

 * sponsor:   => Sponsor28-must


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

Re: [tor-bugs] #19001 [Circumvention/Snowflake]: Tor Browser with Snowflake

[Tor Bug Tracker & Wiki]

#19001: Tor Browser with Snowflake
+--
 Reporter:  dcf |  Owner:  (none)
 Type:  project | Status:  new
 Priority:  Very High   |  Milestone:
Component:  Circumvention/Snowflake |Version:
 Severity:  Critical| Resolution:
 Keywords:  anti-censorship-roadmap-2020Q1  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
|  Sponsor28-must
+--
Changes (by gaba):

 * keywords:  anti-censorship-roadmap-october => anti-censorship-roadmap-
 2020Q1


Comment:

 In the roadmap for anti-censorship team to keep track of this ticket.

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

Re: [tor-bugs] #30878 [Circumvention/Snowflake]: Set up snowbox to simulate censorship

[Tor Bug Tracker & Wiki]

#30878: Set up snowbox to simulate censorship
-+---
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:  2
 Reviewer:   |Sponsor:  Sponsor28
-+---
Changes (by gaba):

 * keywords:  anti-censorship-roadmap-october =>


Comment:

 Not in the roadmap for Q1

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

Re: [tor-bugs] #31395 [Applications/Tor Browser]: Remove inline

[Tor Bug Tracker & Wiki]

#31395: Remove inline 

Re: [tor-bugs] #32767 [Applications/Tor Browser]: Remove Disconnect search as it is discontinued

[Tor Bug Tracker & Wiki]

#32767: Remove Disconnect search as it is discontinued
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam202001R |  Actual Points:  0.25
Parent ID:| Points:  0.25
 Reviewer:  boklm |Sponsor:
--+--
Changes (by acat):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:4 sysrqb]:
 > Can you create this as a fixup! on "Omnibox: Add DDG, Startpage,
 Disconnect, Youtube, Twitter; remove Amazon, eBay, bing"
 (`1d63bba60069585d820b5ae7508ed69fb36f92c0`) instead of a new commit? Are
 all modifications from that original commit?
 Yes, all are modifications from that commit. Done as a fixup in
 ​https://github.com/acatarineu/tor-browser/commit/32767+1.

 We might want to reword this and the test commit in the next rebase, since
 Disconnect is not there anymore.

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

Re: [tor-bugs] #33076 [Metrics/Analysis]: Graph onionperf and consensus information from Rob's experiments

[Tor Bug Tracker & Wiki]

#33076: Graph onionperf and consensus information from Rob's experiments
-+-
 Reporter:  mikeperry|  Owner:
 |  metrics-team
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Analysis |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-team-roadmap-2020Q1, sbws-   |  Actual Points:  2
  roadmap|
Parent ID:  #33121   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by karsten):

 Regarding Objective 3.1 of the MOSS proposal, I'm afraid that the CDF-
 Relay-* graphs will be out of scope. We had to reduce the budget and were
 only able to include graphs based on OnionPerf measurements, not based on
 other Tor descriptors. We can (and should) plan to include CDF-Relay-*
 graphs in that tool in the future, but the coding will likely have to wait
 until we have funding for that part.

 To give you an idea why the CDF-Relay-* graphs are harder to add than the
 OnionPerf-based onces: we're parsing 1.9M of compressed OnionPerf data for
 the CDF-TTFB and CDF-DL graphs, but 841M compressed tor descriptors for
 the CDF-Relay-* graphs. Making the last PDF I attached above kept my local
 workstation (1T NVMe, 64G RAM) busy for over an hour.

 Regarding adding graphs to the metrics website, I don't think that we can
 add any CDFs there without making major changes to the underlying graphing
 engine. Again, to given an example, the uncompressed data that is graphed
 in the last PDF I attached has a size of 4.5G. This is way different from
 existing graphs on the metrics website. I think we're looking at a tool
 that developers will run locally with data downloaded from CollecTor, a
 local database, and enough CPU time and RAM available to chew on all the
 data.

 This all shouldn't stop us from exploring possible graphs that we might
 need in the future. And I can make graphs like the last PDF for occasions
 like the torflow/sbws transition. They will just not be part of the tool
 that we'll have available once the MOSS proposal is done.

 I'll move the torflow/sbws discussion over to #33077. If you have any
 requests for changing the graphs above, except for the votes graph, please
 comment on this ticket. And when you think we're done, please indicate
 that here, too. Thanks!

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

Re: [tor-bugs] #33045 [Core Tor/Tor]: Increase the number of Tor network relays that support IPv6

[Tor Bug Tracker & Wiki]

#33045: Increase the number of Tor network relays that support IPv6
--+
 Reporter:  gaba  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor55-must
--+

Comment (by teor):

 Replying to [comment:5 gaba]:
 > Replying to [comment:3 nusenu]:
 > > > By the numbers, about 29% of Tor’s relay bandwidth supports IPv6--
 but functionally, only 20% of Tor’s available bandwidth supports IPv6.
 > >
 > > These numbers seem outdated.
 > >
 > > onionoo data from 2020-01-24 23:00 UTC:
 > >
 > > What cw fraction / guard/middle/exit probability has an IPv6 ORPort?
 > > CW Fraction: 31.83%
 > > Guard: 29.06%
 > > Middle:  29.79%
 > > Exit: 39.24%
 > > Relays count:  1210
 > >
 > > daily updated onionoo based IPv6 stats:
 https://nusenu.github.io/OrNetStats/#ipv6-relay-stats
 > >
 > > IPv6 related metrics graph:
 > > https://metrics.torproject.org/relays-ipv6.html
 >
 > Thanks! Those numbers were from when we wrote the project last year.

 nusenu, you're also using some different calculations from the grant:
 * you're calculating Guard IPv6 consensus weight fraction
 * the grant uses Guard-but-not-Exit IPv6 consensus weight fraction

 Since exit bandwidth is scarce in the tor network, tor clients use Guard-
 Exits as Exits. Therefore, to support IPv6 clients, we need to increase
 Guard-but-not-Exit IPv6 consensus weight.

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

Re: [tor-bugs] #30733 [Core Tor/sbws]: sbws does not detect changes in descriptor bandwidth values

[Tor Bug Tracker & Wiki]

#30733: sbws does not detect changes in descriptor bandwidth values
-+-
 Reporter:  starlight|  Owner:  juga
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Very High|  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:  sbws:
 |  1.1.0
 Severity:  Critical | Resolution:
 Keywords:  sbws-majority-blocker, sbws-roadmap  |  Actual Points:
Parent ID:  #33121   | Points:  1
 Reviewer:  asn  |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:42 juga]:
 > Replying to [comment:41 asn]:
 > Questions about the dormant mode:
 > - could tor become dormant when it is constantly creating new circuits?.

 Tor should not become dormant if it is constantly creating new circuits.
 If a sbws tor goes dormant, then:
 * there is a bug in sbws, or
 * there is a bug in tor.

 So if a sbws tor becomes dormant, we should look for bugs in sbws or tor.

 Does sbws stop trying to make circuits if:
 * the network goes down?
 * tor doesn't have a recent consensus or descriptors?

 If sbws does do these things, then tor might go dormant. So we should fix
 these bugs. (But they are not urgent.)

 > - would be enough to set the option `DormantCanceledByStartup 1` to
 ensure that tor won't ever become dormant?

 No, `DormantCanceledByStartup 1` only cancels dormant mode when tor is
 restarted.

 What does sbws do when it starts with a dormant tor? Does it still work?

 If it doesn't, we should set `DormantCanceledByStartup 1`, until we fix
 the dormant bugs in sbws.

 > - in which tor version was introduced the dormant mode?, 0.4.0?

 Tor 0.4.0.4-rc.

 > Maybe i could create other ticket to test this once we also run tests
 with different tor versions (#30067)?

 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] #25723 [Circumvention/Snowflake]: Multiplex - one client splits traffic across multiple proxies

[Tor Bug Tracker & Wiki]

#25723: Multiplex - one client splits traffic across multiple proxies
+--
 Reporter:  dcf |  Owner:  dcf
 Type:  defect  | Status:  assigned
 Priority:  Low |  Milestone:
Component:  Circumvention/Snowflake |Version:
 Severity:  Normal  | Resolution:
 Keywords:  anti-censorship-roadmap-2020Q1  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by uiouio27):

 Replying to [comment:4 dcf]:
 > Replying to [comment:2 uiouio27]:
 > > Does that mean that the required feature is covered? As far as I
 understand, that would switch the connection when a proxy leaves but not
 when it is very slow. Would it be still convenient to utilize several
 proxies but coordinately and congestion-based sending traffic to them?
 >
 > Good question. The multiplexing described in that document is simpler
 than what this ticket is about. You are correct that the failover only
 helps when a proxy dies, not when it is slow. But also, there's no way for
 a client to use, say, two 50 KB/s proxies as a single 100 KB/s channel—you
 can only use one at a time. The problem is that the bridge would be
 getting two streams of data and would not know how they should be
 interleaved.
 >

 Thanks for your answer, indeed the problem of resuming the session or any
 download with an alternate connection is necessary to be faced. I have
 seen the implementation of the Turbotunnel and seems interesting and I
 hope that can solve the usability problems. However, I still believe that
 a coordinated collaboration of multiple paths would be more beneficial.
 That would solve two problems: bridge churn, and slow bridges. I am not an
 expert on webrtc, but a solution to interleave multiple streams at
 application layer could also be convenient. I suppose such changes are not
 so complex inside the cgo wrapper of webrtc that Snowflake uses. Would you
 think it is worth to go on that (or a similar) direction?

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

Re: [tor-bugs] #33045 [Core Tor/Tor]: Increase the number of Tor network relays that support IPv6

[Tor Bug Tracker & Wiki]

#33045: Increase the number of Tor network relays that support IPv6
--+
 Reporter:  gaba  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor55-must
--+

Comment (by teor):

 Replying to [comment:4 gaba]:
 > Replying to [comment:2 arma]:
 > > Gaba, is this something you can bring to the metrics team? Especially
 if teor gives them a script that takes in a consensus and outputs a
 fraction?
 >
 > We can talk about it in the meeting next week.

 I've also added these ideas to my IPv6 statistics proposal draft, see
 #33159.

 I'll put them in the "optional work" section, and we can prioritise after
 all the essential work is done.

 Sponsor 55 is a small grant, so we won't have time to do everything.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #33159 [Core Tor/Tor]: Write a proposal for monitoring IPv6

[Tor Bug Tracker & Wiki]

#33159: Write a proposal for monitoring IPv6
+
 Reporter:  teor|  Owner:  teor
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  |   Keywords:  ipv6
Actual Points:  |  Parent ID:  #33052
   Points:  2   |   Reviewer:
  Sponsor:  Sponsor55-must  |
+
 For sponsor 55, I need to write a proposal that covers these objectives:
 * O1.4 - Measure the number of Tor relays that support IPv6 reachability
 checks (#33051)
 * O1.5 - Measure the number of connections, and consumed bandwidth, using
 IPv4 and IPv6 (#33052)

 My current thinking is that:
 * tor should log the number and consensus weight of relays that support
 IPv6 reachability checks, because we will need those numbers during
 testing
 * these numbers are available in the consensus

 Here's what the proposal requires:
 * calculate relay IPv6 reachability numbers a few times during the project
 (we may as well use the tor logs)
 * collect IPv6 connection and bandwidth statistics on tor relays
 * calculate the IPv6 connection and bandwidth amounts a few times during
 the project

 Here are some other useful things we might do:
 * split the collected IPv6 statistics by client/relay
 * calculate the guard-but-not-exit relays that support IPv6 client
 connections
 * log IPv6 statistics in tor's heartbeat logs (we can't use these logs for
 our project reports, because they only show the local relay's statistics)
 * calculate IPv6 reachability relay count and consensus weight on
 consensus-health
 * add a pseudo-flag for relay IPv6 reachability support in Relay Search
 * add metrics graphs that shows our progress on
   * IPv6 reachability
   * client IPv6 support on relays
   * IPv6 connections and bandwidth

 We definitely won't have time to do all of these optional things, so we
 should priorise, once the essential work is done.

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

Re: [tor-bugs] #30733 [Core Tor/sbws]: sbws does not detect changes in descriptor bandwidth values

[Tor Bug Tracker & Wiki]

#30733: sbws does not detect changes in descriptor bandwidth values
-+-
 Reporter:  starlight|  Owner:  juga
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Very High|  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:  sbws:
 |  1.1.0
 Severity:  Critical | Resolution:
 Keywords:  sbws-majority-blocker, sbws-roadmap  |  Actual Points:
Parent ID:  #33121   | Points:  1
 Reviewer:  asn  |Sponsor:
-+-

Comment (by juga):

 Replying to [comment:41 asn]:
 > It would be nice if the new code was also tested.

 agree. It's hard to test right now because:
 - the test network is tear down after 1st consensus and download. If we'd
 use chutney, then i think we could check for changes in descriptors
 (#33150)
 - there could be unit tests where we initialize RelayList with different
 consensus/descriptors, but that won't be possible until #29717
 - we could check that the production bandwidth files detect changes in the
 descriptors via an external tool (#33152)

 Maybe i should create a child ticket for #33149 to test this so we don't
 forget?

 > Also, you might want to check dormant mode and see if you need to
 disable that too, since if your tor thinks you are not using it, it will
 go dormant in 24h and stop downloading consensuses etc. The right way to
 disable dormant mode is to send the `ACTIVE` signal with the controller
 every once in a while. I'm not sure if this applies in your case, but I
 noticed the new torrc options you added are relevant.

 Questions about the dormant mode:
 - could tor become dormant when it is constantly creating new circuits?.
 - would be enough to set the option `DormantCanceledByStartup 1` to ensure
 that tor won't ever become dormant?
 - in which tor version was introduced the dormant mode?, 0.4.0?
 Maybe i could create other ticket to test this once we also run tests with
 different tor versions (#30067)?

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

Re: [tor-bugs] #32915 [Community/Relays]: Cloudflare alt-svc failures cause spurious "DNS resolution error" in Tor Browser (was: Some Tor exit node servers are using Cloudflare DNS, result in "DNS res

[Tor Bug Tracker & Wiki]

#32915: Cloudflare alt-svc failures cause spurious "DNS resolution error" in Tor
Browser
--+--
 Reporter:  cypherpunks   |  Owner:  ggus
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Community/Relays  |Version:
 Severity:  Normal| Resolution:
 Keywords:  network-health|  Actual Points:
Parent ID:  #32864| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 Fix title, exits are not involved.

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