Re: [tor-bugs] #23361 [Core Tor/Tor]: prop224: client can pick super old rendezvous points

[Tor Bug Tracker & Wiki]

#23361: prop224: client can pick super old rendezvous points
-+
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  needs_revision
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:  SponsorR-can
-+

Comment (by teor):

 This also needs a spec change. (Or maybe I missed the relevant part in the
 spec.)

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

Re: [tor-bugs] #23368 [Core Tor/Tor]: Add design and coding guidelines for using floating point

[Tor Bug Tracker & Wiki]

#23368: Add design and coding guidelines for using floating point
-+
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  doc, tor-safety  |  Actual Points:
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+
Changes (by teor):

 * 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

[tor-bugs] #23368 [Core Tor/Tor]: Add design and coding guidelines for using floating point

[Tor Bug Tracker & Wiki]

#23368: Add design and coding guidelines for using floating point
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  doc, tor-safety
Actual Points:|  Parent ID:
   Points:  0.5   |   Reviewer:
  Sponsor:|
--+
 We should add these to a document in doc/HACKING:

 1. Don't use floats.
 2. If you must use floats, document how the limits of floating point
 precision and calculation accuracy affect function outputs.
 3. Remember that different environments can get different results from the
 same floating point calculations. So you can't use floats in anything that
 needs to be deterministic, like consensus generation.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23367 [Metrics/Metrics website]: Onion address counts ignore descriptor upload overlap

[Tor Bug Tracker & Wiki]

#23367: Onion address counts ignore descriptor upload overlap
-+--
 Reporter:  teor |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 Based on this tor metrics paper:
 https://research.torproject.org/techreports/extrapolating-hidserv-
 stats-2015-01-31.pdf

 We ignore descriptor upload overlap periods (they're not even mentioned in
 the paper).

 During an overlap period, descriptors are published to twice as many
 HSDirs (v2 & v3). If we ignore this, we will double-count:
 * v2: uploads and unique onion addresses and descriptor ids for 1 hour per
 day,
 * v3: uploads and unique descriptor ids for 12 hours per day.

 I'm not sure if assuming that descriptors are seen by 2 sets of HSDirs per
 day covers this, because in v2 they are actually seen by 3 sets of HSDirs
 with probability 1/24, when the service address starts with 00-0B
 (assuming stats are collected from 00:00 UTC and relay clocks are
 accurate).

 And in v3, for half the day (00:00 + typical client consensus download
 delay of 1-2 hours) they are seen by 2 HSDirs, and half the day they are
 seen by 1 HSDir. Not that we measure v3 yet.

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

Re: [tor-bugs] #23357 [Core Tor/Tor]: Build with non-Cross-DSO CFI

[Tor Bug Tracker & Wiki]

#23357: Build with non-Cross-DSO CFI
+--
 Reporter:  shawn.webb  |  Owner:  (none)
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  security, defence-in-depth  |  Actual Points:
Parent ID:  | Points:  1.0
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 Replying to [comment:2 shawn.webb]:
 > CFLAGS isn't set by that point, so autoconf will complain with an error
 that `+=` was used instead of `=`.

 Is CFLAGS ever set after this?
 Because if it is, it will overwrite the CFLAGS you just set.

 Replying to [comment:11 shawn.webb]:
 > So, what I can do, is expand the patch to apply the CFLAGS and LDFLAGS
 to more of the applications (rather than just tor). This way, we skip
 applying CFI to the library code (even though the libraries in the
 codebase get statically linked).

 Please make this change and re-submit a patch or git 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] #18101 [Applications/Tor Browser]: IP leak from Windows UI dialog with URI

[Tor Bug Tracker & Wiki]

#18101: IP leak from Windows UI dialog with URI
-+-
 Reporter:  uileak   |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-proxy-bypass, ip-leak,   |  Actual Points:
  TorBrowserTeam201708R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:49 arthuredelstein]:
 > Unfortunately, I haven't yet been able to test these on old Linux and
 macOS platforms. The current platforms on desktops I tested (XFCE, KDE,
 macOS) do not show a text box in the Open Dialog

 I can find 3 text boxes in the macOS 10.12 Open Dialog:
 * command-shift-G shows the "Go to the folder" dialog, but doesn't seem to
 allow URLs
 * the share button (square with upward arrow) allows loading arbitrary
 share extensions, which can access the network, but they require user
 action
 * the search field queries the local spotlight database, and stores
 anything typed into it in the find pasteboard and shares it with other
 apps (#14139)

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

Re: [tor-bugs] #23365 [Internal Services/Tor Sysadmin Team]: Make safetyboard.tp.o cname for our hotcrp submission server

[Tor Bug Tracker & Wiki]

#23365: Make safetyboard.tp.o cname for our hotcrp submission server
-+-
 Reporter:  arma |  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 weasel):

 ;; ANSWER SECTION:
 safetyboard.torproject.net. 3600 IN A   198.96.155.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

Re: [tor-bugs] #18101 [Applications/Tor Browser]: IP leak from Windows UI dialog with URI

[Tor Bug Tracker & Wiki]

#18101: IP leak from Windows UI dialog with URI
-+-
 Reporter:  uileak   |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-proxy-bypass, ip-leak,   |  Actual Points:
  TorBrowserTeam201708R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * status:  needs_information => needs_review


Comment:

 Replying to [comment:48 gk]:

 Answering questions in reverse order:

 > And could you verify that other Tor Browser platforms are unaffected?
 comment:7 seems to point this out for Linux. See comment:9 for macOS.

 Here's a patch that covers all platforms:
 https://github.com/arthuredelstein/tor-browser/commit/18101+2

 Unfortunately, I haven't yet been able to test these on old Linux and
 macOS platforms. The current platforms on desktops I tested (XFCE, KDE,
 macOS) do not show a text box in the Open Dialog. Once I have builds
 ready, I will post them on this ticket so that people can test on old
 Mac/Linux platforms if they have them.

 > Arthur: What do we want to do for XP (see comment:10)?

 I am inclined to treat this problem as wontfix, because XP is deprecated
 by Microsoft and is expected to be deprecated in September by Mozilla as
 well. I did spend a little time looking into the problem but I don't see a
 quick solution.

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

Re: [tor-bugs] #12541 [Core Tor/Tor]: Integrate KIST socket/circuit scheduling

[Tor Bug Tracker & Wiki]

#12541: Integrate KIST socket/circuit scheduling
-+-
 Reporter:  robgjansen   |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  performance, tcp, kist, scheduling,  |  Actual Points:
  tor-relay, term-project-ideas, review- |
  group-22   |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_revision => accepted
 * owner:  pastly => dgoulet


Comment:

 Progress addressing all the review in `ticket12541_032_01`.

 It's missing few things so not 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] #23365 [Internal Services/Tor Sysadmin Team]: Make safetyboard.tp.o cname for our hotcrp submission server

[Tor Bug Tracker & Wiki]

#23365: Make safetyboard.tp.o cname for our hotcrp submission server
-+-
 Reporter:  arma |  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):

 One option weasel suggests is that we could put it on
 safetyboard.torproject.'''net'''.

 That would isolate it from other Tor sites. But it would also potentially
 confuse people who thought we were at .org and didn't understand to go
 somewhere else.

 How's this for a plan: we put it on the .net domain, and tell people that
 address, but also we run a tiny website at safetyboard.torproject.org that
 does a redirect to the .net version. That way if people get confused they
 will still recover.

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

Re: [tor-bugs] #23365 [Internal Services/Tor Sysadmin Team]: Make safetyboard.tp.o cname for our hotcrp submission server

[Tor Bug Tracker & Wiki]

#23365: Make safetyboard.tp.o cname for our hotcrp submission server
-+-
 Reporter:  arma |  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):

 Complicating factor: when hotcrp sets a cookie, the cookie would get set
 in the torproject.org domain, so browsers would then offer it to all the
 other torproject.org sites too. Hm.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23366 [Core Tor/Tor]: test: test_options_validate__outbound_addresses is broken

[Tor Bug Tracker & Wiki]

#23366: test: test_options_validate__outbound_addresses is broken
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-test
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Turns out that `test_options_validate__outbound_addresses()` tries to test
 a bad `OutboundBindAddress` option and thus expects `options_validate()`
 to return -1.

 However, in `options_validate()`:

 {{{
   if (parse_outbound_addresses(options, 1, msg) < 0)
 return -1;
 }}}

 ... but if you look at `parse_outbound_addresses()` it ONLY returns 0 so
 it's simply not working. Was added in with commit `81c78ec7556` which is
 tor-0.3.0.3-alpha.

 `options_act()` also calls `parse_outbound_addresses()` in the same way.

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

Re: [tor-bugs] #22618 [Applications/Tor Browser]: Downloading pdf file via file:/// is stalling if the external helper dialog is enabled

[Tor Bug Tracker & Wiki]

#22618: Downloading pdf file via file:/// is stalling if the external helper 
dialog
is enabled
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-7.0-issues, tbb-regression,  |  Actual Points:
  tbb-e10s, TorBrowserTeam201708R|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * keywords:  tbb-7.0-issues, tbb-regression, tbb-e10s, TorBrowserTeam201708
 => tbb-7.0-issues, tbb-regression, tbb-e10s, TorBrowserTeam201708R
 * status:  needs_revision => needs_review


Comment:

 Here is a fixup patch for torbutton:
 
https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug21766-fixup-01

 And here is one for the browser:
 https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug21766-fixup-01

 Kathy and I are not sure how best to handle the commit message. We did a
 `git commit --squash ...` but we then wrote the commit message that we
 think should be preserved when rebasing is done (when the three Bug 19273
 commits will be squashed together). Hopefully what we did will work, but
 please let us know if we should do something different.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23365 [Internal Services/Tor Sysadmin Team]: Make safetyboard.tp.o cname for our hotcrp submission server

[Tor Bug Tracker & Wiki]

#23365: Make safetyboard.tp.o cname for our hotcrp submission server
-+-
 Reporter:  arma |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Hello admin peoples,

 The Tor Research Safety Board will soon be running a hotcrp submission
 server on 198.96.155.11. (It is maintained by Ian, and the address is
 right next door to submit.petsymposium.org.)

 Can we make a cname or equivalent, so "safetyboard.torproject.org" sends
 people to 198.96.155.11?

 The goal is to have a better way for people to submit their safety board
 requests than "try mailing Roger".

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

Re: [tor-bugs] #23286 [Metrics/CollecTor]: use index-json classes from metrics-lib

[Tor Bug Tracker & Wiki]

#23286: use index-json classes from metrics-lib
---+-
 Reporter:  iwakeh |  Owner:  metrics-team
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:  CollecTor 1.3.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

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


Comment:

 Merged. Closing. 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] #14201 [Metrics/Onionoo]: Configure out/ directory path somewhere else than in web.xml.

[Tor Bug Tracker & Wiki]

#14201: Configure out/ directory path somewhere else than in web.xml.
-+---
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Onionoo-1.4.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

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


Comment:

 Sounds good. Merged with `{}`. 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] #23364 [Applications/Tor Browser]: RBM_NUM_PROCS not respected

[Tor Bug Tracker & Wiki]

#23364: RBM_NUM_PROCS not respected
--+
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arthuredelstein):

 Thanks -- I will give it a try at some point and let you know if I still
 have trouble.

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

Re: [tor-bugs] #22614 [Applications/Tor Browser]: Make e10s/non-e10s Tor Browsers indistinguishable

[Tor Bug Tracker & Wiki]

#22614: Make e10s/non-e10s Tor Browsers indistinguishable
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff52-esr, tbb-fingerprinting  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Backport removal of window.showModalDialog
 https://bugzilla.mozilla.org/show_bug.cgi?id=981796

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

Re: [tor-bugs] #23364 [Applications/Tor Browser]: RBM_NUM_PROCS not respected

[Tor Bug Tracker & Wiki]

#23364: RBM_NUM_PROCS not respected
--+
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by boklm):

 Yes, it should work without using sudo (at least it works for me). If it
 doesn't, it is probably something we should fix.

 Commit 86210c6821e393e98dd58c7d7bb6223755b496d5 fixed some permission
 issues on some systems when running the containers, so maybe you were
 affected by that.

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

Re: [tor-bugs] #23364 [Applications/Tor Browser]: RBM_NUM_PROCS not respected

[Tor Bug Tracker & Wiki]

#23364: RBM_NUM_PROCS not respected
--+
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arthuredelstein):

 In general I was running into errors when I didn't use sudo. I recall it
 had something to do with running the container. It's possible that I need
 to wipe the whole directory and start again without sudo -- should that
 work?

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

Re: [tor-bugs] #23363 [Applications/Tor Browser]: youtube blank white page

[Tor Bug Tracker & Wiki]

#23363: youtube blank white page
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by cypherpunks):

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


Comment:

 Duplicate of #22129.

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

Re: [tor-bugs] #23363 [Applications/Tor Browser]: youtube blank white page

[Tor Bug Tracker & Wiki]

#23363: youtube blank white page
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


Comment:

 #20314 is needed 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] #23364 [Applications/Tor Browser]: RBM_NUM_PROCS not respected

[Tor Bug Tracker & Wiki]

#23364: RBM_NUM_PROCS not respected
--+
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by boklm):

 Ah,ok. But why are you running it with sudo?

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

Re: [tor-bugs] #23364 [Applications/Tor Browser]: RBM_NUM_PROCS not respected (was: RBM_NUM_CORES not respected)

[Tor Bug Tracker & Wiki]

#23364: RBM_NUM_PROCS not respected
--+
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by arthuredelstein):

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


Old description:

> I tried using the RBM_NUM_CORES option (implemented in #23075) with tor-
> browser-build. Unfortunately the build continued to use the default 4
> cores for some reason.
>
> If I replace the line
> {{{
>  num_procs: '[% GET ENV.RBM_NUM_PROCS ? ENV.RBM_NUM_PROCS : "4" %]'
> }}}
> with
> {{{
>  num_procs: '[% GET ENV.RBM_NUM_PROCS ? ENV.RBM_NUM_PROCS : "32" %]'
> }}}
> then it uses 32 cores as the default. So somehow the RBM_NUM_CORES env
> var is not being detected.

New description:

 I tried using the RBM_NUM_PROCS option (implemented in #23075) with tor-
 browser-build. Unfortunately the build continued to use the default 4
 cores for some reason.

 If I replace the line
 {{{
  num_procs: '[% GET ENV.RBM_NUM_PROCS ? ENV.RBM_NUM_PROCS : "4" %]'
 }}}
 with
 {{{
  num_procs: '[% GET ENV.RBM_NUM_PROCS ? ENV.RBM_NUM_PROCS : "32" %]'
 }}}
 then it uses 32 cores as the default. So somehow the RBM_NUM_PROCS env var
 is not being detected.

--

Comment:

 OK, false alarm. Turns out my problem was that I set env var with my user
 account, but then called `sudo make alpha`. The env var is not preserved
 when I use `sudo`. Thanks, boklm!

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

Re: [tor-bugs] #23261 [Applications/Tor Launcher]: implement configuration portion of new Tor Launcher UI

[Tor Bug Tracker & Wiki]

#23261: implement configuration portion of new Tor Launcher UI
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID:  #21951 | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by linda):

 * Attachment "tor-launcher-redesign-v8.pdf" added.


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

Re: [tor-bugs] #23364 [Applications/Tor Browser]: RBM_NUM_CORES not respected

[Tor Bug Tracker & Wiki]

#23364: RBM_NUM_CORES not respected
--+---
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by boklm):

 You can check if the value of `buildconf/num_procs` is correctly set with
 `./rbm/rbm showconf tor buildconf/num_procs`.

 This is what I have:
 {{{
 $ ./rbm/rbm showconf tor buildconf/num_procs
 4
 $ RBM_NUM_PROCS=32 ./rbm/rbm showconf tor buildconf/num_procs
 32
 }}}

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

Re: [tor-bugs] #19270 [Applications/Tor Browser]: update warning on about:tor is not eye-catchy enough

[Tor Bug Tracker & Wiki]

#19270: update warning on about:tor is not eye-catchy enough
--+--
 Reporter:  mrphs |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-usability, ux-team|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * keywords:  tbb-usability, UX => tbb-usability, ux-team


Comment:

 Change the background color from green to red.

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

 Replying to [comment:39 alecmuffett]:
 > Replying to [comment:38 arthuredelstein]:
 > > The client could also somehow indicate in the HTTP request that it
 supports onions.
 >
 > Cute idea, although I can entirely imagine that suggestion would cause
 the //Tor Users Should Look Nondescript// anti-fingerprinting-community,
 to have kittens.

 Good, I love kittens. :) But making it difficult to distinguish Tor
 Browser from other browsers is an unrealistic goal anyhow.

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

Re: [tor-bugs] #23363 [Applications/Tor Browser]: youtube blank white page

[Tor Bug Tracker & Wiki]

#23363: youtube blank white page
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Okay, this seems to be not a bug on our side 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] #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 alecmuffett):

 Replying to [comment:38 arthuredelstein]:
 > The client could also somehow indicate in the HTTP request that it
 supports onions.

 Cute idea, although I can entirely imagine that suggestion would cause the
 //Tor Users Should Look Nondescript// anti-fingerprinting-community, to
 have kittens.

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

Re: [tor-bugs] #23364 [Applications/Tor Browser]: RBM_NUM_CORES not respected

[Tor Bug Tracker & Wiki]

#23364: RBM_NUM_CORES not respected
--+---
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by cypherpunks):

 * status:  new => needs_information


Comment:

 `CORES` or `PROCS`?

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

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

[Tor Bug Tracker & Wiki]

#19001: Tor Browser with Snowflake
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  project| Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by dcf):

 == windows reproducible build ==

 I pushed some preliminary code for getting started with a windows
 reproducible build.
   https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/log/?h
 =snowflake-windows=0f48dc9e1904fa0643576fc8dcf3db50a4d2f959

 It doesn't work yet; after `./mkbundle-windows.sh versions.alpha`, it
 eventually fails with:
 {{{
 + /home/ubuntu/build/webrtc/src/out_bootstrap/gn gen out/Release '--args=
 target_os="win" target_cpu="x86" is_debug=false
 treat_warnings_as_errors=false is_component_build=false is_clang=true
 use_sysroot=false clang_use_chrome_plugins=false
 clang_base_path="/home/ubuntu/build/clang" rtc_include_opus=false
 rtc_include_ilbc=false rtc_include_internal_audio_device=false
 rtc_include_tests=true'
 ERROR at //build/config/BUILDCONFIG.gn:239:3: Assertion failed.
   assert(target_os == host_os, "Win cross-compiles only work on win
 hosts.")
   ^-
 Win cross-compiles only work on win hosts.
 }}}
 But at this point one can ssh into the build VM and start debugging the
 build failures.

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

Re: [tor-bugs] #23364 [Applications/Tor Browser]: RBM_NUM_CORES not respected

[Tor Bug Tracker & Wiki]

#23364: RBM_NUM_CORES not respected
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Description changed by arthuredelstein:

Old description:

> I tried using the RBM_NUM_CORES option (implemented in #23075) with tor-
> browser-build. Unfortunately the build continued to use the default 4
> cores for some reason. If I replace the line in
> {{{
>  num_procs: '[% GET ENV.RBM_NUM_PROCS ? ENV.RBM_NUM_PROCS : "4" %]'
> }}}
> with
> {{{
>  num_procs: '[% GET ENV.RBM_NUM_PROCS ? ENV.RBM_NUM_PROCS : "32" %]'
> }}}
> then it uses 32 cores as the default. So somehow the RBM_NUM_CORES env
> var is not being detected.

New description:

 I tried using the RBM_NUM_CORES option (implemented in #23075) with tor-
 browser-build. Unfortunately the build continued to use the default 4
 cores for some reason.

 If I replace the line
 {{{
  num_procs: '[% GET ENV.RBM_NUM_PROCS ? ENV.RBM_NUM_PROCS : "4" %]'
 }}}
 with
 {{{
  num_procs: '[% GET ENV.RBM_NUM_PROCS ? ENV.RBM_NUM_PROCS : "32" %]'
 }}}
 then it uses 32 cores as the default. So somehow the RBM_NUM_CORES env var
 is not being detected.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23364 [Applications/Tor Browser]: RBM_NUM_CORES not respected

[Tor Bug Tracker & Wiki]

#23364: RBM_NUM_CORES not respected
--+--
 Reporter:  arthuredelstein   |  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:|
--+--
 I tried using the RBM_NUM_CORES option (implemented in #23075) with tor-
 browser-build. Unfortunately the build continued to use the default 4
 cores for some reason. If I replace the line in
 {{{
  num_procs: '[% GET ENV.RBM_NUM_PROCS ? ENV.RBM_NUM_PROCS : "4" %]'
 }}}
 with
 {{{
  num_procs: '[% GET ENV.RBM_NUM_PROCS ? ENV.RBM_NUM_PROCS : "32" %]'
 }}}
 then it uses 32 cores as the default. So somehow the RBM_NUM_CORES env var
 is not being detected.

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

Re: [tor-bugs] #23286 [Metrics/CollecTor]: use index-json classes from metrics-lib

[Tor Bug Tracker & Wiki]

#23286: use index-json classes from metrics-lib
---+-
 Reporter:  iwakeh |  Owner:  metrics-team
 Type:  enhancement| Status:  merge_ready
 Priority:  Medium |  Milestone:  CollecTor 1.3.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Fine to merge now.  I think it is unavoidable to have another commit here
 for the next metrics-lib version and possibly the move of class FileType
 from package 'index' to 'internal' (depends on the metrics-lib release to
 come).
 So, merging now seems best.

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

Re: [tor-bugs] #14201 [Metrics/Onionoo]: Configure out/ directory path somewhere else than in web.xml.

[Tor Bug Tracker & Wiki]

#14201: Configure out/ directory path somewhere else than in web.xml.
-+---
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Onionoo-1.4.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * status:  needs_review => merge_ready


Comment:

 Replying to [comment:10 karsten]:
 > Please review
 [https://gitweb.torproject.org/user/karsten/onionoo.git/log/?h=task-14201
 my task-14201] branch.

 This looks fine.  The old approach was too eager and limiting this to the
 web component is better.

 One tiny thing in 'Main':
 {{{
 -  private Main() {/* empty */}
 +  private Main() {
 +  }
 }}}

 The
 
[https://trac.torproject.org/projects/tor/wiki/org/teams/MetricsTeam/MetricsJavaStyleGuide#s4.1.3
 -braces-empty-blocks coding guidelines] state that empty blocks may be
 concise. I would prefer the comment or `{}` without comment to the
 dangling brace, which looks as if something was missing.

 Other than this, merge ready.

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

Re: [tor-bugs] #23361 [Core Tor/Tor]: prop224: client can pick super old rendezvous points

[Tor Bug Tracker & Wiki]

#23361: prop224: client can pick super old rendezvous points
-+
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  needs_revision
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:  SponsorR-can
-+

Comment (by arma):

 You might also find it useful to put a warn message in, if you're about to
 send a v3 rend request to a relay that doesn't support a v3 rend request.
 In case there are other edge cases (or new ones show up 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] #23361 [Core Tor/Tor]: prop224: client can pick super old rendezvous points

[Tor Bug Tracker & Wiki]

#23361: prop224: client can pick super old rendezvous points
-+
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  needs_revision
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:  SponsorR-can
-+
Changes (by asn):

 * status:  needs_review => needs_revision


Comment:

 Patch does not handle cannibalized circs correctly. Cannibalized circs to
 non-v3-supporting nodes should not be used for v3 rend.

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

Re: [tor-bugs] #23363 [Applications/Tor Browser]: youtube blank white page

[Tor Bug Tracker & Wiki]

#23363: youtube blank white page
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 Thank you for drawing my attention to the slider. Youtube's new design
 seems to require javascript to render. Setting the slider to medium fixed
 it for 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] #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 arthuredelstein):

 Replying to [comment:31 tom]:

 > Now there is one wrinkle in my idea. Alt-Svc is delivered once, and then
 the client remembers it and uses it the next time. (Optionally it uses it
 the first time too, but that gains us no security.)  Remembering means
 state. State means tracking.

 Generally speaking, Tor Browser wipes all state after every session. (We
 should check that that is true for Alt-Svc.) And as Mozilla has already
 kindly implemented [https://bugzilla.mozilla.org/show_bug.cgi?id=1334690
 first-party isolation for Alt-Svc], I think it won't be usable for
 tracking.

 Replying to [comment:35 alecmuffett]:
 > Great.  I posted a long and friendly explanation, and Trac swallowed it
 because it wanted email verification.

 > 2) issuing AltSvc headers makes no sense unless the client is coming
 from an exit node, so if you want people to adopt that solution then you
 need to make it really cheap for sites to check if a client is an exit
 node

 The client could also somehow indicate in the HTTP request that it
 supports onions.

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

Re: [tor-bugs] #23258 [Applications/Tor Browser]: HTTPS Everywhere is not working when noscript is enabled globally

[Tor Bug Tracker & Wiki]

#23258: HTTPS Everywhere is not working when noscript is enabled globally
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  fixed
 Keywords:  TorBrowserTeam201708R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:16 gk]:
 > So, the startup delay is not related to the whitelisting but to the new
 HTTPS-E itself. :/

 They have a couple ideas to resolve a bit that issue, you may want to
 follow https://github.com/EFForg/https-everywhere/issues/12232

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

Re: [tor-bugs] #23363 [Applications/Tor Browser]: youtube blank white page

[Tor Bug Tracker & Wiki]

#23363: youtube blank white page
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by cypherpunks):

 * owner:  (none) => tbb-team
 * status:  new => needs_information
 * component:  - Select a component => Applications/Tor Browser


Comment:

 What is your security slider setting?

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

[tor-bugs] #23363 [- Select a component]: youtube blank white page

[Tor Bug Tracker & Wiki]

#23363: youtube blank white page
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Hello, I'm getting a blank white page with a thin line at the top whenever
 I access youtube.com in the tor browser.

 Previously I was able to access youtube by just closing the tor browser
 then trying again. Now the problem is persistent.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23362 [Applications/Tor Browser]: consider performing network operations in a dedicated process for ESR59

[Tor Bug Tracker & Wiki]

#23362: consider performing network operations in a dedicated process for ESR59
--+
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  ff59-esr, tbb-
  |  security
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 ESR59 will have approx. 8 processes, excluding content processes. And it
 makes sense to run them all in strong sandboxes without network access. To
 achieve this it could be helpful to discuss and coordinate this work with
 Mozilla in https://bugzilla.mozilla.org/show_bug.cgi?id=1322426.

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

Re: [tor-bugs] #23325 [Internal Services/Tor Sysadmin Team]: Torproject mirror cloud.ipnett.se has connectivity issues

[Tor Bug Tracker & Wiki]

#23325: Torproject mirror cloud.ipnett.se has connectivity issues
-+
 Reporter:  hellais  |  Owner:  tpa
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Major| Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


Comment:

 Thanks for tracking this down and getting it resolved.

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

Re: [tor-bugs] #23316 [Webpages/Website]: Replace templates at https://media.torproject.org/templates/

[Tor Bug Tracker & Wiki]

#23316: Replace templates at https://media.torproject.org/templates/
--+
 Reporter:  steph |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by steph):

 * 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] #14201 [Metrics/Onionoo]: Configure out/ directory path somewhere else than in web.xml.

[Tor Bug Tracker & Wiki]

#14201: Configure out/ directory path somewhere else than in web.xml.
-+---
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Onionoo-1.4.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * status:  needs_revision => needs_review


Comment:

 Please review
 [https://gitweb.torproject.org/user/karsten/onionoo.git/log/?h=task-14201
 my task-14201] 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] #23326 [Applications/Tor Browser]: Create WebExtension API for everything needed by privacy-preserving extensions

[Tor Bug Tracker & Wiki]

#23326: Create WebExtension API for everything needed by privacy-preserving
extensions
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


Comment:

 Replying to [comment:2 cypherpunks]:
 > It's your task. You are making privacy-preserving browser, not Mozilla.

 Mozilla uplifts Tor Browser patches to upstream Firefox, so that statement
 is not true.

 > If you are going to upgrade the browser with Mozilla code, you will have
 to create missing APIs you need.

 Ok, then they (Tor Browser developers) will ask Mozilla to add those
 missing APIs, and not TB devs themselves, right?

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

Re: [tor-bugs] #14201 [Metrics/Onionoo]: Configure out/ directory path somewhere else than in web.xml.

[Tor Bug Tracker & Wiki]

#14201: Configure out/ directory path somewhere else than in web.xml.
-+
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Onionoo-1.4.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by karsten):

 I'll prepare a patch for the smaller change in order to save an iteration
 in this review process.

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

Re: [tor-bugs] #21674 [Applications/Tor Browser]: Do we need to set network.dns.blockDotOnion to false in ESR 52?

[Tor Bug Tracker & Wiki]

#21674: Do we need to set network.dns.blockDotOnion to false in ESR 52?
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must,  |  Actual Points:
  TorBrowserTeam201708   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by cypherpunks):

 Replying to [ticket:21674 gk]:
 > `network.dns.blockDotOnion` is set to `false` in Firefox but we might
 need to set it to `true` in Tor Browser for transparent proxying.
 Vice versa.
 According to RFC 7686, only `.onion`-unaware browsers should set it to
 `true`.
 > Do we need to set network.dns.blockDotOnion to false in ESR 52?
 Yes.

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

Re: [tor-bugs] #22232 [Applications/Tor Launcher]: gather info on how Tor Launcher uses bootstrap status messages

[Tor Bug Tracker & Wiki]

#22232: gather info on how Tor Launcher uses bootstrap status messages
---+--
 Reporter:  catalyst   |  Owner:  brade
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  usability, ux  |  Actual Points:
Parent ID:  #21951 | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--

Comment (by mcs):

 Replying to [comment:10 cypherpunks]:
 > > The PROGRESS field of the STATUS_CLIENT messages are used directly
 > *is used

 Thanks! Fixed via commit a120bb02f4dbcb3e26fe0c031d383a9a8681678a on Tor
 Launcher master (we also changed the wording of that sentence slightly to
 avoid confusion).

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

Re: [tor-bugs] #13398 [Applications/Tor Browser]: at startup, browser gleans user FULL NAME (real name, given name) from O/S

[Tor Bug Tracker & Wiki]

#13398: at startup, browser gleans user FULL NAME (real name, given name) from 
O/S
--+---
 Reporter:  zinc  |  Owner:  pospeselr
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201708  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by mcs):

 Replying to [comment:22 gk]:
 > However, after thinking more about this patch I have a bigger concern.
 What is it defending against? I mean, what prevents a rogue extension from
 flipping our pref and just read the values we tried to hide? (I know I
 suggested the pref approach first and should probably have thought more
 about it and not just have recommended the "standard thing" when Firefox
 patches are concerned).
 >
 > One could argue that's not possible with the new WebExtensions-based
 add-ons (which is correct) but then I bet those extensions are not allowed
 to extract the info we want to hide in the first place either (but I could
 be wrong about that). So, should we just say this will be fixed when we
 switch to Firefox 59? And, if we really want to defend against that in the
 ESR 52 cycle we would just rip out the offending code (not bothering about
 upstreaming the patch)?

 So maybe just add #ifdefs for ESR52 to remove the code? I'd still feel
 better if the info was never read (and thus present in memory) in ESR 59
 and later, but in theory the info should not be accessible to
 Webextensions.

 > mcs: What about your refactoring concerns?

 That concern is fairly minor; we could just wait and see what Mozilla says
 if or when we try to upstream the patch. And we can change our approach
 later if upstreaming does not happen (and therefore we would need to
 maintain a patch forever).

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

Re: [tor-bugs] #23361 [Core Tor/Tor]: prop224: client can pick super old rendezvous points

[Tor Bug Tracker & Wiki]

#23361: prop224: client can pick super old rendezvous points
-+
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:  SponsorR-can
-+
Changes (by dgoulet):

 * status:  new => needs_review
 * reviewer:   => asn


Comment:

 See branch: `bug23361_032_01`

 The change it not that trivial but I hope simple enough.

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

Re: [tor-bugs] #22836 [Metrics/Metrics website]: Parse CollecTor's index.json and provide our own directory listing

[Tor Bug Tracker & Wiki]

#22836: Parse CollecTor's index.json and provide our own directory listing
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Please review [https://gitweb.torproject.org/karsten/metrics-
 web.git/commit/?h=task-22836=59fa501ea830504534b3b309ed6280719edc1b9d
 commit 59fa501 in my task-22836 branch] which now uses the index.json-
 handling classes from metrics-lib.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23361 [Core Tor/Tor]: prop224: client can pick super old rendezvous points

[Tor Bug Tracker & Wiki]

#23361: prop224: client can pick super old rendezvous points
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  prop224, tor-hs
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  SponsorR-can  |
--+
 We just discovered that we dont enforce protover rules when prop224
 clients pick rendezvous points, so we end up picking rps on 0.2.8 which
 make our circuits hang.

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

Re: [tor-bugs] #22836 [Metrics/Metrics website]: Parse CollecTor's index.json and provide our own directory listing

[Tor Bug Tracker & Wiki]

#22836: Parse CollecTor's index.json and provide our own directory listing
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 FWIW, I'm working on a patch based on our discussion from yesterday.

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

Re: [tor-bugs] #23360 [Core Tor/Tor]: prop224: Service has dead code which removed a feature

[Tor Bug Tracker & Wiki]

#23360: prop224: Service has dead code which removed a feature
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+
Changes (by dgoulet):

 * status:  needs_revision => needs_review


Comment:

 Fixup commit pushed.

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

Re: [tor-bugs] #23346 [Core Tor/Tor]: prop224: HSdir set changed detection fails sometimes

[Tor Bug Tracker & Wiki]

#23346: prop224: HSdir set changed detection fails sometimes
-+
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:  SponsorR-can
-+
Changes (by dgoulet):

 * status:  needs_review => merge_ready
 * reviewer:   => dgoulet


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

Re: [tor-bugs] #23346 [Core Tor/Tor]: prop224: HSdir set changed detection fails sometimes

[Tor Bug Tracker & Wiki]

#23346: prop224: HSdir set changed detection fails sometimes
-+
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  SponsorR-can
-+

Comment (by dgoulet):

 lgtm;

 I've been testing this for more than 24h now and I haven't see the problem
 happening again.

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

Re: [tor-bugs] #23355 [Core Tor/Tor]: prop224: Implement a client purge state for NEWNYM

[Tor Bug Tracker & Wiki]

#23355: prop224: Implement a client purge state for NEWNYM
-+
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  enhancement  | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:  #23300   | Points:
 Reviewer:  asn  |Sponsor:
-+
Changes (by dgoulet):

 * status:  new => needs_review
 * reviewer:   => asn


Comment:

 Branch `ticket23355_032_01`

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

Re: [tor-bugs] #23360 [Core Tor/Tor]: prop224: Service has dead code which removed a feature

[Tor Bug Tracker & Wiki]

#23360: prop224: Service has dead code which removed a feature
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_revision
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+
Changes (by asn):

 * status:  needs_review => needs_revision


Comment:

 Hmm. Patch looks good to me, but not sure why you swapped the content of
 `hs_hsdir_set_changed_consider_reupload()` with
 `hs_service_dir_info_changed()`. I don't mind the func name change that
 much, but now the comment has been outdated. The `consider_reupload()`
 func has better comment.

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

Re: [tor-bugs] #23327 [Core Tor/Tor]: prop224: client-side memleaks on the last hidserv request subsystem

[Tor Bug Tracker & Wiki]

#23327: prop224: client-side memleaks on the last hidserv request subsystem
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, prop224, memleak  |  Actual Points:
Parent ID:  #23300| Points:  0.3
 Reviewer:  asn   |Sponsor:
--+
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 Yep. Much better!

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

Re: [tor-bugs] #23346 [Core Tor/Tor]: prop224: HSdir set changed detection fails sometimes

[Tor Bug Tracker & Wiki]

#23346: prop224: HSdir set changed detection fails sometimes
-+
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  SponsorR-can
-+
Changes (by asn):

 * status:  new => needs_review


Comment:

 Please see branch `bug23346` in my repo for a fix to these 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] #23360 [Core Tor/Tor]: prop224: Service has dead code which removed a feature

[Tor Bug Tracker & Wiki]

#23360: prop224: Service has dead code which removed a feature
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+
Changes (by dgoulet):

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


Comment:

 Code removal! Yay!

 Branch: `bug23360_032_01`

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

[tor-bugs] #23360 [Core Tor/Tor]: prop224: Service has dead code which removed a feature

[Tor Bug Tracker & Wiki]

#23360: prop224: Service has dead code which removed a feature
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-hs, prop224
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 It appears that `hs_service_dir_info_changed()` has become unused after
 the massive merge of #20657 which was replaced by
 `hs_hsdir_set_changed_consider_reupload()` but then the
 `consider_hsdir_upload_retry()` is not used anymore.

 That feature was about retrying to HSDir for which when we want to upload
 to, we are missing a descriptor. That is not possible to happen anymore
 because in order to compute the HSDir index, the descriptor is needed thus
 mandatory to have in order to learn if the HSDir is the correct one we
 need on the hashring.

 The fix here is to use `hs_service_dir_info_changed()` in `nodelist.c` and
 make it do what `hs_hsdir_set_changed_consider_reupload()` does. And
 remove the `hsdir_missing_info` feature.

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

Re: [tor-bugs] #23318 [Core Tor/Tor]: compute_weighted_bandwidths: do not add 0.5 to final_weight

[Tor Bug Tracker & Wiki]

#23318: compute_weighted_bandwidths: do not add 0.5 to final_weight
+
 Reporter:  cypherpunks |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Very High   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  path-selection  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by cypherpunks):

 It's not only case when code bypassing limits, as noticed by pastly in
 IRC. Guard nodes weights only if new guard added by
 `entry_guards_expand_sample`. Sample guard or subsets never being re-
 weighted: once sampled non-Exit Guard will be used as Exit+Guard (if
 operator change it policy) by client.
 (See related #22779)

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

Re: [tor-bugs] #22752 [Core Tor/Tor]: Assertion failure in consensus_cache_entry_handle_get on Windows

[Tor Bug Tracker & Wiki]

#22752: Assertion failure in consensus_cache_entry_handle_get on Windows
--+
 Reporter:  ahf   |  Owner:  nickm
 Type:  defect| Status:  needs_revision
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:  Sponsor4
--+
Changes (by dgoulet):

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


Comment:

 * I see this that is a very puzzling thing for which I think I figured it
 out:

 {{{
 +  cache->max_entries = max_entries;
 +#ifdef MUST_UNMAP_TO_UNLINK
 +  max_entries = 100;
 +#endif
cache->dir = storage_dir_new(directory, max_entries);
 }}}

  I've looked on how `consensus_cache_open()` is used and how big
 `max_entries` can be and seems it will always be (128 * 2) so the value in
 the case of Windows is drastically bigger (100). And that explains the
 changes file saying that we want a storage dir bigger than the actual
 limit of the cache.

  That code above needs a comment explaining this because I got very
 confused on this arbitrary limit of 100 and the limit vs the
 allocation difference.

 * In `consensus_cache_register_with_sandbox()`:

 {{{
 +#ifdef MUST_UNMAP_TO_UNLINK
 +  /* Our sandbox doesn't support huge limits like we use here.
 +   */
 +  tor_assert_nonfatal_unreached();
 +#endif
 }}}

  And also no sandbox on Windows but let us assume that we can enable that
 define on OperatingSystem9000 for instance, we should indicate here that
 the fix for the requirement to UNMAP is to have a huge file limit thus not
 compatible with our sandbox because the link between "sandbox" and "must
 unmap" is not easy to do...

 * `consensus_cache_may_overallocate()` imo should have documentation on
 *why* it does exists in the first place. If I was new to the code, I would
 look at the function which would lead me to `#define MUST_UNMAP_TO_UNLINK`
 which only has the comment "/* On Windows, unlink won't work if there's an
 active mmap. */" which would let me very confused.

  I would like somewhere a clear comment on the why of the relationship
 between "MUST UNMAP" and the fact that we have a very large max entry
 value for that as a fix.

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

Re: [tor-bugs] #23326 [Applications/Tor Browser]: Create WebExtension API for everything needed by privacy-preserving extensions

[Tor Bug Tracker & Wiki]

#23326: Create WebExtension API for everything needed by privacy-preserving
extensions
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


Comment:

 > Right. But that's a good task for Mozilla and not us.

 It's your task. You are making privacy-preserving browser, not Mozilla. If
 you are going to upgrade the browser with Mozilla code, you will have to
 create missing APIs you need.

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

Re: [tor-bugs] #23275 [Core Tor/Tor]: Consensus diffs are generated even if DirCache and DirPort are 0

[Tor Bug Tracker & Wiki]

#23275: Consensus diffs are generated even if DirCache and DirPort are 0
--+
 Reporter:  teor  |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  031-backport  |  Actual Points:  .1
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:  Sponsor4
--+
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 I assume the fix was in `bug23275_031`.

 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] #14201 [Metrics/Onionoo]: Configure out/ directory path somewhere else than in web.xml.

[Tor Bug Tracker & Wiki]

#14201: Configure out/ directory path somewhere else than in web.xml.
-+
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Onionoo-1.4.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by karsten):

 * status:  needs_review => needs_revision


Comment:

 Hmm, there's one major issue with this approach: This change is backward-
 incompatible with respect to the hourly updater, which previously used
 `"."` as base directory rather than
 `"/srv/onionoo.torproject.org/onionoo"`.

 And another, minor issue is that we're now defining that path in multiple
 places. This seems bad for future maintenance, in particular if we ever
 want to rename Onionoo and update that path.

 How about we limit this change to just the server part and leave the
 hourly updater unchanged. That would implement this ticket. I could edit
 the patch, unless you'd rather want to do that.

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

Re: [tor-bugs] #22287 [Metrics/Onionoo]: Switch from custom CollecTor downloader to metrics-lib's DescriptorCollector

[Tor Bug Tracker & Wiki]

#22287: Switch from custom CollecTor downloader to metrics-lib's
DescriptorCollector
-+---
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Onionoo-1.4.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

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


Comment:

 Looks good, and good catch in that second fixup commit there. Successfully
 tested and pushed to master. 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] #23151 [Applications/Tor Browser]: Tor Browser toolbar design

[Tor Bug Tracker & Wiki]

#23151: Tor Browser toolbar design
--+--
 Reporter:  linda |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 See #23359 for a bug we should take into account when working on this
 ticket. (Note that we don't do anything on our side right now that makes
 the HTTPS-Everywhere button visible. Thus, if we decide we don't want it
 on our toolbar then we need to do something to make that happen)

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

Re: [tor-bugs] #23359 [Applications/Tor Browser]: HTTPS-Everywhere icon is not shown on first start but on restart (was: HTTPS-Everywhere icon is not shown on first start)

[Tor Bug Tracker & Wiki]

#23359: HTTPS-Everywhere icon is not shown on first start but on restart
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * cc: legind (added)


Comment:

 `browser.uiCustomization.state` contains `https-everywhere-button` in the
 `nav-bar` key right from the beginning on my machine if the XPCOM version
 is installed. But not with the WebExtensions-based add-on. On restart,
 when the icon is visible, `https-everywhere-eff_eff_org-browser-action` is
 shown as value in `nav-bar`. Not sure where this is coming from. I guess
 we could think about the general intended behavior while redoing our
 toolbar design (see: #23151).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23359 [Applications/Tor Browser]: HTTPS-Everywhere icon is not shown on first start

[Tor Bug Tracker & Wiki]

#23359: HTTPS-Everywhere icon is not shown on first start
--+--
 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:|
--+--
 When testing the release candidate for 7.0.5 I realized that with the
 WebExtensions-based HTTPS-Everywhere the icon is not shown anymore on the
 toolbar on first start. After a restart it is visible again.

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

Re: [tor-bugs] #23214 [Applications/Tor Browser]: Defend against stack overflow due to overly deep nested (unclosed) XML tags

[Tor Bug Tracker & Wiki]

#23214: Defend against stack overflow due to overly deep nested (unclosed) XML 
tags
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 We could maybe test
 https://bug485941.bmoattachments.org/attachment.cgi?id=8901555 whether it
 fixes the problem without causing collateral damage.

 https://bugzilla.mozilla.org/show_bug.cgi?id=1337712 and
 https://bugzilla.mozilla.org/show_bug.cgi?id=1322307 are related.

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