Re: [tor-bugs] #26381 [Applications/Tor Browser]: about:tor page does not load on first start on Windows and browser is stuck in endless reload cycle

[Tor Bug Tracker & Wiki]

#26381: about:tor page does not load on first start on Windows and browser is 
stuck
in endless reload cycle
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton, ff60-esr, |  Actual Points:
  TorBrowserTeam201808   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-torbutton, ff60-esr, TorBrowserTeam201808R => tbb-
 torbutton, ff60-esr, TorBrowserTeam201808


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

Re: [tor-bugs] #27061 [Applications/Tor Browser]: Enable verification of langpacks checksums

[Tor Bug Tracker & Wiki]

#27061: Enable verification of langpacks checksums
+--
 Reporter:  boklm   |  Owner:  tbb-team
 Type:  task| Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tbb-rbm, TorBrowserTeam201808R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

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


Comment:

 Replying to [comment:4 gk]:
 > Replying to [comment:2 sukhbir]:
 > > Review:
 > >
 > > https://github.com/azadi/tor-browser-build-1/tree/bug-27061
 > >
 > > Note: this modifies only `firefox-langpacks` and does not set the
 `firefox_platform_version`. Let me know if it should do that as well.
 (Also this assumes 60.2 for tor-browser since that has the relevant
 patches but then again, that's not covered in this patch.)
 >
 > No, that's fine. This looks good to me. I'll apply this while we are
 switching to 60.2.0esr, thanks.

 Done with commit 7a88a4858db7fca96e126eba8fd0d0706bc36516 on `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] #27302 [Core Tor/Tor]: Duplicate votes on 0.3.4 and later

[Tor Bug Tracker & Wiki]

#27302: Duplicate votes on 0.3.4 and later
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression, 034-must  |  Actual Points:
Parent ID:  #27146| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [comment:3 teor]:
 > I looked at the logs, and there aren't actually any duplicate POSTs by
 the sending authorities. So I don't know why 0.3.4 authorities log this
 message.

 Hint: Part of the process of making sure we've got all the votes is that
 we fetch missing votes from other dir auths. Do we just ask the others for
 all their votes? I don't remember the details.

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

Re: [tor-bugs] #27381 [Core Tor/Tor]: Bad consensus diffs on 0.3.4 and later

[Tor Bug Tracker & Wiki]

#27381: Bad consensus diffs on 0.3.4 and later
+
 Reporter:  teor|  Owner:  teor
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-auth, 034-must  |  Actual Points:
Parent ID:  #27146  | Points:
 Reviewer:  |Sponsor:
+

Comment (by arma):

 Well, that's exciting -- on the main Tor network, currently only moria1 is
 on a version past 0.3.3.x. So this seems like a good ticket to understand
 better before we ask authorities to upgrade. :)

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

Re: [tor-bugs] #27381 [Core Tor/Tor]: Bad consensus diffs on 0.3.4 and later

[Tor Bug Tracker & Wiki]

#27381: Bad consensus diffs on 0.3.4 and later
+
 Reporter:  teor|  Owner:  teor
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-auth, 034-must  |  Actual Points:
Parent ID:  #27146  | Points:
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * parent:   => #27146


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

Re: [tor-bugs] #27382 [Core Tor/Tor]: Bad valid-after time in 0.3.3 and 0.3.4

[Tor Bug Tracker & Wiki]

#27382: Bad valid-after time in 0.3.3 and 0.3.4
--+--
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-auth  |  Actual Points:
Parent ID:  #27146| Points:
 Reviewer:|Sponsor:
--+--
Changes (by teor):

 * parent:   => #27146


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

Re: [tor-bugs] #27302 [Core Tor/Tor]: Duplicate votes on 0.3.4 and later

[Tor Bug Tracker & Wiki]

#27302: Duplicate votes on 0.3.4 and later
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  regression, 034-must  |  Actual Points:
Parent ID:  #27146| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * parent:   => #27146


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

Re: [tor-bugs] #27303 [Core Tor/Chutney]: Silence duplicate vote warning in chutney

[Tor Bug Tracker & Wiki]

#27303: Silence duplicate vote warning in chutney
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #27146| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * parent:  #27302 => #27146


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

Re: [tor-bugs] #24841 [Core Tor/Tor]: Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address?

[Tor Bug Tracker & Wiki]

#24841: Your relay has a very large number of connections to other relays. Is 
your
outbound address the same as your relay address?
-+-
 Reporter:  tyng |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.8-rc
 Severity:  Normal   | Resolution:
 Keywords:  033-triage-20180320, |  Actual Points:
  033-removed-20180320   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by timkuijsten):

 Since I've been starting a couple of new relays as a new relay operator,
 this message occurs now and then in the first couple of days and it made
 me wonder[0]. If we should ignore these numbers as long as they are below
 60, then why show the message before having connected to at least 60
 relays? I would propose to crank MIN_RELAY_CONNECTIONS_TO_WARN from 5 to
 60 (but I'm completely new :)).

 [0] https://lists.torproject.org/pipermail/tor-
 relays/2018-August/016037.html

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

Re: [tor-bugs] #24841 [Core Tor/Tor]: Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address?

[Tor Bug Tracker & Wiki]

#24841: Your relay has a very large number of connections to other relays. Is 
your
outbound address the same as your relay address?
-+-
 Reporter:  tyng |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.8-rc
 Severity:  Normal   | Resolution:
 Keywords:  033-triage-20180320, |  Actual Points:
  033-removed-20180320   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by timkuijsten):

 * Attachment "avoid_useless_warning.diff" added.

 avoid useless warning for new relays

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

Re: [tor-bugs] #26769 [Core Tor/Tor]: We should make HSv3 desc upload less frequent

[Tor Bug Tracker & Wiki]

#26769: We should make HSv3 desc upload less frequent
--+
 Reporter:  asn   |  Owner:  neel
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs network-health easy hsdir  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by neel):

 * status:  new => assigned
 * cc: neel@… (added)
 * owner:  (none) => neel


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

Re: [tor-bugs] #27364 [Applications]: update ricochet to use hsv3

[Tor Bug Tracker & Wiki]

#27364: update ricochet to use hsv3
--+
 Reporter:  traumschule   |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Applications  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ricochet  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by traumschule):

 * keywords:   => ricochet


Comment:

 Adoption was the wrong word because it implies official interaction.
 Promoting it with a link is probably a good start: #16576

 Other ideas
 - #16059
 - #16203
 - [[CrowdfundingHS2015]]

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

Re: [tor-bugs] #22076 [Webpages/Website]: adjust text shown on screen based on size of text

[Tor Bug Tracker & Wiki]

#22076: adjust text shown on screen based on size of text
--+-
 Reporter:  efittery  |  Owner:  traumschule
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  WebsiteV3
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  website-bug   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by traumschule):

 * status:  new => assigned
 * owner:  hiro => traumschule
 * type:  defect => enhancement


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

Re: [tor-bugs] #23446 [Webpages/Website]: Write a guidelines documentation for requirements with Tor integration by third parties

[Tor Bug Tracker & Wiki]

#23446: Write a guidelines documentation for requirements with Tor integration 
by
third parties
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:  website redesign
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  FAQ   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by traumschule):

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


Comment:

 From my perspective this is implemented: https://www.torproject.org/docs
 /trademark-faq

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

Re: [tor-bugs] #25131 [Webpages/Website]: Sign security.txt (was: Add a security.txt file to torproject.org)

[Tor Bug Tracker & Wiki]

#25131: Sign security.txt
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  website redesign
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

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

Re: [tor-bugs] #25098 [Webpages/Website]: download warnings tell you to use a bridge so a local adversary can't learn you're a tor user

[Tor Bug Tracker & Wiki]

#25098: download warnings tell you to use a bridge so a local adversary can't 
learn
you're a tor user
--+--
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  website redesign
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:  #14686| Points:
 Reviewer:  hiro  |Sponsor:
--+--
Changes (by traumschule):

 * status:  needs_review => 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] #25038 [Webpages/Website]: Add documentation for configuring v3 onion services to website

[Tor Bug Tracker & Wiki]

#25038: Add documentation for configuring v3 onion services to website
--+---
 Reporter:  steph |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by traumschule):

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


Comment:

 #24880

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

Re: [tor-bugs] #22402 [Applications/Tor Launcher]: Usablity and accessiblity improvement on the Tor assistant page

[Tor Bug Tracker & Wiki]

#22402: Usablity and accessiblity improvement on the Tor assistant page
---+--
 Reporter:  iry|  Owner:  linda
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:  website redesign
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID:  #23266 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by traumschule):

 * component:  Webpages/Website => Applications/Tor Launcher


Comment:

 We could point to support.torproject.org now.

 > if possible the assistance URL should be a direct link

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

Re: [tor-bugs] #20045 [Webpages/Website]: FAQ + man page entry for using Tor from an IPv6 only host.

[Tor Bug Tracker & Wiki]

#20045: FAQ + man page entry for using Tor from an IPv6 only host.
---+
 Reporter:  cypherpunks|  Owner:  (none)
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Webpages/Website   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  FAQ tor-doc easy ipv6  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+
Changes (by traumschule):

 * status:  needs_review => 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] #19930 [Webpages/Website]: web site menu needlessly jumps around

[Tor Bug Tracker & Wiki]

#19930: web site menu needlessly jumps around
+-
 Reporter:  chadmiller  |  Owner:  cypherpunks
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  WebsiteV3
Component:  Webpages/Website|Version:
 Severity:  Minor   | Resolution:  fixed
 Keywords:  defer-new-website, ux-team  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by traumschule):

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


Comment:

 seems to be 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] #27347 [Webpages/Website]: Please deactivate job postings from website

[Tor Bug Tracker & Wiki]

#27347: Please deactivate job postings from website
--+
 Reporter:  ewyatt|  Owner:  (none)
 Type:  task  | Status:  closed
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by traumschule):

 * status:  needs_review => 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] #27395 [Applications/Tor Browser]: Refactor the .onion related logic in nsMixedContentBlocker.cpp

[Tor Bug Tracker & Wiki]

#27395: Refactor the .onion related logic in nsMixedContentBlocker.cpp
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 We should make our .onion related logic in nsMixedContentBlocker.cpp
 simpler. We already hit some edge case in #26561 and should try to avoid
 future issues that are related to code complexity.

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

Re: [tor-bugs] #27227 [Webpages/Website]: Please remove both PM positions from the website

[Tor Bug Tracker & Wiki]

#27227: Please remove both PM positions from the website
--+
 Reporter:  ewyatt|  Owner:  (none)
 Type:  task  | Status:  closed
 Priority:  Very High |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by traumschule):

 * status:  needs_review => 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] #27278 [Webpages/Website]: Bad Instruction Page

[Tor Bug Tracker & Wiki]

#27278: Bad Instruction Page
--+---
 Reporter:  TormanToo |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by traumschule):

 * priority:  Very High => Medium
 * status:  new => needs_information


Comment:

 after changes got merged nothings seems to be done here. waiting for an
 answer by the user if the current guide is ok or if anything is missing.

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

Re: [tor-bugs] #26561 [Applications/Tor Browser]: Onion images are not displayed

[Tor Bug Tracker & Wiki]

#26561: Onion images are not displayed
-+--
 Reporter:  akrey|  Owner:  tbb-team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff60-esr, TorBrowserTeam201808R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by gk):

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


Comment:

 Thanks. Cherry-pick to `tor-browser-60.1.0esr-8.0-1` (commit
 4f22857f926d1e35d22709a247cca0aa3f8e560f).

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

Re: [tor-bugs] #26561 [Applications/Tor Browser]: Onion images are not displayed

[Tor Bug Tracker & Wiki]

#26561: Onion images are not displayed
-+-
 Reporter:  akrey|  Owner:  tbb-team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201808R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pospeselr):

 Patch looks good to me!

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

Re: [tor-bugs] #16576 [Webpages/Website]: Add a 'community projects' list (separate page?) to the website

[Tor Bug Tracker & Wiki]

#16576: Add a 'community projects' list (separate page?) to the website
+-
 Reporter:  arma|  Owner:  traumschule
 Type:  task| Status:  assigned
 Priority:  Medium  |  Milestone:  WebsiteV3
Component:  Webpages/Website|Version:
 Severity:  Normal  | Resolution:
 Keywords:  defer-new-website, ux-team  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-
Changes (by traumschule):

 * status:  new => assigned
 * owner:  mrphs => traumschule


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

Re: [tor-bugs] #26561 [Applications/Tor Browser]: Onion images are not displayed

[Tor Bug Tracker & Wiki]

#26561: Onion images are not displayed
-+-
 Reporter:  akrey|  Owner:  tbb-team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201808R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 I think this looks good to me. Richard, could you have a second look? I
 think that's worth inclduing in 8.0 and essentially just code-moving in
 the .onion case.

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

Re: [tor-bugs] #27392 [Applications/Tor Launcher]: Moat url update

[Tor Bug Tracker & Wiki]

#27392: Moat url update
---+
 Reporter:  hiro   |  Owner:  brade
 Type:  defect | Status:  closed
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by gk):

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


Comment:

 I get a bridge, thanks! So, I wrote a patch with the URL update and
 committed it to `master` (commit
 7779e8a8dbfa81c01a2fbc3be596f851e54176ad).

 Two things, though:

 1) One gets only one bridge while in 8.0a10 one gets three. Could you
 please change that behavior? In case a user gets just one bridge and that
 is currently broken that's not so cool. :)
 2) One gets the same CAPTCHA everytime while in 8.0a10 one gets a new one
 with every request. I think we should keep that behavior.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27394 [Internal Services/Service - git]: Please delete four of my unused Git repositories and create three new ones

[Tor Bug Tracker & Wiki]

#27394: Please delete four of my unused Git repositories and create three new 
ones
-+
 Reporter:  karsten  |  Owner:  tor-gitadm
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 Please delete the following four of my user Git repositories that are
 empty and that I'm not planning to use anymore:

  - karsten/metrics-tasks
  - user/karsten/atlas
  - user/karsten/tor-animation
  - user/karsten/tor-brochure

 At the same time, please create the following three user Git repositories:

  - user/karsten/collector (Karsten's collector repository)
  - user/karsten/metrics-tasks (Karsten's metrics-tasks repository)
  - user/karsten/metrics-web (Karsten's metrics-web repository)

 As soon as my repositories karsten/metrics-db and karsten/metrics-web are
 not used anymore, I'll create another ticket to request their deletion.
 That may still take a while, though.

 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] #22637 [Webpages/Website]: Find a more maintainable approach for the signing-keys page

[Tor Bug Tracker & Wiki]

#22637: Find a more maintainable approach for the signing-keys page
--+
 Reporter:  arma  |  Owner:  traumschule
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  website
  |  redesign
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  website-content, website-bug  |  Actual Points:
Parent ID:  #3893 | Points:
 Reviewer:|Sponsor:
--+
Changes (by traumschule):

 * owner:  hiro => traumschule
 * status:  accepted => 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] #26539 [Webpages/Website]: add checksums to download page; make checksum vs. sig file purpose much clearer

[Tor Bug Tracker & Wiki]

#26539: add checksums to download page; make checksum vs. sig file purpose much
clearer
+-
 Reporter:  cypherpunks |  Owner:  traumschule
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Webpages/Website|Version:
 Severity:  Normal  | Resolution:
 Keywords:  gpg, verify gpg signatures  |  Actual Points:
Parent ID:  #3893   | Points:
 Reviewer:  |Sponsor:
+-
Changes (by traumschule):

 * owner:  (none) => traumschule
 * 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] #27099 [Community/Translations]: Support: Finish German localization

[Tor Bug Tracker & Wiki]

#27099: Support: Finish German localization
+--
 Reporter:  traumschule |  Owner:  traumschule
 Type:  enhancement | Status:  needs_review
 Priority:  High|  Milestone:
Component:  Community/Translations  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  #26809  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by traumschule):

 * status:  assigned => needs_review


Comment:

 ~40 strings left: mostly log and config lines
 some strings are doubled: #27393

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27393 [Community/Translations]: doubled/similar strings in support page

[Tor Bug Tracker & Wiki]

#27393: doubled/similar strings in support page
+--
 Reporter:  traumschule |  Owner:  ggus
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Community/Translations  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+--
 some strings are overlapping and needed to be translated twice
 * 177: the brackets seem to be at the wrong place (see comment
 * "Self-testing indicates your ORPort is reachable from the outside.
 Excellent.": 38, 164, 316, 518
 * If you see lines like this in your Tor log: 177, 485
 * DuckDuckGo: 479, 490
 * When it confirms that it's reachable: 359, 527
 * Make sure your clock, date, and timezone are set correctly: 138, 153
 * Install the ntp or openntpd (or similar) package to keep it that way:
 138, 511
 * # Common log error: 130, 236, 337, 531 (maybe split the first part
 each)
 * 93, 201
 there is some more in
 [https://www.transifex.com/otf/torproject/translate/#de/support-
 portal/148568715?q=comment%3A* comments]

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

Re: [tor-bugs] #26207 [Core Tor/Stem]: Stem 1.6.0 incompatible with PyPy 5.6.0

[Tor Bug Tracker & Wiki]

#26207: Stem 1.6.0 incompatible with PyPy 5.6.0
---+
 Reporter:  mikeperry  |  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by traumschule):

 Maybe then pypy could just return 0 for the size instead of bailing out on
 stem 1.6.0. I assume you put some work into the new version .)
 (or there's less need for running high performance stuff on the latest
 version)

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

Re: [tor-bugs] #9036 [Applications/GetTor]: Changing GetTor Message Body

[Tor Bug Tracker & Wiki]

#9036: Changing GetTor Message Body
-+---
 Reporter:  mrphs|  Owner:  sukhbir
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by traumschule):

 * status:  needs_review => needs_information


Comment:

 what is to do here? needs-review => above texts need to be reviewed?
 or does it need a PR for http://jqs44zhtxl2uo6gk.onion/gettor.git/

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

Re: [tor-bugs] #24104 [Core Tor/Tor]: Delay descriptor bandwidth reporting on established relays

[Tor Bug Tracker & Wiki]

#24104: Delay descriptor bandwidth reporting on established relays
-+-
 Reporter:  teor |  Owner:  juga
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-backport-maybe, 033-backport-|  Actual Points:
  maybe, 032-backport-maybe, 029-backport-   |
  maybe, security-low, guard-discovery-stats,|
  chutney-wants, bwauth-wants,   |
  034-triage-20180328, 034-removed-20180328, |
  tor-bwauth, 031-unreached-backport-maybe, 035  |
  -triaged-in-20180711   |
Parent ID:  #25925   | Points:  1
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by ahf):

 * status:  needs_review => merge_ready


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] #19839 [Community/Translations]: BridgeDB website: German translation could be improved (and completed)

[Tor Bug Tracker & Wiki]

#19839: BridgeDB website: German translation could be improved (and completed)
+--
 Reporter:  sebalis |  Owner:  isis
 Type:  defect  | Status:  new
 Priority:  Low |  Milestone:
Component:  Community/Translations  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  bridgedb-reportbug  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by traumschule):

 * component:  Obfuscation/BridgeDB => Community/Translations


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

Re: [tor-bugs] #26381 [Applications/Tor Browser]: about:tor page does not load on first start on Windows and browser is stuck in endless reload cycle

[Tor Bug Tracker & Wiki]

#26381: about:tor page does not load on first start on Windows and browser is 
stuck
in endless reload cycle
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  defect   | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton, ff60-esr, |  Actual Points:
  TorBrowserTeam201808R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_review => new


Comment:

 Replying to [comment:23 pospeselr]:
 > Simple enough patch to set the sandbox level to 2 in the Windows build
 (until I can figure out the root issue):
 >
 > https://gitweb.torproject.org/user/richard/tor-
 browser.git/commit/?h=bug_26381=f41857c98e0271c575b74924adca4f0988fa5f8f
 >
 > Doing a full rbm-build to make sure nothing funky happens.

 Looks good to me. Cherry-picked the workaround to `tor-
 browser-60.1.0esr-8.0-1` (commit
 b8dcb4f1ab5f06017cee025a2ad35cd17d869679). I guess we can use this ticket
 for track the issue further down, thus setting state back to `new`.

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

Re: [tor-bugs] #26520 [Applications/Tor Browser]: NoScript is broken with TOR_SKIP_LAUNCH=1 in ESR 60-based Tor Browser

[Tor Bug Tracker & Wiki]

#26520: NoScript is broken with TOR_SKIP_LAUNCH=1 in ESR 60-based Tor Browser
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff60-esr, TorBrowserTeam201808R, |  Actual Points:
  noscript, AffectsTails |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks3):

 One noted regression: Click-to-play for local videos (`file://`) no longer
 seems to work (tested on TB 8.0a10).

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

Re: [tor-bugs] #17569 [Applications/Tor Browser]: Add uBlock Origin to the Tor Browser

[Tor Bug Tracker & Wiki]

#17569: Add uBlock Origin to the Tor Browser
-+-
 Reporter:  kernelcorn   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability tbb-security, tbb- |  Actual Points:
  performance|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks3):

 "... we will start blocking slow-loading trackers by default in Firefox
 63." ;)

 https://blog.mozilla.org/futurereleases/2018/08/30/changing-our-approach-
 to-anti-tracking/

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

Re: [tor-bugs] #27305 [Webpages/Website]: create a download page for TBA on torproject.org

[Tor Bug Tracker & Wiki]

#27305: create a download page for TBA on torproject.org
--+
 Reporter:  isabela   |  Owner:
  |  traumschule
 Type:  task  | Status:
  |  needs_review
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201808  |  Actual Points:
Parent ID:  #26531| Points:
 Reviewer:|Sponsor:  Sponsor8
--+

Comment (by hiro):

 APK link: https://dist.torproject.org/torbrowser/mobile/1.0a1/tor-browser-
 android-arm-1.0a1.apk

 Will do the fixes and push tomorrow morning EU 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] #26520 [Applications/Tor Browser]: NoScript is broken with TOR_SKIP_LAUNCH=1 in ESR 60-based Tor Browser

[Tor Bug Tracker & Wiki]

#26520: NoScript is broken with TOR_SKIP_LAUNCH=1 in ESR 60-based Tor Browser
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff60-esr, TorBrowserTeam201808R, |  Actual Points:
  noscript, AffectsTails |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Thanks for the heads-up! Works for us as we are still waiting for the
 60.2.0esr candidate builds to start our own ones.

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

Re: [tor-bugs] #26207 [Core Tor/Stem]: Stem 1.6.0 incompatible with PyPy 5.6.0

[Tor Bug Tracker & Wiki]

#26207: Stem 1.6.0 incompatible with PyPy 5.6.0
---+
 Reporter:  mikeperry  |  Owner:  atagar
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Thank traumschule. On first glance that looks to be a replacement for
 'size of our process in memory' rather than 'size of individual object X'.
 That said, this is a very, very unimportant helper function. If there's a
 PyPy drop in replacement then neat, but unimportant.

 As for testing multiple versions of pypy, pre-release I'll only be testing
 against the copy I got from apt-get. If folks would like specific versions
 checked we should probably set up a jenkins job.

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

Re: [tor-bugs] #27112 [Core Tor/Stem]: Decouple payload processing from pop/unpack + tune abstraction layers

[Tor Bug Tracker & Wiki]

#27112: Decouple payload processing from pop/unpack + tune abstraction layers
---+
 Reporter:  dmr|  Owner:  dmr
 Type:  enhancement| Status:  needs_revision
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  client |  Actual Points:
Parent ID: | Points:
 Reviewer:  atagar |Sponsor:
---+

Comment (by dmr):

 Ok, now onto specific points in your comment.

 Replying to [comment:7 atagar]:
 > I think we might be misunderstanding each other, and it boils down to
 one simple question: **When you say 'for multi-hop circuits' which of the
 following do you mean?**
 >
 > a. So we can **relay**. That is to say, be in the **middle** of the
 circuit.
 > b. So we can **make circuits**. That is to say, we're the **originator**
 of a multi-hop circuit.
 >
 > If you mean 'a' then yes, much of this is necessary, but that is **not**
 our task at present. If the later then I'm unsure why much of this is
 necessary but quite possible I'm missing something.
 I mean 'b', but I do think that the `stem.client.cell` shouldn't have any
 limitations in it that prevents 'a'. Any logic that differentiates relay
 from client should be at another code layer. So I think with the proposed
 solutions, there isn't a difference here.

 > > (1) to confirm that we didn't get unlucky with 'recognized' == 0;
 >
 > If we're a client then all cells we receive are decryptable. The
 'recognized' field is nothing more than a poor man's 'is this cell still
 encrypted?' check. This is only relevant if we implement relaying.
 >
 > > (2) to work against various corruption / attacks that would affect the
 integrity of our payload
 >
 > As for this part, yup. I'd actually be **delighted** to merge a
 targeted, simple patch that implements decryption digests (with tests). I
 stared at your branch for hours this weekend hoping to integrate that, but
 honestly I couldn't make heads or tails of this code. The myriad of
 helpers (especially with names like 'coerce' and 'interpret') made my head
 spin.
 Agreed, it was messy and had a lot of helpers (and naming is hard). I'll
 try to take a look at adjusting `decrypt()`. Right now it also don't check
 `'recognized'`, which I believe it should do before attempting to create a
 RelayCell (and per my proposed solutions, //not// attempt to create a
 RelayCell).

 > > but I was pretty solid with the encrypt() and decrypt() interface /
 methods
 >
 > I kept the encrypt/decrypt interfaces the same. The **only** thing I
 dropped was...
 I guess I meant the interface holistically.

 Hopefully this illustrates some of the differences.

 `decrypt()`
 ||= Where =||= Returns =||= Raises =||= Params =||
 ||branch||(RawRelayCell, fully_decrypted bool, CipherContext,
 HASH)||nothing, I believe||self (BaseRelayCell), CipherContext, HASH||
 ||master||(RelayCell, CipherContext, HASH)||stem.ProtocolError and
 anything the `RelayCell` unpacking or constructor may
 raise||//(staticmethod)// link_protocol, bytes from ORPort, CipherContext,
 HASH||

 For brevity, I won't do the same for encrypt(), but it's similar. (It also
 only has a single layer of encryption implemented in the branch, although
 it's fairly easily refactored to `BaseRelayCell`)

 Again, I'm not tied to the specifics here. I do especially think returning
 `fully_decrypted` is necessary, and it makes sense to me that this method
 operate on the same types that it returns a superset of.


 > b. Rearchitecture of our RelayCell class, splitting this up into dozens
 of helpers. I wasn't a fan of this.
 Sorry, that was messy and overdone. Some of it I believe helped and was
 necessary, but other parts arguably didn't add much value, or were placed
 at the wrong level. (I'm still rethinking how to have a hierarchy for
 RELAY/RELAY_EARLY `Cell`s.)

 > Sorry! I know it sucks to get this kind of pushback on a branch you've
 worked so hard on.
 You raise fair points. Mostly I'm just trying to communicate where I'm
 coming from, and it looks like neither the code nor the commit messages
 did a good job of this.

 > 3. I **want** to merge your decryption digest implementation (there's
 now a TODO comment in decrypt() about it) but I couldn't make sense of
 this code.
 Good TODO comment - it helps keep track of things.

 For posterity's sake: it's a bit more complicated than the example in the
 comment.
 * the digest is computed using the //payload// (not the whole packed cell)
 with 0 in the digest field (hence the `pack_payload` helper method)
 * `self.digest` is an int per unpacking (and otherwise would've been
 coerced by the constructor), but `new_digest` is still a HASH, so we need
 to coerce the latter to `int` to compare (hence the `coerce_digest` helper
 method)

 > 4. I **do not** 

Re: [tor-bugs] #27112 [Core Tor/Stem]: Decouple payload processing from pop/unpack + tune abstraction layers

[Tor Bug Tracker & Wiki]

#27112: Decouple payload processing from pop/unpack + tune abstraction layers
---+
 Reporter:  dmr|  Owner:  dmr
 Type:  enhancement| Status:  needs_revision
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  client |  Actual Points:
Parent ID: | Points:
 Reviewer:  atagar |Sponsor:
---+

Comment (by dmr):

 Sorry again for the delay in my response, and for the verbosity...

 I think it's probably best that I step back a bit to explain a bit more of
 the broader picture as I see it.
 The changes in that branch were indeed messy, but I think they did push
 towards the vision I have. While I don't have the "end design" quite
 figured out (hence most of the messiness), I think it would help if I
 clarify at least an intermediate part of my vision. Thereafter, I can
 respond a bit more specifically to your comments.

 I see the following current limitations in stem.client's design:
 1. dropping multiplexed cells or (worse) throwing exceptions when they
 occur
 2. having `unpack()`/`pop()` methods that effectively won't work on the
 stream of data received from a guard, if there's //any// RELAY/RELAY_EARLY
 cells in there
 3. allowing only a single layer of decryption, instead of an arbitrary
 number of layers
 4. being limited to only a single "actor" that may send/process Cells
 (related to `1.`)

 There are more, but the above are the main ones that I was trying to
 address with this ticket.
 I felt my changes took a pretty big step forward towards these (not
 completed), but I feel the current master has not - mostly taking only
 some abstraction-layer tuning and small fixes.

 I'm not dead-set on any given design, but I hope the following helps
 explain why I was trending the way I was.


  Limitation 1: dropping multiplexed cells or (worse) throwing
 exceptions when they occur
 By this I mean: Tor is multiplexed by nature. Most cell sequences on the
 wire can be interleaved with others (the spec calls out just a few
 exceptions).
 This should be fairly self-evident by the ability to have multiple
 circuits and streams open concurrently, but I wanted to call it out
 explicitly.

 This is related to `4.` but goes beyond it - any hop on any of our
 circuits may send a Cell to us - it does not have to be a response in part
 of a sequence.

 The client needs some way to handle this - i.e. to demultiplex.

 **My proposed solution** to this for stem is to centralize ORPort reads -
 separating that from more specific handlers. A central point (probably a
 dedicated thread) should be the only thing reading from the ORport socket.
 Sorting and handling of incoming cells probably will be facilitated by
 queues (not there yet).
 (This ticket doesn't aim to centralize that, but rather take a step
 towards making that possible.)


  Limitation 2: having `unpack()`/`pop()` methods that effectively
 won't work on the stream of data received from a guard, if there's //any//
 RELAY/RELAY_EARLY cells in there

 Because our `Cell.unpack()`/`Cell.pop()` methods will directly create an
 interpreted RelayCell, from the payload sent over the wire (which, per the
 spec, is always encrypted), these methods effectively can't be used on
 incoming bytes that may have a RELAY/RELAY_EARLY cell.
 (Said a different way, interpreting an encrypted payload as if it were
 unencrypted doesn't get us the data we want, and has plenty of potential
 to throw an exception.)

 Since most of a tor client's useful operation involves relayed Cells,
 these methods in their current form don't quite make sense to me.

 The `Cell.by_value()` lookup method seemed like a natural place to adjust
 the returned class, but I'm not tied to changing that if you'd suggest
 another method.

 To make these methods more universally useful (e.g. to use `Cell.unpack()`
 in whatever solution fixes `1.`), **my proposed solution** for this is to
 unpack RELAY cells into some intermediate form that allows parsing the
 payload but not interpreting it. This was the basis for the
 `RawRelayCell`.

 I'm not tied to `RawRelayCell`, but I did see it as an interim way to
 solve this. (I'm still trying to figure out the best hierarchy for
 RELAY/RELAY_EARLY Cell classes.)


  Limitation 3: allowing only a single layer of decryption, instead of
 an arbitrary number of layers
 Right now, the `Cell.decrypt()` method creates a `RelayCell`, meaning that
 it suffers from the same problems as `unpack()`/`pop()` does, for use in
 multi-hop circuits.

 We need a way to arbitrarily decrypt the payload without creating a
 "Exception hazard" (here: RelayCell) automatically. When decrypting, we at
 least need to parse and look at `'recognized'`, and per the spec
 

Re: [tor-bugs] #27112 [Core Tor/Stem]: Decouple payload processing from pop/unpack + tune abstraction layers

[Tor Bug Tracker & Wiki]

#27112: Decouple payload processing from pop/unpack + tune abstraction layers
---+
 Reporter:  dmr|  Owner:  dmr
 Type:  enhancement| Status:  needs_revision
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  client |  Actual Points:
Parent ID: | Points:
 Reviewer:  atagar |Sponsor:
---+
Changes (by dmr):

 * status:  needs_review => needs_revision


Comment:

 Swapping status

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

Re: [tor-bugs] #27367 [Core Tor/Tor]: Authorities and relays should reject non-UTF-8 in relay descriptors

[Tor Bug Tracker & Wiki]

#27367: Authorities and relays should reject non-UTF-8 in relay descriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust-wants, prop285, |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #24033   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by atagar):

 Related a few past tickets where this has bitten us.

 Just a quick note that dirauths could use Stem as a tool for rejecting
 malformed content. It does stricter validation than the tor binary that
 descriptors are conformant with the spec. I've been performing this check
 through DocTor since 2013, filing tickets each time more bad data makes it
 into the consensus...

 https://gitweb.torproject.org/doctor.git/tree/descriptor_checker.py

 Bad data chokes not only Stem, but metrics-lib and anything else that
 ingests it.

 Clearly in an ideal world the tor binary itself would do better validation
 but in the absence of that if we took advantage of Stem's validator I
 wouldn't need to keep filing tickets every few months. Using Stem on
 dirauths to reject malformed descriptors would prevent these issues
 upfront, saving Karsten and I hassle.

 If that's a no-go I could also redirect the DocTor check I mention above
 to email other folks (Nick? teor? Maybe the network team list?) so I don't
 need to file tickets each time this comes up.

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

Re: [tor-bugs] #16858 [Core Tor/Tor]: Non-ascii country code in extrainfo descriptor

[Tor Bug Tracker & Wiki]

#16858: Non-ascii country code in extrainfo descriptor
-+
 Reporter:  atagar   |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-relay geoip  |  Actual Points:
Parent ID:  #27367   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by atagar):

 * parent:   => #27367


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

Re: [tor-bugs] #24821 [Core Tor/Tor]: Relay publishing malformed dirreq-v3-tunneled-dl

[Tor Bug Tracker & Wiki]

#24821: Relay publishing malformed dirreq-v3-tunneled-dl
-+-
 Reporter:  atagar   |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Major| Resolution:  fixed
 Keywords:  tor-relay, extra-info,   |  Actual Points:
  033-triage-20180320, 033-removed-20180320  |
Parent ID:  #27367   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by atagar):

 * parent:   => #27367


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

Re: [tor-bugs] #27351 [Applications/Tor Browser]: DisableNetwork is not unset if bootstrapping fails

[Tor Bug Tracker & Wiki]

#27351: DisableNetwork is not unset if bootstrapping fails
--+--
 Reporter:  traumschule   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  s8-errors |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by catalyst):

 * cc: catalyst (added)
 * keywords:   => s8-errors


Comment:

 I think we should only log about DisableNetwork being set once each time
 it gets set, instead of each time tor tries to open a connection
 somewhere. We should also log when it is unset, because right now it's
 not, and that can confound the interpretation of the log messages
 following the one that mentions DisableNetwork being set. I'm pretty sure
 Tor Launcher sets DisableNetwork=0 once the user clicks OK on the Tor
 network settings dialog.

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

Re: [tor-bugs] #25713 [Core Tor/Tor]: "DisableNetwork is set" log message in Tor Browser scares/confuses users

[Tor Bug Tracker & Wiki]

#25713: "DisableNetwork is set" log message in Tor Browser scares/confuses users
+
 Reporter:  arma|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  ux-team, s8-errors  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by catalyst):

 * keywords:  ux-team => ux-team, s8-errors
 * cc: catalyst (added)


Comment:

 Replying to [comment:8 traumschule]:
 > After my monologue in #27351 i propose it to log "DisableNetwork is set.
 Network settings are opened or  bootstrapping failed. Do we have
 connectivity? Tor will not make or accept non-control network connections.
 Shutting down all existing connections."
 I think this wording is too specific to Tor Browser and is not something
 that the tor daemon should use to log this event.

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

Re: [tor-bugs] #27392 [Applications/Tor Launcher]: Moat url update

[Tor Bug Tracker & Wiki]

#27392: Moat url update
---+---
 Reporter:  hiro   |  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by hiro):

 Hi, you should now be able to receive a bridge if you test the urls in
 torbrowser.
 Please let me know if you have any issues.

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

Re: [tor-bugs] #22089 [Applications/Tor Browser]: Add Decentraleyes to slighten off a bit Exit traffic and work around some CDNs blocking of Tor

[Tor Bug Tracker & Wiki]

#22089: Add Decentraleyes to slighten off a bit Exit traffic and work around 
some
CDNs blocking of Tor
-+-
 Reporter:  imageverif   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability-website, tbb-  |  Actual Points:
  performance|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks3):

 An example that I encountered today where this may have been useful on
 stackoverflow:

 {{{
 Loading failed for the 

Re: [tor-bugs] #26520 [Applications/Tor Browser]: NoScript is broken with TOR_SKIP_LAUNCH=1 in ESR 60-based Tor Browser

[Tor Bug Tracker & Wiki]

#26520: NoScript is broken with TOR_SKIP_LAUNCH=1 in ESR 60-based Tor Browser
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff60-esr, TorBrowserTeam201808R, |  Actual Points:
  noscript, AffectsTails |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by ma1):

 Ehy, just in case you did not merge it yet,
 [https://github.com/hackademix/noscript/releases/tag/10.1.9.1 10.1.9.1]
 has a
 
[https://github.com/hackademix/noscript/commit/6a0252c6de229076e2730a5f9c07d9776ddfeaba
 #diff-5e04e03ae0aa4ef9cfac4f0150549534 zero-risk patch] which I guess is
 of particular interest for Tor/Tails, since I guess private browsing
 windows are the likely norm, rather than the exception.

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

Re: [tor-bugs] #27392 [Applications/Tor Launcher]: Moat url update

[Tor Bug Tracker & Wiki]

#27392: Moat url update
---+---
 Reporter:  hiro   |  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by gk):

 * priority:  Medium => Very High


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

Re: [tor-bugs] #27367 [Core Tor/Tor]: Authorities and relays should reject non-UTF-8 in relay descriptors

[Tor Bug Tracker & Wiki]

#27367: Authorities and relays should reject non-UTF-8 in relay descriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust-wants, prop285, |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #24033   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cyberpunks):

 Replying to [comment:7 teor]:
 > Since the UTF-8 checking function accepts a length, we should probably
 also check for NUL. If we fail on the first NUL, this check becomes a
 last-ditch memory safety check, as most bytes in RAM are NUL.
 >
 > We should probably also log a bug warning if the function encounters a
 NUL byte:

 Receiving a NUL byte isn't a bug though. This function is processing
 untrusted input from `fetch_from_buf_http()` that might contain anything
 including NUL bytes.

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

Re: [tor-bugs] #27384 [Community/Translations]: remove aboutTor.properties from translation cycle

[Tor Bug Tracker & Wiki]

#27384: remove aboutTor.properties from translation cycle
+--
 Reporter:  arthuredelstein |  Owner:  emmapeel
 Type:  task| Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Community/Translations  |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by emmapeel):

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


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

Re: [tor-bugs] #27367 [Core Tor/Tor]: Authorities and relays should reject non-UTF-8 in relay descriptors

[Tor Bug Tracker & Wiki]

#27367: Authorities and relays should reject non-UTF-8 in relay descriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust-wants, prop285, |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #24033   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cyberpunks):

 Replying to [comment:8 teor]:
 > Oh, and I think that the changes file still mentions relays?

 The changes file was reverted actually. Fixed.

 But this ticket says 'and relays.' Could edit the summary and have a
 separate ticket for making relays reject in the future?

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

Re: [tor-bugs] #20260 [Applications/Tor Browser]: Add mitigating action to window size warning

[Tor Bug Tracker & Wiki]

#20260: Add mitigating action to window size warning
-+-
 Reporter:  lunar|  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, tbb-torbutton, tbb-   |  Actual Points:
  fingerprinting-resolution  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by kevun):

 Interesting, huertanix. I recently did a UX experiment on the Tor Browser
 and this warning was viewed as one of the  positives of the Tor Browser
 interface by new users, and didn't seem to be missed. Either way, having a
 way to undo the mistake and set it back to the common dimensions seems
 like a very useful feature.

 For the idea of a JS prompt that is more in-your-face, I like it but it
 would have to be carefully designed to avoid pop-up fatigue. Maybe only
 one pop-up per browsing session?

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

Re: [tor-bugs] #20700 [Core Tor/Tor]: prop224: Implement standard client authorization

[Tor Bug Tracker & Wiki]

#20700: prop224: Implement standard client authorization
-+-
 Reporter:  dgoulet  |  Owner:  haxxpop
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, 035-roadmap-|  Actual Points:
  master, 035-triaged-in-20180711|
Parent ID:  #25955   | Points:  3
 Reviewer:  nickm|Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_revision => needs_review
 * reviewer:  dgoulet => nickm


Comment:

 After many many reviews and revisions from me/asn/haxxpop, I present the
 branch for upstream merge:

 Branch: `ticket20700_035_02`
 PR: https://github.com/torproject/tor/pull/301

 Props goes to haxxpop for this big piece of work and his patience!

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

Re: [tor-bugs] #27392 [Applications/Tor Launcher]: Moat url update

[Tor Bug Tracker & Wiki]

#27392: Moat url update
---+---
 Reporter:  hiro   |  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by brade):

 * cc: gk, mcs (added)


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

Re: [tor-bugs] #26937 [Core Tor/sbws]: sbws: Warn when there is not enough disk space

[Tor Bug Tracker & Wiki]

#26937: sbws: Warn when there is not enough disk space
---+--
 Reporter:  juga   |  Owner:  juga
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #25925 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by pastly):

 Sorry. I haven't gotten to re-reviewing the PR because of I don't think
 that sbws even should have this code, thus I've never been motivated to
 look at it again.

 I'll find 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

[tor-bugs] #27392 [Applications/Tor Launcher]: Moat url update

[Tor Bug Tracker & Wiki]

#27392: Moat url update
---+---
 Reporter:  hiro   |  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+---
 Hi,

 I have deployed moat on an Azure VM.

 Here are the details:
 extensions.torlauncher.moat_servicehttps://moat.onionlab.eu/moat
 extensions.torlauncher.bridgedb_front  ajax.aspnetcdn.com
 extensions.torlauncher.bridgedb_reflector
 https://onionquiche.azureedge.net/

 The moat distributor is working, but I have issues retrieving bridges. I
 will update this ticket as soon as I have more news.

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

Re: [tor-bugs] #27391 [Internal Services/Service - git]: Allow teor and juga access to sbws repo

[Tor Bug Tracker & Wiki]

#27391: Allow teor and juga access to sbws repo
-+
 Reporter:  pastly   |  Owner:  tor-gitadm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by pastly):

 * Attachment "0001-Allow-teor-and-juga-access-to-sbws-repo.patch" added.


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

[tor-bugs] #27391 [Internal Services/Service - git]: Allow teor and juga access to sbws repo

[Tor Bug Tracker & Wiki]

#27391: Allow teor and juga access to sbws repo
-+
 Reporter:  pastly   |  Owner:  tor-gitadm
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+
 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Please allow teor and juga full access to the sbws repo.

 See attached patch where I attempt to make this change. Note that I've
 never
 touched a gitolite config file in my life.

 My name is pastly and I approve this message.
 -BEGIN PGP SIGNATURE-

 iQIzBAEBCAAdFiEEt+EF/E5tk3f4nLpMg7ypUpT7uwoFAluH73kACgkQg7ypUpT7
 uwrY6A//bkUjf0KyPWm1C9s1StSJynNBarxqh5qpYB+LY1Nvo1qxk497+PPHa49Z
 nONV7YHbiLQwt1R9abeu6h+Y708qzrSk082riCfo4b44G47be6bsLkCCnaX+uiSu
 7VelKOiKU+FrN1WVt7JA8NPHN5Ms7MTBcj4cvCAH0F3BcHzPTE3MXuWDP+R5Rfvg
 pHbu4lgb8e1BjKBydmPA6M5ggU7GQxtSZEDhIwtKEdOZj7vpnG1poXh7TZnojm5H
 QnR2BfxelWA2s8fT+AndyJBhkZ2HP/U+26XPfvjLRG3SpNA4nmlLAXAUQTgqc4zF
 HBQE4KWcvzSY2Lo9dXx/cOffuyZT2x0k13oFjZUM69YUs18iquQgc+betvps9an4
 zVwvzn4VFsA082Lar78NTrGpwyADfBF69VkMUnWAjMcYq6xhJNtDNNOFkntBuNNm
 BjXbfVu15S3F0LVoSn21zt+7HaL9YQ6Y0pXPvT53u4VP8nvQiFVKHPtVebPMztUJ
 9Q5PKJgwiGDx4s6i28JoqAzXWFsGnRLh1BXrAmuqOOQzpjl53ZmOioa+0eyW8kZU
 J3zzMnp1Ii8pUXZYsjBky0aj4I9JdGw16Hs+dNeMk2RzPMl4SxFU8MgWuZl6OYvo
 QPZHPS9ujcezoyQDSMoFjBoaSZmXDU7VylhK96mWZHJokvlh4w8=
 =+FiV
 -END PGP SIGNATURE-
 }}}

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

Re: [tor-bugs] #27385 [Obfuscation/Snowflake]: https://snowflake.torproject.org/embed is confusing

[Tor Bug Tracker & Wiki]

#27385: https://snowflake.torproject.org/embed is confusing
---+
 Reporter:  cypherpunks3   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords:  snowflake, ux-team |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by cypherpunks3):

 Replying to [comment:3 antonela]:
 > Is it this work attached to any deadline?
 There is no dedicated snowflake maintainer currently so the answer is most
 probably no. That said I heard recently from a ~150K Alexa rank website
 owner that he wanted to include snowflake embeds in his site (which
 prompted me to open this ticket), so if this can be done early it would be
 nice.

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

Re: [tor-bugs] #17873 [Core Tor/Tor]: replacing 0.0.0.0 listeners at runtime fails

[Tor Bug Tracker & Wiki]

#17873: replacing 0.0.0.0 listeners at runtime fails
-+-
 Reporter:  cypherpunks  |  Owner:  rl1987
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, port, bind, switching,   |  Actual Points:
  035-triaged-in-20180711|
Parent ID:   | Points:
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by ahf):

 * status:  needs_review => needs_revision


Comment:

 I've left some comments and a small nit on the PR. Generally I think this
 looks good.

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => merge_ready


Comment:

 Left a very small nitpick on the PR. Otherwise looks good!

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

Re: [tor-bugs] #27385 [Obfuscation/Snowflake]: https://snowflake.torproject.org/embed is confusing

[Tor Bug Tracker & Wiki]

#27385: https://snowflake.torproject.org/embed is confusing
---+
 Reporter:  cypherpunks3   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords:  snowflake, ux-team |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by antonela):

 hey, thanks for inviting me to the party! I have been playing/reading
 with/about snowflake, and I have some ideas. Is it this work attached to
 any deadline?

 Added to my plate.

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

Re: [tor-bugs] #17413 [Webpages/Website]: Usability of MacOS installation process

[Tor Bug Tracker & Wiki]

#17413: Usability of MacOS installation process
-+-
 Reporter:  cypherpunks  |  Owner:
 |  traumschule
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
 |  WebsiteV3
Component:  Webpages/Website |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ux, ux, usability,   |  Actual Points:
  documentation, install, defer-new-website, |
  website-content, ux-team   |
Parent ID:  #3893| Points:
 Reviewer:   |Sponsor:
-+-
Changes (by antonela):

 * keywords:
 tor-ux, ux, usability, documentation, install, defer-new-website,
 website-content
 =>
 tor-ux, ux, usability, documentation, install, defer-new-website,
 website-content, ux-team


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

Re: [tor-bugs] #17413 [Webpages/Website]: Usability of MacOS installation process

[Tor Bug Tracker & Wiki]

#17413: Usability of MacOS installation process
-+-
 Reporter:  cypherpunks  |  Owner:
 |  traumschule
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
 |  WebsiteV3
Component:  Webpages/Website |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ux, ux, usability,   |  Actual Points:
  documentation, install, defer-new-website, |
  website-content|
Parent ID:  #3893| Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:
 ux, usability, documentation, install, defer-new-website, website-
 content
 =>
 tor-ux, ux, usability, documentation, install, defer-new-website,
 website-content


Comment:

 Please say "typing command-O".

 Here is my general feedback:
 * this document is very long, and has a lot of words. Is it intended as a
 reference?
 * sometimes, adding words makes things harder to understand. I'm still not
 convinced that the section about veritfying gpg keys is helpful. (But I
 realise that's a problem with the PGP standard and the web of trust, so it
 might not be our problem to solve.)
 * please get a ux person to review this web page, if they have time
 * I don't know if we have minimum supported browser versions for the tor
 website. That's something that hiro might know.

 I think someone else should review this change next, because I've reviewed
 the content as best I can.

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

Re: [tor-bugs] #17413 [Webpages/Website]: Usability of MacOS installation process

[Tor Bug Tracker & Wiki]

#17413: Usability of MacOS installation process
-+-
 Reporter:  cypherpunks  |  Owner:
 |  traumschule
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
 |  WebsiteV3
Component:  Webpages/Website |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux, usability, documentation,|  Actual Points:
  install, defer-new-website, website-content|
Parent ID:  #3893| Points:
 Reviewer:   |Sponsor:
-+-
Changes (by traumschule):

 * status:  needs_revision => needs_review


Comment:

 Thanks for your time!

 Note: According to
 [https://www.w3schools.com/cssref/css3_browsersupport.asp browser support
 for CSS3 properties] the ued transition feature is not supported by
 browsers older than: IE 10, FF 16, Chrome 26, Safari 6.1 and Opera 12.1.
 Merging this might make some users unhappy.

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

Re: [tor-bugs] #27351 [Applications/Tor Browser]: DisableNetwork is not unset if bootstrapping fails (was: Reloading TB's Tor instance disables network)

[Tor Bug Tracker & Wiki]

#27351: DisableNetwork is not unset if bootstrapping fails
--+--
 Reporter:  traumschule   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by traumschule):

 I think the actual problem is that DisableNetwork does not get unset after
 Tor is (re)started if the bootstrapping fails and the user never gets to
 know why. I considered closing this as "Not a bug" because of my own
 fault, if you agree, just do it, but maybe there's something to learn for
 the future.

 When I kill TB's Tor process this message pops up:
 > Tor unexpectedly exited. This might be due to a bug in Tor itself,
 another program on your system, or faulty hardware. Until you restart Tor,
 the Tor Browser will not able to reach any websites. If the problem
 persists, please send a copy of your Tor Log to the support team.
 > Restarting Tor will not close your browser tabs.

 It gives me the options "Ok" and "Restart Tor".

 It could also say "To Restart Tor later open the Network Settings via the
 onion menu." and offer the buttions "Restart Tor" "Keep Network turned
 off". Now a user knows, it was a deliberate decision, even when some other
 application killed tor without the user being aware of it.

 When I click "Restart Tor" in the Network Settings dialogue, Tor gets
 restarted and I see the bootstrap dialogue after clicking "OK".

 It is usually fine for most users except for those who edited torrc, so
 one could say "Their fault", they should know what they are doing. In my
 case I added another SocksPort. To solve this issue and possible future
 issues, the Tor Launcher would need to be smart enough to disable the
 SocksPort or other ports that could be set. I guess this is unfeasable.
 But why is Tor unable to bind to this port with "Adress in use", the
 former Tor process is not there anymore. At this point I realized that I
 was stupid enough to set it to 9050. I just reproduced it:

 {{{
 8/30/18, 08:38:19.800 [NOTICE] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 8/30/18, 08:38:19.800 [NOTICE] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 8/30/18, 08:38:19.800 [NOTICE] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 8/30/18, 08:38:19.800 [NOTICE] Opening Socks listener on 127.0.0.1:9150
 8/30/18, 08:38:19.810 [NOTICE] Bootstrapped 80%: Connecting to the Tor
 network
 8/30/18, 08:38:19.820 [NOTICE] Renaming old configuration file to
 "/home/user/src/tor/tor-
 browser8.0a10/Browser/TorBrowser/Data/Tor/torrc.orig.1"
 8/30/18, 08:38:19.820 [NOTICE] Bootstrapped 85%: Finishing handshake with
 first hop
 8/30/18, 08:38:20.830 [NOTICE] Bootstrapped 90%: Establishing a Tor
 circuit
 8/30/18, 08:38:26.393 [NOTICE] Tor has successfully opened a circuit.
 Looks like client functionality is working.
 8/30/18, 08:38:26.393 [NOTICE] Bootstrapped 100%: Done
 8/30/18, 08:45:32.980 [NOTICE] New control connection opened from
 127.0.0.1.
 8/30/18, 08:46:21.427 [NOTICE] Bootstrapped 90%: Establishing a Tor
 circuit
 8/30/18, 08:46:21.692 [NOTICE] Tor has successfully opened a circuit.
 Looks like client functionality is working.
 8/30/18, 08:46:21.692 [NOTICE] Bootstrapped 100%: Done
 8/30/18, 08:46:31.995 [NOTICE] New control connection opened from
 127.0.0.1.
 }}}
 Nyx connected two times, the first time i killed the tor process to set
 the nonsensical already attached to SocksPort and the interface hangs with
 the "Starting" message. But the important message that it cannot attach to
 the requested port is not even logged, because DisableNetwork only gets
 unset when the bootstrap succeeded. The important question that should
 appear in the UI if starting hangs for a while:

 comment:3:ticket:24627:
 > With DisableNetwork set, the .onion you tried to reach will inevitably
 fail because Tor just won't do any actions on the network.
 > Did you do anything special to your "tor" process or torrc file that
 would set that value? Were you using Tor Browser here? Maybe your computer
 didn't had connectivity anymore?

 Also the Copy Tor Log To Clipboard method is not the best option in my
 eyes. What is the reasoning? If the goal is to hide technical stuff, the
 ui should be clever to show the relevant error, maybe the last warning. I
 remember Vidalia showed the log in a tab, it could be another 

Re: [tor-bugs] #24627 [Core Tor/Tor]: DisableNetwork is set - Rend stream is 120 seconds late

[Tor Bug Tracker & Wiki]

#24627: DisableNetwork is set - Rend stream is 120 seconds late
+--
 Reporter:  stevensondhiem  |  Owner:  (none)
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  user disappeared
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by traumschule):

 * status:  needs_information => closed
 * resolution:   => user disappeared


Comment:

 Closing this as duplicate of #25713 and it does not look like we will get
 an answer from the user 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] #25713 [Core Tor/Tor]: "DisableNetwork is set" log message in Tor Browser scares/confuses users

[Tor Bug Tracker & Wiki]

#25713: "DisableNetwork is set" log message in Tor Browser scares/confuses users
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by traumschule):

 After my monologue in #27351 i propose it to log "DisableNetwork is set.
 Network settings are opened or  bootstrapping failed. Do we have
 connectivity? Tor will not make or accept non-control network connections.
 Shutting down all existing connections."

 But this is even longer and should not appear every second. The
 connectivity test could be done by Tor and log that the guard is not
 reachable (anymore). Instead of proposing to set DisableNetwork=0 with
 stem or nyx the UI could offer a button "Enable Network" and show the
 error if it fails.

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

Re: [tor-bugs] #26561 [Applications/Tor Browser]: Onion images are not displayed

[Tor Bug Tracker & Wiki]

#26561: Onion images are not displayed
-+-
 Reporter:  akrey|  Owner:  tbb-team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201808R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * status:  new => needs_review
 * keywords:  ff60-esr, TorBrowserTeam201808 => ff60-esr,
 TorBrowserTeam201808R


Comment:

 Here's a patch for review:

 https://github.com/arthuredelstein/tor-browser/commit/26561

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

Re: [tor-bugs] #27390 [Metrics/CollecTor]: Properly clean up sanitized web server logs in the recent/ directory

[Tor Bug Tracker & Wiki]

#27390: Properly clean up sanitized web server logs in the recent/ directory
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by karsten):

 * status:  new => needs_review


Comment:

 Please review [https://gitweb.torproject.org/karsten/metrics-
 db.git/commit/?h=task-27390=4e61b4b2739cba441e2f9f47e1b3016cf692bc7c
 commit 4e61b4b in my task-27390 branch].

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

[tor-bugs] #27390 [Metrics/CollecTor]: Properly clean up sanitized web server logs in the recent/ directory

[Tor Bug Tracker & Wiki]

#27390: Properly clean up sanitized web server logs in the recent/ directory
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 Looks like we forgot to properly implement the part where we clean up
 sanitized web server logs in the recent/ directory. They just pile up
 there and are not deleted when they turn older than three days. That's
 different from all other modules.

 See [https://collector.torproject.org/index/index.json CollecTor's index
 file] which contains lots and lots of not-as-recent sanitized web server
 logs.

 I'll post a branch in a minute. Let's put out a release with this fix
 within the next week or so.

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

Re: [tor-bugs] #26381 [Applications/Tor Browser]: about:tor page does not load on first start on Windows and browser is stuck in endless reload cycle

[Tor Bug Tracker & Wiki]

#26381: about:tor page does not load on first start on Windows and browser is 
stuck
in endless reload cycle
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton, ff60-esr, |  Actual Points:
  TorBrowserTeam201808R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by scriptCache):

 It affects shitty scriptCache*.bin/urlCache*.bin (what does it cache?!)
 stuff only. They are not created in startupCache folder in *\Desktop
 location. Both 'omni.ja's are mapped successfully, and there is no visible
 problem with tokens (compared to the official build).
 Maybe, some mess with paths/rights in
 https://bugzilla.mozilla.org/show_bug.cgi?id=1359653?
 (BTW, why does TB have version 60.1.0.6609, but Firefox - 60.1.0.6746?)

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

Re: [tor-bugs] #27367 [Core Tor/Tor]: Authorities and relays should reject non-UTF-8 in relay descriptors

[Tor Bug Tracker & Wiki]

#27367: Authorities and relays should reject non-UTF-8 in relay descriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust-wants, prop285, |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #24033   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 I opened #27389 to allow failures on that target, until the compiler is
 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] #27388 [Core Tor/Tor]: is_extrainfo in comment of router_parse_list_from_string() should be want_extrainfo

[Tor Bug Tracker & Wiki]

#27388: is_extrainfo in comment of router_parse_list_from_string() should be
want_extrainfo
--+
 Reporter:  neel  |  Owner:  neel
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  doc, comment  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * keywords:   => doc, comment
 * status:  needs_review => merge_ready
 * milestone:   => Tor: 0.3.5.x-final


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

Re: [tor-bugs] #27389 [Core Tor/Tor]: Appveyor Windows 64-bit builds fail because the compiler is broken

[Tor Bug Tracker & Wiki]

#27389: Appveyor Windows 64-bit builds fail because the compiler is broken
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:
  |  needs_review
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.3.4.1-alpha
 Severity:  Major | Resolution:
 Keywords:  035-must, 034-must, 034-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 CI is here:
 https://ci.appveyor.com/project/teor2345/tor/build/1.0.117

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

Re: [tor-bugs] #27388 [Core Tor/Tor]: is_extrainfo in comment of router_parse_list_from_string() should be want_extrainfo

[Tor Bug Tracker & Wiki]

#27388: is_extrainfo in comment of router_parse_list_from_string() should be
want_extrainfo
--+--
 Reporter:  neel  |  Owner:  neel
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by teor):

 This looks fine to me. The Appveyor 64-bit CI is failing due to #27389.

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

Re: [tor-bugs] #27389 [Core Tor/Tor]: Appveyor Windows 64-bit builds fail because the compiler is broken

[Tor Bug Tracker & Wiki]

#27389: Appveyor Windows 64-bit builds fail because the compiler is broken
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:
  |  needs_review
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.3.4.1-alpha
 Severity:  Major | Resolution:
 Keywords:  035-must, 034-must, 034-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * keywords:  035-must => 035-must, 034-must, 034-backport
 * status:  new => needs_review
 * version:   => Tor: 0.3.4.1-alpha
 * milestone:  Tor: 0.3.5.x-final => Tor: 0.3.4.x-final


Comment:

 We introduced appveyor in 0.3.4, so this patch needs to be backported to
 0.3.4.

 See my branch bug27389-034, on https://github.com/teor2345/tor.git
 It allows failures for the 64-bit build.

 When the compiler is fixed, we should revert this patch.

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

[tor-bugs] #27389 [Core Tor/Tor]: Appveyor Windows 64-bit builds fail because the compiler is broken

[Tor Bug Tracker & Wiki]

#27389: Appveyor Windows 64-bit builds fail because the compiler is broken
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Major |   Keywords:  035-must
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Since about 6 hours ago, all Appveyor 64-bit Windows builds fail the first
 C file they build with:

 {{{
 bash.exe : In file included from ../src/core/or/or.h:16,
 At line:2 char:5
 + & $commandPath $args 2>&1
 + ~
 + CategoryInfo  : NotSpecified: (In file
 include...ore/or/or.h:16,:String) [], RemoteException
 + FullyQualifiedErrorId : NativeCommandError

  from ../src/app/main/ntmain.c:22:
 ../src/lib/cc/torint.h:52:2: error: #error "Seems that your platform
 doesn't use 2's complement arithmetic. Argh."
  #error "Seems that your platform doesn't use 2's complement arithmetic.
 Argh."
   ^
 In file included from ../src/core/or/or.h:26,
  from ../src/app/main/ntmain.c:22:
 ../src/lib/cc/compat_compiler.h:28:2: error: #error "It seems your
 platform does not represent NULL as zero. We can't cope."
  #error "It seems your platform does not represent NULL as zero. We can't
 cope."
   ^
 ../src/lib/cc/compat_compiler.h:32:2: error: #error "It seems your
 platform does not represent 0.0 as zeros. We can't cope."
  #error "It seems your platform does not represent 0.0 as zeros. We can't
 cope."
   ^
 In file included from ../src/core/or/or.h:16,
  from ../src/feature/dirauth/dircollate.h:16,
  from ../src/feature/dirauth/dircollate.c:25:
 ../src/lib/cc/torint.h:52:2: error: #error "Seems that your platform
 doesn't use 2's complement arithmetic. Argh."
  #error "Seems that your platform doesn't use 2's complement arithmetic.
 Argh."
   ^
 In file included from ../src/core/or/or.h:26,
  from ../src/feature/dirauth/dircollate.h:16,
  from ../src/feature/dirauth/dircollate.c:25:
 ../src/lib/cc/compat_compiler.h:28:2: error: #error "It seems your
 platform does not represent NULL as zero. We can't cope."
  #error "It seems your platform does not represent NULL as zero. We can't
 cope."
   ^
 ../src/lib/cc/compat_compiler.h:32:2: error: #error "It seems your
 platform does not represent 0.0 as zeros. We can't cope."
  #error "It seems your platform does not represent 0.0 as zeros. We can't
 cope."
   ^
 }}}
 
https://ci.appveyor.com/project/teor2345/tor/build/1.0.113/job/ujbvwntcu1pdk2m6#L762

 CC'ing mikeperry, because he's on CI rotation this week.
 Which is weird, because configure seems to succeed.

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

Re: [tor-bugs] #13461 [Core Tor/Tor]: Point to Tor.framework in contrib, for iOS and macOS

[Tor Bug Tracker & Wiki]

#13461: Point to Tor.framework in contrib, for iOS and macOS
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, doc, osx, build, tor-client|  Actual Points:
  portability|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:41 rl1987]:
 > I mean, we generally don't link to community projects in any
 documentation that we have inside core tor repo. We probably should be
 linking it from somewhere in our wiki.

 We bundle a win32 build project in:
 https://github.com/teor2345/tor/tree/master/contrib/win32build

 My suggestion is that instead of bundling a project file for macOS Xcode,
 we could tell people to use Tor.framework.

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

Re: [tor-bugs] #13461 [Core Tor/Tor]: Point to Tor.framework in contrib, for iOS and macOS

[Tor Bug Tracker & Wiki]

#13461: Point to Tor.framework in contrib, for iOS and macOS
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, doc, osx, build, tor-client|  Actual Points:
  portability|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by rl1987):

 I mean, we generally don't link to community projects in any documentation
 that we have inside core tor repo. We probably should be linking it from
 somewhere in our wiki.

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

Re: [tor-bugs] #17413 [Webpages/Website]: Usability of MacOS installation process

[Tor Bug Tracker & Wiki]

#17413: Usability of MacOS installation process
-+-
 Reporter:  cypherpunks  |  Owner:
 |  traumschule
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
 |  WebsiteV3
Component:  Webpages/Website |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux, usability, documentation,|  Actual Points:
  install, defer-new-website, website-content|
Parent ID:  #3893| Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 See my comments on the pull request.

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

Re: [tor-bugs] #27367 [Core Tor/Tor]: Authorities and relays should reject non-UTF-8 in relay descriptors

[Tor Bug Tracker & Wiki]

#27367: Authorities and relays should reject non-UTF-8 in relay descriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust-wants, prop285, |  Actual Points:
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #24033   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 The same thing went wrong with the rebuild:
 https://ci.appveyor.com/project/teor2345/tor/build/1.0.111/job/8nf6lhj1oag6nbmf

 I wonder if the compiler that we're using has been updated to a broken
 version.

 I pushed the common ancestor of your branch and master to master-unicode-
 descriptors1, and the current master to master. If they both fail, I'll
 open a ticket to disable that build:
 https://github.com/teor2345/tor/branches

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

Re: [tor-bugs] #27364 [Applications]: update ricochet to use hsv3

[Tor Bug Tracker & Wiki]

#27364: update ricochet to use hsv3
--+
 Reporter:  traumschule   |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Applications  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Ok, so the codebase is stalled, but there are people active on the bug
 tracker.

 Disregarding project activity, here's my response:

 Replying to [comment:1 teor]:
 > Replying to [ticket:27364 traumschule]:
 > > Is the Tor Project willing to adopt ricochet?
 >
 > What do you mean by "adopt"?
 >
 > ...
 > As far as I'm aware, they do not want a closer association with the Tor
 Project.
 >
 > Also, the Tor Project Applications team is focused on Tor Browser and
 Tor Browser for Android right now.

 I'm not sure there is anything we can do to help right now.

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

Re: [tor-bugs] #27351 [Applications/Tor Browser]: Reloading TB's Tor instance disables network

[Tor Bug Tracker & Wiki]

#27351: Reloading TB's Tor instance disables network
--+--
 Reporter:  traumschule   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by traumschule):

 looked into the future, opened two files and thinking about #25713 now
 {{{
 src/chrome/content/network-settings.js:93:const kTorConfKeyDisableNetwork
 = "DisableNetwork";
 src/chrome/content/network-settings.js:1851:
 settings[kTorConfKeyDisableNetwork] = false;
 src/chrome/content/network-settings.js:1890:  const kErrorPrefix =
 "Setting DisableNetwork=1 failed: ";
 src/chrome/content/network-settings.js:1894:settings["DisableNetwork"]
 = true;
 src/components/tl-process.js:319:  TorStartAndControlTor:
 function(aForceDisableNetwork)
 src/components/tl-process.js:328:this._startTor(aForceDisableNetwork);
 src/components/tl-process.js:331:this._controlTor(isRunningTor,
 aForceDisableNetwork);
 src/components/tl-process.js:360:  _startTor:
 function(aForceDisableNetwork)
 src/components/tl-process.js:490:  if (aForceDisableNetwork ||
 TorLauncherUtil.shouldShowNetworkSettings ||
 src/components/tl-process.js:493:args.push("DisableNetwork");
 src/components/tl-process.js:697:  settings["DisableNetwork"] = false;
 }}}

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

Re: [tor-bugs] #27254 [Applications/Tor Browser]: TBA: Investigate "Assist app" functionality

[Tor Bug Tracker & Wiki]

#27254: TBA: Investigate "Assist app" functionality
--+--
 Reporter:  towiw |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by towiw3):

 When home button is long-pressed, Fennec is opened and a new tab is
 loaded. It appears to be using the Assist app permission only for opening
 Fennec and loading a new tab from anywhere. But still it is a dangerous
 permission. If Google apps are not installed and there is no other Assist
 app, TBA automatically becomes the Assist app.

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

Re: [tor-bugs] #27148 [Applications/GetTor]: GetTor: mention that HTML mails are not supported

[Tor Bug Tracker & Wiki]

#27148: GetTor: mention that HTML mails are not supported
-+--
 Reporter:  traumschule  |  Owner:  ilv
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/GetTor  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by traumschule):

 * status:  new => needs_review


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

Re: [tor-bugs] #27364 [Applications]: update ricochet to use hsv3

[Tor Bug Tracker & Wiki]

#27364: update ricochet to use hsv3
--+
 Reporter:  traumschule   |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Applications  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by traumschule):

 I don't think this is urgent and I don't want to push it on anybody of
 course.

 > Ricochet has active developers.

 I see no actual activity on the [https://github.com/ricochet-
 im/ricochet/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc 148
 tickets], [https://github.com/ricochet-
 im/ricochet/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc PRs] do not get
 merged (maybe their quality is too low, but it is not in the comments).
 There was a [https://github.com/ricochet-
 im/ricochet/pull/580#issuecomment-392801245 statement in May] that there
 are active developers but the [https://github.com/ricochet-
 im/ricochet/commits/master last commit] was a year ago. Only
 [https://github.com/ricochet-im/ricochet/network activity in branches] is
 a port to  go (see https://cwtch.im).

 [[doc/TorifyHOWTO/InstantMessaging#Ricochet|"Development stalled in
 November 2016, though it has been relatively stable in the time since."]]
 is a good summary in my eyes.

 But my impression could be wrong.

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