Re: [tor-bugs] #27484 [Applications/Tor Browser]: Onboarding: unintuitive not-navigation buttons, starting with "Circuit Display" / "See My Path"

[Tor Bug Tracker & Wiki]

#27484: Onboarding: unintuitive not-navigation buttons, starting with "Circuit
Display" / "See My Path"
-+-
 Reporter:  dmr  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-8.0-issues, tbb-onboarding, ux-  |  Actual Points:
  team   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pili):

 Personally I prefer Option A, but I don't have strong feelings about 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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #13065, #13730

[Tor Bug Tracker & Wiki]

Batch modification to #13065, #13730 by gk:


Comment:
Adding update keyword

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

[tor-bugs] #29614 [Applications/Tor Browser]: Use SHA-256 algorithm for Windows authenticode timestamping

[Tor Bug Tracker & Wiki]

#29614: Use SHA-256 algorithm for Windows authenticode timestamping
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-security,
 Severity:  Normal   |  TorBrowserTeam201902,
 |  GeorgKoppen201902
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We switched to using SHA-256 for the authenticode signature but we should
 use that hash algo for the timestamp as well (currently that's still
 SHA-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] #29614 [Applications/Tor Browser]: Use SHA-256 algorithm for Windows authenticode timestamping

[Tor Bug Tracker & Wiki]

#29614: Use SHA-256 algorithm for Windows authenticode timestamping
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201902,  |  Actual Points:
  GeorgKoppen201902  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Should be not too hard to adapt our timestamping script, see:
 https://sourceforge.net/p/osslsigncode/support-requests/9/.

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

Re: [tor-bugs] #18287 [Applications/Tor Browser]: Use SHA-2 signature for Tor Browser setup executables

[Tor Bug Tracker & Wiki]

#18287: Use SHA-2 signature for Tor Browser setup executables
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-security, TorBrowserTeam201805,  |  Actual Points:
  GeorgKoppen201805  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:13 cypherpunks]:
 > Replying to [comment:12 gk]:
 > > Oh, I forgot to add that the timestamping and deterministic signature
 stripping is still working as expected.
 > and using SHA-1, fwiw. (SHA-2 digest + SHA-2 certificate + SHA-1
 timestamp)

 Yes, that's solved in #29614.

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

Re: [tor-bugs] #29120 [Applications/Tor Browser]: Default value of media.cache_size (0) causes some media to load extremely slowly or become unplayable

[Tor Bug Tracker & Wiki]

#29120: Default value of media.cache_size (0) causes some media to load 
extremely
slowly or become unplayable
-+-
 Reporter:  QZw2aBQoPyuEVXYVlBps |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-disk-leak, tbb-usability-|  Actual Points:
  website, TorBrowserTeam201902  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-disk-leak, tbb-usability-website, TorBrowserTeam201902R =>
 tbb-disk-leak, tbb-usability-website, TorBrowserTeam201902
 * status:  needs_review => needs_revision


Comment:

 Setting to `needs_revision` to address mcs's concern. We are close! :)

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

Re: [tor-bugs] #29611 [Applications/Tor Browser]: Work around lack of app.update.enabled pref in Firefox 63+

[Tor Bug Tracker & Wiki]

#29611: Work around lack of app.update.enabled pref in Firefox 63+
+--
 Reporter:  dcf |  Owner:  tbb-team
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  meek moat tbb-update, ff68-esr  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * keywords:  meek moat => meek moat tbb-update, ff68-esr
 * cc: mcs, brade (added)


Comment:

 dcf: Is there any reason to have this merged into Tor Browser based on ESR
 60? Otherwise I'd set the review flag to a month where we likely pick up
 patches for the esr68 transition and have us looking over it then.

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

Re: [tor-bugs] #29330 [Metrics/Website]: Do something with advertised bandwidth distribution graphs

[Tor Bug Tracker & Wiki]

#29330: Do something with advertised bandwidth distribution graphs
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  irl  |Sponsor:
-+--
Changes (by karsten):

 * Attachment "cwdist-irl-percentiles-2019-02-28.png" added.


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

Re: [tor-bugs] #29330 [Metrics/Website]: Do something with advertised bandwidth distribution graphs

[Tor Bug Tracker & Wiki]

#29330: Do something with advertised bandwidth distribution graphs
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  irl  |Sponsor:
-+--

Comment (by karsten):

 Replying to [comment:3 irl]:
 > Switching to consensus weight is a good compromise where the alternative
 is removing the graphs.

 Works for me.

 > I don't think we need both percentiles and n-th fastest. Drop the n-th
 fastest and just have percentiles.

 Works for me, too.

 > Can we do 100, 99, 98, 95, 75, 50, 25, 3, 2, 1, 0? These don't need to
 be configurable, just fixed is OK.

 This one is tricky. We're looking at a distribution that is far from
 normal. I made a quick graph with those percentiles:

 [[Image(cwdist-irl-percentiles-2019-02-28.png, 600px​)]]

 (That graph would need some more love, like using labels on the y axis
 that are not in scientific notation, reordering percentiles in the legend,
 and using more intuitive labels for the two subplots than TRUE and NA. I
 didn't spend the time on that yet, but those things would get fixed.)

 The only really visible percentiles are 100, 99, 98, and maybe 95. All
 others are hard to distinguish in the graph.

 I also tried a log scale, but you can imagine how that's rather
 unintuitive to read. Another uncool aspect of the log scale is that the
 minimum consensus weight (of unmeasured relays) is 0.

 I'd say, if we switch to consensus weight percentiles, let's keep
 percentiles configurable. Maybe one person is interested in the extremes,
 and another person wants to look at the center. Giving them just a single
 graph might make at least one of them unhappy.

 In fact, we could even keep the n-th fastest if that keeps folks happy.
 This part doesn't cost us much maintenance effort. It's the advertised
 bandwidth stuff that I'd really want to get rid of.

 arma, what do you think?

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

Re: [tor-bugs] #29221 [Core Tor/Tor]: Tooling to track code-style/best-practices violations

[Tor Bug Tracker & Wiki]

#29221: Tooling to track code-style/best-practices violations
+--
 Reporter:  nickm   |  Owner:  (none)
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  network-team-roadmap-2019-Q1Q2  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:
|  Sponsor31-can
+--

Comment (by asn):

 OK. Something that looks like a plausible MVP here can be found in my
 `bug29221_draft` above. Or: https://github.com/torproject/tor/pull/742

 Let me know how this looks like to you.

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

Re: [tor-bugs] #29553 [Core Tor/Tor]: pre-commit hook gives a warning when there are no changes files, when source files aren't where expected, and doesn't exit.

[Tor Bug Tracker & Wiki]

#29553: pre-commit hook gives a warning when there are no changes files, when
source files aren't where expected, and doesn't exit.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  asn-merge |  Actual Points:
Parent ID:| Points:  .1
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by asn):

 * 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] #29599 [Core Tor/Tor]: Test failure due to missing sr_state_free[_all]() in shared-random unit tests

[Tor Bug Tracker & Wiki]

#29599: Test failure due to missing sr_state_free[_all]() in shared-random unit
tests
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Major| Resolution:  fixed
 Keywords:  tor-ci, tor-test, memory-leak,   |  Actual Points:
  external-change, 029-backport, 033-backport,   |
  034-backport, 035-backport, 040-backport,  |
  nickm-merge|
Parent ID:   | Points:  0.5
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by asn):

 LGTM!

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

Re: [tor-bugs] #29574 [Applications/Tor Browser]: Configure Orbot to Use TOPL and tor-android-service Libraries

[Tor Bug Tracker & Wiki]

#29574: Configure Orbot to Use TOPL and tor-android-service Libraries
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a3,  |  Actual Points:
  TorBrowserTeam201902R  |
Parent ID:  #27609   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

 * keywords:  tbb-mobile, TBA-a3, TorBrowserTeam201902 => tbb-mobile,
 TBA-a3, TorBrowserTeam201902R


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

Re: [tor-bugs] #18287 [Applications/Tor Browser]: Use SHA-2 signature for Tor Browser setup executables

[Tor Bug Tracker & Wiki]

#18287: Use SHA-2 signature for Tor Browser setup executables
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-security, TorBrowserTeam201805,  |  Actual Points:
  GeorgKoppen201805  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 https://blogs.msdn.microsoft.com/ie/2012/08/14/microsoft-smartscreen-
 extended-validation-ev-code-signing-certificates/

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

Re: [tor-bugs] #28803 [Applications/Tor Browser]: Integrate building pluggable transports for Android into tor-browser-build

[Tor Bug Tracker & Wiki]

#28803: Integrate building pluggable transports for Android into 
tor-browser-build
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, TBA-a3, tor-|  Actual Points:
  pt, TorBrowserTeam201902   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by gk):

 * status:  new => needs_revision


Comment:

 FWIW, this needs revision as we need to make sure that the built stuff is
 actually used by our bundle. This requires at least copying the files to
 the proper places in a different project in `tor-browser-build`.

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

Re: [tor-bugs] #29570 [Core Tor/Tor]: Enforce mutually exclusive logic for IPv6 ORPort flags

[Tor Bug Tracker & Wiki]

#29570: Enforce mutually exclusive logic for IPv6 ORPort flags
---+---
 Reporter:  s7r|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:  Tor:
   |  unspecified
 Severity:  Normal | Resolution:
 Keywords:  tor-relay, ipv6, reachability  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by AVee):

 I'm not sure there is a bug here. As per
 https://lists.torproject.org/pipermail/tor-
 relays/2019-February/016994.html it seems this setup is actually working.

 I fully agree that IPv6 is intended to provide end to end connectivity,
 but in practice there are a number of ways (and reasons) for network
 traffic to move from IPv4 to IPv6 and vice-versa. This setup is one of
 just them. While this case runs counter to what IPv6 intends to achieve,
 it does work... Moreover, a relay in an IPv6 only network that is through
 router tricks still reachable on a IPv4 address seems a sensible case to
 me.

 The assumption here seems to be that IPv4 and IPv6 are strictly separate
 worlds, but they are not. Therefore I'd be inclined to say pretty much
 anything advertised could be valid because pretty much anything can be
 made to work at network level and it's impossible for Tor to know about
 that. Isn't that why connectivity testing is done?

 I'm not sufficiently into the internals of Tor to know if anything there
 may prevent any of this from working. But in that case I might even argue
 that's actually a bug.

 (A warning like 'You are advertising IPv''X'' but not listening there'
 would still be useful for troubleshooting.)

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

Re: [tor-bugs] #28685 [Applications/Tor Browser]: Tor Browser for Android needs a more dynamic Build ID

[Tor Bug Tracker & Wiki]

#28685: Tor Browser for Android needs a more dynamic Build ID
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, TBA-a3, |  Actual Points:
  TorBrowserTeam201902R  |
Parent ID:  #28708   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by boklm):

 * keywords:  tbb-mobile, tbb-rbm, TBA-a3, TorBrowserTeam201902 => tbb-
 mobile, tbb-rbm, TBA-a3, TorBrowserTeam201902R
 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:11 gk]:
 >
 > We shipped 8.0.6 with 60.5.1esr, no? It seems we should adapt the
 comment in the script accordingly.

 I fixed that in branch `bug_28685_v4`:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_28685_v4&id=d11f03f7c10c2cf5a942a353d0961249ceee9644

 >
 > The new scheme makes the calculation save until Tor Browser 18, if I see
 this correctly. That's okay for me.

 We currently subtract 5, so Tor Browser 17 would be month 12. But we can
 increase the value we subtract when changing year, to allow more versions.

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

Re: [tor-bugs] #29046 [Core Tor/sbws]: Remove unused testnets

[Tor Bug Tracker & Wiki]

#29046: Remove unused testnets
---+---
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords:  easy   |  Actual Points:
Parent ID:  #28684 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by juga):

 * status:  assigned => merge_ready
 * milestone:  sbws: 1.1.x-final => sbws: 1.0.x-final


Comment:

 Because this remove lot of unused files in a source distribution, moving
 to 1.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] #29299 [Core Tor/sbws]: Include scanner country and Web server country in the bandwidth file header

[Tor Bug Tracker & Wiki]

#29299: Include scanner country and Web server country in the bandwidth file 
header
---+---
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  sbws: 1.1.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:  1
Parent ID: | Points:  1
 Reviewer:  catalyst   |Sponsor:
---+---
Changes (by juga):

 * actualpoints:   => 1


Comment:

 I merged, then realized about that child.
 Going to work on child.

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

Re: [tor-bugs] #29576 [Applications/Tor Browser]: Tor Browser won't start

[Tor Bug Tracker & Wiki]

#29576: Tor Browser won't start
--+---
 Reporter:  thelamper |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by thelamper):

 I made an exception for Tor in Windows Defender and this resolved the
 issue, at least for now.

 Not sure why this problem arose initially. As I mentioned, I have always
 had both McAfee and Windows Defender firewalls running on my computer and
 it had never interfered with the 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] #29046 [Core Tor/sbws]: Remove unused testnets

[Tor Bug Tracker & Wiki]

#29046: Remove unused testnets
---+---
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:  fixed
 Keywords:  easy   |  Actual Points:
Parent ID:  #28684 | Points:
 Reviewer: |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

[tor-bugs] #29615 [Applications/Tor Browser]: Adjust creation of buildID script

[Tor Bug Tracker & Wiki]

#29615: Adjust creation of buildID script
-+-
 Reporter:  gk   |  Owner:  tbb-team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  TorBrowserTeam201912,
 Severity:  Normal   |  tbb-rbm
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We should adjust the creation of our build ID script to make sure we have
 a larger space using the months available (currently Tor Browser 17 is the
 last major version that produces valid buildIDs). And we should think
 about a good way to implement something where we don't need to worry about
 the buildID creation in the future 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] #28685 [Applications/Tor Browser]: Tor Browser for Android needs a more dynamic Build ID

[Tor Bug Tracker & Wiki]

#28685: Tor Browser for Android needs a more dynamic Build ID
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-mobile, tbb-rbm, TBA-a3, |  Actual Points:
  TorBrowserTeam201902R  |
Parent ID:  #28708   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by gk):

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


Comment:

 Looks good. Commit d11f03f7c10c2cf5a942a353d0961249ceee9644 on `master`
 has the patch. I've filed #29615 for follow-up work.

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

Re: [tor-bugs] #29576 [Applications/Tor Browser]: Tor Browser won't start

[Tor Bug Tracker & Wiki]

#29576: Tor Browser won't start
--+---
 Reporter:  thelamper |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Glad this is working for you. You might have got a Windows defender update
 that is now interfering with Tor. Anyway, no Tor Browser bug 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] #29576 [Applications/Tor Browser]: Tor Browser won't start

[Tor Bug Tracker & Wiki]

#29576: Tor Browser won't start
--+---
 Reporter:  thelamper |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 Start signing the exes. No?

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

Re: [tor-bugs] #28329 [Applications/Tor Browser]: Design TBA+Orbot configuration UI/UX

[Tor Bug Tracker & Wiki]

#28329: Design TBA+Orbot configuration UI/UX
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, ux-team, TBA-a3, |  Actual Points:
  TorBrowserTeam201902   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by antonela):

 * Attachment "measurements.png" added.


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

Re: [tor-bugs] #28329 [Applications/Tor Browser]: Design TBA+Orbot configuration UI/UX

[Tor Bug Tracker & Wiki]

#28329: Design TBA+Orbot configuration UI/UX
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, ux-team, TBA-a3, |  Actual Points:
  TorBrowserTeam201902   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by antonela):

 comment:33 > That worked! Thanks!

 UI Review

 **1.0 / 2.0 - Bootstrapping**
 - The phone gets suspended during the bootstrapping, going black screen.
 It is probably a local configuration, but can we do something to avoid it?
 - The settings icon needs margin. And probably a better support for
 different screens dpi. Could we have a
 [https://material.io/tools/icons/?icon=settings&style=baseline SVG]?
 - I attached a quick screen elements measurements, maybe it helps to match
 the design with the development. Also, you can find a clickable one
 [https://marvelapp.com/4fcjj0e/screen/53905418/handoff here]

 [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/28329/measurements.png, 700px)]]

 - Let me know how you want to work with the animation, I can give you the
 assets you need or maybe we want to try something different for this
 release.
 - Could we have Roboto Monospace font at the log screen? If we are keeping
 the out of the box material, [https://material.io/design/typography/the-
 type-system.html#type-scale Body2] seems the appropriate font-size :)

 **3.0 - Network Settings**
 - When the user switches the bridge on, let's first animate the switcher
 to on and then go to the second screen.
 - "You are using a bridge to connect to Tor" needs to fit in two lines and
 should replace "Config a bridge to connect to Tor" when the bridge is
 enabled.
 - Let's don't move users to the main screen right after they select a
 bridge. It's confusing. We can move them to the previous screen, or they
 can navigate back. I prefer the second option.
 - When users switch off, the "You are using a built-in bridge to connect
 to Tor" line needs to disappear. Even if that config is going to be
 persistent until the next switch on, let's hide it when the option is off
 to avoid confusion.

 **3.1 - Network Settings/Select a bridge**
 - Select a bridge needs left margin
 - The back arrow doesn't work, the bottom navigation one yes

 **3.1.1 - Network Settings/Provide a Bridge**
 - Enter Bridge needs left margin
 - The back arrow doesn't work, the bottom navigation one yes


 Can't wait for the next iteration. This work has been huge! We are almost
 there!

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

Re: [tor-bugs] #29425 [Metrics/Statistics]: Write integration tests for data-processing modules

[Tor Bug Tracker & Wiki]

#29425: Write integration tests for data-processing modules
-+
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Metrics/Statistics   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-roadmap-2019-q2  |  Actual Points:
Parent ID:   | Points:  8
 Reviewer:  irl  |Sponsor:
-+

Comment (by karsten):

 I'm unclear how to reproduce or fix that UTF8 encoding issue. How would I
 do this?

 Regarding the PostgreSQL server setup, the easiest way is to enable
 `trust` authentication for users connecting from localhost, so in other
 words disable authentication for whoever manages to connect to the
 database. In order to do this, you'll have to edit your `pg_hba.conf` file
 in `/etc/postgresql/$postgresql_version/main/` by replacing these lines:

 {{{
 local   all all peer
 hostall all 127.0.0.1/32md5
 hostall all ::1/128 md5
 }}}

 with these lines:

 {{{
 local   all all trust
 hostall all 127.0.0.1/32trust
 hostall all ::1/128 trust
 }}}

 That's what I'm doing on my development machine, and it might well be that
 it was `brew` setting this up as default. I know that this setting is
 different on Debian, and it's likely going to be different on any
 production system. Still, for running tests this should be sufficient. And
 yes, if we require this, we should document 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] #29425 [Metrics/Statistics]: Write integration tests for data-processing modules

[Tor Bug Tracker & Wiki]

#29425: Write integration tests for data-processing modules
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Statistics   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-roadmap-2019-q2  |  Actual Points:
Parent ID:   | Points:  8
 Reviewer:  irl  |Sponsor:
-+--
Changes (by karsten):

 * status:  needs_revision => needs_review


Comment:

 Please give it another try!

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

Re: [tor-bugs] #29610 [Core Tor/Tor]: Server being attacked

[Tor Bug Tracker & Wiki]

#29610: Server being attacked
--+---
 Reporter:  pidgin|  Owner:  (none)
 Type:  project   | Status:  closed
 Priority:  Very High |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Critical  | Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by nickm):

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


Comment:

 This is a duplicate of #29607.  Please don't open the same tickets over
 and over.

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

Re: [tor-bugs] #29607 [Core Tor/Tor]: Need urgent help!

[Tor Bug Tracker & Wiki]

#29607: Need urgent help!
--+
 Reporter:  pidgin|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Closed #29610 as a duplicate here.  What is causing you to conclude that
 this is an attack against Tor, instead of (say) an attack against some
 other component?  Right now, there's not enough information in your
 report(s) to tell.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29616 [Core Tor/Tor]: Git scripts should fetch once only.

[Tor Bug Tracker & Wiki]

#29616: Git scripts should fetch once only.
--+--
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  git-scripts
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Hi!

 When I run "git-pull-all.sh", it does a git pull on each worktree.  Git
 pull has two parts: a fetch, and a merge.  The fetch is slow, but fetches
 all the branches from origin.  The merge part is fast, since it doesn't
 touch the network.

 It would be cool if the pull and merge scripts only did a single fetch of
 the origin, and then did a bunch of fast-forward-only merges.  That way
 they could run a bit faster.

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

Re: [tor-bugs] #29541 [Core Tor/Tor]: Re-enable util/mmap_anon_no_fork

[Tor Bug Tracker & Wiki]

#29541: Re-enable util/mmap_anon_no_fork
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop289, prop289-assigned-   |  Actual Points:
  sponsor-v, 041-proposed-on-roadmap, network-   |
  team-roadmap-2019-Q1Q2 |
Parent ID:  #26288   | Points:
 Reviewer:  mikeperry|Sponsor:
-+-

Comment (by nickm):

 I really don't see how this test bug could have affected those tests...
 but the world has been known to do things that I do not expect.  If they
 happen one time in ten, maybe checking to see whether this fix fixes them
 too might be reasonable.

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

Re: [tor-bugs] #26288 [Core Tor/Tor]: prop289: Implement authenticated SENDME

[Tor Bug Tracker & Wiki]

#26288: prop289: Implement authenticated SENDME
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop289, 035-roadmap-master, 035 |  Actual Points:
  -triaged-in-20180711, prop289-assigned-|
  sponsor-v, 041-proposed-on-roadmap, network-   |
  team-roadmap-2019-Q1Q2 |
Parent ID:   | Points:  21
 Reviewer:  nickm|Sponsor:
 |  SponsorV
-+-

Comment (by dgoulet):

 Replying to [comment:19 teor]:
 > I reviewed the protocol parts of this patch:
 >
 > Phase 3 of the transition plan requires old clients and relays to
 download a consensus so they learn that they should stop trying to connect
 to the network. But since 0.2.8, clients (and censored relays that can't
 access any DirPorts) will try to use the ORPort to download a consensus.
 But ORPort circuits from legacy clients will fail during phase 3.

 This is what the new protover version is all about. We would flip
 `FlowCtrl=1` _before_ the consensus param `sendme_accept_min_version=1` is
 set. This would effectively exit() every clients/relays that can't support
 v1.

 Then we can enforce *only* accepting v1 through the consensus (if that
 param is needed at all).

 >
 > Here's what I think we need to do:
 > 1. always allow legacy sendmes for BEGINDIR for the consensus, and
 everything that is required to validate a consensus:
 >   * authority certificates,
 >   * relay descriptors (for bridge clients),
 >   * anything else?

 I'm quite reluctant to keep legacy SENDMEs even when the protover
 _and_/_or_ the consensus param is flipped. The whole point of that
 protover is that we don't have to deal with clients not supporting v1. And
 we can NOT flip the "min accept" param before that protover.

 > 3. Don't remove the section about extensive testing using chutney:
 > {{{
 > -   We'll want to do a bunch of testing in chutney before flipping the
 > -   switches in the real network: I've long suspected we still have bugs
 > -   in our sendme timing, and this proposal might expose some of them.
 > }}}
 > 4. Do the chutney tests now, and do them again when we want to implement
 each phase on the public network

 I don't see the point of that in a proposal to be honest. Chutney tests
 have been done extensively to develop that branch so I'm not sure what
 this (4) is about here?...

 Any switch we flip in the consensus, especially something like this, needs
 to be tested a lot. Not doing so is a bit reckless on our part and I doubt
 having it in the proposal saying "we need to test this" is useful at
 all...

 What I recommend we do is actually describe the "ordering" of all the
 pieces in the transition plan. And then document what we should NOT do so
 in 10 years, we have a reminder of what to do (because I don't see Phase 3
 being done until many years!).

 >
 > The spec and the code are also out of sync: the spec talks about
 FlowCtrl, but the code doesn't have FlowCtrl.

 Yes, that is what the original comment mean on my part is that I didn't do
 this yet because I wasn't sure it was the right approach with the
 `SendMe`.

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

Re: [tor-bugs] #29541 [Core Tor/Tor]: Re-enable util/mmap_anon_no_fork

[Tor Bug Tracker & Wiki]

#29541: Re-enable util/mmap_anon_no_fork
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  041-proposed-on-roadmap, network-|  Actual Points:
  team-roadmap-2019-Q1Q2 |
Parent ID:   | Points:
 Reviewer:  mikeperry|Sponsor:
-+-
Changes (by dgoulet):

 * keywords:
 prop289, prop289-assigned-sponsor-v, 041-proposed-on-roadmap, network-
 team-roadmap-2019-Q1Q2
 => 041-proposed-on-roadmap, network-team-roadmap-2019-Q1Q2
 * parent:  #26288 =>


Comment:

 I have no clue how this relates to prop289 (#26288). Feel free to re-
 parent but explains why before?

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

Re: [tor-bugs] #29425 [Metrics/Statistics]: Write integration tests for data-processing modules

[Tor Bug Tracker & Wiki]

#29425: Write integration tests for data-processing modules
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Statistics   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-roadmap-2019-q2  |  Actual Points:
Parent ID:   | Points:  8
 Reviewer:  irl  |Sponsor:
-+--
Changes (by karsten):

 * owner:  metrics-team => karsten
 * status:  needs_review => accepted


Comment:

 Taking this out of review after running it on a Linux machine and finding
 differences. Will try to fix these differences first and will put it back
 into needs_review afterwards.

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

Re: [tor-bugs] #29541 [Core Tor/Tor]: Re-enable util/mmap_anon_no_fork

[Tor Bug Tracker & Wiki]

#29541: Re-enable util/mmap_anon_no_fork
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  041-proposed-on-roadmap, network-|  Actual Points:
  team-roadmap-2019-Q1Q2 |
Parent ID:   | Points:
 Reviewer:  mikeperry|Sponsor:
-+-

Comment (by nickm):

 This is prop289 because it's a bug in the no-fork mmap tests; I added the
 no-fork mmap to make the fast PRNG more fork-safe.

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

Re: [tor-bugs] #29562 [Core Tor/Tor]: APPCRASH of tor.exe on Windows when PT bootstrap is cancelled

[Tor Bug Tracker & Wiki]

#29562: APPCRASH of tor.exe on Windows when PT bootstrap is cancelled
-+-
 Reporter:  dcf  |  Owner:  ahf
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression 040-must crash nickm- |  Actual Points:  0.3
  merge  |
Parent ID:   | Points:  0.3
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * keywords:  regression 040-must crash => regression 040-must crash nickm-
 merge
 * reviewer:   => dgoulet


Comment:

 lgtm!

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

Re: [tor-bugs] #29562 [Core Tor/Tor]: APPCRASH of tor.exe on Windows when PT bootstrap is cancelled

[Tor Bug Tracker & Wiki]

#29562: APPCRASH of tor.exe on Windows when PT bootstrap is cancelled
-+-
 Reporter:  dcf  |  Owner:  ahf
 Type:  defect   | Status:
 |  merge_ready
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression 040-must crash nickm- |  Actual Points:  0.3
  merge  |
Parent ID:   | Points:  0.3
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => merge_ready


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

Re: [tor-bugs] #29562 [Core Tor/Tor]: APPCRASH of tor.exe on Windows when PT bootstrap is cancelled

[Tor Bug Tracker & Wiki]

#29562: APPCRASH of tor.exe on Windows when PT bootstrap is cancelled
-+-
 Reporter:  dcf  |  Owner:  ahf
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.0.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  regression 040-must crash nickm- |  Actual Points:  0.3
  merge  |
Parent ID:   | Points:  0.3
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Merged to 0.4.0 and forward. 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] #29273 [Obfuscation/BridgeDB]: Document BridgeDB infrastructure

[Tor Bug Tracker & Wiki]

#29273: Document BridgeDB infrastructure
+--
 Reporter:  ahf |  Owner:  dgoulet
 Type:  task| Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Obfuscation/BridgeDB|Version:
 Severity:  Normal  | Resolution:
 Keywords:  network-team-roadmap-2019-Q1Q2  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  sysrqb  |Sponsor:  Sponsor19
+--
Changes (by dgoulet):

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


Comment:

 Branch in my bridgedb-admin.git repo: `ticket29273`

 It is not entirely completed. I documented the deployment/running part of
 BridgeDB within this branch. Over time, many things probably will be added
 but for now it gives a good picture of the current *complicated*
 situation.

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

Re: [tor-bugs] #29489 [Obfuscation/Snowflake]: Set up automated local testing environment for Snowflake

[Tor Bug Tracker & Wiki]

#29489: Set up automated local testing environment for Snowflake
---+--
 Reporter:  cohosh |  Owner:  cohosh
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #29259 | Points:
 Reviewer: |Sponsor:  Sponsor19
---+--
Changes (by cohosh):

 * status:  assigned => needs_review


Comment:

 Because this is working, I'm putting it into needs_review for now. We'll
 probably want to add new features as we go but for now it works for basic
 testing.

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

Re: [tor-bugs] #27484 [Applications/Tor Browser]: Onboarding: unintuitive not-navigation buttons, starting with "Circuit Display" / "See My Path"

[Tor Bug Tracker & Wiki]

#27484: Onboarding: unintuitive not-navigation buttons, starting with "Circuit
Display" / "See My Path"
-+-
 Reporter:  dmr  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-8.0-issues, tbb-onboarding, ux-  |  Actual Points:
  team   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 It would be interesting to know if Mozilla did any usability studies with
 their approach (Option B).

 Option A seems like it will definitely be an improvement over what we have
 today, but I wonder if people will notice the big button a lot more than
 the inline link.  The button is like "Next" with a different label and it
 is a little confusing that it is positioned below the current topic's
 image.

 Another approach would be to include a button labeled "Next" on every
 panel except the last one and then have an action button there as well for
 panels that have an action. Something like:
 {{{
   [See My Path][Next]
 }}}

 That would be easier to implement than Option A, but I do not know if it
 will completely solve the usability hiccup.

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

Re: [tor-bugs] #27539 [Applications/Tor Browser]: Create plan for releasing on F-Droid

[Tor Bug Tracker & Wiki]

#27539: Create plan for releasing on F-Droid
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201902,|  Actual Points:
  TBA-8.5|
Parent ID:  #26318   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by sysrqb):

 quick update here. I like this plan in theory, where we run our own repo
 and publish updates on f-droid.org and our own. My main worry is our
 ability for running more services like this as an organization. I think
 this is something we can think about more and make plans for in the (not
 too distant) future - maybe. In the meantime, I'd like to get f-droid.org
 builds working now.

 I currently have a metadata file ready and it successfully builds tor
 browser using tor-browser-build within a fdroidserver instance I installed
 locally. My main worry here is how long the build process takes. On a
 bare-metal older laptop I'm using, the entire build process for armv7
 takes roughly 3.5 hours. I'm under the impression F-Droid use VMs for each
 app build, and there's an upper bound of 7 hours(?) per build. If this is
 true, then I won't be surprised if we hit that timeout limit. One of the
 main reasons for this is artifacts are not cached across builds - so all
 repos and files are cloned/downloaded for every build iteration. I
 understand why this is important for a general apk builder, but this is
 painful for a large project like tor browser.

 In addition, the Tor Browser build process requires 40+ GB of disk space
 and 2+ GB of RAM, and I'm not sure if F-Droid's default build server will
 support this.

 I haven't confirmed reproducible builds between our apk and fdroid yet.

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

Re: [tor-bugs] #29489 [Obfuscation/Snowflake]: Set up automated local testing environment for Snowflake

[Tor Bug Tracker & Wiki]

#29489: Set up automated local testing environment for Snowflake
---+--
 Reporter:  cohosh |  Owner:  cohosh
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #29259 | Points:
 Reviewer: |Sponsor:  Sponsor19
---+--

Comment (by ahf):

 Just tried this out locally in a VM and it seems to work well! I think we
 could close this now and then iterate like cohosh writes in the last
 comment.

 One nice to have feature:

 - Make the config environment generator script clone the snowflake repo if
 it doesn't exist already.

 I'm going to move this to `closed` instead of `merge_ready`, but there is
 one more task related to this we need to do: once the Gitlab instance is
 up and running we should probably move it into the snowflake namespace
 there.

 For other people who want to try this out on Debian Stable: I followed the
 Docker guide from here: https://www.digitalocean.com/community/tutorials
 /how-to-install-and-use-docker-on-debian-9 - the `docker` package on
 Debian out of the box have nothing to do with the docker you need to run
 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] #26920 [Applications/Tor Browser]: Deploy Marionette as a Pluggable Transport

[Tor Bug Tracker & Wiki]

#26920: Deploy Marionette as a Pluggable Transport
--+---
 Reporter:  Marionette|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  Marionette tor-pt |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor19
--+---

Comment (by cohosh):

 I have a marionette bridge set up for testing.

 === Bridge Info

 You can add the following line to the client's torrc file:
 {{{
 Bridge marionette 165.227.39.255:8081
 }}}

 The hashed-fingerprint is {{{F669BDEFC46E6F441A87418579A653C1D35BCF6F}}}

 This bridge also has an IPv6 address: {{{2604:a880:cad:d0::30:1}}}

 === Testing specifics

 You can place quite a bit of load on this one. I've placed an accounting
 max of 1TB/month on the bridge.

 === Build process for marionette

 It took some work to build the marionette server and configure the torrc
 file at the bridge. Right now it does not work out the box and the given
 torrc files in the marionette repository need to be modified for
 production bridge use.

 I've created a pull request to fix the compilation and linking issues
 here: https://github.com/redjack/marionette/pull/22

 These are the steps that I followed to build and deploy marionette:
 1. Build the dependencies {{{./build_third_party.sh}}} Note: you should
 run this script instead of following the User Guide. This will install the
 dependencies locally instead of system-wide and put them in the directory
 third_party/libs (which is where marionette later assumes they will be)

 2. go build

 3. go install ./cmd/marionette

 4. Place the binary (located locally in $GOPATH/bin) in /usr/local/bin/ of
 the bridge server

 Here's a sample torrc file that will work:
 {{{
 Nickname pick-a-nickname
 ContactInfo you 
 RunAsDaemon 0
 Log notice stderr

 BridgeRelay 1
 SOCKSPort 0
 ORPort 9001
 ExtORPort 9002
 #IPv6 is also enabled
 ORPort [ipv6 address]:9001

 ServerTransportPlugin marionette exec /usr/local/bin/marionette pt-server
 -log-file /var/log/tor/marionette-server.log -format http_simple_blocking

 # Marionette gets its listening port from its specification document.
 # This should be fixed before deployment. We hardcode this value to 8081.
 ServerTransportListenAddr marionette 0.0.0.0:8081
 }}}

 I've verified the bridge is working by connecting with a client with the
 following torrc file:
 {{{
 RunAsDaemon 0
 Log notice stderr
 DataDirectory datadir

 SocksPort 19050

 UseBridges 1

 # See comment in torrc.server for information about why this must always
 be 8081.
 Bridge marionette 165.227.39.255:8081

 ClientTransportPlugin marionette exec ./marionette pt-client -log-file
 marionette-client.log -format http_simple_blocking
 }}}

 === Other notes on marionette

 - The dependencies for marionette are still a bit troublesome. I'm worried
 that they will be difficult to maintain and easily go out of date. I see
 that python is no longer required which seems to be an improvement but I'm
 curious about the need for re2 and openfst.

 - It would be nice to fix the listen port to not be hardcoded:
 {{{
 # Marionette gets its listening port from its specification document.
 # This should be fixed before deployment. We hardcode this value to 8081.
 ServerTransportListenAddr marionette 0.0.0.0:8081
 }}}
 At cmd/marionette/pt_server.go:86
 {{{
 // Marionette always listen on port 8081 so we ignore TOR.
 // This should probably be fixed.
 host, port, err :=
 net.SplitHostPort(bindAddr.Addr.String())
 }}}

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

Re: [tor-bugs] #29604 [Core Tor/Tor]: Always pull-all before merge-forward

[Tor Bug Tracker & Wiki]

#29604: Always pull-all before merge-forward
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:  git-scripts   |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

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


Comment:

 Ok I just realized that our merge forward script does a pull of the branch
 before merging forward as in making sure the branch is up to date.

 {{{
   # Update the current branch with a pull to get the latest.
   pull_branch "$current"
 }}}

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

Re: [tor-bugs] #29606 [Core Tor/Tor]: Remove tor 0.3.3 from the git-* scripts

[Tor Bug Tracker & Wiki]

#29606: Remove tor 0.3.3 from the git-* scripts
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  git-scripts   |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

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


Comment:

 Pushed upstream.

 Commit: 9256b02cc8b2cc6ae495f9f2262b546429a89dbd

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

Re: [tor-bugs] #26920 [Applications/Tor Browser]: Deploy Marionette as a Pluggable Transport

[Tor Bug Tracker & Wiki]

#26920: Deploy Marionette as a Pluggable Transport
--+---
 Reporter:  Marionette|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  Marionette tor-pt |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor19
--+---
Changes (by cohosh):

 * cc: cohosh (added)


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

Re: [tor-bugs] #29616 [Core Tor/Tor]: Git scripts should fetch once only.

[Tor Bug Tracker & Wiki]

#29616: Git scripts should fetch once only.
--+--
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  git-scripts   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dgoulet):

 * status:  new => needs_review


Comment:

 PR: https://github.com/torproject/tor/pull/743
 Branch: `ticket29616_041_01`

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

[tor-bugs] #29617 [- Select a component]: OOM manger wipes entire DNS cache

[Tor Bug Tracker & Wiki]

#29617: OOM manger wipes entire DNS cache
+--
 Reporter:  pulls   |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  - Select a component
  Version:  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 In relay.c, function cell_queues_check_size, the OOM manager attempts to
 clear one tenth of MaxMemInQueues bytes from the DNS cache by calling
 dns_cache_handle_oom. The function dns_cache_handle_oom, in dns.c, runs in
 a loop removing cached entries that are now+n*time_inc old, until at least
 the requested number of bytes have been freed. The first iteration of the
 loop has n=0, and likely will not remove enough bytes. The second
 iteration is way too aggressive, because:

 {{{
 time_inc += 3600; /* Increase time_inc by 1 hour. */
 }}}

 This is guaranteed to wipe the entire DNS cache, because in dns_clip_ttl
 the maximum time to cache is MAX_DNS_TTL_AT_EXIT, which is set in dns.h
 to:

 {{{
 /** Lowest value for DNS ttl that a server will give. */
 #define MIN_DNS_TTL_AT_EXIT (5*60)
 /** Highest value for DNS ttl that a server will give. */
 #define MAX_DNS_TTL_AT_EXIT (60*60)
 }}}

 One possible and reasonable fix would be to instead increment time_inc by
 MIN_DNS_TTL_AT_EXIT.

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

Re: [tor-bugs] #28547 [Core Tor/sbws]: Monitor relays that are not measured by each sbws instance

[Tor Bug Tracker & Wiki]

#28547: Monitor relays that are not measured by each sbws instance
-+-
 Reporter:  teor |  Owner:  juga
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth, sbws-1.0-must-   |  Actual Points:
  moved-20181128 |
Parent ID:  #25925   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gaba):

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


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

Re: [tor-bugs] #29617 [Core Tor/Tor]: OOM manger wipes entire DNS cache

[Tor Bug Tracker & Wiki]

#29617: OOM manger wipes entire DNS cache
--+
 Reporter:  pulls |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.0.2-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by pulls):

 * version:   => Tor: 0.4.0.2-alpha
 * component:  - Select a component => Core Tor/Tor


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

[tor-bugs] #29618 [Core Tor/Chutney]: Chutney doesn't use python3 if a "python2" binary exists, and fails if it uses python3 anyway.

[Tor Bug Tracker & Wiki]

#29618: Chutney doesn't use python3 if a "python2" binary exists, and fails if 
it
uses python3 anyway.
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 In the "chutney" shell script, the search list for python binaries is:
 {{{
 binaries="python2 python"
 }}}

 This means that even if python3 is installed as "python", chutney will use
 python2 instead.

 This mistake has led us to accumulate a bunch of python3
 incompatibilities.

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

Re: [tor-bugs] #29618 [Core Tor/Chutney]: Chutney doesn't use python3 if a "python2" binary exists, and fails if it uses python3 anyway.

[Tor Bug Tracker & Wiki]

#29618: Chutney doesn't use python3 if a "python2" binary exists, and fails if 
it
uses python3 anyway.
--+--
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Very High |  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * status:  new => needs_review


Comment:

 See branch bug29618

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

Re: [tor-bugs] #27912 [Core Tor/Chutney]: Add travis CI for the Chutney repository

[Tor Bug Tracker & Wiki]

#27912: Add travis CI for the Chutney repository
--+--
 Reporter:  nickm |  Owner:  teor
 Type:  enhancement   | Status:  needs_review
 Priority:  High  |  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #20647| Points:  0.5
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 I've updated the branch as 'chutney-travis-v2'.  It won't work without the
 fixes for #29618, though.

 Here is a PR for a branch containing both sets of fixes:
 https://github.com/torproject/chutney/pull/3

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

Re: [tor-bugs] #28848 [Obfuscation/Snowflake]: Document Snowflake broker implementation

[Tor Bug Tracker & Wiki]

#28848: Document Snowflake broker implementation
-+-
 Reporter:  ahf  |  Owner:  ahf
 Type:  project  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Snowflake|Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, tor-pt, network-team- |  Actual Points:  3
  roadmap-2019-Q1Q2  |
Parent ID:   | Points:  8
 Reviewer:  cohosh, arma |Sponsor:
 |  Sponsor19
-+-
Changes (by ahf):

 * actualpoints:  2 => 3


Comment:

 I think I've fixed all the issues listed above with an exception of the
 following:

 - I've not specified that we require requests to be either POST/GET since
 it seems like the broker don't care, but in the client/proxy code we do
 specify it to use POST most of the time. I think if we begin to enforce
 this we should specify it.
 - I've left out command line options for now, since I think they are more
 of a implementation detail?

 Let me know what you think.

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

[tor-bugs] #29619 [Webpages/Blog]: Add comment policy to the blog

[Tor Bug Tracker & Wiki]

#29619: Add comment policy to the blog
---+--
 Reporter:  steph  |  Owner:  hiro
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 Add a comment policy to the blog above the comment field so it'll be
 visible on each post beneath "Join the discussion."

 Note: only "join the discussion" remains visible from the blog archive.
 The new text is only visible inside each post.

 "Join the discussion...

 We encourage respectful, on-topic comments. Comments that violate our
 [https://gitweb.torproject.org/community/policies.git/tree/code_of_conduct.txt
 Code of Conduct] will be deleted. Off-topic comments may be deleted at the
 discretion of the post moderator. Please do not comment as a way to
 receive support or report bugs on a post unrelated to a release. If you
 are looking for support, please see our [https://support.torproject.org/
 support portal] or ways to
 
[https://trac.torproject.org/projects/tor/wiki/doc/community/HowToReportBugFeedback
 get in touch with us].

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

Re: [tor-bugs] #28848 [Obfuscation/Snowflake]: Document Snowflake broker implementation

[Tor Bug Tracker & Wiki]

#28848: Document Snowflake broker implementation
-+-
 Reporter:  ahf  |  Owner:  ahf
 Type:  project  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Snowflake|Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, tor-pt, network-team- |  Actual Points:  3
  roadmap-2019-Q1Q2  |
Parent ID:   | Points:  8
 Reviewer:  cohosh, arma |Sponsor:
 |  Sponsor19
-+-
Changes (by cohosh):

 * status:  needs_review => merge_ready


Comment:

 It looks good, thanks!

 >I've not specified that we require requests to be either POST/GET since
 it seems like the broker don't >care, but in the client/proxy code we do
 specify it to use POST most of the time. I think if we begin >to enforce
 this we should specify it.
 Sounds good.
 >I've left out command line options for now, since I think they are more
 of a implementation detail?
 Good point, agreed.

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

Re: [tor-bugs] #29562 [Core Tor/Tor]: APPCRASH of tor.exe on Windows when PT bootstrap is cancelled

[Tor Bug Tracker & Wiki]

#29562: APPCRASH of tor.exe on Windows when PT bootstrap is cancelled
-+-
 Reporter:  dcf  |  Owner:  ahf
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.0.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  regression 040-must crash nickm- |  Actual Points:  0.3
  merge  |
Parent ID:   | Points:  0.3
 Reviewer:  dgoulet  |Sponsor:
-+-

Old description:

> * [https://www.torproject.org/dist/torbrowser/8.5a8/torbrowser-install-
> win64-8.5a8_en-US.exe Tor Browser 8.5a8 64-bit]
>  * tor 0.4.0.1-alpha 81f2b89efc94723f
>  * Windows 7
>
> Start Tor Browser, click Configure, then select a pluggable transport (I
> tried both obfs4 and meek-azure). While bootstrapping is in progress,
> click Cancel. tor.exe crashes with the log:
> {{{
> [ERR] tor_assertion_failed_(): Bug: process.c:522:
> process_get_win32_process: Assertion process->win32_process failed;
> aborting. (on Tor 0.4.0.1-alpha 81f1b89efc94723f)
> [ERR] Bug: Assertion process->win32_process failed in
> process_get_win32_process at process.c:522. (Stack trace not available)
> (on Tor 0.4.0.1-alpha 81f1b89efc94723f)
> }}}
>
> These dialogs appear in succession. Sometimes, the "application has
> requested the Runtime to terminate it in an unusual way" would not
> appear, and instead the "tor.exe has stopped working" would appear twice.
>
> [[Image(terminate.png)]]
>
> [[Image(stoppedworking.png)]]
>
> [[Image(exited.png)]]
>
> The "View problem details" expander shows:
> {{{
> Problem signature:
>   Problem Event Name:   APPCRASH
>   Application Name: tor.exe
>   Application Version:  0.0.0.0
>   Application Timestamp:a640a628
>   Fault Module Name:tor.exe
>   Fault Module Version: 0.0.0.0
>   Fault Module Timestamp:   a640a628
>   Exception Code:   4015
>   Exception Offset: 002c6a44
>   OS Version:   6.1.7601.2.1.0.256.48
>   Locale ID:1033
>   Additional Information 1: 869c
>   Additional Information 2: 869c6822c6babdacb5663a19facccafb
>   Additional Information 3: 607b
>   Additional Information 4: 607bd60f513aeecf36fa5e247b547f57
> }}}
>
> Here are tor logs from different runs. One of them mentions a clock skew,
> but that seems to be a problem with the remote system. I checked and the
> time on the local Windows host was correct.
>
> {{{
> 2/23/19, 08:42:06.326 [NOTICE] DisableNetwork is set. Tor will not make
> or accept non-control network connections. Shutting down all existing
> connections.
> 2/23/19, 08:42:09.765 [NOTICE] DisableNetwork is set. Tor will not make
> or accept non-control network connections. Shutting down all existing
> connections.
> 2/23/19, 08:42:09.765 [NOTICE] Switching to guard context "default" (was
> using "bridges")
> 2/23/19, 08:42:09.765 [NOTICE] DisableNetwork is set. Tor will not make
> or accept non-control network connections. Shutting down all existing
> connections.
> 2/23/19, 08:42:09.765 [NOTICE] DisableNetwork is set. Tor will not make
> or accept non-control network connections. Shutting down all existing
> connections.
> 2/23/19, 08:42:09.765 [NOTICE] Opening Socks listener on 127.0.0.1:9150
> 2/23/19, 08:42:09.765 [NOTICE] Opened Socks listener on 127.0.0.1:9150
> 2/23/19, 08:42:10.224 [WARN] Managed proxy at
> 'TorBrowser\Tor\PluggableTransports\terminateprocess-buffer.exe'
> reported: 2019/02/23 08:42:09 running firefox command
> ["C:\\Users\\david\\Desktop\\Tor Browser\\Browser\\firefox.exe" "--
> invisible" "-no-remote" "-profile" "C:\\Users\\david\\Desktop\\Tor
> Browser\\Browser\\TorBrowser\\Data\\Browser\\profile.meek-http-helper"]
> 2/23/19, 08:42:10.224 [WARN] Managed proxy at
> 'TorBrowser\Tor\PluggableTransports\terminateprocess-buffer.exe'
> reported: 2019/02/23 08:42:09 firefox started with pid 3552
> 2/23/19, 08:42:10.224 [NOTICE] Bootstrapped 5% (conn): Connecting to a
> relay
> 2/23/19, 08:42:10.564 [WARN] Managed proxy at
> 'TorBrowser\Tor\PluggableTransports\terminateprocess-buffer.exe'
> reported: 2019/02/23 08:42:10 running meek-client command
> ["TorBrowser\\Tor\\PluggableTransports\\meek-client.exe" "--helper"
> "127.0.0.1:1468"]
> 2/23/19, 08:42:10.565 [WARN] Managed proxy at
> 'TorBrowser\Tor\PluggableTransports\terminateprocess-buffer.exe'
> reported: 2019/02/23 08:42:10 meek-client started with pid 4004
> 2/23/19, 08:42:10.565 [WARN] Managed proxy at
> 'TorBrowser\Tor\PluggableTransports\te

Re: [tor-bugs] #28848 [Obfuscation/Snowflake]: Document Snowflake broker implementation

[Tor Bug Tracker & Wiki]

#28848: Document Snowflake broker implementation
-+-
 Reporter:  ahf  |  Owner:  ahf
 Type:  project  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Snowflake|Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  snowflake, tor-pt, network-team- |  implemented
  roadmap-2019-Q1Q2  |  Actual Points:  3
Parent ID:   | Points:  8
 Reviewer:  cohosh, arma |Sponsor:
 |  Sponsor19
-+-
Changes (by ahf):

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


Comment:

 Thanks! All done. Closing.

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

Re: [tor-bugs] #29618 [Core Tor/Chutney]: Chutney doesn't use python3 if a "python2" binary exists, and fails if it uses python3 anyway.

[Tor Bug Tracker & Wiki]

#29618: Chutney doesn't use python3 if a "python2" binary exists, and fails if 
it
uses python3 anyway.
--+--
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Very High |  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  .3
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor19
--+--
Changes (by nickm):

 * sponsor:   => Sponsor19
 * actualpoints:   => .3


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

Re: [tor-bugs] #27912 [Core Tor/Chutney]: Add travis CI for the Chutney repository

[Tor Bug Tracker & Wiki]

#27912: Add travis CI for the Chutney repository
--+--
 Reporter:  nickm |  Owner:  teor
 Type:  enhancement   | Status:  needs_review
 Priority:  High  |  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  .5
Parent ID:  #20647| Points:  0.5
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * actualpoints:   => .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] #29611 [Applications/Tor Browser]: Work around lack of app.update.enabled pref in Firefox 63+

[Tor Bug Tracker & Wiki]

#29611: Work around lack of app.update.enabled pref in Firefox 63+
+--
 Reporter:  dcf |  Owner:  tbb-team
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  meek moat tbb-update, ff68-esr  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by dcf):

 Replying to [comment:2 gk]:
 > dcf: Is there any reason to have this merged into Tor Browser based on
 ESR 60? Otherwise I'd set the review flag to a month where we likely pick
 up patches for the esr68 transition and have us looking over it then.

 It's not needed for ESR 60. In ESR 68 it's possible to delete the
 app.update.enabled line completely.

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

Re: [tor-bugs] #29562 [Core Tor/Tor]: APPCRASH of tor.exe on Windows when PT bootstrap is cancelled

[Tor Bug Tracker & Wiki]

#29562: APPCRASH of tor.exe on Windows when PT bootstrap is cancelled
-+-
 Reporter:  dcf  |  Owner:  ahf
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.0.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  regression 040-must crash nickm- |  Actual Points:  0.3
  merge  |
Parent ID:   | Points:  0.3
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor19
-+-
Changes (by ahf):

 * sponsor:   => Sponsor19


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

Re: [tor-bugs] #29489 [Obfuscation/Snowflake]: Set up automated local testing environment for Snowflake

[Tor Bug Tracker & Wiki]

#29489: Set up automated local testing environment for Snowflake
---+-
 Reporter:  cohosh |  Owner:  cohosh
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords: |  Actual Points:
Parent ID:  #29259 | Points:
 Reviewer: |Sponsor:  Sponsor19
---+-
Changes (by ahf):

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


Comment:

 Forgot to close 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] #29489 [Obfuscation/Snowflake]: Set up automated local testing environment for Snowflake

[Tor Bug Tracker & Wiki]

#29489: Set up automated local testing environment for Snowflake
---+-
 Reporter:  cohosh |  Owner:  cohosh
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords: |  Actual Points:  3.3
Parent ID:  #29259 | Points:
 Reviewer: |Sponsor:  Sponsor19
---+-
Changes (by cohosh):

 * actualpoints:   => 3.3


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

Re: [tor-bugs] #29297 [Obfuscation/Obfsproxy]: Add any necessary metrics to verify if obfs4 is working or not

[Tor Bug Tracker & Wiki]

#29297: Add any necessary metrics to verify if obfs4 is working or not
---+---
 Reporter:  chelseakomlo   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Obfsproxy  |Version:
 Severity:  Normal | Resolution:
 Keywords:  obfs4  |  Actual Points:
Parent ID:  #29279 | Points:  2
 Reviewer: |Sponsor:  Sponsor19
---+---
Changes (by gaba):

 * points:   => 2
 * actualpoints:  2 =>


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

Re: [tor-bugs] #29594 [Obfuscation/BridgeDB]: Remove OpenSSL.rand.bytes from code

[Tor Bug Tracker & Wiki]

#29594: Remove OpenSSL.rand.bytes from code
--+--
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:  bridgedb  |  Actual Points:
Parent ID:| Points:
 Reviewer:  sysrqb|Sponsor:
--+--
Changes (by catalyst):

 * cc: catalyst (added)


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

[tor-bugs] #29620 [Core Tor/Tor]: bridge: Make tor sign the networkstatus-bridges document

[Tor Bug Tracker & Wiki]

#29620: bridge: Make tor sign the networkstatus-bridges document
--+-
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  bridgedb, authority
Actual Points:|  Parent ID:
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+-
 Turns out that `networkstatus-bridges` document, when dumped on disk on
 the Bridge Authority side, is not signed.

 This means that when it is pushed to BridgeDB, the only trust anchor we
 have is the SSH key thus making BridgeDB unable to verify the received
 document signature that it was indeed signed by the authority.

 For now, it is "OK" that we do that because the configured SSH key between
 the authority and BridgeDB has a pinned IP address to it so an attacker
 would need to steal that key _and_ push descriptors from that IP which is
 somehow already a lot.

 Regardless, adding the signature is something quite cheap that tor can do
 which  would allow BridgeDB an extra validation there instead of relying
 solely on the SSH tunnel.

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

Re: [tor-bugs] #29276 [Obfuscation/BridgeDB]: Make a release of BridgeDB

[Tor Bug Tracker & Wiki]

#29276: Make a release of BridgeDB
--+
 Reporter:  ahf   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  5
 Reviewer:|Sponsor:
--+

Comment (by catalyst):

 dgoulet says we should update the requirements.txt to the latest available
 versions, which means fixing #29594 first.

 (Do we pin the updated versions, or leave them unpinned?)

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

Re: [tor-bugs] #29594 [Obfuscation/BridgeDB]: Remove OpenSSL.rand.bytes from code

[Tor Bug Tracker & Wiki]

#29594: Remove OpenSSL.rand.bytes from code
--+--
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:  bridgedb  |  Actual Points:
Parent ID:  #29276| Points:
 Reviewer:  sysrqb|Sponsor:
--+--
Changes (by catalyst):

 * parent:   => #29276


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

Re: [tor-bugs] #29276 [Obfuscation/BridgeDB]: Make a release of BridgeDB

[Tor Bug Tracker & Wiki]

#29276: Make a release of BridgeDB
--+--
 Reporter:  ahf   |  Owner:  catalyst
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  5
 Reviewer:|Sponsor:
--+--
Changes (by catalyst):

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


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

Re: [tor-bugs] #29620 [Core Tor/Tor]: bridge: Make tor sign the networkstatus-bridges document

[Tor Bug Tracker & Wiki]

#29620: bridge: Make tor sign the networkstatus-bridges document
-+--
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bridgedb, authority  |  Actual Points:
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+--

Comment (by sysrqb):

 (see #12254 for some more details and thought on this topic, too)

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

Re: [tor-bugs] #29620 [Core Tor/Tor]: bridge: Make tor sign the networkstatus-bridges document

[Tor Bug Tracker & Wiki]

#29620: bridge: Make tor sign the networkstatus-bridges document
-+--
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  duplicate
 Keywords:  bridgedb, authority  |  Actual Points:
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+--
Changes (by dgoulet):

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


Comment:

 Oh wow... total duplicate! Closing this one in favor of #12254. Good catch
 sysrqb!

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

Re: [tor-bugs] #29570 [Core Tor/Tor]: Enforce mutually exclusive logic for IPv6 ORPort flags

[Tor Bug Tracker & Wiki]

#29570: Enforce mutually exclusive logic for IPv6 ORPort flags
---+---
 Reporter:  s7r|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:  Tor:
   |  unspecified
 Severity:  Normal | Resolution:
 Keywords:  tor-relay, ipv6, reachability  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by s7r):

 Replying to [comment:4 AVee]:
 > I'm not sure there is a bug here. As per
 https://lists.torproject.org/pipermail/tor-
 relays/2019-February/016994.html it seems this setup is actually working.
 >

 Negative.
 This rare setup is working because the IPv6 address is assigned to a
 HAProxy daemon, which translates it to IPv4 and forwards it to the IPv4
 address behind NAT, where is also the ORPort 0.0.0.0 listening.

 This is of course transparent to the directory authorities since HAProxy
 handles the conversion from v6 to v4 they can't know that the relay there
 is not actually listening on a v6 address.

 But this does not mean the bug doesn't exist. It's possible with current
 ticket not fixed to only state a v6 address to advertise, and NONE to
 listen, which is not good.

 And the action should be to exit as loud and as fast as possible as teor
 says.

 > I fully agree that IPv6 is intended to provide end to end connectivity,
 but in practice there are a number of ways (and reasons) for network
 traffic to move from IPv4 to IPv6 and vice-versa. This setup is one of
 just them. While this case runs counter to what IPv6 intends to achieve,
 it does work... Moreover, a relay in an IPv6 only network that is through
 router tricks still reachable on a IPv4 address seems a sensible case to
 me.
 >
 > The assumption here seems to be that IPv4 and IPv6 are strictly separate
 worlds, but they are not. Therefore I'd be inclined to say pretty much
 anything advertised could be valid because pretty much anything can be
 made to work at network level and it's impossible for Tor to know about
 that. Isn't that why connectivity testing is done?

 They are separate worlds actually, totally separate. But there were some
 solutions engineered to make transition from v4 easier and faster and to
 allow existent v4 network to adopt v6 without rebuilding from 0.

 Again, of course whatever relay operators choose to do at their network
 level does not concern us, as long as the relay is reachable and can be
 used. Like in this case, the bug is not that this particular operator
 chose to use HAProxy to translate v6 traffic to v4 and forward it to the
 NAT IPv4 address - regardless this is not recommended - this does not
 affect Tor.

 The bug is that you can build a descriptor with an address from a class
 (v6 class) when you are not listening on any address of that class, at
 all. This opens the door for many mistaken setups, and also fills
 descriptors with useless data that make directory authorities chase green
 horses.

 >
 > I'm not sufficiently into the internals of Tor to know if anything there
 may prevent any of this from working. But in that case I might even argue
 that's actually a bug.
 >
 > (A warning like 'You are advertising IPv''X'' but not listening there'
 would still be useful for troubleshooting.)

 As stated above, it is preferred to exit as fast as possible on such
 misconfigurations. There are such warnings for mismatches when you listen
 on something and advertise something else, but such a warning cannot work
 in this ticket because it breaks logic:

 The correct message here should be "You are advertising IPv6 address
 : but you are not listening on ANY IPv6 address" -- this is
 irrational because this shouldn't be possible in the first place.

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

Re: [tor-bugs] #29570 [Core Tor/Tor]: Enforce mutually exclusive logic for IPv6 ORPort flags

[Tor Bug Tracker & Wiki]

#29570: Enforce mutually exclusive logic for IPv6 ORPort flags
---+---
 Reporter:  s7r|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:  Tor:
   |  unspecified
 Severity:  Normal | Resolution:
 Keywords:  tor-relay, ipv6, reachability  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by s7r):

 In this particular case, if only `ORPort 0.0.0.0:9050` was set, and it was
 just HAProxy that listened on the IPv6 address and forwarded to the NAT
 IPv4 address ORPort, while indeed strange and not recommended, would be
 totally transparent to Tor / directory authorities and would of course not
 be a bug.

 But if you can have only a line: `ORPort [ipv6:address]:9050 NoListen` and
 no following IPv6 ORPort with NoAdvertise, this is a bug as in config
 parameters are not properly sanitized.

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

Re: [tor-bugs] #29570 [Core Tor/Tor]: Enforce mutually exclusive logic for IPv6 ORPort flags

[Tor Bug Tracker & Wiki]

#29570: Enforce mutually exclusive logic for IPv6 ORPort flags
---+---
 Reporter:  s7r|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:  Tor:
   |  unspecified
 Severity:  Normal | Resolution:
 Keywords:  tor-relay, ipv6, reachability  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by s7r):

 The right solution to achieve such tunneled / encapsulated setups is to
 have another torrc parameter `Advertise6to4OrportAddress :` that will tell Tor to include this IPv6 address in the
 descriptor without binding to any IPv6 address because traffic to that
 IPv6 address : port is translated to v4 and forwarded to the IPv4 ORPort.
 At least this is the way it would make sense to me, but more opinions
 required 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] #29120 [Applications/Tor Browser]: Default value of media.cache_size (0) causes some media to load extremely slowly or become unplayable

[Tor Bug Tracker & Wiki]

#29120: Default value of media.cache_size (0) causes some media to load 
extremely
slowly or become unplayable
-+-
 Reporter:  QZw2aBQoPyuEVXYVlBps |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-disk-leak, tbb-usability-|  Actual Points:
  website, TorBrowserTeam201902  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by QZw2aBQoPyuEVXYVlBps):

 Here's the patch with the parentheses 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] #29120 [Applications/Tor Browser]: Default value of media.cache_size (0) causes some media to load extremely slowly or become unplayable

[Tor Bug Tracker & Wiki]

#29120: Default value of media.cache_size (0) causes some media to load 
extremely
slowly or become unplayable
-+-
 Reporter:  QZw2aBQoPyuEVXYVlBps |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-disk-leak, tbb-usability-|  Actual Points:
  website, TorBrowserTeam201902  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by QZw2aBQoPyuEVXYVlBps):

 * Attachment "MemoryMediaCache5.patch" added.


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

Re: [tor-bugs] #29064 [Core Tor/Tor]: shellcheck: test_rust.sh issues

[Tor Bug Tracker & Wiki]

#29064: shellcheck: test_rust.sh issues
+
 Reporter:  rl1987  |  Owner:  rl1987
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  catalyst|Sponsor:
+
Changes (by catalyst):

 * status:  needs_review => merge_ready


Comment:

 Looks good by visual inspection.  I'll trust the CI on 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] #29073 [Core Tor/Tor]: shellcheck: linux-tor-prio.sh issues

[Tor Bug Tracker & Wiki]

#29073: shellcheck: linux-tor-prio.sh issues
--+
 Reporter:  rl1987|  Owner:  rl1987
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  catalyst  |Sponsor:
--+
Changes (by catalyst):

 * status:  needs_review => needs_revision


Comment:

 Looks good by visual inspection. Please split the formatting change into a
 separate commit, as noted on github. I'll try to see if anyone is willing
 to test 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] #29621 [Core Tor]: Systemd Tor service starts too early

[Tor Bug Tracker & Wiki]

#29621: Systemd Tor service starts too early
---+--
 Reporter:  tomreyn|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Low|  Component:  Core Tor
  Version:  Tor: 0.3.5.8   |   Severity:  Minor
 Keywords:  systemd packaging  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 **Defect description:**
 Tor 0.3.5.8 (.deb packages from deb.torproject.org) on Ubuntu 18.04 amd64
 (systemd), starts too early during the boot process, (reproducibly)
 resulting in "Problem bootstrapping" messages:

 {{{
 $ journalctl --utc -b | sed -e 's/'$HOSTNAME'/myhostname/' -e 's/
 Tor[\[0-9\]*]/ Tor[1234]/' | grep 'myhostname Tor'
 Feb 28 17:17:42 myhostname Tor[1234]: Tor 0.3.5.8 running on Linux with
 Libevent 2.1.8-stable, OpenSSL 1.1.0g, Zlib 1.2.11, Liblzma 5.2.2, and
 Libzstd 1.3.3.
 Feb 28 17:17:42 myhostname Tor[1234]: Tor can't help you if you use it
 wrong! Learn how to be safe at
 https://www.torproject.org/download/download#warning
 Feb 28 17:17:42 myhostname Tor[1234]: Read configuration file
 "/usr/share/tor/tor-service-defaults-torrc".
 Feb 28 17:17:42 myhostname Tor[1234]: Read configuration file
 "/etc/tor/torrc".
 Feb 28 17:17:42 myhostname Tor[1234]: Opening Socks listener on
 127.0.0.1:9050
 Feb 28 17:17:42 myhostname Tor[1234]: Opened Socks listener on
 127.0.0.1:9050
 Feb 28 17:17:42 myhostname Tor[1234]: Parsing GEOIP IPv4 file
 /usr/share/tor/geoip.
 Feb 28 17:17:42 myhostname Tor[1234]: Parsing GEOIP IPv6 file
 /usr/share/tor/geoip6.
 Feb 28 17:17:42 myhostname Tor[1234]: Bootstrapped 0%: Starting
 Feb 28 17:17:43 myhostname Tor[1234]: Starting with guard context
 "default"
 Feb 28 17:17:43 myhostname Tor[1234]: Signaled readiness to systemd
 Feb 28 17:17:43 myhostname Tor[1234]: Problem bootstrapping. Stuck at 0%:
 Starting. (Network is unreachable; NOROUTE; count 1; recommendation warn;
 host A59B27226496443A93D25E8D87BFCB8ADEDB4862 at 51.75.125.233:9001)
 Feb 28 17:17:43 myhostname Tor[1234]: Opening Socks listener on
 /run/tor/socks
 Feb 28 17:17:43 myhostname Tor[1234]: Opened Socks listener on
 /run/tor/socks
 Feb 28 17:17:43 myhostname Tor[1234]: Opening Control listener on
 /run/tor/control
 Feb 28 17:17:43 myhostname Tor[1234]: Opened Control listener on
 /run/tor/control
 Feb 28 17:17:43 myhostname Tor[1234]: Bootstrapped 5%: Connecting to
 directory server
 Feb 28 17:17:43 myhostname Tor[1234]: Problem bootstrapping. Stuck at 5%:
 Connecting to directory server. (Network is unreachable; NOROUTE; count 2;
 recommendation warn; host 617314F0CD8B8EA76B4963AC6C6BA3773DA63594 at
 144.76.91.135:9001)
 Feb 28 17:17:43 myhostname Tor[1234]: Problem bootstrapping. Stuck at 5%:
 Connecting to directory server. (Network is unreachable; NOROUTE; count 3;
 recommendation warn; host A0F39D32028CEC7F35419E9570401DE15B1B4564 at
 5.196.58.96:9001)
 Feb 28 17:17:44 myhostname Tor[1234]: Problem bootstrapping. Stuck at 5%:
 Connecting to directory server. (Network is unreachable; NOROUTE; count 4;
 recommendation warn; host BCC9FA5994200032E9CD04866B823B6D929F22A8 at
 78.31.65.92:443)
 Feb 28 17:17:45 myhostname Tor[1234]: Bootstrapped 10%: Finishing
 handshake with directory server
 Feb 28 17:17:45 myhostname Tor[1234]: Bootstrapped 80%: Connecting to the
 Tor network
 Feb 28 17:17:45 myhostname Tor[1234]: Bootstrapped 90%: Establishing a Tor
 circuit
 Feb 28 17:17:47 myhostname Tor[1234]: Bootstrapped 100%: Done
 }}}

 **Impact:**
 As seen, Tor does finally bootstrap successfully, and functionality is not
 impacted.

 **Correction:**
 This issue appears to be caused by imperfect service dependencies as set
 in /lib/systemd/system/tor@.service and
 /lib/systemd/system/tor@default.service:

 {{{
 [Unit]
 After=network.target nss-lookup.target
 }}}

 My interpretation of the
 [https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ systemd
 documentation] is that this should correctly say:
 {{{
 [Unit]
 After=network-online.target nss-lookup.target
 Want=network-online.target nss-lookup.target
 }}}

 I suspect that using "network-online.target" (instead of "network.target")
 may also allow for removing the "nss-lookup.target" dependency, but have
 not attempted to verify this.

 **Related:**
 * [ticket:25803#comment:6 Ticket #25803 "Infinite restart loop when daemon
 crashes", comment 6]
 * [ticket:20930 Ticket #20930 "Use new systemd hardening options"]

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

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

[Tor Bug Tracker & Wiki]

#29144: Log the correct "auto" port number for listening sockets
--+
 Reporter:  kjak  |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  041-proposed  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:  catalyst  |Sponsor:
--+
Changes (by catalyst):

 * status:  needs_review => merge_ready


Comment:

 Looks good to me!  I did a quick manual test with `ControlPort auto` and
 confirmed that the log message read as expected with a non-zero port
 number.

 Note for whoever merges this: the pull request is based on master, but
 looks like it cherry-picks cleanly to 0.3.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] #29144 [Core Tor/Tor]: Log the correct "auto" port number for listening sockets

[Tor Bug Tracker & Wiki]

#29144: Log the correct "auto" port number for listening sockets
--+
 Reporter:  kjak  |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  041-proposed  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:  catalyst  |Sponsor:
--+

Comment (by dgoulet):

 Replying to [comment:5 catalyst]:
 > Note for whoever merges this: the pull request is based on master, but
 looks like it cherry-picks cleanly to 0.3.5.

 Not sure this qualifies for a backport as the log are at notice level. You
 think it 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] #29108 [Core Tor/Tor]: Refactor crypto_digest.c to have fewer ifdefs

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:2 rl1987]:
 > https://github.com/torproject/tor/pull/657
 >
 > I could try unifying this patch with #28837, if that's needed.
 Thanks, if you could please resolve the current merge conflict, that would
 be great! Feel free to force-push the pull request branch this time.

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

Re: [tor-bugs] #28656 [Core Tor/Tor]: Bug: src/feature/nodelist/nodelist.c:2501: compute_frac_paths_available : Non-fatal assertion !(f_exit > 0.0) failed.

[Tor Bug Tracker & Wiki]

#28656: Bug: src/feature/nodelist/nodelist.c:2501: compute_frac_paths_available 
:
Non-fatal assertion !(f_exit > 0.0) failed.
-+-
 Reporter:  meejah   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, 035-rc-blocker?, |  Actual Points:
  034-backport, 035-backport, postfreeze-ok, |
  040-must   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by meejah):

 * Attachment "logs-info.txt.gz" added.

 INFO level logs from a different run showing the bug

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

Re: [tor-bugs] #28656 [Core Tor/Tor]: Bug: src/feature/nodelist/nodelist.c:2501: compute_frac_paths_available : Non-fatal assertion !(f_exit > 0.0) failed.

[Tor Bug Tracker & Wiki]

#28656: Bug: src/feature/nodelist/nodelist.c:2501: compute_frac_paths_available 
:
Non-fatal assertion !(f_exit > 0.0) failed.
-+-
 Reporter:  meejah   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, 035-rc-blocker?, |  Actual Points:
  034-backport, 035-backport, postfreeze-ok, |
  040-must   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by meejah):

 I added some logs from a different run that exhibited this bug. The Tor
 had been idle for some time before I noticed the bug. Running version
 39a104993

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

Re: [tor-bugs] #26288 [Core Tor/Tor]: prop289: Implement authenticated SENDME

[Tor Bug Tracker & Wiki]

#26288: prop289: Implement authenticated SENDME
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop289, 035-roadmap-master, 035 |  Actual Points:
  -triaged-in-20180711, prop289-assigned-|
  sponsor-v, 041-proposed-on-roadmap, network-   |
  team-roadmap-2019-Q1Q2 |
Parent ID:   | Points:  21
 Reviewer:  nickm|Sponsor:
 |  SponsorV
-+-

Comment (by teor):

 Replying to [comment:20 dgoulet]:
 > Replying to [comment:19 teor]:
 > > I reviewed the protocol parts of this patch:
 > >
 > > Phase 3 of the transition plan requires old clients and relays to
 download a consensus so they learn that they should stop trying to connect
 to the network. But since 0.2.8, clients (and censored relays that can't
 access any DirPorts) will try to use the ORPort to download a consensus.
 But ORPort circuits from legacy clients will fail during phase 3.
 >
 > This is what the new protover version is all about. We would flip
 `FlowCtrl=1` _before_ the consensus param `sendme_accept_min_version=1` is
 set. This would effectively exit() every clients/relays that can't support
 v1.

 You're right, old clients and relays that download a consensus while
 FlowCtrl=1 is required, and while v1 sendmes are accepted, will cache that
 consensus. Then they will refuse to connect to the network as long as they
 have that cached consensus.

 But when we start rejecting v1 sendmes, old clients will fail to download
 a consensus. (Most old relays will still be able to fetch consensuses,
 because they use DirPorts.) These old clients may be new installs of an
 old version, clients or relays which clear their data directories, or
 clients that are only launched occasionally.

 How will we handle them?
 We'll shut down most old clients that are already installed. Is that
 enough?
 How much time do we need between setting the protocol version requirement,
 and rejecting v1 sendmes?

 What will an old client do if we reject its sendmes?
 How many old clients will it take to bring down the network?
 Do we need to keep testing old clients without a cached consensus, but
 with v1 sendmes rejected?

 We need to talk about these issues in the proposal.

 > Then we can enforce *only* accepting v1 through the consensus (if that
 param is needed at all).
 >
 > >
 > > Here's what I think we need to do:
 > > 1. always allow legacy sendmes for BEGINDIR for the consensus, and
 everything that is required to validate a consensus:
 > >   * authority certificates,
 > >   * relay descriptors (for bridge clients),
 > >   * anything else?
 >
 > I'm quite reluctant to keep legacy SENDMEs even when the protover
 _and_/_or_ the consensus param is flipped. The whole point of that
 protover is that we don't have to deal with clients not supporting v1. And
 we can NOT flip the "min accept" param before that protover.

 I agree: having to keep legacy code is a really bad outcome.

 > > 3. Don't remove the section about extensive testing using chutney:
 > > {{{
 > > -   We'll want to do a bunch of testing in chutney before flipping the
 > > -   switches in the real network: I've long suspected we still have
 bugs
 > > -   in our sendme timing, and this proposal might expose some of them.
 > > }}}
 > > 4. Do the chutney tests now, and do them again when we want to
 implement each phase on the public network
 >
 > I don't see the point of that in a proposal to be honest. Chutney tests
 have been done extensively to develop that branch so I'm not sure what
 this (4) is about here?...

 Future Tor changes can break our transition plans.

 > Any switch we flip in the consensus, especially something like this,
 needs to be tested a lot. Not doing so is a bit reckless on our part and I
 doubt having it in the proposal saying "we need to test this" is useful at
 all...
 >
 > What I recommend we do is actually describe the "ordering" of all the
 pieces in the transition plan. And then document what we should NOT do so
 in 10 years, we have a reminder of what to do (because I don't see Phase 3
 being done until many years!).

 You're right, writing it down doesn't help that much.

 Here's one way to regularly test future transition plans:

 1. We write a script that runs chutney tests that test each part of the
 transition plan, for o

Re: [tor-bugs] #29541 [Core Tor/Tor]: Re-enable util/mmap_anon_no_fork

[Tor Bug Tracker & Wiki]

#29541: Re-enable util/mmap_anon_no_fork
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop289, prop289-assigned-   |  Actual Points:
  sponsor-v, 041-proposed-on-roadmap, network-   |
  team-roadmap-2019-Q1Q2 |
Parent ID:  #26288   | Points:
 Reviewer:  mikeperry|Sponsor:
-+-
Changes (by teor):

 * keywords:  041-proposed-on-roadmap, network-team-roadmap-2019-Q1Q2 =>
 prop289, prop289-assigned-sponsor-v, 041-proposed-on-roadmap, network-
 team-roadmap-2019-Q1Q2
 * parent:   => #26288


Comment:

 Restoring prop289

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

Re: [tor-bugs] #29576 [Applications/Tor Browser]: Tor Browser won't start

[Tor Bug Tracker & Wiki]

#29576: Tor Browser won't start
--+---
 Reporter:  thelamper |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by thelamper):

 Can you tell me what you mean by 'signing the exes'? 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] #29586 [Core Tor/Tor]: Intermittent test failures in relay/close_circ_rephist

[Tor Bug Tracker & Wiki]

#29586: Intermittent test failures in relay/close_circ_rephist
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.2-alpha
 Severity:  Normal| Resolution:  not a bug
 Keywords:  tor-ci, tor-test  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by teor):

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


Comment:

 We think this issue happened due to a clock change during the test run. If
 it happens again, we can reopen 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] #29585 [Core Tor/Tor]: Intermittent test failures in dir/dirserv_read_measured_bandwidths

[Tor Bug Tracker & Wiki]

#29585: Intermittent test failures in dir/dirserv_read_measured_bandwidths
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:  Tor:
  |  unspecified
 Severity:  Normal| Resolution:  not a bug
 Keywords:  tor-ci, tor-test, tor-bwauth  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by teor):

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


Comment:

 We think this issue happened due to a clock change during the test run. If
 it happens again, we can reopen 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] #29541 [Core Tor/Tor]: Re-enable util/mmap_anon_no_fork

[Tor Bug Tracker & Wiki]

#29541: Re-enable util/mmap_anon_no_fork
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop289, prop289-assigned-   |  Actual Points:
  sponsor-v, 041-proposed-on-roadmap, network-   |
  team-roadmap-2019-Q1Q2 |
Parent ID:  #26288   | Points:
 Reviewer:  mikeperry|Sponsor:
-+-

Comment (by teor):

 Replying to [comment:4 nickm]:
 > I really don't see how this test bug could have affected those tests...
 but the world has been known to do things that I do not expect.  If they
 happen one time in ten, maybe checking to see whether this fix fixes them
 too might be reasonable.

 To be clear, #29585 and #29586 happened once. And then they haven't
 happened again. I think they may have happened due to a clock change
 during the test run. If they happen again, we can reopen those tickets.

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

Re: [tor-bugs] #29616 [Core Tor/Tor]: Git scripts should fetch once only.

[Tor Bug Tracker & Wiki]

#29616: Git scripts should fetch once only.
--+--
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  git-scripts   |  Actual Points:
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:
--+--
Changes (by teor):

 * status:  needs_review => needs_revision
 * reviewer:   => teor


Comment:

 These merges need to be fast-forward-only merges, using `git merge --ff-
 only`.

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

Re: [tor-bugs] #29196 [Core Tor/Tor]: circ: Remove p_mux and n_mux from circuit_t and or_circuit_t

[Tor Bug Tracker & Wiki]

#29196: circ: Remove p_mux and n_mux from circuit_t and or_circuit_t
---+
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-cmux, tor-circuit  |  Actual Points:
Parent ID: | Points:
 Reviewer:  catalyst   |Sponsor:
---+
Changes (by catalyst):

 * status:  needs_review => needs_information


Comment:

 This ticket says it targets 0.4.1 but the branch seems based on 0.4.0 (and
 has no pull request?). I'm not sure, which target branch is intended?

 The code changes look good by visual inspection, and when I pushed the
 branch to my github, the only Travis failure was from the Cargo.lock issue
 that might already be fixed in master.

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

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

[Tor Bug Tracker & Wiki]

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

 * keywords:  041-proposed => 041-proposed, 035-backport, 040-backport


Comment:

 In general, we are backporting ux issues to 0.3.5, including logging
 issues.
 This issue is a minor source code change that is very low risk, so I will
 backport it to 0.3.5.

 Please cherry-pick to maint-0.3.5 before merging to 0.4.0 and master.
 Then I will backport it some time after the mainline CI passes.

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  merge_ready => needs_revision


Comment:

 Actually, I will do the cherry-pick, because our draft merge policy says:
 {{{
  * For patch quality: We should make sure that every commit to Tor is
 reviewed and double-checked for conformance.

 …

 4. What patches can be merged without review?

 The following items do not need a reviewer or a separate merger:

 Putting out releases:
* Creating the ChangeLog and ReleaseNotes
* Bumping the version number
* Creating a signed tag

 Typo fixes in comments.
 }}}

 But it seems redundant to require someone to do the cherry-pick, someone
 else to review it, and then a third person to merge. We could probably get
 away with 2 people.

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_revision => needs_review


Comment:

 The 0.3.5 cherry-pick is:
 https://github.com/torproject/tor/pull/745

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

Re: [tor-bugs] #29555 [Applications/Tor Browser]: Tor unexpectedly exited. this may be do to a Tor Bug, etc

[Tor Bug Tracker & Wiki]

#29555: Tor unexpectedly exited. this may be do to a Tor Bug, etc
--+---
 Reporter:  FMCfmc|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  exited|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by FMCfmc):

 Windows 10 64 bit,
 downloaded Tor from Tor Site
 downloaded March 18 2018 can not tell version
 has always worked until last week or so
 Reinstalled and does not work
 I do not know if any Tor.exe or Firefox.exe is running in the background

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