Re: [tor-bugs] #21312 [Obfuscation/Snowflake]: snowflake-client is pegged at 100% cpu

[Tor Bug Tracker & Wiki]

#21312: snowflake-client is pegged at 100% cpu
---+
 Reporter:  arlolra|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by yawning):

 > Here's a graph of the number of file descriptors held open by the
 snowflake-client process while I was using it today.

 
https://chromium.googlesource.com/external/webrtc/+/8c38e8b9b96d72317d6ce94c1442113b4e385dcb/webrtc/base/thread.cc#142

 
https://chromium.googlesource.com/external/webrtc/+/8c38e8b9b96d72317d6ce94c1442113b4e385dcb/webrtc/base/messagequeue.cc#122

 
https://chromium.googlesource.com/external/webrtc/+/edc6e57a92d2b366871f4c2d2e926748326017b9/webrtc/base/physicalsocketserver.cc#561

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23242 [- Select a component]: Can't open tor browser not a bug. I'm just dumb.

[Tor Bug Tracker & Wiki]

#23242: Can't open tor browser not a bug. I'm just dumb.
--+
 Reporter:  idithere@…|  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I downloaded tor browser but can't open it.  I installed it ok. I'm just
 to dumb. I don't even know what a ticket is. I don't understand any of
 this. I tried to use the suggested support sites but don't understand them
 either.  The browser takes me the place where I find two buttons, one
 Connect, and the other some thing I have to configure.

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

Re: [tor-bugs] #22839 [Core Tor/Tor]: Build tor with Rust code enabled on Windows

[Tor Bug Tracker & Wiki]

#22839: Build tor with Rust code enabled on Windows
-+-
 Reporter:  isis |  Owner:  snoek
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, windows, tor-build, review-|  Actual Points:
  group-22   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorZ
-+-

Comment (by alexcrichton):

 Er wait hang on, actually I think we used to emit libfoo.a and then
 https://github.com/rust-lang/rust/pull/29520/files caused an accidental
 regression here... In any case I'll continue discussion on
 https://github.com/rust-lang/rust/issues/43749

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

Re: [tor-bugs] #23240 [Applications/Tor Launcher]: do not show progress bar at zero when bootstrap progress is greater than zero

[Tor Bug Tracker & Wiki]

#23240: do not show progress bar at zero when bootstrap progress is greater than
zero
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201708R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--

Comment (by dcf):

 That said, I do think the call to
 `protocolSvc.TorRetrieveBootstrapStatus()` is a good idea in any case.  I
 believe the safety timeout is not necessary if the progress bar keeps
 state and remains unhidden.

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

Re: [tor-bugs] #23240 [Applications/Tor Launcher]: do not show progress bar at zero when bootstrap progress is greater than zero

[Tor Bug Tracker & Wiki]

#23240: do not show progress bar at zero when bootstrap progress is greater than
zero
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201708R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by dcf):

 * cc: dcf (added)


Comment:

 comment:1 looks like an effective workaround, but I suspect it can be
 addressed in a more direct way. I think the root of the problem is that
 progressMeter.value is reset to 0 every time the progress bar dialog is
 shown. I added some logging:
 {{{
 --- a/src/chrome/content/progress.js
 +++ b/src/chrome/content/progress.js
 @@ -51,6 +51,10 @@ function initDialog()
}
catch (e) {}

 +  var meter = document.getElementById("progressMeter");
 +  if (meter)
 +TorLauncherLogger.log(6, "initDialog meter.value " + meter.value);
 +
var isBrowserStartup = false;
if (window.arguments)
{
 @@ -181,9 +185,12 @@ var gObserver = {
var labelText =
  TorLauncherUtil.getLocalizedBootstrapStatus(statusObj,
 "TAG");
var percentComplete = (statusObj.PROGRESS) ? statusObj.PROGRESS :
 0;
 +  TorLauncherLogger.log(6, "statusObj.PROGRESS " +
 statusObj.PROGRESS);

var meter = document.getElementById("progressMeter");
 +  if (meter)
 +TorLauncherLogger.log(6, "meter.value " + meter.value + " -> " +
 percentComplete);
if (meter)
  meter.value = percentComplete;

var bootstrapDidComplete = (percentComplete >= 100);
 }}}
 I hacked Browser/start-tor-browser to add `--jsconsole` to the command
 line so I could see the log output. Then I did this:
  1. `./start-tor-browser.desktop`
  2. Click "Open Settings" quickly before the bootstrap finishes.
  3. Wait a few seconds on the initial screen.
  4. Click "Connect" to make the progress bar reappear and let it finish
 bootstrapping.
 Step 4 of the above process shows the problem from #22266: even though the
 bootstrapping is really at ~90%, the progress bar goes back to 0% and then
 straight to 100% the second time the progress dialog is shown.

 Here is the log output:
 {{{
 [08-15 01:41:13] TorLauncher -: initDialog meter.value 0
 Tor NOTICE: Bootstrapped 85%: Finishing handshake with first hop
 [08-15 01:41:14] TorLauncher -: statusObj.PROGRESS 85
 [08-15 01:41:14] TorLauncher -: meter.value 0 -> 85
 Tor NOTICE: Bootstrapped 90%: Establishing a Tor circuit
 [08-15 01:41:14] TorLauncher -: statusObj.PROGRESS 90
 [08-15 01:41:14] TorLauncher -: meter.value 85 -> 90

   (Here is where I clicked "Open Settings", waited a few seconds, then
 clicked "Connect")

 [08-15 01:41:20] TorLauncher -: initDialog meter.value 0
 Tor NOTICE: Bootstrapped 100%: Done
 [08-15 01:41:21] TorLauncher -: statusObj.PROGRESS 100
 [08-15 01:41:21] TorLauncher -: meter.value 0 -> 100
 }}}
 Notice that when initDialog is called the second time, meter.value is
 reset to 0, rather than remembering its previous value of 90. Maybe this
 is because [https://gitweb.torproject.org/tor-
 launcher.git/tree/src/chrome/content/network-settings.js?h=0.2.12.3#n1252
 openProgressDialog] creates a brand new dialog from scratch? Perhaps
 instead, it could keep the same dialog in memory, and show or hide it as
 appropriate, so that meter.value retains its state.

 I ''don't'' think the usability problem from #22266 is an initial jump
 from 0% to 80%. That's normal and expected with an up-to-date consensus
 cache. Rather, the usability problem is when you cancel an in-progress
 bootstrapping at 60%, and when you resume, the meter goes down to 0% then
 back up to 65%. The changes in comment:1 make the bar invisible when it
 would misleadingly be set at 0%, but it would be better if the bar
 remembered its state and didn't go back to 0% at all.

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

Re: [tor-bugs] #23097 [Core Tor/Tor]: The circuit timeout prediction is not working properly

[Tor Bug Tracker & Wiki]

#23097: The circuit timeout prediction is not working properly
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Very High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  031-backport  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by mikeperry):

 * status:  new => needs_review


Comment:

 Ok, the simple fix we discussed is in mikeperry/bug23097. Is there an easy
 way to repro this?

 In the meantime I can let an idle HS run overnight with this code, and see
 if it still builds circuits 1x/sec or not. Will that do it?

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

Re: [tor-bugs] #13837 [Core Tor/Tor]: Mitigate guard discovery by pinning middle node

[Tor Bug Tracker & Wiki]

#13837: Mitigate guard discovery by pinning middle node
+--
 Reporter:  asn |  Owner:
|  mikeperry
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:  Tor:
|  unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, tor-guard, guard-discovery  |  Actual Points:
Parent ID:  #9001   | Points:
 Reviewer:  |Sponsor:
|  SponsorV-can
+--

Comment (by mikeperry):

 FYI: I will be writing a more thorough experimentation plan, a README, and
 looking at onionperf after I complete more work on subtickets of #9001,
 but this may not happen until September.

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

Re: [tor-bugs] #13837 [Core Tor/Tor]: Mitigate guard discovery by pinning middle node

[Tor Bug Tracker & Wiki]

#13837: Mitigate guard discovery by pinning middle node
+--
 Reporter:  asn |  Owner:
|  mikeperry
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:  Tor:
|  unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, tor-guard, guard-discovery  |  Actual Points:
Parent ID:  #9001   | Points:
 Reviewer:  |Sponsor:
|  SponsorV-can
+--

Comment (by mikeperry):

 Replying to [comment:15 nickm]:
 > Just skimmed the simulation code -- this looks like a plausible place to
 begin with the measurements. Do we have a plan to do these measurements,
 or should we make one?

 There is a rough outline of a plan in the comments of that script, but
 I've been thinking a bit more about it since then. Basically, I think we
 want to run several onionperf instances with different values for each of
 the NUM_LAYERN_GUARDS values. We may also want to play with cutting off
 various percentiles of the network (though this capability is not written
 in the prototype yet).

 We're going to need to measure variance of these instances somehow, or
 ideally even capture the full performance density distribution for a given
 parameter set. Variance in performance over time will be the key thing
 that changes with the parameters. We want to minimize this variance for
 sane parameter values. I think what this means is that we want to scale
 the rotation times down, so as to capture the effect of rotation on our
 performance variance over time for a fixed parameter set.

 > Also, I'm assuming that this simulation isn't trying to simulate the
 exact way in which guard sets change over time. If it is, we need to bring
 it into conformance with prop271.

 I thought about this and I don't think we want something very much like
 prop271 at all. prop271 has a lot of logic about trying to determine
 connectivity and detect and protect against various guard biasing
 attempts. For this code, I think we should trust the consensus completely,
 and have the notion of a "fallback set" and the "primary set", where we
 prefer the "primary set" if they are in the consensus, but fall back to
 members of the "fallback set" otherwise. This is kind of what the code
 does, but hat part is a bit wonky and could be done 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] #21312 [Obfuscation/Snowflake]: snowflake-client is pegged at 100% cpu

[Tor Bug Tracker & Wiki]

#21312: snowflake-client is pegged at 100% cpu
---+
 Reporter:  arlolra|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by dcf):

 Here's a graph of the number of file descriptors held open by the
 snowflake-client process while I was using it today. The first plateau at
 21:30 is when it stopped working and I turned off snowflake in the
 browser. snowflake-client continued running, got out of whatever rut it
 was in, and consumed a few more descriptors before I finally closed the
 browser.

 [[Image(snowflake-client-fds-20170814.png)]]

 The descriptors are six-fd repetitions of this nature. I suspect there's
 one for each attempt to contact the broker (i.e. ` Handler: snowflake
 assigned `).
 {{{
 snowflake 28366 david  217w FIFO   0,10  0t0 1150258477 pipe
 snowflake 28366 david  218r FIFO   0,10  0t0 1150258478 pipe
 snowflake 28366 david  219w FIFO   0,10  0t0 1150258478 pipe
 snowflake 28366 david  220u IPv4 1150257563  0t0UDP
 xx.Berkeley.EDU:48700
 snowflake 28366 david  221u IPv4 1150258488  0t0TCP
 xx.Berkeley.EDU:46037 (LISTEN)
 snowflake 28366 david  222r FIFO   0,10  0t0 1150262588 pipe
 snowflake 28366 david  223w FIFO   0,10  0t0 1150262588 pipe
 snowflake 28366 david  224r FIFO   0,10  0t0 1150262589 pipe
 snowflake 28366 david  225w FIFO   0,10  0t0 1150262589 pipe
 snowflake 28366 david  226u IPv4 1150260856  0t0UDP
 xx.Berkeley.EDU:49943
 snowflake 28366 david  227u IPv4 1150262068  0t0TCP
 xx.Berkeley.EDU:52465 (LISTEN)
 }}}

 During the plateau at 21:30, there were a lot of `Buffered` messages in
 the log:
 {{{
 2017/08/14 14:24:34 WebRTC: DataChannel.OnOpen
 2017/08/14 14:24:34 Buffered 1057 bytes --> WebRTC
 2017/08/14 14:24:36 Buffered 1057 bytes --> WebRTC
 2017/08/14 14:24:38 Buffered 1057 bytes --> WebRTC
 2017/08/14 14:24:39 Buffered 1057 bytes --> WebRTC
 2017/08/14 14:24:40 Buffered 1057 bytes --> WebRTC
 2017/08/14 14:24:42 Buffered 1057 bytes --> WebRTC
 2017/08/14 14:24:44 Buffered 1057 bytes --> WebRTC
 2017/08/14 14:24:46 Buffered 1057 bytes --> WebRTC
 2017/08/14 14:24:48 Buffered 1057 bytes --> WebRTC
 2017/08/14 14:24:50 Buffered 1057 bytes --> WebRTC
 2017/08/14 14:24:52 Buffered 1057 bytes --> WebRTC
 2017/08/14 14:24:54 Buffered 1057 bytes --> WebRTC
 2017/08/14 14:24:56 Buffered 1057 bytes --> WebRTC
 2017/08/14 14:24:58 Buffered 1057 bytes --> WebRTC
 2017/08/14 14:25:00 Buffered 1057 bytes --> WebRTC
 2017/08/14 14:25:01 Buffered 543 bytes --> WebRTC
 2017/08/14 14:25:02 Buffered 543 bytes --> WebRTC
 2017/08/14 14:25:03 Buffered 543 bytes --> WebRTC
 2017/08/14 14:25:03 WebRTC: No messages received for 30 seconds -- closing
 stale connection.
 2017/08/14 14:25:03 WebRTC: closing DataChannel
 2017/08/14 14:25:03 WebRTC: DataChannel.OnClose [locally]
 2017/08/14 14:25:03 WebRTC: closing PeerConnection
 2017/08/14 14:25:03 WebRTC: Closing
 2017/08/14 14:25:04 Buffered 543 bytes --> WebRTC
 2017/08/14 14:25:05 Buffered 543 bytes --> WebRTC
 2017/08/14 14:25:06 Buffered 543 bytes --> WebRTC
 2017/08/14 14:25:07 Buffered 543 bytes --> WebRTC
 }}}

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21312#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #23241 [Applications/Tor Browser]: "This page isn't redirecting properly" errors in TorBrowser but not in Firefox

[Tor Bug Tracker & Wiki]

#23241: "This page isn't redirecting properly" errors in TorBrowser but not in
Firefox
--+--
 Reporter:  msfc  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by msfc):

 I have the security slider at its default position: Low.

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

Re: [tor-bugs] #21312 [Obfuscation/Snowflake]: snowflake-client is pegged at 100% cpu

[Tor Bug Tracker & Wiki]

#21312: snowflake-client is pegged at 100% cpu
---+
 Reporter:  arlolra|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dcf):

 * Attachment "snowflake-client-fds-20170814.png" added.

 Graph of number of file descriptors used by snowflake-client.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21312>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
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] #23241 [Applications/Tor Browser]: "This page isn't redirecting properly" errors in TorBrowser but not in Firefox

[Tor Bug Tracker & Wiki]

#23241: "This page isn't redirecting properly" errors in TorBrowser but not in
Firefox
--+--
 Reporter:  msfc  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 The subject error appears on many URLs with TorBrowser. The few that I
 have tried in regular Firefox work fine. One such example is
 http://www.jreast.co.jp/en. The problem also happens when tumblr redirects
 the browser to unmasked "sensitive" blogs.

 None of the reasons given in Firefox's help for this error seems to apply
 to TorBrowser: cookies are enabled, network.http.sendReferer is enabled,
 etc.

 I am using TB 7.0.4.

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

Re: [tor-bugs] #23114 [Core Tor/Tor]: Circuit Build Timeout should apply at circuit completion

[Tor Bug Tracker & Wiki]

#23114: Circuit Build Timeout should apply at circuit completion
--+--
 Reporter:  mikeperry |  Owner:  mikeperry
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #23100| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mikeperry):

 FYI there is an initial sketch of a patch in mikeperry/prop247_torrc-
 rebased for this. More work is needed though.

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

Re: [tor-bugs] #22839 [Core Tor/Tor]: Build tor with Rust code enabled on Windows

[Tor Bug Tracker & Wiki]

#22839: Build tor with Rust code enabled on Windows
-+-
 Reporter:  isis |  Owner:  snoek
 Type:  task | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust, windows, tor-build, review-|  Actual Points:
  group-22   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorZ
-+-

Comment (by alexcrichton):

 >  @alexcrichton, if you happen to read this, it just so happens that you
 fixed Rust bug 29508, which is the inverse of this possible Rust bug I
 described above in that MSVC static libs had the GCC .a naming. Any
 thoughts?

 Holy cow, turns out this has been the implementation since before 1.0! I
 actually had no idea about this...

 That being said, I think that .a and .lib files are equivalent for the
 purposes of `ld` or w/e MinGW linker is being used (we just pass the .lib
 files to the linker). Have you found they don't work though? If they don't
 then we can surely get a fix in!

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

[tor-bugs] [Tor Bug Tracker & Wiki] Trac email verification for user: alexcrichton

[Tor Bug Tracker & Wiki]

Please visit the following URL to confirm your email address.

Verification URL: 

Username: alexcrichton
Verification Token: RECGij3w

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

Re: [tor-bugs] #23236 [Obfuscation/BridgeDB]: Distribute 1/3 of all bridges' addr:port+some_bytes_of_data in captcha like format

[Tor Bug Tracker & Wiki]

#23236: Distribute 1/3 of all bridges' addr:port+some_bytes_of_data in captcha 
like
format
--+-
 Reporter:  cypherpunks   |  Owner:  isis
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by cypherpunks):

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


Comment:

 Ok, seems like too much efforts to get nothing. It needs some attaches,
 user need to find way to concatenate txt and attached data (or to get many
 errors). Too complex to implement and hard to use, while adversary can to
 buy cheap human-readers.

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

Re: [tor-bugs] #22266 [Core Tor/Tor]: fix the jump-to-80% issue

[Tor Bug Tracker & Wiki]

#22266: fix the jump-to-80% issue
+
 Reporter:  catalyst|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  usability, ux, ux-team  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by cypherpunks):

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


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

Re: [tor-bugs] #23239 [Applications/Tor Browser]: link File>Email Link NOT working

[Tor Bug Tracker & Wiki]

#23239: link File>Email Link NOT working
--+---
 Reporter:  ramcclain@…   |  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 mcs):

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


Comment:

 By default, external protocols are disabled in Tor Browser (this is to
 avoid a potential proxy bypass when an external application is started
 unexpectedly). To enable the `File|Email Link` feature as well as clicks
 on mailto: URLs, from within Tor Browser open `about:config` and set the
 value of `network.protocol-handler.external.mailto` to `true`.

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

Re: [tor-bugs] #23239 [Applications/Tor Browser]: link File>Email Link NOT working

[Tor Bug Tracker & Wiki]

#23239: link File>Email Link NOT working
--+--
 Reporter:  ramcclain@…   |  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 mcs):

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


Comment:

 I assume this is a Tor Browser issue.

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

Re: [tor-bugs] #23240 [Applications/Tor Launcher]: do not show progress bar at zero when bootstrap progress is greater than zero

[Tor Bug Tracker & Wiki]

#23240: do not show progress bar at zero when bootstrap progress is greater than
zero
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201708R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by mcs):

 * keywords:   => TorBrowserTeam201708R
 * cc: tbb-team (added)
 * status:  new => needs_review


Comment:

 Here is an oniongit merge request to use for code review and discussion:
 https://oniongit.eu/brade/tor-launcher/merge_requests/1
 (comments here are welcome too).

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

Re: [tor-bugs] #22266 [Core Tor/Tor]: fix the jump-to-80% issue

[Tor Bug Tracker & Wiki]

#22266: fix the jump-to-80% issue
---+
 Reporter:  catalyst   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  usability, ux  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by mcs):

 We are working on improving things on the Tor Launcher side. I opened
 #23240.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23240 [Applications/Tor Launcher]: do not show progress bar at zero when bootstrap progress is greater than zero

[Tor Bug Tracker & Wiki]

#23240: do not show progress bar at zero when bootstrap progress is greater than
zero
---+---
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor:  Sponsor4   |
---+---
 To help with some of the usability issues related to #22266, we should
 avoid showing the bootstrap progress bar in Tor Launcher at zero when the
 actual phase/progress value is greater than zero. Therefore we will change
 Tor Launcher to retrieve the current bootstrap progress value before
 displaying its progress bar. That way users will not see a surprising jump
 from 0% to 80%.

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

Re: [tor-bugs] #22891 [Core Tor/Tor]: Add GitLab CI configs

[Tor Bug Tracker & Wiki]

#22891: Add GitLab CI configs
-+-
 Reporter:  catalyst |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ci continuous-integration testing|  Actual Points:
  best-practice unit-testing new-developers  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by hiro):

 Hi,

 I can have VM deployed with docker as runner. I have a docker server VM
 that can do this for you guys. I can start to do some tests and send a
 patch with a .gitlab-ci that you can evaluate if you want.

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

Re: [tor-bugs] #23022 [Webpages/Blog]: Increase leading image margin-bottom

[Tor Bug Tracker & Wiki]

#23022: Increase leading image margin-bottom
---+--
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by steph):

 That'd be great!

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

Re: [tor-bugs] #23022 [Webpages/Blog]: Increase leading image margin-bottom

[Tor Bug Tracker & Wiki]

#23022: Increase leading image margin-bottom
---+--
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by hiro):

 Yes I increased padding in all places, but can only use bottom padding if
 you prefer.

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

[tor-bugs] [Tor Bug Tracker & Wiki] Trac email verification for user: ramccl...@protonmail.com

[Tor Bug Tracker & Wiki]

Please visit the following URL to confirm your email address.

Verification URL: 

Username: ramccl...@protonmail.com
Verification Token: 43a-4228

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

Re: [tor-bugs] #23239 [- Select a component]: link File>Email Link NOT working (was: link File>Email Link now working)

[Tor Bug Tracker & Wiki]

#23239: link File>Email Link NOT working
--+
 Reporter:  ramcclain@…   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

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

Re: [tor-bugs] #23239 [- Select a component]: link File>Email Link now working

[Tor Bug Tracker & Wiki]

#23239: link File>Email Link now working
--+
 Reporter:  ramcclain@…   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ramcclain@…):

 * Attachment "TorEmailTo.jpg" 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] #23239 [- Select a component]: link File>Email Link now working

[Tor Bug Tracker & Wiki]

#23239: link File>Email Link now working
--+
 Reporter:  ramcclain@…   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 New user. Trying to make the Email LInk work under File. Can't find any
 other setup other than just link it. Tried to my Apple Mail, didn't work,
 and then to my Protonmail account, also didn't 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

[tor-bugs] #23238 [Applications/Quality Assurance and Testing]: Using Application Verifier Within Your Software Development Lifecycle

[Tor Bug Tracker & Wiki]

#23238: Using Application Verifier Within Your Software Development Lifecycle
-+-
 Reporter:  cypherpunks  |  Owner:  boklm
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance   |Version:
  and Testing|   Keywords:  tbb-
 Severity:  Normal   |  security
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 AppVerifier assists in finding subtle programming errors, security issues,
 and user account privilege problems that can be difficult to identify
 during a typical test pass.
 https://msdn.microsoft.com/en-us/library/aa480483.aspx

 Mozilla ignored it for 12 years!
 https://bugzilla.mozilla.org/show_bug.cgi?id=244805
 But it doesn't mean they had no bugs!
 https://bugzilla.mozilla.org/show_bug.cgi?id=1289994

 Old version download page https://www.microsoft.com/en-
 us/download/details.aspx?id=20028
 Current state https://docs.microsoft.com/en-us/windows-
 hardware/drivers/debugger/application-verifier

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

[tor-bugs] [Tor Bug Tracker & Wiki] Trac email verification for user: fusl

[Tor Bug Tracker & Wiki]

Please visit the following URL to confirm your email address.

Verification URL: 

Username: fusl
Verification Token: dNn_RVm9

-- 
Tor Bug Tracker & Wiki 
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] #23237 [Core Tor/Tor]: Add 'GETINFO ip-to-country/available'

[Tor Bug Tracker & Wiki]

#23237: Add 'GETINFO ip-to-country/available'
--+
 Reporter:  atagar|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Minor |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Hi Nick. Very minor ask but if we had a 'GETINFO ip-to-country/available'
 option to determine if tor has a geoip database available that would
 simplify Stem a bit. Stem tracks 'is the geoip database available' so it
 can avoid 'GETINFO ip-to-country/*' requests that are doomed to fail
 anyway.

 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] #23231 [Applications/Tor Browser]: Error in STL wrappers when building Firefox 64-bit for Windows (was: Error in STL wrappers when building firefox for Windows 64)

[Tor Bug Tracker & Wiki]

#23231: Error in STL wrappers when building Firefox 64-bit for Windows
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #23229| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * type:  task => defect


Comment:

 > for Windows 64
 "Windows 10 is the last version of Windows" (c) M$ ;)

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

Re: [tor-bugs] #22983 [Metrics/metrics-lib]: add a descriptor interface and implementation for web-logs

[Tor Bug Tracker & Wiki]

#22983: add a descriptor interface and implementation for web-logs
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 2.1.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by iwakeh):

 Replying to [comment:19 karsten]:
 > That's quite a few commits there, more than I can handle in a single
 chunk. But let me start going through them and put reviews here as I
 finish them.

 Yes, thanks for starting!

 >
 > e0c5774 and e224680 look good. Already merged to master.
 >
 > Some suggestions for 77b143d:
 >  - JSON is not exactly a compression type, it's a file content type.
 Maybe we can remove it now and fall back to the same PLAIN type that we
 fall back to for uncompressed logs?

 I didn't want to impose additional changes for generating the index.json*
 files.  I think it is also useful to state explicitly that files ending in
 '.json' are not compressed.
 Maybe, we can revisit the question later when applying more changes, e.g.,
 also adding enums for 'tar' and 'tar.gz' etc.?

 >  - The (duplicate) documentation in `FileType` doesn't help that much.
 I'd say let's either document all types or none of them. If I had to
 choose, I'd say none.

 Agreed, I removed the comments.

 >  - In `FileType#findType`, I think it's bad to catch `RuntimeException`,
 because that covers all kinds of programming errors made by application
 developers. For example, if they give us `ext = null` as parameter, we'll
 tell them it's a `PLAIN` file, but really they shouldn't give us that
 parameter. Better catch `IllegalArgumentException` only and let them catch
 their `NullPointerException` if they think that giving us `null` is a good
 idea. Related to this, let's not say in the documentation that we're not
 throwing any exceptions. (Of course, if the plan is to handle `null`
 exactly like this, let's put `IllegalArgumentException |
 NullPointerException` in the `catch` clause to indicate that we put it
 there intentionally.)

 True, the catch can be more restrictive; a fixup-commit contains the
 `IllegalArgumentException | NullPointerException` variation.

 >  - If you make changes to this commit, please make them as fixup/squash
 commit on top of the branch, so that I can continue reviewing subsequent
 commits.
 >
 > d687f44 looks good.
 >
 > I didn't finish my review of 76ae1e7, but here's some early feedback:
 >  - There's a file `IndexNode.java.orig` which should go away (in a later
 fixup commit).

 Removed.

 >  - The documentation of `WebServerAccessLogImpl` says that "the file is
 not read." Yet, it says a few sentences later that "it will be compressed
 to the default compression type" in case it's not compressed yet. That's a
 contradiction. And should we really do this? Or should we provide a way
 for the (internal) user to compress the file using the compression type of
 their choice?

 Good point!  I added a fixup commit, which provides a constructor arg for
 the default compression, but that will only be used, if the supplied log
 file doesn't have any compression extension.  All other cases, like
 changing compression type should be handled outside of metrics-lib using
 FileType enums directly.

 There is no contradiction, b/c the given bytes will be compressed, but not
 the file.  The File constructor argument is here to implement `Descriptor`
 interface's method `getDescriptorFile` (and also b/c we need filename and
 immediate parent path for meta-data).
 I think, it doesn't hurt to move the discussion and resulting changes to
 'the big picture' of ticket #22695.

 >
 > I'll resume the review as soon as I get to it.

 All changes are provided as fixup commits.

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

Re: [tor-bugs] #23022 [Webpages/Blog]: Increase leading image margin-bottom

[Tor Bug Tracker & Wiki]

#23022: Increase leading image margin-bottom
---+--
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by steph):

 Replying to [comment:1 hiro]:
 > I added 1.5 padding to leading image. What do you think?

 I think the bottom padding looks good, thanks!

 Was padding also increased on all sides? I think the padding is too much
 on the top, and we lose the full width image.

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

Re: [tor-bugs] #21759 [Metrics/CollecTor]: Add persistence for torperf/onionperf

[Tor Bug Tracker & Wiki]

#21759: Add persistence for torperf/onionperf
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  CollecTor 1.4.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Regarding the first part of comment:12:
 The discussion should be taken to a ticket summarizing the changes for all
 modules.
 I'll look for an appropriate ticket or create a new one.

 The current implementation of sync-runs is not affected by this
 considering our agreement in comment:8 and comment:9.

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

Re: [tor-bugs] #21759 [Metrics/CollecTor]: Add persistence for torperf/onionperf

[Tor Bug Tracker & Wiki]

#21759: Add persistence for torperf/onionperf
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  CollecTor 1.4.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by iwakeh):

 * status:  needs_information => needs_review


Comment:

 Please review the commits on top of this
 [https://gitweb.torproject.org/user/iwakeh/collector.git/log/?h=task-21759-2
 task-21759-2 branch].

 The
 
[https://gitweb.torproject.org/user/iwakeh/collector.git/commit/?h=task-21759-2&id=0e5146e582cbf887e4b0b84e75d856bc1e663c5d
 first commit] makes the onionperf module implementation adhere to the
 standard, i.e., use a sources property for determining the operation types
 (in this commit only Remote).  It also makes naming changes such that only
 'OnionPerf' is used for camel-case names.

 The
 
[https://gitweb.torproject.org/user/iwakeh/collector.git/commit/?h=task-21759-2&id=943deb3027c2622d14cf20818f8569eebf499f51
 second commit] adds Sync as new source.

 The
 
[https://gitweb.torproject.org/user/iwakeh/collector.git/commit/?h=task-21759-2&id=554947350ef9a03928561576614ba1358b59bf90
 third] adds and adapts tests accordingly.  The tests need task-22912 for
 successful completion.  Thus, temporarily metrics-lib version is set to
 'dev'
 
[https://gitweb.torproject.org/user/iwakeh/collector.git/commit/?h=task-21759-2&id=b84b8908914d186ee05ef6ae80cdde475474b9da
 here].

 The final two commits take care of changelog and tiny typos.

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

Re: [tor-bugs] #23217 [Internal Services/Service - trac]: This is a test ticket after trac update

[Tor Bug Tracker & Wiki]

#23217: This is a test ticket after trac update
--+---
 Reporter:  hiro  |  Owner:  hiro
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by hiro):

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


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

Re: [tor-bugs] #22009 [Webpages]: Adding Tor-official logos

[Tor Bug Tracker & Wiki]

#22009: Adding Tor-official logos
--+
 Reporter:  linda |  Owner:  hiro
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Webpages  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by hiro):

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


Comment:

 Done.

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #22348, #22779, #20657, #19281, ...

[Tor Bug Tracker & Wiki]

Batch modification to #22348, #22779, #20657, #19281, #12541, #19418, #22677, 
#22802, #22839, #22976, #23061, #23149, #23106 by nickm:


--
Tickets URL: 

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

Re: [tor-bugs] #23022 [Webpages/Blog]: Increase leading image margin-bottom

[Tor Bug Tracker & Wiki]

#23022: Increase leading image margin-bottom
---+--
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by hiro):

 * status:  new => needs_review


Comment:

 I added 1.5 padding to leading image. What do you think?

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

Re: [tor-bugs] #22806 [Webpages/Blog]: http://blog.torproject.org/ should redirect to https

[Tor Bug Tracker & Wiki]

#22806: http://blog.torproject.org/ should redirect to https
---+
 Reporter:  arma   |  Owner:  hiro
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by hiro):

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


Comment:

 This got overwritten in the last update from pantheon :(. It is fixed
 again now.

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

Re: [tor-bugs] #23236 [Obfuscation/BridgeDB]: Distribute 1/3 of all bridges' addr:port+some_bytes_of_data in captcha like format

[Tor Bug Tracker & Wiki]

#23236: Distribute 1/3 of all bridges' addr:port+some_bytes_of_data in captcha 
like
format
--+--
 Reporter:  cypherpunks   |  Owner:  isis
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 https://github.com/rday/ObfuscaTOR 2009 year. no progress no interest.
 why?

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

Re: [tor-bugs] #22786 [Webpages/Blog]: The blog's search box is hard to find, particularly on high security mode

[Tor Bug Tracker & Wiki]

#22786: The blog's search box is hard to find, particularly on high security 
mode
---+--
 Reporter:  teor   |  Owner:  hiro
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID:  #22013 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by hiro):

 * status:  new => needs_review


Comment:

 I have removed fonts and edited the blog search box. Please close this if
 you think the issue is solved.

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

Re: [tor-bugs] #23236 [Obfuscation/BridgeDB]: Distribute 1/3 of all bridges' addr:port+some_bytes_of_data in captcha like format (was: Distribute 1/3 of bridge's addr:port in captcha like format)

[Tor Bug Tracker & Wiki]

#23236: Distribute 1/3 of all bridges' addr:port+some_bytes_of_data in captcha 
like
format
--+--
 Reporter:  cypherpunks   |  Owner:  isis
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

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

[tor-bugs] #23236 [Obfuscation/BridgeDB]: Distribute 1/3 of bridge's addr:port in captcha like format

[Tor Bug Tracker & Wiki]

#23236: Distribute 1/3 of bridge's addr:port in captcha like format
--+--
 Reporter:  cypherpunks   |  Owner:  isis
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Happens for non protected distributors like e-mail.
 Guess not a first time this idea pops, some research already happen, pdfs
 published, tickets closed and idea was discarded ages ago for some good
 reasons? Or maybe implemented in some way? I just didn't found something
 yet, so this ticket is to get some resolution.

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

Re: [tor-bugs] #21778 [Applications/Tor Browser]: Canvas prompt is not showing up anymore in Tor Browser based in ESR52

[Tor Bug Tracker & Wiki]

#21778: Canvas prompt is not showing up anymore in Tor Browser based in ESR52
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff52-esr, tbb-7.0-must-alpha, tbb-   |  Actual Points:
  e10s, TorBrowserTeam201704R|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by cypherpunks):

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


Comment:

 Replying to [comment:11 cypherpunks]:
 > Can't you just leave people who use "High" security? This popup is very
 annoying.
 There's a related bug on Mozilla's bug tracker about not showing this
 popup until there's some user input, please don't mess up other tickets.

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

Re: [tor-bugs] #22839 [Core Tor/Tor]: Build tor with Rust code enabled on Windows

[Tor Bug Tracker & Wiki]

#22839: Build tor with Rust code enabled on Windows
--+
 Reporter:  isis  |  Owner:  snoek
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust, windows, tor-build  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:  SponsorZ
--+

Comment (by snoek):

 welcome :)

 And yep, I think as long as we are not functionally dependent on Rust
 code, we shouldn't need to break things for the old/current MinGW. These
 changes above shouldn't break it. The only change that bubbles down into
 the makefile for non-rust building is the added windows userenv lib
 dependency, but that should come with any MinGW install.

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

Re: [tor-bugs] #22983 [Metrics/metrics-lib]: add a descriptor interface and implementation for web-logs

[Tor Bug Tracker & Wiki]

#22983: add a descriptor interface and implementation for web-logs
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 2.1.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by karsten):

 That's quite a few commits there, more than I can handle in a single
 chunk. But let me start going through them and put reviews here as I
 finish them.

 e0c5774 and e224680 look good. Already merged to master.

 Some suggestions for 77b143d:
  - JSON is not exactly a compression type, it's a file content type. Maybe
 we can remove it now and fall back to the same PLAIN type that we fall
 back to for uncompressed logs?
  - The (duplicate) documentation in `FileType` doesn't help that much. I'd
 say let's either document all types or none of them. If I had to choose,
 I'd say none.
  - In `FileType#findType`, I think it's bad to catch `RuntimeException`,
 because that covers all kinds of programming errors made by application
 developers. For example, if they give us `ext = null` as parameter, we'll
 tell them it's a `PLAIN` file, but really they shouldn't give us that
 parameter. Better catch `IllegalArgumentException` only and let them catch
 their `NullPointerException` if they think that giving us `null` is a good
 idea. Related to this, let's not say in the documentation that we're not
 throwing any exceptions. (Of course, if the plan is to handle `null`
 exactly like this, let's put `IllegalArgumentException |
 NullPointerException` in the `catch` clause to indicate that we put it
 there intentionally.)
  - If you make changes to this commit, please make them as fixup/squash
 commit on top of the branch, so that I can continue reviewing subsequent
 commits.

 d687f44 looks good.

 I didn't finish my review of 76ae1e7, but here's some early feedback:
  - There's a file `IndexNode.java.orig` which should go away (in a later
 fixup commit).
  - The documentation of `WebServerAccessLogImpl` says that "the file is
 not read." Yet, it says a few sentences later that "it will be compressed
 to the default compression type" in case it's not compressed yet. That's a
 contradiction. And should we really do this? Or should we provide a way
 for the (internal) user to compress the file using the compression type of
 their choice?

 I'll resume the review as soon as I get to it.

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

Re: [tor-bugs] #23231 [Applications/Tor Browser]: Error in STL wrappers when building firefox for Windows 64

[Tor Bug Tracker & Wiki]

#23231: Error in STL wrappers when building firefox for Windows 64
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #23229| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 The full error is:
 {{{
 Executing: /var/tmp/dist/mingw-w64/helpers/x86_64-w64-mingw32-g++
 -std=gnu++11 -mwindows -shared -Wl,--out-implib -Wl,libmozglue.a -o
 mozglue.dll /var/tmp/build/firefox-
 af0ca6a886c7/obj-mingw/mozglue/build/tmp8l87fh.list module.res
 -specs=/var/tmp/dist/mingw-w64/msvcr100.spec -static mozglue.def
 -DELAYLOAD:user32.dll -luuid -lgdi32 -lwi
 nmm -lwsock32 -luserenv -lsecur32 -ldbghelp -lversion -ldelayimp
 /var/tmp/build/firefox-af0ca6a886c7/obj-
 mingw/mozglue/build/tmp8l87fh.list:
 INPUT("SSE.o")
 INPUT("WindowsDllBlocklist.o")
 INPUT("dummy.o")
 INPUT("../../memory/mozalloc/winheap.o")
 INPUT("../../memory/mozalloc/Unified_cpp_memory_mozalloc0.o")
 INPUT("../misc/StackWalk.o")
 INPUT("../misc/TimeStamp.o")
 INPUT("../misc/TimeStamp_windows.o")
 INPUT("../../mfbt/Compression.o")
 INPUT("../../mfbt/Decimal.o")
 INPUT("../../mfbt/Unified_cpp_mfbt0.o")
 INPUT("../../mfbt/Unified_cpp_mfbt1.o")

 
/var/tmp/dist/mingw-w64/lib/gcc/x86_64-w64-mingw32/5.4.0/../../../../x86_64-w64-mingw32/lib/libstdc++.a(functexcept.o):/var/tmp/build/gcc/x86_64-w64-mingw32/libstdc++-v3
 /src/c++11/../../../../gcc-5.4.0/libstdc++-v3/src/c++11/functexcept.cc:58:
 multiple definition of `std::__throw_bad_exception()'
 ../misc/TimeStamp.o:/var/tmp/build/firefox-af0ca6a886c7/obj-
 mingw/dist/include/mozilla/throw_gcc.h:43: first defined here
 
/var/tmp/dist/mingw-w64/lib/gcc/x86_64-w64-mingw32/5.4.0/../../../../x86_64-w64-mingw32/lib/libstdc++.a(functexcept.o):/var/tmp/build/gcc/x86_64-w64-mingw32/libstdc++-v3
 /src/c++11/../../../../gcc-5.4.0/libstdc++-v3/src/c++11/functexcept.cc:62:
 multiple definition of `std::__throw_bad_alloc()'
 ../misc/TimeStamp.o:/var/tmp/build/firefox-af0ca6a886c7/obj-
 mingw/dist/include/mozilla/throw_gcc.h:49: first defined here
 
/var/tmp/dist/mingw-w64/lib/gcc/x86_64-w64-mingw32/5.4.0/../../../../x86_64-w64-mingw32/lib/libstdc++.a(functexcept.o):/var/tmp/build/gcc/x86_64-w64-mingw32/libstdc++-v3
 /src/c++11/../../../../gcc-5.4.0/libstdc++-v3/src/c++11/functexcept.cc:66:
 multiple definition of `std::__throw_bad_cast()'
 ../misc/TimeStamp.o:/var/tmp/build/firefox-af0ca6a886c7/obj-
 mingw/dist/include/mozilla/throw_gcc.h:55: first defined here
 
/var/tmp/dist/mingw-w64/lib/gcc/x86_64-w64-mingw32/5.4.0/../../../../x86_64-w64-mingw32/lib/libstdc++.a(functexcept.o):/var/tmp/build/gcc/x86_64-w64-mingw32/libstdc++-v3
 /src/c++11/../../../../gcc-5.4.0/libstdc++-v3/src/c++11/functexcept.cc:70:
 multiple definition of `std::__throw_bad_typeid()'
 ../misc/TimeStamp.o:/var/tmp/build/firefox-af0ca6a886c7/obj-
 mingw/dist/include/mozilla/throw_gcc.h:61: first defined here
 
/var/tmp/dist/mingw-w64/lib/gcc/x86_64-w64-mingw32/5.4.0/../../../../x86_64-w64-mingw32/lib/libstdc++.a(functexcept.o):/var/tmp/build/gcc/x86_64-w64-mingw32/libstdc++-v3
 /src/c++11/../../../../gcc-5.4.0/libstdc++-v3/src/c++11/functexcept.cc:74:
 multiple definition of `std::__throw_logic_error(char const*)'
 ../misc/TimeStamp.o:/var/tmp/build/firefox-af0ca6a886c7/obj-
 mingw/dist/include/mozilla/throw_gcc.h:74: first defined here
 
/var/tmp/dist/mingw-w64/lib/gcc/x86_64-w64-mingw32/5.4.0/../../../../x86_64-w64-mingw32/lib/libstdc++.a(functexcept.o):/var/tmp/build/gcc/x86_64-w64-mingw32/libstdc++-v3
 /src/c++11/../../../../gcc-5.4.0/libstdc++-v3/src/c++11/functexcept.cc:78:
 multiple definition of `std::__throw_domain_error(char const*)'
 ../misc/TimeStamp.o:/var/tmp/build/firefox-af0ca6a886c7/obj-
 mingw/dist/include/mozilla/throw_gcc.h:80: first defined here
 
/var/tmp/dist/mingw-w64/lib/gcc/x86_64-w64-mingw32/5.4.0/../../../../x86_64-w64-mingw32/lib/libstdc++.a(functexcept.o):/var/tmp/build/gcc/x86_64-w64-mingw32/libstdc++-v3/src/c++11/../../../../gcc-5.4.0/libstdc++-v3/src/c++11/functexcept.cc:82:
 multiple definition of `std::__throw_invalid_argument(char const*)'
 ../misc/TimeStamp.o:/var/tmp/build/firefox-af0ca6a886c7/obj-
 mingw/dist/include/mozilla/throw_gcc.h:86: first defined here
 
/var/tmp/dist/mingw-w64/lib/gcc/x86_64-w64-mingw32/5.4.0/../../../../x86_64-w64-mingw32/lib/libstdc++.a(functexcept.o):/var/tmp/build/gcc/x86_64-w64-mingw32/libstdc++-v3/src/c++11/../../../../gcc-5.4.0/libstdc++-v3/src/c++11/functexcept.cc:86:
 multiple definition of `std::__throw_length_error(char const*)'
 ../mis