Re: [tor-bugs] #24619 [Applications/Tor Browser]: Tor exited unexpectedly

[Tor Bug Tracker & Wiki]

#24619: Tor exited unexpectedly
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * owner:  (none) => tbb-team
 * keywords:  7.0.10, 7.0.11, Tor Exited Unexpectedly => tbb-crash
 * component:  - Select a component => Applications/Tor Browser
 * status:  new => needs_information


Comment:

 Could you give us the full error message? And do you have some good steps
 to reproduce this reliably for us?

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

Re: [tor-bugs] #24620 [Applications/Tor Browser]: Can't see chat on wm.exchanger.ru (was: Can's see chat.)

[Tor Bug Tracker & Wiki]

#24620: Can't see chat on wm.exchanger.ru
--+--
 Reporter:  Ilya_SpongeBob2   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:   => tbb-usability-website


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

Re: [tor-bugs] #17650 [Applications/Tor Browser]: Cannot login to Youtube

[Tor Bug Tracker & Wiki]

#17650: Cannot login to Youtube
--+
 Reporter:  mansdt|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  worksforme
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

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


Comment:

 Thanks. Might be indeed that our switch to Firefox 52 switched that but I
 am not sure. Resolving this as `WORKSFORME` then.

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

Re: [tor-bugs] #24566 [Applications/Tor Browser]: When I open TorBrowser 7.0.11 the popup goes completely white

[Tor Bug Tracker & Wiki]

#24566: When I open TorBrowser 7.0.11 the popup goes completely white
--+---
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gk):

 Replying to [comment:11 Dbryrtfbcbhgf]:
 > Replying to [comment:10 gk]:
 > > Replying to [comment:9 Dbryrtfbcbhgf]:
 > > > Here is the video
 > > >
 ​https://filenurse.com/download/048ee301b1d2c7c3c164cd8fd5f2df5a.html
 > > > I reported this bug to mozilla.
 > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1424945
 > >
 > > Thanks. Does this affect a clean Firefox 57.0.2 as well? If so, might
 be worth mentioning on the Mozilla ticket. That said, it seems to me
 7.0.10 worked for you a couple of days/weeks ago but suddenly now you are
 seeing this problem even with that version? Or am I misunderstanding you?
 > The bug does Not effect 57.0.2 (64-bit). The issue only started after I
 updated my Mac to 10.13.2 (17C88) up from 10.13.1

 Okay, so it affects Firefox 52.5.2esr but not Firefox 57.0.2. Could you
 figure out which Firefox version fixed this bug? Maybe we can backport the
 patch for ESR 52? All Firefox versions are at:
 https://ftp.mozilla.org/pub/firefox/releases/

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24620 [Applications/Tor Browser]: Can's see chat.

[Tor Bug Tracker & Wiki]

#24620: Can's see chat.
--+--
 Reporter:  Ilya_SpongeBob2   |  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:|
--+--
 On Torbrowser 7.0.11 [https://dist.torproject.org/torbrowser/7.0.11
 /torbrowser-install-7.0.11_en-US.exe] with turned off all addons
 can't see a chat on page
 https://wm.exchanger.ru/asp/contacts.asp?lang=en-US

 On Portable FF ESR 52.5.2
 
[https://sourceforge.net/projects/portableapps/files/Mozilla%20Firefox%2C%20Portable%20Ed./Mozilla%20Firefox%20ESR%2C%20Portable%20Edition%2052.5.2/]
 all is OK.

 Screen shot: https://s.sender.mobi/u/image/2017/12/14/4rf4z8TA0/-.JPG

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

Re: [tor-bugs] #24616 [Applications/Tor Browser]: Audit the use of IsSecureContext to avoid bleeding http/https origins

[Tor Bug Tracker & Wiki]

#24616: Audit the use of IsSecureContext to avoid bleeding http/https origins
--+--
 Reporter:  tom   |  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 gk):

 Replying to [ticket:24616 tom]:
 > http://example.com and https://example.com are different origins and do
 not share state (cookies, etc)
 >
 > If TB edits IsSecureContext to make .onion secure,

 Why should we want to do that? I deliberately avoided that when fixing
 #21321 because messing with secure contexts in an .onion context is risky
 (for one it needs a spec update as https://w3c.github.io/webappsec-secure-
 contexts/ does not treat .onion as secure context). And it seems to me we
 can avoid that at a fairly low cost by treating it as potentially
 trustworthy. See: https://bugzilla.mozilla.org/show_bug.cgi?id=1382359
 where Christoph said this approach looks good to him. FWIW: I still plan
 to provide the second half of the patch for that bug this year.

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

Re: [tor-bugs] #23169 [Metrics/Website]: Explain why metrics are important and what we do to make sure they're safe

[Tor Bug Tracker & Wiki]

#23169: Explain why metrics are important and what we do to make sure they're 
safe
-+--
 Reporter:  arma |  Owner:  irl
 Type:  defect   | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by irl):

 I've done a little work on the homepage to make it clearer right from
 landing on the website what it is that Tor Metrics is about, with a link
 to the about page. I've also added links at the bottom for relay search
 and exonerator, which could help to show that Tor Metrics isn't just the
 graphs.

 Demo at: https://people.torproject.org/~irl/metrics/

 I plan to write further text into the About page including some diagrams
 of flow of data collection (relays/dirauths/onionperf -> collector ->
 onionoo/statistics) and safety of data collection (minimisation, source
 aggregation, transparency and linking to research safety board).

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

Re: [tor-bugs] #24045 [Metrics/Atlas]: Measure and map overloaded or over-weighted relays

[Tor Bug Tracker & Wiki]

#24045: Measure and map overloaded or over-weighted relays
-+-
 Reporter:  teor |  Owner:
 |  metrics-team
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Metrics/Atlas|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-performance, tbb-usability,  |  Actual Points:
  performance, tbb-needs |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by irl):

 * component:  Metrics/Analysis => Metrics/Atlas


Comment:

 Ana is working on this along with a non-aggregated version of the current
 map to integrate into Relay Search, so I'll reassign this ticket to that
 component.

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

[tor-bugs] #24619 [- Select a component]: Tor exited unexpectedly

[Tor Bug Tracker & Wiki]

#24619: Tor exited unexpectedly
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  - Select a   |Version:
  component  |   Keywords:  7.0.10, 7.0.11, Tor
 Severity:  Major|  Exited Unexpectedly
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 OS: Windows 7 SP1 x64

 Tor browser 7.0.11 (32-bit)

 Installed it fine, but everytime I log back in from sleep or hibernation,
 or if it sits idle for a while, I get the error message:

 "Tor unexpectedly exited, etc etc"

 Restarting doesn't solve it. Reinstalling didn't solve it. I noticed it
 started happening for me after installing 7.0.10 about a week or so ago.
 Went back to 7.0.8, but that didn't solve it either. It's still happening
 with 7.0.11, but not as much as 7.0.10.

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

Re: [tor-bugs] #20942 [Core Tor/Fallback Scripts]: Make consensus expiry tolerance for fallbacks lower when the stale consensus bug is fixed

[Tor Bug Tracker & Wiki]

#20942: Make consensus expiry tolerance for fallbacks lower when the stale
consensus bug is fixed
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:
Parent ID:  #22271 | Points:  0.1
 Reviewer: |Sponsor:
---+---

Comment (by ingoglia.osource@…):

 Here is the diff for changing the CONSENSUS_EXPIRY_TOLERANCE to 0:

 diff --git a/scripts/maint/updateFallbackDirs.py
 b/scripts/maint/updateFallbackDirs.py
 index 82a60420b..cfd72c87d 100755
 --- a/scripts/maint/updateFallbackDirs.py
 +++ b/scripts/maint/updateFallbackDirs.py
 @@ -102,7 +102,7 @@ DOWNLOAD_MICRODESC_CONSENSUS = True
  # 0.3.0.0-alpha-dev and later deliver stale consensuses, but typically
 recover
  # after ~12 hours.
  # We should make this lower when #20909 is fixed, see #20942.
 -CONSENSUS_EXPIRY_TOLERANCE = 24*60*60
 +CONSENSUS_EXPIRY_TOLERANCE = 0

  # Output fallback name, flags, bandwidth, and ContactInfo in a C comment?
  OUTPUT_COMMENTS = True if OUTPUT_CANDIDATES else 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] #24565 [Community/Tor Support]: User queries and issues

[Tor Bug Tracker & Wiki]

#24565: User queries and issues
---+---
 Reporter:  Pari   |  Owner:  phoul
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by phoul):

 Replying to [comment:1 gk]:
 > I wonder if it would be smart to have a wiki page on trac instead. It
 seems to me it gets easily messy if we want to use the bug tracker for
 that project.

 Hi gk, I think you're right, having an updating ticket like this will
 likely become confusing fairly quickly.

 Pari, I've opened a new wiki page at
 https://trac.torproject.org/projects/tor/wiki/org/teams/CommunityTeam/issues
 and copied the contents of your ticket over, along with a few formatting
 changes. Updating this page instead of a ticket should help keep things a
 bit cleaner.

 Please feel free to edit the new page as much as you'd like! I will also
 review the content every few days, just to make sure we are not listing
 unsupported activities as "issues" (like running Flash).

 Thank you for putting this together, this is a great list!

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

Re: [tor-bugs] #17782 [Core Tor/Tor]: Relays may publish descriptors with incorrect IP address

[Tor Bug Tracker & Wiki]

#17782: Relays may publish descriptors with incorrect IP address
---+---
 Reporter:  fk |  Owner:  teor
 Type:  defect | Status:
   |  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Major  | Resolution:
 Keywords:  intro tor-relay address-detection  |  Actual Points:  0.5
Parent ID:  #24403 | Points:  1
 Reviewer: |Sponsor:  SponsorV-
   |  can
---+---
Changes (by teor):

 * status:  needs_review => needs_revision


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

Re: [tor-bugs] #17782 [Core Tor/Tor]: Relays may publish descriptors with incorrect IP address

[Tor Bug Tracker & Wiki]

#17782: Relays may publish descriptors with incorrect IP address
---+---
 Reporter:  fk |  Owner:  teor
 Type:  defect | Status:
   |  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Major  | Resolution:
 Keywords:  intro tor-relay address-detection  |  Actual Points:  0.5
Parent ID:  #24403 | Points:  1
 Reviewer: |Sponsor:  SponsorV-
   |  can
---+---

Comment (by teor):

 Turns out this is wrong, we need to keep the old check:
 * check that our origin circuit to ourselves completes successfully, and
 close it
 * check that our or circuit from ourselves comes in on an inbound
 connection
 * check that our or circuit from ourselves matches an open origin circuit
 (there should be a nonce in the existing protocol that we can use here)

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

Re: [tor-bugs] #24526 [Core Tor/Tor]: Make it clear that multi-relay operators are expected to set a working ContactInfo and proper MyFamily

[Tor Bug Tracker & Wiki]

#24526: Make it clear that multi-relay operators are expected to set a working
ContactInfo and proper MyFamily
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-doc, man  |  Actual Points:
Parent ID:  #24497| Points:
 Reviewer:|Sponsor:
--+
Changes (by cypherpunks):

 * 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] #24526 [Core Tor/Tor]: Make it clear that multi-relay operators are expected to set a working ContactInfo and proper MyFamily

[Tor Bug Tracker & Wiki]

#24526: Make it clear that multi-relay operators are expected to set a working
ContactInfo and proper MyFamily
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-doc, man  |  Actual Points:
Parent ID:  #24497| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 Part 1: Make ContactInfo mandatory for operators running multiple relays /
 bridges:

 based on the email from David (4 Dec 2017 18:07:08 -0500) on bad-relays
 I'm submitting a patch to make it clear to relay/bridge operators that a
 contact information is mandatory if you run more than one relay.

 This should make bad-relays@ cases less problematic where we have a
 presumed relay group like [ 1 ] and have no way to contact the operator
 before removing these relays from the tor network (because historically
 such groups turned out to be malicious).

 I didn't add to the man page what happens if you do not set it (your
 relays might get removed if we detect a very likely group of relays
 without contactInfo [ 1 ]), because that would make it longer.

 This adds a single and clear statement to the ContactInfo entry.

 tor.1.txt:

 {{{
 @@ -1716,7 +1716,8 @@
  [[ContactInfo]] **ContactInfo** __email_address__::
  Administrative contact information for this relay or bridge. This
 line
  can be used to contact you if your relay or bridge is misconfigured
 or
 -something else goes wrong. Note that we archive and publish all
 +something else goes wrong. ContactInfo must be set if you run more
 than
 +one relay or bridge. Note that we archive and publish all
  descriptors containing these lines and that Google indexes them, so
  spammers might also collect them. You may want to obscure the fact
  that it's an email address and/or generate a new address for this
 }}}

 [ 1 ] https://nusenu.github.io/OrNetRadar/2017/11/30/a6

 As David suggested after the man page is updated (this should get
 backported), David plans to announce this change on the blog.

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

Re: [tor-bugs] #24608 [Core Tor/Tor]: Update our Cargo.lock file to remove the deprecated and removed [root] section

[Tor Bug Tracker & Wiki]

#24608: Update our Cargo.lock file to remove the deprecated and removed [root]
section
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.6-alpha
 Severity:  Normal   | Resolution:
 Keywords:  rust, cargo, rust-pilot, tor-ci  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-

Comment (by isis):

 Carol Nichols and Alex Crichton seemed to have tracked down the
 regression, which was in part triggered by our use of `$CARGO_HOME` being
 ''inside'' the cargo workspace (trying very hard to not make a "THE BUGS
 ARE COMING FROM INSIDE THE `$HOME`" joke and failing). The issue for that
 is [https://github.com/rust-lang/cargo/issues/4815 here]. It should be in
 a nightly soon.

 In the meantime, Alex suggested we remove the `CARGO_HOME` portion of the
 `src/rust/target/release/@TOR_RUST_STATIC_NAME@` directive in
 `src/rust/tor_rust/include.am`.

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

Re: [tor-bugs] #24566 [Applications/Tor Browser]: When I open TorBrowser 7.0.11 the popup goes completely white

[Tor Bug Tracker & Wiki]

#24566: When I open TorBrowser 7.0.11 the popup goes completely white
--+---
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by Dbryrtfbcbhgf):

 Replying to [comment:10 gk]:
 > Replying to [comment:9 Dbryrtfbcbhgf]:
 > > Here is the video
 > > ​https://filenurse.com/download/048ee301b1d2c7c3c164cd8fd5f2df5a.html
 > > I reported this bug to mozilla.
 > > https://bugzilla.mozilla.org/show_bug.cgi?id=1424945
 >
 > Thanks. Does this affect a clean Firefox 57.0.2 as well? If so, might be
 worth mentioning on the Mozilla ticket. That said, it seems to me 7.0.10
 worked for you a couple of days/weeks ago but suddenly now you are seeing
 this problem even with that version? Or am I misunderstanding you?
 The bug does Not effect 57.0.2 (64-bit). The issue only started after I
 updated my Mac to 10.13.2 (17C88) up from 10.13.1

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

Re: [tor-bugs] #24616 [Applications/Tor Browser]: Audit the use of IsSecureContext to avoid bleeding http/https origins

[Tor Bug Tracker & Wiki]

#24616: Audit the use of IsSecureContext to avoid bleeding http/https origins
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arthuredelstein):

 * cc: arthuredelstein (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] #24612 [Core Tor/Tor]: Fix pretty printing of configure output for rust checks

[Tor Bug Tracker & Wiki]

#24612: Fix pretty printing of configure output for rust checks
-+
 Reporter:  isis |  Owner:  (none)
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-build, autoconf  |  Actual Points:
Parent ID:   | Points:  .1
 Reviewer:   |Sponsor:
-+
Changes (by isis):

 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.3.x-final


Comment:

 Sure, that sounds fine, it's just cosmetic.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24618 [Applications/Tor Browser]: Tor Browser doesn't prevent maximizing windows

[Tor Bug Tracker & Wiki]

#24618: Tor Browser doesn't prevent maximizing windows
--+--
 Reporter:  cypherpunks   |  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:|
--+--
 Tor Browser only shows a "helpful" message after the damage has been done.
 It should prevent maximizing the window in the first place (at least show
 a "are you sure" confirmation dialog).

 Maximizing can accidentally happen with window managers, when a window is
 moved to the screen edge or the title bar is accidentally double-clicked.

 In a virtual machine, or using certain app panels, the screen resolution
 can be fairly unique.

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

Re: [tor-bugs] #24617 [Core Tor/Tor]: Feature flags for new controller-accessible Tor features

[Tor Bug Tracker & Wiki]

#24617: Feature flags for new controller-accessible Tor features
--+
 Reporter:  meejah|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by meejah):

 nickm points out on #tor-dev that Proposition 264 ("Putting version
 numbers on the Tor subprotocols") might be a good basis for this.

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

Re: [tor-bugs] #24433 [Obfuscation/BridgeDB]: moat isn't returning bridges on successful CAPTCHA completion

[Tor Bug Tracker & Wiki]

#24433: moat isn't returning bridges on successful CAPTCHA completion
--+--
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  bridgedb-dist moat|  Actual Points:  1
Parent ID:| Points:  1
 Reviewer:|Sponsor:  SponsorM
--+--

Comment (by mcs):

 Replying to [comment:9 isis]:
 > Oops, I believe the original behaviour was actually correct: the client,
 when requesting /fetch, sends a `"type": "client-transports"`. The server,
 when responding to that request, iff there was no overlap in which
 transports are supported, sends `"type": "moat-transports"` to let the
 client software know which types it ''does'' have available.
 >
 > I've reverted 50a9321f.

 Ah, that makes sense. Sorry for the false alarm.

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

Re: [tor-bugs] #24433 [Obfuscation/BridgeDB]: moat isn't returning bridges on successful CAPTCHA completion

[Tor Bug Tracker & Wiki]

#24433: moat isn't returning bridges on successful CAPTCHA completion
--+--
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  bridgedb-dist moat|  Actual Points:  1
Parent ID:| Points:  1
 Reviewer:|Sponsor:  SponsorM
--+--

Comment (by mcs):

 Replying to [comment:8 isis]:
 > > * The `data` payload is specified as an object but the implementation
 uses an array. This is permitted by the JSON API specification but seems
 unnecessary for the moat protocol (since each request and response only
 includes one JSON object).
 >
 > We can change it back to a single object if you think that's better. My
 reasoning was:
 >
 > 1. I totally read the spec wrong and I thought it said they had to be
 arrays, and
 > 2. future-compatibility, in case we decided at some point that providing
 the user with more messages/errors might be helpful (e.g. if there is some
 non-fatal error which we might want to return/log/display on the client-
 side, but we're still also going to return bridges/captchas).

 My argument is that using arrays just makes the code a little more
 complicated, and on the client side we are always going to send a one-
 element array for requests and we are going to use data[0] when handling
 each response. But let's just use arrays since that is what is already
 implemented.

 Please update the spec when you have 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] #24211 [Applications/Orbot]: Update UserAgent string to 52!

[Tor Bug Tracker & Wiki]

#24211: Update UserAgent string to 52!
+
 Reporter:  cypherpunks |  Owner:  n8fr8
 Type:  defect  | Status:  closed
 Priority:  Very High   |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Critical| Resolution:  fixed
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by cypherpunks):

 * status:  new => 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] #22084 [Applications/Tor Browser]: Neuter NetworkInformation API on Tor Browser Mobile

[Tor Bug Tracker & Wiki]

#22084: Neuter NetworkInformation API on Tor Browser Mobile
-+-
 Reporter:  gk   |  Owner:  igt0
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile tbb-fingerprinting,   |  Actual Points:
  TorBrowserTeam201712   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

 * status:  needs_revision => 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] #24433 [Obfuscation/BridgeDB]: moat isn't returning bridges on successful CAPTCHA completion

[Tor Bug Tracker & Wiki]

#24433: moat isn't returning bridges on successful CAPTCHA completion
--+--
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  bridgedb-dist moat|  Actual Points:  1
Parent ID:| Points:  1
 Reviewer:|Sponsor:  SponsorM
--+--
Changes (by isis):

 * status:  needs_review => closed
 * resolution:   => fixed
 * actualpoints:  .5 => 1


Comment:

 Replying to [comment:8 isis]:
 > Replying to [comment:6 mcs]:
 > > * For the `/fetch` request, the `type` is specified as `moat-
 transports` but the implementation uses `client-transports`. For
 consistency with the other `type` values you may want to use `moat-
 transports`.
 >
 >
 
[https://gitweb.torproject.org/user/isis/bridgedb.git/commit/?h=develop=50a9321fadcfd0e9a4f30bc1919c1bf46d27d8e1
 50a9321f]

 Oops, I believe the original behaviour was actually correct: the client,
 when requesting /fetch, sends a `"type": "client-transports"`. The server,
 when responding to that request, iff there was no overlap in which
 transports are supported, sends `"type": "moat-transports"` to let the
 client software know which types it ''does'' have available.

 I've reverted 50a9321f.

 Closing as fixed; fingers crossed nothing else is broken.

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

Re: [tor-bugs] #24614 [Applications/Tor Browser]: update to Meek 0.28 tag

[Tor Bug Tracker & Wiki]

#24614: update to Meek 0.28 tag
--+--
 Reporter:  brade |  Owner:  brade
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  meek  |  Actual Points:
Parent ID:  #23136| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * cc: dcf (added)
 * keywords:   => meek


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

Re: [tor-bugs] #24617 [Core Tor/Tor]: Feature flags for new controller-accessible Tor features (was: Feature flags for new Tor features)

[Tor Bug Tracker & Wiki]

#24617: Feature flags for new controller-accessible Tor features
--+
 Reporter:  meejah|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |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

[tor-bugs] #24617 [Core Tor/Tor]: Feature flags for new Tor features

[Tor Bug Tracker & Wiki]

#24617: Feature flags for new Tor features
--+
 Reporter:  meejah|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 As Tor grows new features available via the control protocol, it would be
 useful to indicate support for these features via some GETINFO.

 Currently, controllers have two ways to discover if the Tor they connected
 to supports a feature: "just try" and see if there's an error; or look at
 the Tor version.

 Both of these can be problematic:

 You can't always "just try". For example, when HS_DESC was first added as
 an event it didn't include the onion address, so you'd wait forever to see
 if a descriptor was uploaded. For completely new commands, "just try" is
 probably sufficient but when commands gain new capabilities and/or options
 it can get less obvious what the right thing to do is.

 Doing version comparisons can get tricky: as a new feature is implemented,
 it will generally appear on master first, then maybe in an alpha release
 and finally in a "real/full" release. A controller wanting to take fullest
 advantage of a new feature (e.g. to let users test it against a Tor from
 "master") would have to program in each of these versions separately,
 which is tedious.

 Instead, a definitive "GETINFO" which returns details of the feature would
 be ideal. Then, a controller can change its behavior and take advantage of
 a new feature as soon as it's on master and users can continue to take
 advantage of this as the feature moves through alphas, betas, etcetera.
 This would also work well for features that can be turned off (or on)
 through other mechanisms (e.g. configuration, command-line or build
 options).

 Such flags could also "roll up" logical features that actually need
 multiple controller commands/events to work. For example, adding v3
 services changed some config options, modified the ADD_ONION command and
 (later) provided upload information via the HS_DESC event. So until the
 ADD_ONION *and* HS_DESC changes landed, a controller couldn't properly add
 a v3 ephemeral service.

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

Re: [tor-bugs] #22084 [Applications/Tor Browser]: Neuter NetworkInformation API on Tor Browser Mobile

[Tor Bug Tracker & Wiki]

#22084: Neuter NetworkInformation API on Tor Browser Mobile
-+-
 Reporter:  gk   |  Owner:  igt0
 Type:  task | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile tbb-fingerprinting,   |  Actual Points:
  TorBrowserTeam201712   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by igt0):

 Thanks,

 I attached the back ported patches following the proposed workflow:

 Part 1:
 https://trac.torproject.org/projects/tor/attachment/ticket/22084/0001
 -PATCH-Bug-1372072-Part-1-Spoofing-network-informatio.patch

 Part 2:
 https://trac.torproject.org/projects/tor/attachment/ticket/22084/0002
 -PATCH-Bug-1372072-Part-2-Add-a-test-case-for-check-w.patch

 Replying to [comment:10 gk]:
 > Thanks. I think the code backported looks good. However, I think we
 should have a better patch format. First, we should keep the Mozilla bug
 number. That makes it easier to find the patch(es) in our tree. Second, we
 should keep the patch(set) structure: one commit in our tree should match
 one commit taken from Mozilla. This allows us to pinpoint possible issues
 easier. Third, we should fix up the commit message if needed (in your case
 you still have included "This tests not only windows, but also workers."
 even though you rightly omitted the workers related part).
 >
 > A workflow that works fine for me is having `mozilla-central` as a git
 remote and cherry picking the patches from that one into `tor-browser`
 one-by-one, fixing them up if needed and adapting the commit message
 afterwards with `git commit --amend` if needed as well.

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

Re: [tor-bugs] #22084 [Applications/Tor Browser]: Neuter NetworkInformation API on Tor Browser Mobile

[Tor Bug Tracker & Wiki]

#22084: Neuter NetworkInformation API on Tor Browser Mobile
-+-
 Reporter:  gk   |  Owner:  igt0
 Type:  task | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile tbb-fingerprinting,   |  Actual Points:
  TorBrowserTeam201712   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by igt0):

 * Attachment "0002-PATCH-Bug-1372072-Part-2-Add-a-test-case-for-
 check-w.patch" added.

 Version 2 - Backport test from firefox

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

Re: [tor-bugs] #22084 [Applications/Tor Browser]: Neuter NetworkInformation API on Tor Browser Mobile

[Tor Bug Tracker & Wiki]

#22084: Neuter NetworkInformation API on Tor Browser Mobile
-+-
 Reporter:  gk   |  Owner:  igt0
 Type:  task | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile tbb-fingerprinting,   |  Actual Points:
  TorBrowserTeam201712   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by igt0):

 * Attachment "0001-PATCH-Bug-1372072-Part-1-Spoofing-network-
 informatio.patch" added.

 Version 2 - Backport code from Firefox

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

Re: [tor-bugs] #24433 [Obfuscation/BridgeDB]: moat isn't returning bridges on successful CAPTCHA completion

[Tor Bug Tracker & Wiki]

#24433: moat isn't returning bridges on successful CAPTCHA completion
--+--
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:  bridgedb-dist moat|  Actual Points:  .5
Parent ID:| Points:  1
 Reviewer:|Sponsor:  SponsorM
--+--

Comment (by isis):

 Replying to [comment:6 mcs]:
 > Kathy and I worked on integration some more and noticed the following
 issues (please let is know if you want us to open new tickets):

 Hi! Thanks for the review!

 > * The spec in README.rst needs to be updated. General issues are that
 single quotes should be replaced with double quotes and that all JSON
 values should be enclosed in quotes (e.g., the `id` value is not).

 Fixed in
 
[https://gitweb.torproject.org/user/isis/bridgedb.git/commit/?h=develop=8d8db4a06d3dff5e9f82adcb4e0e921fe3577098
 8d8db4a0]

 > * For the `/fetch` request, the `type` is specified as `moat-transports`
 but the implementation uses `client-transports`. For consistency with the
 other `type` values you may want to use `moat-transports`.

 
[https://gitweb.torproject.org/user/isis/bridgedb.git/commit/?h=develop=50a9321fadcfd0e9a4f30bc1919c1bf46d27d8e1
 50a9321f]

 > * The `data` payload is specified as an object but the implementation
 uses an array. This is permitted by the JSON API specification but seems
 unnecessary for the moat protocol (since each request and response only
 includes one JSON object).

 We can change it back to a single object if you think that's better. My
 reasoning was:

 1. I totally read the spec wrong and I thought it said they had to be
 arrays, and
 2. future-compatibility, in case we decided at some point that providing
 the user with more messages/errors might be helpful (e.g. if there is some
 non-fatal error which we might want to return/log/display on the client-
 side, but we're still also going to return bridges/captchas).

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

Re: [tor-bugs] #24615 [Applications/Tor Browser]: Resize window in 50 pixel steps

[Tor Bug Tracker & Wiki]

#24615: Resize window in 50 pixel steps
---+--
 Reporter:  tange  |  Owner:  tbb-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Minor  | Resolution:
 Keywords:  tbb-fingerprinting-resolution  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by tange):

 * keywords:   => tbb-fingerprinting-resolution


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

Re: [tor-bugs] #18044 [Applications/Tor Browser]: Prompt if Tor Browser is zoomed

[Tor Bug Tracker & Wiki]

#18044: Prompt if Tor Browser is zoomed
-+-
 Reporter:  bugzilla |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-resolution, tbb-  |  Actual Points:
  usability, tbb-bounty, tbb-torbutton   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by tange):

 Can we instead make sure the user zooms in steps that others might use to
 (similar to #24615)?

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

Re: [tor-bugs] #17650 [Applications/Tor Browser]: Cannot login to Youtube

[Tor Bug Tracker & Wiki]

#17650: Cannot login to Youtube
--+---
 Reporter:  mansdt|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-usability-website |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by tange):

 I tested on Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:52.0)
 Gecko/20100101 Firefox/52.0

 Login works (you need to authorize using phone).

 Youtube does not play immediately. Cliking 'Learn more' gives a popup:

 > Temporarily allow (juutubeurl-obfuscated)/(watch?v=6FbdqwlR0H4
 > (audio/webm; codecs="opus" (MSE)  / (juutubeurl))

 If you go to the [wiki:NoScript NoScript-button] and allow opus/webm, then
 the video plays.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24616 [Applications/Tor Browser]: Audit the use of IsSecureContext to avoid bleeding http/https origins

[Tor Bug Tracker & Wiki]

#24616: Audit the use of IsSecureContext to avoid bleeding http/https origins
--+--
 Reporter:  tom   |  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:|
--+--
 http://example.com and https://example.com are different origins and do
 not share state (cookies, etc)

 If TB edits IsSecureContext to make .onion secure, it may be the case that
 the origin separation checks use IsSecureContext and thus data will bleed
 between them. That would be bad.

 We could probably talk to Kate about this.

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

Re: [tor-bugs] #24522 [Internal Services/Tor Sysadmin Team]: Please create email alias/UID and LDAP access for Igor

[Tor Bug Tracker & Wiki]

#24522: Please create email alias/UID and LDAP access for Igor
-+-
 Reporter:  ewyatt   |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Yes please!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24615 [Applications/Tor Browser]: Resize window in 50 pixel steps

[Tor Bug Tracker & Wiki]

#24615: Resize window in 50 pixel steps
--+--
 Reporter:  tange |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Resizing the tor-browser window makes it easier to identify you.

 However, wasting the screen estate is also bad.

 I suggest two ways to have a compromise:

  * Resize the window to any size you like, but the view area in the window
 is always (n*50)x(m*50) pixels. This way everyone with a similar screen
 size will also be reported as the same size to the website.

  * Force resizing of the window to be in 50 pixel steps.

 I have no idea which one of these is easier to build.

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

Re: [tor-bugs] #24554 [Core Tor/Tor]: sched: Have per-scheduler type data in a channel_t

[Tor Bug Tracker & Wiki]

#24554: sched: Have per-scheduler type data in a channel_t
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:  #23993| Points:
 Reviewer:  pastly|Sponsor:
--+

Comment (by dgoulet):

 pastly did review and I fixed stuff. I'll rebase this on latest master and
 open a new merge request for upstream merge.

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

Re: [tor-bugs] #24367 [Core Tor/Tor]: Changing pluggable transports (during start-up) in Tor Browser is broken

[Tor Bug Tracker & Wiki]

#24367: Changing pluggable transports (during start-up) in Tor Browser is broken
-+-
 Reporter:  gk   |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  030-backport, 031-backport,  |  Actual Points:
  regression, tor-bridge-client, s8-errors,  |
  tbb-wants  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-

Comment (by nickm):

 I've been staring at the logs, and I have a new idea:
 {{{
 Nov 22 11:37:06.000 [info] TLS error while handshaking with [scrubbed]:
 wrong version number (in SSL routines:ssl3_get_record:SSLv3/TLS write
 client hello)
 }}}

 This is an error I might expect to see if we had a mismatched pluggable
 transport: if we weren't using one when we were supposed to, or if we were
 using the wrong one and the transport didn't notice.

 I've made a new branch `ideas_for_24367` to try to track down this
 possibility.  It doesn't make any changes: it just adds new logs to 0.3.2
 to keep track of our transport plans, and the bridge addresses we think
 our guards have.  Could you generate info-level logs for the failing case
 using this branch?

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

Re: [tor-bugs] #24414 [Metrics/Website]: Update list of services in services.html

[Tor Bug Tracker & Wiki]

#24414: Update list of services in services.html
-+
 Reporter:  cypherpunks  |  Owner:  irl
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by karsten):

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


Comment:

 Looks good! Added another `target="_blank"` for the external link part,
 and merged. Thanks! Closing.

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

Re: [tor-bugs] #24580 [Metrics/ExoneraTor]: Let ExoneraTor only serve completed dates

[Tor Bug Tracker & Wiki]

#24580: Let ExoneraTor only serve completed dates
+
 Reporter:  karsten |  Owner:  iwakeh
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+
Changes (by karsten):

 * status:  needs_review => needs_revision


Comment:

 Looks good. Please find
 [https://gitweb.torproject.org/user/karsten/exonerator.git/log/?h=task-24580
 my updated task-24580 branch with fixup commits]. Are these good to go in,
 squashed into yours?

 There's also a placeholder commit pointing out a minor (related) issue I
 found while testing. I'm not entirely sure what the best fix would be
 there. Do you want to give that a try?

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

Re: [tor-bugs] #24521 [Applications/Tor Browser]: Investigate Making Canvas Unfingerprintable

[Tor Bug Tracker & Wiki]

#24521: Investigate Making Canvas Unfingerprintable
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mrphs):

 * cc: mrphs (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] #24211 [Applications/Orbot]: Update UserAgent string to 52!

[Tor Bug Tracker & Wiki]

#24211: Update UserAgent string to 52!
+---
 Reporter:  cypherpunks |  Owner:  n8fr8
 Type:  defect  | Status:  new
 Priority:  Very High   |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Critical| Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---

Comment (by n8fr8):

 Done here: https://github.com/guardianproject/tor-
 browser/commit/9669dbf94b6be41c7a67c965b8995d933c1b4e9e

 New release imminent!

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

Re: [tor-bugs] #24213 [Applications/Orbot]: ORFOX - No Tor related settings/addon

[Tor Bug Tracker & Wiki]

#24213: ORFOX - No Tor related settings/addon
+---
 Reporter:  cypherpunks |  Owner:  n8fr8
 Type:  defect  | Status:  new
 Priority:  Very High   |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Critical| Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---

Comment (by n8fr8):

 Actually, the current issue is that you need to do a clean install from
 scratch. The add-ons are only installed at first run (for now)

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

Re: [tor-bugs] #24613 [Core Tor/Tor]: Avoid monotime_coarse_absolute_msec in channelpadding code

[Tor Bug Tracker & Wiki]

#24613: Avoid monotime_coarse_absolute_msec in channelpadding code
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+
Changes (by nickm):

 * cc: mikeperry, ahf (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] #24519 [Webpages/Website]: Make section headings in the FAQ linkable

[Tor Bug Tracker & Wiki]

#24519: Make section headings in the FAQ linkable
--+
 Reporter:  kat5  |  Owner:  kat5
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by kat5):

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


Comment:

 Merged by hiro.

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

Re: [tor-bugs] #24399 [Webpages/Website]: Consistent set of icons for relay flags

[Tor Bug Tracker & Wiki]

#24399: Consistent set of icons for relay flags
--+
 Reporter:  irl   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by antonela):

 Thanks both! I'll work on this review asap :)

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

Re: [tor-bugs] #24580 [Metrics/ExoneraTor]: Let ExoneraTor only serve completed dates

[Tor Bug Tracker & Wiki]

#24580: Let ExoneraTor only serve completed dates
+--
 Reporter:  karsten |  Owner:  iwakeh
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+--
Changes (by iwakeh):

 * status:  needs_revision => 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] #24580 [Metrics/ExoneraTor]: Let ExoneraTor only serve completed dates

[Tor Bug Tracker & Wiki]

#24580: Let ExoneraTor only serve completed dates
+
 Reporter:  karsten |  Owner:  iwakeh
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+
Changes (by iwakeh):

 * status:  accepted => needs_revision


Comment:

 Please review four commits on
 [https://gitweb.torproject.org/user/iwakeh/exonerator.git/log/?h=task-24580
 this branch].

 I tried to encapsulate all date related requests in a special
 ExoneraTorDate class and also separated the tests and extended them a
 little.  The goal is to make the servlets decision making obvious from the
 code and have the decision making about the date parameter in one place.
 Please check that the existing logic didn't get changed in the process.
 (Maybe, the tests could be altered to catch the things that you find?)

 The final commit tweaks the error message a little to tell users when to
 return.

 (The very same approach of encapsulation could also be used for the ip
 parameter later.)

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

Re: [tor-bugs] #24614 [Applications/Tor Browser]: update to Meek 0.28 tag

[Tor Bug Tracker & Wiki]

#24614: update to Meek 0.28 tag
--+--
 Reporter:  brade |  Owner:  brade
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #23136| Points:
 Reviewer:|Sponsor:
--+--
Changes (by brade):

 * parent:   => #23136


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24614 [Applications/Tor Browser]: update to Meek 0.28 tag

[Tor Bug Tracker & Wiki]

#24614: update to Meek 0.28 tag
--+--
 Reporter:  brade |  Owner:  brade
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Tor Launcher will soon require TOR_PT_EXIT_ON_STDIN_CLOSE support in Meek
 which will require us to move to Meek 0.28 tag.

 This is needed for Moat integration.

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

Re: [tor-bugs] #24612 [Core Tor/Tor]: Fix pretty printing of configure output for rust checks

[Tor Bug Tracker & Wiki]

#24612: Fix pretty printing of configure output for rust checks
-+
 Reporter:  isis |  Owner:  (none)
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-build, autoconf  |  Actual Points:
Parent ID:   | Points:  .1
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 We can take this in master, but the patch doesn't apply to 0.3.2.  I'm
 inclined to say that master is good enough here, if you agree.

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

Re: [tor-bugs] #24423 [Core Tor/Tor]: Fix STACK warnings in Tor

[Tor Bug Tracker & Wiki]

#24423: Fix STACK warnings in Tor
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-27  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+
Changes (by nickm):

 * status:  accepted => needs_review


Comment:

 I've tried the first approach you suggested, and didn't get
 signed/unsigned warnings, so lt's try it out.

 gk, does my `stack_again_032` branch fix the warning for you?

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

Re: [tor-bugs] #24374 [Core Tor/Tor]: Reduce monotime_coarse_absolute_msec() usage

[Tor Bug Tracker & Wiki]

#24374: Reduce monotime_coarse_absolute_msec() usage
--+
 Reporter:  ahf   |  Owner:  nickm
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  s8-perf, review-group-27  |  Actual Points:
Parent ID:  #24062| Points:
 Reviewer:  teor  |Sponsor:  Sponsor8
--+
Changes (by nickm):

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


Comment:

 Changes file added as 8441189b3caee2

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

Re: [tor-bugs] #24011 [Core Tor/Tor]: Attempt to open a stream on first hop of circuit

[Tor Bug Tracker & Wiki]

#24011: Attempt to open a stream on first hop of circuit
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-circuit   |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Ok I've tried a lot in the last hour to hit it and I can't... What I'm
 trying to get is the debug logs out of it but it could be slowing things
 down enough to never hit it :S ... If you are ever able to get it with
 debug, I'll gladly eat those ;).

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

Re: [tor-bugs] #24613 [Core Tor/Tor]: Avoid monotime_coarse_absolute_msec in channelpadding code

[Tor Bug Tracker & Wiki]

#24613: Avoid monotime_coarse_absolute_msec in channelpadding code
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 My branch `xfer_time_coarse` makes a start here.
 Also reviewable at https://oniongit.eu/nickm/tor/merge_requests/11

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24613 [Core Tor/Tor]: Avoid monotime_coarse_absolute_msec in channelpadding code

[Tor Bug Tracker & Wiki]

#24613: Avoid monotime_coarse_absolute_msec in channelpadding code
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor8-can  |
--+
 As noted on #24374, `monotime_coarse_absolute_msec()` can be expensive on
 32-bit systems since it has to do a 64-bit division to compute msec.  We
 fixed the use of `monotime_coarse_absolute_msec` in `buf_t` and
 `packed_cell_t`, but we still have it in the channelpadding system.

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

Re: [tor-bugs] #24374 [Core Tor/Tor]: Reduce monotime_coarse_absolute_msec() usage

[Tor Bug Tracker & Wiki]

#24374: Reduce monotime_coarse_absolute_msec() usage
--+
 Reporter:  ahf   |  Owner:  nickm
 Type:  enhancement   | Status:  reopened
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  s8-perf, review-group-27  |  Actual Points:
Parent ID:  #24062| Points:
 Reviewer:  teor  |Sponsor:  Sponsor8
--+
Changes (by nickm):

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


Comment:

 Note: this is missing a changes file!

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

Re: [tor-bugs] #24591 [Metrics/Atlas]: regression in contactInfo escape/display via 37a65a761afa5a62630c620ac00f42a228604df7 ?

[Tor Bug Tracker & Wiki]

#24591: regression in contactInfo escape/display via
37a65a761afa5a62630c620ac00f42a228604df7 ?
---+--
 Reporter:  cypherpunks|  Owner:  metrics-team
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by irl):

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


Comment:

 Fixed in 71c4518. Looks like this is actually already handled in the
 templating system, but wasn't in a previous version. Nickname seems to
 escape also, which is why I thought this was missing here. Perhaps that
 escaping is also unnecessary.

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

Re: [tor-bugs] #24563 [Metrics/Atlas]: Relay Search map has severe area distortions

[Tor Bug Tracker & Wiki]

#24563: Relay Search map has severe area distortions
---+--
 Reporter:  teor   |  Owner:  metrics-team
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by irl):

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


Comment:

 Merged and deployed.

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

Re: [tor-bugs] #24399 [Webpages/Website]: Consistent set of icons for relay flags

[Tor Bug Tracker & Wiki]

#24399: Consistent set of icons for relay flags
--+
 Reporter:  irl   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by irl):

 This is looking great (:

 For the IPv6, I like the IPv6 OR icon for "ReachableIPv6" and Unreachable
 IPv6 ORPort for "UnreachableIPv6", I think it would be useful though to
 keep the other IPv6 icons in case we need that for IPv6 in general,
 including the alt version but rename those to just "IPv6", "No IPv6" and
 "IPv6 Alt".

 Can we also add an "IPv4Reachable" and unreachable variant, along with
 plain IPv4 and the alt version?

 Can we add a "NoIPv6Consensus" to an "IPv6" with a question mark
 underneath? Can we then also change "NoEdConsensus" to be similar in that
 it has an "ED" and a question mark underneath?

 For V2Dir, I think this is actually fine with the V2 inside it, but adding
 a generic "Directory" would be cool. Can we invert the FallbackDir icon
 and place it on the generic directory icon for FallbackDir?

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

Re: [tor-bugs] #24398 [Applications/Tor Browser]: Plugin-container exhausts memory leading to thrash and/or crash on Linux

[Tor Bug Tracker & Wiki]

#24398: Plugin-container exhausts memory leading to thrash and/or crash on Linux
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tbb-crash, TorBrowserTeam201712R  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Applied to `tor-browser-52.5.2esr-7.5-2` (as commit
 cef2fe28a238d7e445d7c5b4292bfe27c1b71bca). 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] #23104 [Applications/Tor Browser]: CSS line-height reveals the platform Tor Browser is running on

[Tor Bug Tracker & Wiki]

#23104: CSS line-height reveals the platform Tor Browser is running on
-+-
 Reporter:  gk   |  Owner:  igt0
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-fingerprinting-os,   |  Actual Points:
  TorBrowserTeam201712R  |
Parent ID:   | Points:
 Reviewer:  gk   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Looks good. Applied to `tor-browser-52.5.2esr-7.5-2` as commit
 89d8bc54cfe6a4cd999ab1f16f434c4fb809b643.

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

Re: [tor-bugs] #23761 [Metrics/Website]: Add IPv6 relay graphs to metrics site

[Tor Bug Tracker & Wiki]

#23761: Add IPv6 relay graphs to metrics site
--+--
 Reporter:  teor  |  Owner:  metrics-team
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:
Component:  Metrics/Website   |Version:
 Severity:  Normal| Resolution:
 Keywords:  core-tor-wants, ipv6  |  Actual Points:  0.5
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--

Comment (by karsten):

 The review process of #24218 is still ongoing, but I'm sharing some
 updated graphs below, which are the result of (successfully) processing
 the descriptor archive with this new module.

 [[Image(relays-ipv6-2017-09-14-2017-12-13.png, 700px)]]

 [[Image(bridges-ipv6-2017-09-14-2017-12-13.png, 700px)]]

 [[Image(advbw-ipv6-2017-09-14-2017-12-13.png​, 700px)]]

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

Re: [tor-bugs] #23761 [Metrics/Website]: Add IPv6 relay graphs to metrics site

[Tor Bug Tracker & Wiki]

#23761: Add IPv6 relay graphs to metrics site
--+--
 Reporter:  teor  |  Owner:  metrics-team
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:
Component:  Metrics/Website   |Version:
 Severity:  Normal| Resolution:
 Keywords:  core-tor-wants, ipv6  |  Actual Points:  0.5
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--
Changes (by karsten):

 * Attachment "bridges-ipv6-2017-09-14-2017-12-13.png" added.


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

Re: [tor-bugs] #23761 [Metrics/Website]: Add IPv6 relay graphs to metrics site

[Tor Bug Tracker & Wiki]

#23761: Add IPv6 relay graphs to metrics site
--+--
 Reporter:  teor  |  Owner:  metrics-team
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:
Component:  Metrics/Website   |Version:
 Severity:  Normal| Resolution:
 Keywords:  core-tor-wants, ipv6  |  Actual Points:  0.5
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--
Changes (by karsten):

 * Attachment "advbw-ipv6-2017-09-14-2017-12-13.png" added.


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

Re: [tor-bugs] #23761 [Metrics/Website]: Add IPv6 relay graphs to metrics site

[Tor Bug Tracker & Wiki]

#23761: Add IPv6 relay graphs to metrics site
--+--
 Reporter:  teor  |  Owner:  metrics-team
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:
Component:  Metrics/Website   |Version:
 Severity:  Normal| Resolution:
 Keywords:  core-tor-wants, ipv6  |  Actual Points:  0.5
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--
Changes (by karsten):

 * Attachment "relays-ipv6-2017-09-14-2017-12-13.png" added.


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

Re: [tor-bugs] #24563 [Metrics/Atlas]: Relay Search map has severe area distortions

[Tor Bug Tracker & Wiki]

#24563: Relay Search map has severe area distortions
---+--
 Reporter:  teor   |  Owner:  metrics-team
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cypherpunks):

 * 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] #24563 [Metrics/Atlas]: Relay Search map has severe area distortions

[Tor Bug Tracker & Wiki]

#24563: Relay Search map has severe area distortions
---+--
 Reporter:  teor   |  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cypherpunks):

 * Attachment "0001-Changes-map-projection-to-Cylindrical-Equal-Area-
 fix.patch" added.


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

Re: [tor-bugs] #24218 [Metrics/Statistics]: Implement new metrics-web module for IPv6 relay statistics

[Tor Bug Tracker & Wiki]

#24218: Implement new metrics-web module for IPv6 relay statistics
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+--

Comment (by karsten):

 I finished the import of descriptors back to 2007. And while doing so I
 discovered an issue related to a UNIQUE constraint and NULL values.
 Databases can really be tricky sometimes.

 I just pushed [https://gitweb.torproject.org/karsten/metrics-
 web.git/log/?h=tasks-24218-23761 three new commits to my tasks-24218-23761
 branch]. Still ready for 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] #24610 [Core Tor/Tor]: assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed

[Tor Bug Tracker & Wiki]

#24610: assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed
-+
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by dgoulet):

 Comment from the code:

 {{{
 status = hs_client_refetch_hsdesc(_conn->hs_ident->identity_pk);
 if (BUG(status == HS_CLIENT_FETCH_HAVE_DESC)) {
   /* This case is unique because it can NOT happen in theory. Once we
 get
* a new descriptor, the HS client subsystem is notified immediately
 and
* the connections waiting for it are handled which means the state
 will
* change from renddesc wait state. Log this and continue to next
* connection. */
   continue;
 }
 }}}

 So, I think it is a wrong logic. Consider the following case:

 Imagine your client has fetched the descriptor for a service and at some
 point, all intro points weren't usable or in other words the intro points
 rotated and the client now has to fetch a new descriptor. Then this
 suspend happens while waiting for the descriptor fetch.

 We come back from suspend, the clock jumps 2000 seconds (33 minutes) and
 `rend_cache_failure_clean_callback()` is called (it is an housekeeping
 function which runs every 30 seconds). It cleans up the intro point
 failure cache (lifetime of entries are 2 minutes). Which means that the
 descriptor we have in the cache now suddenly is considered "usable".

 During that waiting period for the descriptor, a new consensus comes in so
 we have new directory information and we end up in retrying all pending
 SOCKS connection waiting for a descriptor
 `retry_all_socks_conn_waiting_for_desc()` that might have been hold back
 in the first place because we were missing directory information.

 Then, the BUG() is hit if we try a refetch for a service but for which we
 already have a descriptor. And that descriptor became usable after the
 suspend.

 So this means that the `BUG()` should not be there and be considered
 possible to have that situation.

 And extra bonus point, this should actually be a special case that we
 handle for which we try to attach the connection to a circuit instead of
 leaving it in limbo in `RENDDESC_WAIT` state and timing out after 120
 seconds. In short, put the SOCKS conn in circuit wait state and try to
 attach it if we have a usable descriptor.

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

Re: [tor-bugs] #24606 [Webpages/Website]: web pages are not fully loaded

[Tor Bug Tracker & Wiki]

#24606: web pages are not fully loaded
--+--
 Reporter:  Ahmed94   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Webpages/Website  |Version:  Tor: unspecified
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by Ahmed94):

 * version:  Tor: 0.3.2.6-alpha => Tor: unspecified


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

Re: [tor-bugs] #24606 [Webpages/Website]: web pages are not fully loaded

[Tor Bug Tracker & Wiki]

#24606: web pages are not fully loaded
--+
 Reporter:  Ahmed94   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Webpages/Website  |Version:  Tor: 0.3.2.6-alpha
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by Ahmed94):

 * severity:  Normal => Major


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

Re: [tor-bugs] #24487 [Core Tor/Tor]: Reverse path selection (choose outer hops first)

[Tor Bug Tracker & Wiki]

#24487: Reverse path selection (choose outer hops first)
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery-prop247-controller   |  Actual Points:
  needs-proposal |
Parent ID:  #9001| Points:
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-
Changes (by nickm):

 * keywords:  guard-discovery-prop247-controller => guard-discovery-
 prop247-controller needs-proposal


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

Re: [tor-bugs] #24487 [Core Tor/Tor]: Reverse path selection (choose outer hops first)

[Tor Bug Tracker & Wiki]

#24487: Reverse path selection (choose outer hops first)
+--
 Reporter:  mikeperry   |  Owner:
|  mikeperry
 Type:  defect  | Status:  assigned
 Priority:  High|  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  guard-discovery-prop247-controller  |  Actual Points:
Parent ID:  #9001   | Points:
 Reviewer:  |Sponsor:
|  SponsorV-can
+--
Changes (by asn):

 * cc: asn (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] #15599 [Applications/Tor Browser]: Range requests used by pdfjs are not isolated to URL bar domain

[Tor Bug Tracker & Wiki]

#15599: Range requests used by pdfjs are not isolated to URL bar domain
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-linkability, |  Actual Points:
  TorBrowserTeam201712   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-linkability => tbb-linkability, TorBrowserTeam201712
 * owner:  tbb-team => pospeselr


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

Re: [tor-bugs] #17933 [Applications/Tor Browser]: Tor Browser does not isolate the pdf 'download' (via the download button) to URL bar domain

[Tor Bug Tracker & Wiki]

#17933: Tor Browser does not isolate the pdf 'download' (via the download 
button)
to URL bar domain
-+-
 Reporter:  arma |  Owner:
 |  pospeselr
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-linkability, tbb-usability,  |  Actual Points:
  TorBrowserTeam201712, ff52-esr-will-have   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-linkability, tbb-usability, TorBrowserTeam201712 =>
 tbb-linkability, tbb-usability, TorBrowserTeam201712, ff52-esr-will-
 have
 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 Okay, as comment:6 and comment:9 indicated it seems we are done here:
 saving the pdf in arma's case should be working since we switched to ESR
 52 (and once all the issues with our external helper app dialog got
 fixed). Yay! Let's close this ticket then.

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

Re: [tor-bugs] #24561 [Applications/Tor Browser]: Add authenticode/marsigning check scripts to tor-browser-build

[Tor Bug Tracker & Wiki]

#24561: Add authenticode/marsigning check scripts to tor-browser-build
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201712R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * status:  new => needs_review
 * keywords:  tbb-rbm => tbb-rbm, TorBrowserTeam201712R


Comment:

 `bug_24561` (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_24561=fe6712e01e0f229f80b9d7c7294ffdff6c7fe84f)
 in my public `tor-browser-build` repo has a fix for this ticket.

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

Re: [tor-bugs] #24566 [Applications/Tor Browser]: When I open TorBrowser 7.0.11 the popup goes completely white

[Tor Bug Tracker & Wiki]

#24566: When I open TorBrowser 7.0.11 the popup goes completely white
--+---
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gk):

 Replying to [comment:9 Dbryrtfbcbhgf]:
 > Here is the video
 > ​https://filenurse.com/download/048ee301b1d2c7c3c164cd8fd5f2df5a.html
 > I reported this bug to mozilla.
 > https://bugzilla.mozilla.org/show_bug.cgi?id=1424945

 Thanks. Does this affect a clean Firefox 57.0.2 as well? If so, might be
 worth mentioning on the Mozilla ticket. That said, it seems to me 7.0.10
 worked for you a couple of days/weeks ago but suddenly now you are seeing
 this problem even with that version? Or am I misunderstanding you?

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

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

[Tor Bug Tracker & Wiki]

#21952: .Onion everywhere?: increasing the use of onion services through 
automatic
redirects and aliasing
--+--
 Reporter:  linda |  Owner:  linda
 Type:  project   | Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Webpages  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 https://addons.mozilla.org/en-US/firefox/addon/heal
 thyonions/

 (found it here:
 https://trac.torproject.org/projects/tor/wiki/org/projects/WeSupportTor )

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

Re: [tor-bugs] #24580 [Metrics/ExoneraTor]: Let ExoneraTor only serve completed dates

[Tor Bug Tracker & Wiki]

#24580: Let ExoneraTor only serve completed dates
+--
 Reporter:  karsten |  Owner:  iwakeh
 Type:  enhancement | Status:  accepted
 Priority:  Medium  |  Milestone:
Component:  Metrics/ExoneraTor  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+--
Changes (by iwakeh):

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


Comment:

 I grab this.  It will be good to create an example here for applying Java
 8 features (related to date and time) to existing code bases.

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

Re: [tor-bugs] #23840 [Community/Tor Support]: Google's reCAPTCHA fails 99%

[Tor Bug Tracker & Wiki]

#23840: Google's reCAPTCHA fails 99%
---+--
 Reporter:  cypherpunks|  Owner:  hiro
 Type:  defect | Status:  reopened
 Priority:  Immediate  |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Blocker| Resolution:
 Keywords:  noscript   |  Actual Points:
Parent ID:  #18361 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cypherpunks):

 * parent:   => #18361


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

Re: [tor-bugs] #23840 [Community/Tor Support]: Google's reCAPTCHA fails 99%

[Tor Bug Tracker & Wiki]

#23840: Google's reCAPTCHA fails 99%
---+--
 Reporter:  cypherpunks|  Owner:  hiro
 Type:  defect | Status:  reopened
 Priority:  Immediate  |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Blocker| Resolution:
 Keywords:  noscript   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 Cloudflare is using Google's reCaptcha API.
 So "Google's reCAPTCHA fails 99%" is the correct title.

 Er...

 Tor developers! Say something already!!

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

Re: [tor-bugs] #22084 [Applications/Tor Browser]: Neuter NetworkInformation API on Tor Browser Mobile

[Tor Bug Tracker & Wiki]

#22084: Neuter NetworkInformation API on Tor Browser Mobile
-+-
 Reporter:  gk   |  Owner:  igt0
 Type:  task | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile tbb-fingerprinting,   |  Actual Points:
  TorBrowserTeam201712   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  needs_review => needs_revision
 * keywords:  tbb-mobile tbb-fingerprinting, TorBrowserTeam201712R => tbb-
 mobile tbb-fingerprinting, TorBrowserTeam201712


Comment:

 Thanks. I think the code backported looks good. However, I think we should
 have a better patch format. First, we should keep the Mozilla bug number.
 That makes it easier to find the patch(es) in our tree. Second, we should
 keep the patch(set) structure: one commit in our tree should match one
 commit taken from Mozilla. This allows us to pinpoint possible issues
 easier. Third, we should fix up the commit message if needed (in your case
 you still have included "This tests not only windows, but also workers."
 even though you rightly omitted the workers related part).

 A workflow that works fine for me is having `mozilla-central` as a git
 remote and cherry picking the patches from that one into `tor-browser`
 one-by-one, fixing them up if needed and adapting the commit message
 afterwards with `git commit --amend` if needed as well.

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