Re: [tor-bugs] #21777 [Applications/Tor Browser]: Investigate cross-compiling Tor Browser for Windows with clang-cl

[Tor Bug Tracker & Wiki]

#21777: Investigate cross-compiling Tor Browser for Windows with clang-cl
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  project  | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff59-esr,   |  Actual Points:
  GeorgKoppen201712, TorBrowserTeam201712|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-rbm => tbb-rbm, ff59-esr, GeorgKoppen201712,
 TorBrowserTeam201712
 * priority:  Medium => High


Comment:

 The Google people made this work, so we have an alternative road to the
 mingw-w64/clang setup we could try.

 Tracking LLVM master causes still issues sometimes
 (https://bugs.chromium.org/p/chromium/issues/detail?id=781873) but they
 get resolved pretty fast it seems.

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

Re: [tor-bugs] #21777 [Applications/Tor Browser]: Investigate cross-compiling Tor Browser for Windows with clang-cl

[Tor Bug Tracker & Wiki]

#21777: Investigate cross-compiling Tor Browser for Windows with clang-cl
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  project  | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff59-esr,   |  Actual Points:
  GeorgKoppen201712, TorBrowserTeam201712|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 The announcement and some discussion with details is on:
 https://groups.google.com/a/chromium.org/forum/#!msg/chromium-
 dev/cIA9fBb9vBE/73cOvZu9BQAJ

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

Re: [tor-bugs] #20322 [Applications/Tor Browser]: SafeSEH support for mingw-w64 for Tor Browser on Windows

[Tor Bug Tracker & Wiki]

#20322: SafeSEH support for mingw-w64 for Tor Browser on Windows
-+-
 Reporter:  bugzilla |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201711,  |  Actual Points:
  GeorgKoppen201711  |
Parent ID:  #21777   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by gk):

 * priority:  Very High => Medium
 * parent:   => #21777


Comment:

 I did some digging and with our GCC-based toolchain this is tricky right
 now. However, we probably need a clang-based toolchain for ESR 59 anyway
 due to https://bugzilla.mozilla.org/show_bug.cgi?id=1390583 and it seems
 we'd get SafeSEH when switching. Thus, it makes no sense to fix this bug
 right now for the current toolchain. We should get SafeSEH with #21777
 being 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] #18222 [Applications/Tor Browser]: Tor Browser sets different Guard for one of the tabs when goes crazy

[Tor Bug Tracker & Wiki]

#18222: Tor Browser sets different Guard for one of the tabs when goes crazy
--+---
 Reporter:  bugzilla  |  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:  new => closed
 * resolution:   => not a bug


Comment:

 Replying to [comment:14 teor]:
 > It's normal for tor to use more than one guard in some circumstances,
 particularly if the connection to one of the primary guards is unreliable.
 >
 > I don't think this is even a bug.

 I 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] #24390 [Webpages/Blog]: Blog issue

[Tor Bug Tracker & Wiki]

#24390: Blog issue
---+---
 Reporter:  Dbryrtfbcbhgf  |  Owner:  hiro
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Major  | Resolution:  not a bug
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by arma):

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


Comment:

 What? This is not a blog issue.

 Feel free to ask the Tor Browser team about their release plans, for
 example by watching their weekly meetings on irc (or reading the notes
 from them).

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

Re: [tor-bugs] #24390 [Webpages/Blog]: Blog issue

[Tor Bug Tracker & Wiki]

#24390: Blog issue
---+---
 Reporter:  Dbryrtfbcbhgf  |  Owner:  hiro
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Major  | Resolution:  not a bug
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by gk):

 Replying to [comment:1 arma]:
 > What? This is not a blog issue.
 >
 > Feel free to ask the Tor Browser team about their release plans, for
 example by watching their weekly meetings on irc (or reading the notes
 from them).

 I think one could argue that *is* a blog issue because what Nick meant was
 "which should be out in early December". He wanted to talk about the next
 tor release, not Tor Browser one.

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

[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:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  tbb-crash,
 Severity:  Normal   |  TorBrowserTeam201711R
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We got a nice bugreport from a cypherpunk on our tbb-dev mailing list
 (https://lists.torproject.org/pipermail/tbb-dev/2017-November/000673.html)
 with a patch up for review (which I'll attach in a minute) (the problem
 seems to be caused by our workaround for #24052):
 {{{
 STR
 ---

 1. Run one of the platforms affected by the recent "tormoil" vulnerability
 (I
tested this on a GNU/Linux distro).

 2. Under Tor Browser 7.0.10's installation directory, create
 `Browser/TorBrowser/Data/Browser/profile.default/chrome/userContent.css`
with the following content (you can use whatever you want here, just
 adjust
the next steps accordingly):

  body {
background-color: blue !important;
color: white !important;
  }

 3. Start Tor Browser.

 4. Confirm that the content background looks blue.

 5. Right click the blue background on an empty spot (body element) and
 choose
"Inspect Element".

 6. Wait until the Inspector window shows up.  Observe memory consumption
 of
process "plugin-container" continually rise.

 Analysis
 

 I think this regression is caused by the workaround [0] for the recent
 critical
 vulnerability [1], but it has exposed what looks to me (not being privy to
 the
 details of "tormoil") like another bug, this one in javascript code.

   0: https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-
 browser-52.5.0esr-7.0-1&id=643117230bb3402c997f065980db1eec19c7a6ed
   1: https://trac.torproject.org/projects/tor/ticket/24052

 `newChannelForURL` in DevToolsUtils.js (packed inside
 `Browser/browser/omni.ja`) will recursively call itself when
 `NetUtil.newChannel` raises an exception, prepending "file://" to the
 input
 URL:

   /**
* Opens a channel for given URL. Tries a bit harder than
 NetUtil.newChannel.
*
* @param {String} url - The URL to open a channel for.
* @param {Object} options - The options object passed to @method fetch.
* @return {nsIChannel} - The newly created channel. Throws on failure.
*/
   function newChannelForURL(url, { policy, window, principal }) {
 var securityFlags =
 Ci.nsILoadInfo.SEC_ALLOW_CROSS_ORIGIN_DATA_IS_NULL;

 let uri;
 try {
   uri = Services.io.newURI(url, null, null);
 } catch (e) {
   // In the xpcshell tests, the script url is the absolute path of the
 test
   // file, which will make a malformed URI error be thrown. Add the
 file
   // scheme to see if it helps.
   uri = Services.io.newURI("file://" + url, null, null);
 }

 [...]

 try {
   return NetUtil.newChannel(channelOptions);
 } catch (e) {
   // In xpcshell tests on Windows,
 nsExternalProtocolHandler::NewChannel()
   // can throw NS_ERROR_UNKNOWN_PROTOCOL if the external protocol
 isn't
   // supported by Windows, so we also need to handle the exception
 here if
   // parsing the URL above doesn't throw.
   return newChannelForURL("file://" + url, { policy, window, principal
 });
 }
   }

 With the mentioned patch, the call to `NetUtil.newChannel` raises an
 exception.  This results in infinite recursion coupled with rapid (though
 linear) memory consumption.  Thus, `plugin-container` will, in just a few
 seconds, exhaust all available memory.

 Partial fix
 ---

 AFAICT, the current patch for "tormoil" is just a hurried stop-gap
 workaround
 and as such it is acceptable, and somewhat expected, for it to cause
 other,
 less severe, kinds of breakage.  However, ISTM that the code in
 `newChannelForURL` is buggy regardless: the recursion has no (evident)
 termination condition.

 The comment before the recursive call says that it is needed due to some
 tests
 for which `newChannel` can raise `NS_ERROR_UNKNOWN_PROTOCOL`.  So maybe it
 should only catch the exception (and make the recursive call) if the error
 is
 that one and `url` does not already start with "file://".  The attached
 patch
 does this.  It does not fix the regression (the Developer Toolbox still
 fails
 to show the appropriate styles and stylesheets), but at least fixes the
 DoS
 caused by the runaway memory allocation.
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Proj

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:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash, TorBrowserTeam201711R  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * Attachment "tor-browser-runaway-memory-allocation.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] #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:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash, TorBrowserTeam201711R  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 I gave the STR a quick test and for some reason I did not have a plugin-
 container process to begin with. So, we might need slightly adapted STR
 for testing the patch.

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

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:
  |  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash, TorBrowserTeam201711R  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

 * 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] #23970 [Applications/Tor Browser]: Printing to a file is broken with Linux content sandboxing enabled

[Tor Bug Tracker & Wiki]

#23970: Printing to a file is broken with Linux content sandboxing enabled
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff59-esr-will-have, AffectsTails,|  Actual Points:
  tbb-regression, TorBrowserTeam201711   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:
 ff59-esr-will-have, AffectsTails, tbb-regression, GeorgKoppen201711,
 TorBrowserTeam201711R
 => ff59-esr-will-have, AffectsTails, tbb-regression,
 TorBrowserTeam201711
 * status:  needs_review => needs_revision


Comment:

 I have not looked closer at the backport but here are some things we
 should fix:

 1) Looking at the dependencies for bug 1309205 it seems to me we need to
 backport https://hg.mozilla.org/mozilla-central/rev/997c6b961cd0.

 2) We should have one commit per Mozilla commit. This makes it easier to
 review the backport at least. It might even make it easier to narrow
 problems down during bisecting if we don't have just a big patch
 comprising all the changesets.

 3) "Issue 23970" -> "Bug 23970"

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

Re: [tor-bugs] #24361 [Applications/rbm]: rbm gives an error if a build script contains a wide character

[Tor Bug Tracker & Wiki]

#24361: rbm gives an error if a build script contains a wide character
+--
 Reporter:  boklm   |  Owner:  boklm
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/rbm|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201711R  |  Actual Points:
Parent ID:  #21998  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * keywords:  tbb-rbm, TorBrowserTeam201712R => tbb-rbm,
   TorBrowserTeam201711R


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

Re: [tor-bugs] #24154 [Applications/Tor Browser]: Look into fuzzing our tor-browser patches

[Tor Bug Tracker & Wiki]

#24154: Look into fuzzing our tor-browser patches
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201711,|  Actual Points:
  GeorgKoppen201711  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by gk):

 * keywords:  TorBrowserTeam201711 => TorBrowserTeam201711,
   GeorgKoppen201711


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

Re: [tor-bugs] #24040 [Applications/Tor Browser]: TorBrowser crashes at riot.im/app

[Tor Bug Tracker & Wiki]

#24040: TorBrowser crashes at riot.im/app
-+-
 Reporter:  user |  Owner:  tbb-team
 Type:  defect   | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-crash, TorBrowserTeam201711  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * status:  assigned => needs_information


Comment:

 Replying to [comment:19 user]:
 > 7.0.9:
 >   checkbox on -> crash within 15 minutes
 >   checkbox off -> no crash after an hour

 Hey user! Could you test whether the following testbuild fixes your
 problem?

 https://people.torproject.org/~gk/testbuilds/tor-browser-linux64-24040_en-
 US.tar.xz
 https://people.torproject.org/~gk/testbuilds/tor-browser-linux64-24040_en-
 US.tar.xz.asc

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

Re: [tor-bugs] #24390 [Webpages/Blog]: Blog issue

[Tor Bug Tracker & Wiki]

#24390: Blog issue
---+---
 Reporter:  Dbryrtfbcbhgf  |  Owner:  hiro
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Major  | Resolution:  not a bug
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by hiro):

 Still blog issues should be used to track problems w the blog itself.
 Comments w what is written on the blog should go to comments on the post.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #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|   Keywords:  ux-team
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Relay Search currently uses a set of icons for relay flags that exist as
 16x16 PNGs. Over time we have added new icons but we've never considered
 consistency across projects or reusability of these icons.

 Ideally, we could have icons for the following flags that are reusable
 across projects (meanings are in dir-spec):

 * Authority
 * BadExit
 * Fast
 * Guard
 * HSDir
 * NoEdConsensus
 * Running
 * Stable
 * V2Dir
 * Valid
 * Exit

 Atlas also synthesises additional flags, as does consensus-health:

 * Not Recommended - This relay is running a Tor version that is not
 recommended by the directory authorities and may contain known issues.
 * Unmeasured - This relay has not been measured by at least 3 bandwidth
 authorities and so its consensus weight is currently capped.
 * FallbackDir - This relay is hardcoded into the tor source code as a
 fallback directory.
 * IPv6 ORPort - This relay listens for OR connections using IPv6.
 * IPv6 Exit - This relay allows exit connections using IPv6.
 * Unreachable ORPort - This relay has an unreachable OR address according
 to at least one directory authority.
 * T-Shirt - This relay has met the t-shirt team criteria for a t-shirt (in
 theory).

 Ideally these icons would be available for use in projects in the
 following formats:

 * Web Icon Font
 * SVG
 * 16x16, 32x32 and 64x64 PNGs

 If we could also throw in an onion, and relay and bridge icons, a
 fingerprint icon, AS icon, country icon (maybe a globe), this could be a
 really useful tool for user facing projects that has consistent UX across
 those projects.

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

Re: [tor-bugs] #24396 [Webpages/Website]: helloo

[Tor Bug Tracker & Wiki]

#24396: helloo
---+-
 Reporter:  jfcournoyer1986@…  |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  HTTPSE Cr 2013.4.2x
Component:  Webpages/Website   |Version:  Tor: unspecified
 Severity:  Normal | Resolution:  invalid
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by nickm):

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


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

Re: [tor-bugs] #21998 [Applications/Tor Browser]: Add the option for debug builds to rbm

[Tor Bug Tracker & Wiki]

#21998: Add the option for debug builds to rbm
---+--
 Reporter:  gk |  Owner:  tbb-team
 Type:  enhancement| Status:  needs_review
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201711  |  Actual Points:
Parent ID:  #17379 | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by boklm):

 * status:  needs_revision => needs_review


Comment:

 I pushed a new version of the patch fixing those 2 issues in branch
 `bug_21998_v3`:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_21998_v3&id=61ee91b5aa8975743b0daaf3c9ac80c5b00ccc10

 I rebased the workaround for #21925 in branch `bug_21925_v3`:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_21925_v3&id=a634ea5f9b56273a7173f1c17ddc6e0bd055903e

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

Re: [tor-bugs] #23435 [Internal Services/Service - git]: New git repository in Infrastructure and Administration /project for newsletter microsite

[Tor Bug Tracker & Wiki]

#23435: New git repository in Infrastructure and Administration /project for
newsletter microsite
-+-
 Reporter:  hiro |  Owner:  tor-gitadm
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #23096   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hiro):

 name: newsletter

 description: newsletter.tpo admin interface

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

Re: [tor-bugs] #23437 [Webpages/Webtools]: newsletter archive, subscribe and unsubscribed pages

[Tor Bug Tracker & Wiki]

#23437: newsletter archive, subscribe and unsubscribed pages
---+
 Reporter:  isabela|  Owner:  hiro
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Webpages/Webtools  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  ux-team|  Actual Points:
Parent ID:  #23096 | Points:
 Reviewer: |Sponsor:
---+
Changes (by hiro):

 * status:  needs_review => 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] #21411 [Webpages/Website]: Commit access tpo.org for Linda

[Tor Bug Tracker & Wiki]

#21411: Commit access tpo.org for Linda
--+
 Reporter:  lnl   |  Owner:  hiro
 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 hiro):

 * 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] #24384 [Metrics/Onionoo]: Decode percent-encoded characters in qualified search terms

[Tor Bug Tracker & Wiki]

#24384: Decode percent-encoded characters in qualified search terms
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  defect   | Status:  merge_ready
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

 * status:  new => merge_ready


Comment:

 URI syntax allows for different types of delimeters.  For generic
 delimeters, e.g. `/` and `?`, the percent encoding is only used when they
 appear inside data transferred in the URI.
 There is another subset of delimiters (referred to as sub-delims in
 [https://tools.ietf.org/html/rfc3986#section-2.2 rfc3986]), which can be
 used as separators in sub-components as an application defines it: For
 example, if the plus `+` was used as a delimiter between several search
 terms it ought to be percent encoded when being part of the data.  Without
 any special meaning (as done in Onionoo) the plus doesn't need to be
 encoded and whether only the non-encoded or both are accepted is courtesy
 of the processing application.

 With the current patch Onionoo allows for plus to be submitted as `+` and
 `%B2` in searches.  The following tests pass (ResourceServletTest) as well
 as their already existing counterparts with just `+`:

 {{{
   @Test(timeout = 100)
   public void testSearchBase64FingerprintPlusEncoded() {
 this.assertSummaryDocument(
 "/summary?search=ACXBNsHzqe7%2BKuP5GPA7+iG1Bws", 1,
 new String[] { "TimMayTribute" }, 0, null);
   }

   @Test(timeout = 100)
   public void testSearchEmailAddressEncodedPlus() {
 this.assertSummaryDocument(
 "/summary?search=contact:", 1,
 new String[] { "TimMayTribute" }, 0, null);
   }
 }}}

 Regarding the space character:

 Replacing it by `+` is done for form encoding (cf.
 [https://secure.php.net/manual/en/function.urlencode.php PHP manual],
 [https://www.w3.org/TR/html4/interact/forms.html#h-17.13.3.4 w3c HTML
 spec]) whereas `encodeURIComponent()` properly uses the percent encoding
 according to the applied URI spec.

 Onionoo does not receive form data, therefore accepting plus encoded as
 `+` or `%2B` and space as `%20` is perfectly fine.

 The patch passes all checks and tests, and is ready to be merged.  Maybe,
 with some tests added to make clear what data is accepted.

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

Re: [tor-bugs] #22649 [Applications/Tor Browser]: Save Link As... in the context menu results in using the catch-all circuit

[Tor Bug Tracker & Wiki]

#22649: Save Link As... in the context menu results in using the catch-all 
circuit
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-7.0-issues, tbb-regression,  |  Actual Points:
  tbb-linkability|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by davidw):

 * cc: dwatson@… (added)


Comment:

 I can confirm this. I originally posted to #22616 but it seems more
 appropriate here.

 The problem for me is concurrent downloads. First download always works
 but trying to download another file at the same time always fails with
 this:
 {{{
 unsafe CPOW usage forbidden
 contentAreaUtils.js:466
 continueSave
 chrome://global/content/contentAreaUtils.js:466:1
 internalSave/<
 chrome://global/content/contentAreaUtils.js:446:7
 Handler.prototype.process resource://gre/modules/Promise-
 backend.js:932:23
 this.PromiseWalker.walkerLoop   resource://gre/modules
 /Promise-backend.js:813:7
 bound   self-
 hosted:913:17
 bound bound self-
 hosted:913:17
 this.PromiseWalker.scheduleWalkerLoop/< resource://gre/modules
 /Promise-backend.js:747:11
 }}}

 Mac OS 10.11.6 with Tor 7.0.6 (64bit), and also 7.5a8

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

Re: [tor-bugs] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

[Tor Bug Tracker & Wiki]

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  reopened
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Blocker  | Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare |
Parent ID:  #18361   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 This isn't the correct solution. The green icon only tells you that the
 exit and the server you're communicating to (Cloudflare in this case) is
 encrypted, and that's it. It shouldn't extend to how someone sets up their
 website, otherwise it opens a slippery slope: why not block all websites
 because all servers have the backdoor that is Intel Management Engine or
 AMD's Platform Security Processor? Why not block all onion services on the
 same ground? Also, good luck confusing most users by blocking a large
 portion of the web: w3techs.com/technologies/history_overview/proxy/all

 (Yes, Cloudflare is evil and tries to pass as some kind of "anti-DDoSes
 hero" and with all their HN PR, this has no bearing on this however.)

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

Re: [tor-bugs] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

[Tor Bug Tracker & Wiki]

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Blocker  | Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare |
Parent ID:  #18361   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

 * status:  reopened => needs_information


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

Re: [tor-bugs] #24044 [Core Tor/Tor]: Resolved [scrubbed] which was already resolved; ignoring

[Tor Bug Tracker & Wiki]

#24044: Resolved [scrubbed] which was already resolved; ignoring
--+
 Reporter:  mo|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.2-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Dhalgren):

 likely is #18580

 message not mentioned in the ticket, but is the initial symptom appearing
 at the top of the two linked `tor-relays` posts

 cause is volumes of `Unbound` responses appearing within the 120 second
 resolve effort, but long after `eventdns` discarded the requests

 solution is upgrading to 0.3.2.4+ or tuning `resolve.conf` per

 
https://trac.torproject.org/projects/tor/wiki/doc/DnsResolver#TuningeventdnscomponentofTorDaemon

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

Re: [tor-bugs] #24390 [Webpages/Blog]: Blog issue

[Tor Bug Tracker & Wiki]

#24390: Blog issue
---+---
 Reporter:  Dbryrtfbcbhgf  |  Owner:  hiro
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Major  | Resolution:  not a bug
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by Dbryrtfbcbhgf):

 Replying to [comment:3 hiro]:


 > Still blog issues should be used to track problems w the blog itself.
 Comments w what is written on the blog should go to comments on the post.
 The comment section on https://blog.torproject.org/tor-0325-alpha-released
 is disabled, that is why I posted the issue 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] #24308 [Core Tor/Tor]: MaxMemInCellQueues minimum of 256MB is still too large for low-RAM relays (LEDE and OpenWRT routers)

[Tor Bug Tracker & Wiki]

#24308: MaxMemInCellQueues minimum of 256MB is still too large for low-RAM 
relays
(LEDE and OpenWRT routers)
-+-
 Reporter:  pmetras  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.12
 Severity:  Normal   | Resolution:
 Keywords:  tor- |  Actual Points:
  relay,lowmem,openwrt,lede,router   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pmetras):

 For your information, the previous version of Tor on OpenWRT Chaos Calmer
 was `TorVersion Tor 0.2.5.12` indeed, now declared insecure.

 I didn't had to specify a `MaxMemInCellQueues` value with that version.
 The warning "Using 256MB..." and the crashes appeared in the log with
 0.2.9

 May I suggest that using a negative number like `MaxMemInCellQueues
 -128Mb` will enforce the given value, bypassing the default? I understand
 that low-RAM hardware has to be tuned by owners and won't/should'n support
 automatic defaults blindly. So if the admin decides to overwrite the
 software defaults, that's his own responsibility and it should not happen
 by mistake.

 If I know the syntax you'll be using, I can backport the code in my
 version and my relay will be up again. 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] #24308 [Core Tor/Tor]: MaxMemInCellQueues minimum of 256MB is still too large for low-RAM relays (LEDE and OpenWRT routers)

[Tor Bug Tracker & Wiki]

#24308: MaxMemInCellQueues minimum of 256MB is still too large for low-RAM 
relays
(LEDE and OpenWRT routers)
-+-
 Reporter:  pmetras  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.12
 Severity:  Normal   | Resolution:
 Keywords:  tor- |  Actual Points:
  relay,lowmem,openwrt,lede,router   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pmetras):

 Reading from the documentation that the torrc options can also be given at
 the command line, `-128MB` is not a good choice. Perhaps adding a "+" like
 `+128MB` to enforce the specified parameters is probably 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