Re: [tor-bugs] #29538 [Core Tor/Tor]: Coverage fails on master

[Tor Bug Tracker & Wiki]

#29538: Coverage fails on master
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:  closed
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Major| Resolution:  not a
 Keywords:  tor-ci, tor-test, external-failure,  |  bug
  040-must   |  Actual Points:  0.3
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  new => closed
 * version:  Tor: unspecified =>
 * resolution:   => not a bug
 * actualpoints:  0.2 => 0.3


Comment:

 Replying to [comment:6 teor]:
 > #29435 might also be related - we were looking for coverage files in the
 wrong locations.

 Actually, I think that's a different script.

 coveralls seems to have recovered and processed their backlog.
 If any pull requests are missing a coverage report, please re-run the
 coverage build.

 If you don't have the permissions to launch builds on Travis:
 * login to Travis with your GitHub account,
 * close and re-open the pull request,
 * push another commit, or
 * open a trac ticket and someone will do it for you

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

Re: [tor-bugs] #29494 [Core Tor/Tor]: Optimize interaction between circuitmux and circuitpadding

[Tor Bug Tracker & Wiki]

#29494: Optimize interaction between circuitmux and circuitpadding
--+---
 Reporter:  mikeperry |  Owner:  mikeperry
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  wtf-pad   |  Actual Points:
Parent ID:| Points:  5
 Reviewer:|Sponsor:  Sponsor2
--+---

Comment (by mikeperry):

 Draft branch: https://github.com/mikeperry-tor/tor/commits/bug29494. Tests
 fail due to event changes. I want to mull this over a little more, but
 figured I'd post it for reference.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29555 [- Select a component]: Tor unexpectedly exited. this may be do to a Tor Bug, etc

[Tor Bug Tracker & Wiki]

#29555: Tor unexpectedly exited. this may be do to a Tor Bug, etc
--+--
 Reporter:  FMCfmc|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  - Select a component
  Version:  Tor: unspecified  |   Severity:  Normal
 Keywords:  exited|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 I have been trying to get onto Tor for 3 days and only get this message.
 when I click restart it goes to same message.
 191 MB (200,915,222 bytes)

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

Re: [tor-bugs] #29518 [Applications/Tor Browser]: general.useragent.override

[Tor Bug Tracker & Wiki]

#29518: general.useragent.override
--+---
 Reporter:  sj2001010 |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by sysrqb):

 * status:  new => needs_information


Comment:

 You are running Tor Browser on Windows, and the Javascript code
 (navigator.userAgent) is showing an "X11; Linux x86_64" user agent string?

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

Re: [tor-bugs] #29080 [Applications/Tor Browser]: Merge OrbotService and TOPL

[Tor Bug Tracker & Wiki]

#29080: Merge OrbotService and TOPL
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TBA-a3,  |  Actual Points:
  TorBrowserTeam201902   |
Parent ID:  #27609   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sysrqb):

 * cc: n8fr8 (added)


Comment:

 Adding nathan, in case he wants to burn some cycles reviewing some of
 this.

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

Re: [tor-bugs] #29204 [Core Tor/Tor]: Inspect circuit queue during padidng decisions

[Tor Bug Tracker & Wiki]

#29204: Inspect circuit queue during padidng decisions
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, 041-proposed, network-  |  Actual Points:
  team-roadmap-2019-Q1Q2 |
Parent ID:  #28634   | Points:  5
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor2
-+-

Comment (by dgoulet):

 So after discussion with Mike on IRC, the approach in the patch is good.
 It is correct to only look at the circuit queue since circuit padding
 needs to pad on a per-circuit level.

 Two things. First, I think this is an artifact that shouldn't be in the
 patch:

 {{{
   mi->is_padding_timer_scheduled = 0;
 }}}

 Second, because this adds a new consensus param so we'll need a
 torspec.git patch before we release stable.

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

Re: [tor-bugs] #28465 [Core Tor/Tor]: Use or remove "package" lines from votes

[Tor Bug Tracker & Wiki]

#28465: Use or remove "package" lines from votes
--+--
 Reporter:  irl   |  Owner:  irl
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by irl):

 Proposal submitted to tor-dev:

 https://lists.torproject.org/pipermail/tor-dev/2019-February/013703.html

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

[tor-bugs] #29554 [Applications/Tor Browser]: about:preferences hash urls do not work properly in Tor Browser

[Tor Bug Tracker & Wiki]

#29554: about:preferences hash urls do not work properly in Tor Browser
--+---
 Reporter:  pospeselr |  Owner:  pospeselr
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #25658
   Points:|   Reviewer:
  Sponsor:|
--+---
 Firefox allows you to access various sub-sections of the various pages in
 about:preferences by accessing urls in the form
 about:preferences#$(pane)-$(section). Ie, to access the Privacy -> Reports
 section you can navigate to: about:preferences#privacy-reports

 In latest version of vanilla Firefox this navigates to the Privacy pane
 and then scrolls down to the Reports section. In Tor Browser, it only
 navigates to the Privacy pane, without scrolling down the the Reports
 section.

 This feature is required for the 'Advanced Security Settings...' button to
 work correctly in the new security UI.

 The relevant place to start looking is in the init_all() and gotoPref()
 methods in /browser/components/preferences/in-content/preferences.js

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

Re: [tor-bugs] #29494 [Core Tor/Tor]: Optimize interaction between circuitmux and circuitpadding

[Tor Bug Tracker & Wiki]

#29494: Optimize interaction between circuitmux and circuitpadding
--+---
 Reporter:  mikeperry |  Owner:  mikeperry
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  wtf-pad   |  Actual Points:
Parent ID:| Points:  5
 Reviewer:|Sponsor:  Sponsor2
--+---

Comment (by mikeperry):

 Ok, so for simplicity, lying to circpad seems like the right move. If the
 queue is full, its going to be wrong anyway..

 However, the second piece of this ticket is about when to tell circpad
 that a padding cell or normal cell was sent. Right now, we tell circpad
 that a padding cell was sent as soon as its callback to send it fires (via
 circpad_cell_event_padding_sent() from
 circpad_send_padding_cell_for_callback()). With respect to the wire, this
 is incorrect because the cell may still wait around in a circuitmux queue
 for a long time before being sent. This delay may cause the padding system
 to decide to send another padding packet before the one it just sent even
 hits the wire.

 Similarly, we call circpad_cell_event_nonpadding_sent() from
 circpad_deliver_sent_relay_cell_events() (via
 relay_send_command_from_edge_()) and from
 circpad_deliver_unrecognized_cell_events() (via
 circuit_receive_relay_cell()). These calls are *also* before the cell is
 added to the circuitmux queue. This means that circuitpadding may schedule
 padding timers for additional padding that fire before the actual data
 packet makes it through the queue.

 In both cases, this will lead to more padding added to the circuit than we
 wanted to. Worse, it means more padding added to *already busy, saturated,
 and/or stalled circuits*, which is...not a good look.

 I think the right solution is to make these circpad_cell_event_*_sent()
 callbacks from channel_flush_from_first_active_circuit(), possibly right
 after the cell is popped from the queue. This will be about as accurate as
 we can get, because right after this it goes into the outbuf and should
 get sent by KIST within ~10ms, give or take TCP congestion.

 The difficulty with this is that circpad needs to know if this cell is
 padding or not. Since the cell has already been encrypted, we can't just
 inspect the relay command field anymore. We need to add an additional
 bitfield to packed_cell_t. 1 bit should suffice, though. All we need to
 know is is_padding or not.. But we need to set that bitfield in the
 relay_send_command_from_edge_() call, where the relay cell padding command
 is set. Otherwise the bitfield flag should remain 0.

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

Re: [tor-bugs] #15035 [Applications/Orbot]: URI format for bridges

[Tor Bug Tracker & Wiki]

#15035: URI format for bridges
+---
 Reporter:  eighthave   |  Owner:  n8fr8
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  uri, url, bridge|  Actual Points:
Parent ID:  #28015  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by eighthave):

 * cc: hans@… (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] #29489 [Obfuscation/Snowflake]: Set up automated local testing environment for Snowflake

[Tor Bug Tracker & Wiki]

#29489: Set up automated local testing environment for Snowflake
---+---
 Reporter:  cohosh |  Owner:  cohosh
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor19
---+---

Comment (by cohosh):

 I have a minimal test environment here now:
 https://github.com/cohosh/snowbox

 Right now I'm trying out running everything in the same docker container.
 This eases set up: the only dependency will be to have docker installed
 and the Snowflake source code cloned locally and mounted to the container
 using

 {{{
 docker run -p 8080:8080 -it  -v ${SNOWFLAKE_REPO}:/go/src/snowflake.git
 snowbox /bin/bash
 }}}

 This seems a better route than copying the repo locally as it can be built
 once in the container and reused without needing to be rebuilt if the
 container is restarted.

 Right now there is a bash script called script.sh that must be run inside
 the docker container that builds and runs parts of Snowflake. So far I am
 disabling TLS for these local tests and passing in the local broker and
 Snowflake proxy URLs through command line arguments.
 The broker is run using: {{{./broker -addr ":8080" -disable-tls}}} and
 port 8080 is exposed so that localhost:8080/debug can be accessed from the
 host machine.
 The proxy-go instance is run using {{{./proxy-go -broker
 "http://localhost:8080; -relay "wss://localhost"}}} to point to the
 broker.

 The next steps are:
 - Get a local bridge (snowflake server) running and the corresponding
 torrc files configured to actually send client traffic through the local
 environment
 - See if we can run each component using the same methods as the
 production enviornment. Right now I'm just using nohup, but the proxy-go
 instances are managed using runit in production.
 - Reproduce the proxy-go deadlocking bug #25688

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

Re: [tor-bugs] #29518 [Applications/Tor Browser]: general.useragent.override

[Tor Bug Tracker & Wiki]

#29518: general.useragent.override
--+--
 Reporter:  sj2001010 |  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 rl1987):

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


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

Re: [tor-bugs] #29522 [Community/Tor Support]: no connected

[Tor Bug Tracker & Wiki]

#29522: no connected
---+---
 Reporter:  dimaknv|  Owner:  phoul
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by rl1987):

 * owner:  (none) => phoul
 * component:  - Select a component => Community/Tor Support


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

Re: [tor-bugs] #29537 [Core Tor/Tor]: verify intptr_t round-trip through void *

[Tor Bug Tracker & Wiki]

#29537: verify intptr_t round-trip through void *
+--
 Reporter:  catalyst|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  portability technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by rl1987):

 * cc: rl1987 (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] #29060 [Core Tor/Tor]: shellcheck: test-network.sh issues

[Tor Bug Tracker & Wiki]

#29060: shellcheck: test-network.sh issues
+
 Reporter:  rl1987  |  Owner:  rl1987
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  ahf |Sponsor:
+
Changes (by rl1987):

 * status:  needs_revision => needs_review


Comment:

 In c346eff223e94b5fbeb6e751a99393fc5f7dd4b0 I'm trying to walk away from
 requiring bash by removing the `ORIGINAL_ARGS` array/variable.

 Not sure I'm not breaking something here. Why did we save `$@` into a
 variable in the first place?

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

Re: [tor-bugs] #28685 [Applications/Tor Browser]: Tor Browser for Android needs a more dynamic Build ID

[Tor Bug Tracker & Wiki]

#28685: Tor Browser for Android needs a more dynamic Build ID
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, TBA-a3, |  Actual Points:
  TorBrowserTeam201902   |
Parent ID:  #28708   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by sysrqb):

 Replying to [comment:5 boklm]:
 > #19528 is the ticket where we added the `get-moz-build-date` script
 generating a build id based on the firefox version.
 >
 > To solve the issue of two Tor Browser versions based on the same Firefox
 having the same build id, I think we could:
 > - use the Tor Browser version instead of the firefox version to generate
 a build id. I think the reason we did not do that was that it would make
 it harder to do #18325.
 > - Use the `tor-browser.git` commit date as the build id. This should fix
 the issue when a new release includes a new `tor-browser.git` commit,
 however it is still possible to have two releases with the same build id
 if they use the same `tor-browser.git` commit.
 > - Use the `tor-browser.git` commit date, and add to it the Tor Browser
 version.

 Hrm. #18325 is interesting. Android is the only platform where we want
 exactly what gk wants to avoid. Would it be crazy if we used a different
 buildid on desktop and Android? I see the benefit of having #18325, but
 considering on Android we can't install an update if it has the same
 buildid as the currently-installed version, we must bump the buildid for
 each release - regardless of whether the release changes any firefox code.

 Alternatively, we change how the Android versionCode is created for TBA.
 This will result in one more patch we carry for tor-browser, but then we
 can avoid the conflict with #18325 and maybe tor-browser-build can set the
 Android versionCode independently.

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

Re: [tor-bugs] #29553 [Core Tor/Tor]: pre-commit hook gives a warning when there are no changes files, when source files aren't where expected, and doesn't exit.

[Tor Bug Tracker & Wiki]

#29553: pre-commit hook gives a warning when there are no changes files, when
source files aren't where expected, and doesn't exit.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  .1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * cc: rl1987 (added)
 * status:  assigned => needs_review


Comment:

 See branch `ticket29553` with PR at
 https://github.com/torproject/tor/pull/720 .  The branch is based on
 0.4.0, but I see no reason to backport.

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

Re: [tor-bugs] #29553 [Core Tor/Tor]: pre-commit hook gives a warning when there are no changes files, when source files aren't where expected, and doesn't exit. (was: pre-commit hook gives a warning

[Tor Bug Tracker & Wiki]

#29553: pre-commit hook gives a warning when there are no changes files, when
source files aren't where expected, and doesn't exit.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  .1
 Reviewer:|Sponsor:
--+
Description changed by nickm:

Old description:

> Problem 1:
>
> {{{
> Traceback (most recent call last):
>   File "scripts/maint/lintChanges.py", line 111, in 
> if lintfile(fname):
>   File "scripts/maint/lintChanges.py", line 53, in lintfile
> with open(fname) as f:
> IOError: [Errno 2] No such file or directory: './changes/*'
> On branch release-0.3.5
> Your branch is up to date with 'origin/release-0.3.5'.
> }}}
>
> Problem 2:  The script lets me commit anyway.

New description:

 Problem 1:

 {{{
 Traceback (most recent call last):
   File "scripts/maint/lintChanges.py", line 111, in 
 if lintfile(fname):
   File "scripts/maint/lintChanges.py", line 53, in lintfile
 with open(fname) as f:
 IOError: [Errno 2] No such file or directory: './changes/*'
 On branch release-0.3.5
 Your branch is up to date with 'origin/release-0.3.5'.
 }}}

 Problem 2:  The script lets me commit anyway.

 Problem 3:  It doesn't run checkSpace.pl on the right locations for our
 pre-0.3.5 source layout.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29553 [Core Tor/Tor]: pre-commit hook gives a warning when there are no changes files,

[Tor Bug Tracker & Wiki]

#29553: pre-commit hook gives a warning when there are no changes files,
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:  .1|   Reviewer:
  Sponsor:|
--+
 Problem 1:

 {{{
 Traceback (most recent call last):
   File "scripts/maint/lintChanges.py", line 111, in 
 if lintfile(fname):
   File "scripts/maint/lintChanges.py", line 53, in lintfile
 with open(fname) as f:
 IOError: [Errno 2] No such file or directory: './changes/*'
 On branch release-0.3.5
 Your branch is up to date with 'origin/release-0.3.5'.
 }}}

 Problem 2:  The script lets me commit anyway.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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: #29315, #29166, #29330, #29425

[Tor Bug Tracker & Wiki]

Batch modification to #29315, #29166, #29330, #29425 by irl:
reviewer to irl

Comment:
Planned for review party tomorrow.

--
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] #29547 [Core Tor/Tor]: Disable merging to unsupported branches on origin

[Tor Bug Tracker & Wiki]

#29547: Disable merging to unsupported branches on origin
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  git-scripts   |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--

Comment (by nickm):

 See also #29532

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

Re: [tor-bugs] #29507 [Metrics/Analysis]: Evaluate existing OnionPerf data regarding worst-case performance

[Tor Bug Tracker & Wiki]

#29507: Evaluate existing OnionPerf data regarding worst-case performance
---+--
 Reporter:  karsten|  Owner:  karsten
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Metrics/Analysis   |Version:
 Severity:  Normal | Resolution:
 Keywords:  onionperf,metrics-roadmap-2019-q2  |  Actual Points:
Parent ID: | Points:  3
 Reviewer: |Sponsor:
---+--
Changes (by gaba):

 * points:   => 3


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

Re: [tor-bugs] #29168 [Core Tor/Tor]: Fix TROVE-2019-001 (KIST can write above outbuf highwater mark)

[Tor Bug Tracker & Wiki]

#29168: Fix TROVE-2019-001 (KIST can write above outbuf highwater mark)
-+-
 Reporter:  nickm|  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  security, trove, regression, |  Actual Points:
  040-must   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 For what it's worth, we've only been able to actually make this crash
 occur in a pretty nonstandard testing environment, and only then against
 clients.   But it's entirely possible that there's some way to exploit
 this in the wild that we're missing.  Out of caution, we're giving this
 issue medium severity, and putting out patches: better safe than sorry.

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

Re: [tor-bugs] #29204 [Core Tor/Tor]: Inspect circuit queue during padidng decisions

[Tor Bug Tracker & Wiki]

#29204: Inspect circuit queue during padidng decisions
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, 041-proposed, network-  |  Actual Points:
  team-roadmap-2019-Q1Q2 |
Parent ID:  #28634   | Points:  5
 Reviewer:  dgoulet  |Sponsor:
 |  Sponsor2
-+-
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 One single comment in the PR :).

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

Re: [tor-bugs] #29168 [Core Tor/Tor]: Fix TROVE-2019-001 (KIST can write above outbuf highwater mark) (was: Fix TROVE-2019-001)

[Tor Bug Tracker & Wiki]

#29168: Fix TROVE-2019-001 (KIST can write above outbuf highwater mark)
-+-
 Reporter:  nickm|  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  security, trove, regression, |  Actual Points:
  040-must   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Old description:



New description:

 From the fix in be84ed1a64ed7ce810bd3924fa96c2588b491ef5:
 {{{
 KIST works by computing how much should be allowed to write to the
 kernel for
 a given socket, and then it writes that amount to the outbuf.

 The problem is that it could be possible that the outbuf already has
 lots of
 data in it from a previous scheduling round (because the kernel is
 full/busy
 and Tor was not able to flush the outbuf yet). KIST ignores that the
 outbuf
 has been filling (is above its "highwater") and writes more anyway.
 The end
 result is that the outbuf length would exceed INT_MAX, hence causing
 an
 assertion error and a corresponding "Bug()" message to get printed to
 the
 logs.

 This commit makes it for KIST to take into account the outbuf length
 when
 computing the available space.
 }}}

--

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

Re: [tor-bugs] #25849 [Applications/Tor Browser]: Ship tor in Tor Browser nightly builds for Windows with Rust enabled

[Tor Bug Tracker & Wiki]

#25849: Ship tor in Tor Browser nightly builds for Windows with Rust enabled
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-rbm, TorBrowserTeam201902R,  |  Actual Points:
  boklm201811, GeorgKoppen201902 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

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


Comment:

 This looks good to me. I merged this to master with commit
 d500c61974ff1cdbccd31a64181aa10cb1e9482f.

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

Re: [tor-bugs] #29552 [Core Tor/Tor]: memory leak: protover_contains_long_protocol_names in protover.c calls parse_protocol_list, but doesn't free smartlist returned (treats it as a boolean)

[Tor Bug Tracker & Wiki]

#29552: memory leak: protover_contains_long_protocol_names in protover.c calls
parse_protocol_list, but doesn't free smartlist returned (treats it as a
boolean)
---+--
 Reporter:  drjohnson1984  |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor: 0.3.3.7
 Severity:  Normal | Resolution:  invalid
 Keywords:  memory-leak|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by drjohnson1984):

 The code looked like this in 0.3.3.7:
 bool
 protover_contains_long_protocol_names(const char *s)
 {
   if (!parse_protocol_list(s))
 return true;
   return false;
 }

 Because we modify source for internal testing and use, we only
 infrequently merge in versions.  I figured this would have generated a bug
 report at some point to go with the fix, but I guess not. Sorry to have
 bothered you

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

Re: [tor-bugs] #29552 [Core Tor/Tor]: memory leak: protover_contains_long_protocol_names in protover.c calls parse_protocol_list, but doesn't free smartlist returned (treats it as a boolean)

[Tor Bug Tracker & Wiki]

#29552: memory leak: protover_contains_long_protocol_names in protover.c calls
parse_protocol_list, but doesn't free smartlist returned (treats it as a
boolean)
---+--
 Reporter:  drjohnson1984  |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor: 0.3.3.7
 Severity:  Normal | Resolution:  invalid
 Keywords:  memory-leak|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dgoulet):

 Replying to [comment:2 drjohnson1984]:
 > The code looked like this in 0.3.3.7:

 Ah! So 0.3.3.x is end of life in 7 days. I would strongly suggest to use
 at least 0.3.4 :).

 It was backported in 0.3.3.8:

 {{{
   o Major bugfixes (directory authority, backport from 0.3.4.3-alpha):
 - Stop leaking memory on directory authorities when planning to
   vote. This bug was crashing authorities by exhausting their
   memory. Fixes bug 26435; bugfix on 0.3.3.6.
 }}}

 See #26435.

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

Re: [tor-bugs] #29552 [Core Tor/Tor]: memory leak: protover_contains_long_protocol_names in protover.c calls parse_protocol_list, but doesn't free smartlist returned (treats it as a boolean)

[Tor Bug Tracker & Wiki]

#29552: memory leak: protover_contains_long_protocol_names in protover.c calls
parse_protocol_list, but doesn't free smartlist returned (treats it as a
boolean)
---+--
 Reporter:  drjohnson1984  |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:
Component:  Core Tor/Tor   |Version:  Tor: 0.3.3.7
 Severity:  Normal | Resolution:  invalid
 Keywords:  memory-leak|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by dgoulet):

 * priority:  Medium => High
 * resolution:   => invalid
 * status:  new => closed
 * component:  Core Tor => Core Tor/Tor


Comment:

 Here is the function:

 {{{
 bool
 protover_contains_long_protocol_names(const char *s)
 {
   smartlist_t *list = parse_protocol_list(s);
   if (!list)
 return true; /* yes, has a dangerous name */
   SMARTLIST_FOREACH(list, proto_entry_t *, ent, proto_entry_free(ent));
   smartlist_free(list);
   return false; /* no, looks fine */
 }
 }}}

 The `if (!list)` means `if (list == NULL)` so we are looking at it and we
 only free it if non-NULL.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29552 [Core Tor]: memory leak: protover_contains_long_protocol_names in protover.c calls parse_protocol_list, but doesn't free smartlist returned (treats it as a boolean)

[Tor Bug Tracker & Wiki]

#29552: memory leak: protover_contains_long_protocol_names in protover.c calls
parse_protocol_list, but doesn't free smartlist returned (treats it as a
boolean)
---+--
 Reporter:  drjohnson1984  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Component:  Core Tor
  Version:  Tor: 0.3.3.7   |   Severity:  Normal
 Keywords:  memory-leak|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 The function parse_protocol_list in protover.c allocates a smartlist, and
 returns a pointer to the smartlist as long as there are no parse errors.
 The funcction protover_contains_long_protocol_names calls the former, but
 should capture and delete the returned smartlist if it is not null.

 I searched the database for these function names and they didn't show up,
 so I assume this is unreported and still a problem.  I apologize if I
 missed it somehow.

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

Re: [tor-bugs] #29546 [Core Tor/Tor]: Add draft maintainer table to network team wiki

[Tor Bug Tracker & Wiki]

#29546: Add draft maintainer table to network team wiki
--+
 Reporter:  teor  |  Owner:  teor
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  policy, doc   |  Actual Points:
Parent ID:| Points:  0.3
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Whatever we do, I would like us also to update `Maintaining.md`.
 Personally, I don't think our wiki is usable and probably used by a small
 subset of people. Thus keeping that information in the repository is
 logical and most likely to be seen/noticed.

 https://gitweb.torproject.org/tor.git/tree/doc/HACKING/Maintaining.md

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

Re: [tor-bugs] #28329 [Applications/Tor Browser]: Design TBA+Orbot configuration UI/UX

[Tor Bug Tracker & Wiki]

#28329: Design TBA+Orbot configuration UI/UX
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, ux-team, TBA-a3, |  Actual Points:
  TorBrowserTeam201902   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by sysrqb):

 * status:  new => needs_review


Comment:

 There's a branch for review on `28329_6`. I ran into multiple bugs, and I
 resolved some of them. The remaining bugs are:
   1. The (spinning) onion image isn't as large as it's shown in the mockup
   1. There is a up button (back button) in the upper-lefthand corner of
 the settings screen and it does nothing
   1. The mockup shows a dividing line between radio button bridge types, I
 failed getting that working
   1. When the gear/cog button is clicked from the Tor Log screen, the
 bootstrap process isn't stopped

 (I'm probably forgetting some others, too)

 I took a different approach for built-in bridges than Orbot. The bridges
 are provided by Gecko preferences the same as Tor Launcher. I think
 this'll make maintaining the list easier. However, as a result of this,
 the bridges are fetched asynchronously, so I added a placeholder in the
 radio button list while we wait for the response from Gecko.

 I also added a Save button on the "Provide a Bridge" screen, because
 inputting a bridge into the the text box and then pressing "Back" didn't
 seem like an obvious flow.

 On the branch, you can ignore the last commit. I simply used that for
 testing the Radio Button creation.

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

Re: [tor-bugs] #29551 [Core Tor/sbws]: Use timeout from the requests' session attribute in the methods

[Tor Bug Tracker & Wiki]

#29551: Use timeout from the requests' session attribute in the methods
---+---
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+---
Changes (by juga):

 * status:  needs_review => merge_ready


Comment:

 This is an small fix but important to get merged. It has been tested in
 the public network.

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

Re: [tor-bugs] #29551 [Core Tor/sbws]: Use timeout from the requests' session attribute in the methods

[Tor Bug Tracker & Wiki]

#29551: Use timeout from the requests' session attribute in the methods
---+---
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+---
Changes (by juga):

 * status:  assigned => needs_review


Comment:

 https://github.com/torproject/sbws/pull/336

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

Re: [tor-bugs] #21377 [Core Tor/Tor]: DirAuths should expose bwauth bandwidth files

[Tor Bug Tracker & Wiki]

#21377: DirAuths should expose bwauth bandwidth files
-+-
 Reporter:  tom  |  Owner:  juga
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, metrics, tor-bwauth,|  Actual Points:
  035-removed-20180711, 040-roadmap-proposed |
Parent ID:  #25925   | Points:
 Reviewer:  ahf  |Sponsor:
-+-

Comment (by juga):

 Oh, do the children tickets need to be closed before?.
 (In this case i thought that they were improvements that could be solved
 later and would need to be unparented to close this ticket first.)
 In that case i would wait for #28815 before adapting the code to #28816,
 unless there's a better strategy.

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

Re: [tor-bugs] #29550 [Core Tor/Tor]: Tor nightly fails to build for Windows

[Tor Bug Tracker & Wiki]

#29550: Tor nightly fails to build for Windows
-+
 Reporter:  boklm|  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-needs, 040-must  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

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


Comment:

 34183f0d71c2e2d10e3d64291e3bb83a27c2416a is a fix here; I've applied it to
 0.4.0 and forward.

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

Re: [tor-bugs] #29550 [Core Tor/Tor]: Tor nightly fails to build for Windows

[Tor Bug Tracker & Wiki]

#29550: Tor nightly fails to build for Windows
-+
 Reporter:  boklm|  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-needs, 040-must  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by nickm):

 In that case, it's probably better to revert that LDFLAGS change; it looks
 like a mistake.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29551 [Core Tor/sbws]: Use timeout from the requests' session attribute in the methods

[Tor Bug Tracker & Wiki]

#29551: Use timeout from the requests' session attribute in the methods
---+---
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points:  1  |   Reviewer:
  Sponsor: |
---+---
 In #28741 we added HTTP headers to send in every request.
 The session object was refactored to also add proxies and timeout.
 But requests doesn't use a timeout attribute, it can only be passed as a
 method argument.

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

Re: [tor-bugs] #29550 [Core Tor/Tor]: Tor nightly fails to build for Windows

[Tor Bug Tracker & Wiki]

#29550: Tor nightly fails to build for Windows
-+
 Reporter:  boklm|  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-needs, 040-must  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by boklm):

 I think the issue might be caused by this change from commit
 `acbde10fce5d688d70b5a4bfb3a736da838bb4cc`:
 {{{
 -src_test_test_slow_LDFLAGS = $(src_test_test_LDFLAGS)
 +src_test_test_slow_LDFLAGS =@TOR_LDFLAGS_openssl@
 }}}

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

Re: [tor-bugs] #27486 [Applications/Tor Browser]: Onboarding: "Visit an Onion" creates an "about:blank" loading page

[Tor Bug Tracker & Wiki]

#27486: Onboarding: "Visit an Onion" creates an "about:blank" loading page
-+-
 Reporter:  dmr  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Minor| Resolution:
 Keywords:  tbb-8.0-issues, tbb-onboarding, ux-  |  Actual Points:
  team, tbb-8.0.1-can, TorBrowserTeam201902R |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * status:  new => needs_review
 * keywords:  tbb-8.0-issues, tbb-onboarding, ux-team, tbb-8.0.1-can =>
 tbb-8.0-issues, tbb-onboarding, ux-team, tbb-8.0.1-can,
 TorBrowserTeam201902R


Comment:

 Here is a patch:
 https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug27486-01=86581f52952e4cb2480a161ae91d62d60f37da1a

 From the commit message:
  Instead of using a simple , programmatically open onboarding web
 pages by using tabBrowser.addTab(). The same technique is now used for
 "See My Path", "See FAQs", and "Visit an Onion".

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

Re: [tor-bugs] #29544 [Applications/Tor Browser]: couldn't load " xpcom".

[Tor Bug Tracker & Wiki]

#29544: couldn't load " xpcom".
--+---
 Reporter:  proserv   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by mcs):

 * status:  new => 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] #29544 [Applications/Tor Browser]: couldn't load " xpcom".

[Tor Bug Tracker & Wiki]

#29544: couldn't load " xpcom".
--+--
 Reporter:  proserv   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 I am sorry Tor Browser won't start for you. Please answer the following
 questions so we can help:
 * What operating system are you using?
 * Which version of Tor Browser are you using and where did you download it
 from?
 * Are any other messages logged or displayed?

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

Re: [tor-bugs] #29550 [Core Tor/Tor]: Tor nightly fails to build for Windows

[Tor Bug Tracker & Wiki]

#29550: Tor nightly fails to build for Windows
-+
 Reporter:  boklm|  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-needs, 040-must  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

 * milestone:   => Tor: 0.4.0.x-final


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

Re: [tor-bugs] #29540 [Applications/Tor Browser]: Impossible to change the color of visited links in Tor Browser

[Tor Bug Tracker & Wiki]

#29540: Impossible to change the color of visited links in Tor Browser
--+--
 Reporter:  sajolida  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  UX|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 I am 95% sure that visited link color won't change when "Remember browsing
 and download history" history is disabled (which is true by default in Tor
 Browser due to use of permanent private browsing mode). If that is the
 cause of this issue, then I think this is a "won't fix."

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

Re: [tor-bugs] #29425 [Metrics/Statistics]: Write integration tests for data-processing modules

[Tor Bug Tracker & Wiki]

#29425: Write integration tests for data-processing modules
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Statistics   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-roadmap-2019-q2  |  Actual Points:
Parent ID:   | Points:  8
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Replying to [ticket:29425 karsten]:
 > A next good step after that would be to talk about where/how to put this
 under version control. If that's impossible, we might be able to reduce
 the test data size a bit more, but maybe not as substantial as we'd want.

 I put some more thoughts on this. How about we create a new `metrics-
 test.git` repository for this? Testing metrics-web could be the start, and
 we could easily extend tests to other metrics code bases in the future. To
 be clear, unit tests would still exist in the respective repositories,
 this would just be for integration/system tests.

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

Re: [tor-bugs] #29550 [Core Tor/Tor]: Tor nightly fails to build for Windows

[Tor Bug Tracker & Wiki]

#29550: Tor nightly fails to build for Windows
-+--
 Reporter:  boklm|  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-needs, 040-must  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by boklm):

 * priority:  Medium => High
 * keywords:  tbb-needs => tbb-needs, 040-must


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

Re: [tor-bugs] #29550 [Core Tor/Tor]: Tor nightly fails to build for Windows

[Tor Bug Tracker & Wiki]

#29550: Tor nightly fails to build for Windows
--+--
 Reporter:  boklm |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-needs |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by boklm):

 * keywords:   => tbb-needs


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

Re: [tor-bugs] #29550 [Core Tor/Tor]: Tor nightly fails to build for Windows

[Tor Bug Tracker & Wiki]

#29550: Tor nightly fails to build for Windows
--+--
 Reporter:  boklm |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by boklm):

 * status:  new => needs_review


Comment:

 The attached patch `0001-Make-test-slow-compile-with-zlib.patch` is fixing
 the build for me.

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

Re: [tor-bugs] #29550 [Core Tor/Tor]: Tor nightly fails to build for Windows

[Tor Bug Tracker & Wiki]

#29550: Tor nightly fails to build for Windows
--+
 Reporter:  boklm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by boklm):

 * Attachment "0001-Make-test-slow-compile-with-zlib.patch" added.


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

[tor-bugs] #29550 [Core Tor/Tor]: Tor nightly fails to build for Windows

[Tor Bug Tracker & Wiki]

#29550: Tor nightly fails to build for Windows
--+
 Reporter:  boklm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Since 2019-02-15, tor fails to build for Windows inside the Tor Browser
 nightly builds.

 It fails with this error:
 {{{
   CCLD src/tools/tor-gencert.exe
   CCLD src/test/test-switch-id.exe
   CCLD src/test/test-timers.exe
   CCLD src/test/test-bt-cl.exe
   CCLD src/test/test-rng.exe
   CCLD src/test/fuzz/fuzz-consensus.exe
   CCLD src/test/fuzz/fuzz-descriptor.exe
   CCLD src/test/fuzz/fuzz-diff.exe
   CCLD src/test/fuzz/fuzz-diff-apply.exe
   CCLD src/test/fuzz/fuzz-extrainfo.exe
   CCLD src/test/fuzz/fuzz-hsdescv2.exe
   CCLD src/test/fuzz/fuzz-hsdescv3.exe
   CCLD src/test/fuzz/fuzz-http.exe
   CCLD src/test/fuzz/fuzz-http-connect.exe
   CCLD src/test/fuzz/fuzz-iptsv2.exe
   CCLD src/test/fuzz/fuzz-microdesc.exe
   CCLD src/test/fuzz/fuzz-socks.exe
   CCLD src/test/fuzz/fuzz-strops.exe
   CCLD src/test/fuzz/fuzz-vrs.exe
   CCLD src/app/tor.exe
   CCLD src/tools/tor-resolve.exe
   CCLD src/tools/tor-print-ed-signing-cert.exe
   CCLD src/test/bench.exe
   CCLD src/test/test.exe
   CCLD src/test/test-slow.exe
 
/var/tmp/dist/mingw-w64/lib/gcc/i686-w64-mingw32/6.4.0/../../../../i686-w64-mingw32/bin/ld:
 cannot find -lz
 collect2: error: ld returned 1 exit status
 make[1]: *** [src/test/test-slow.exe] Error 1
 Makefile:8673: recipe for target 'src/test/test-slow.exe' failed
 make[1]: *** Waiting for unfinished jobs
 make[1]: Leaving directory '/var/tmp/build/tor-59c3910becd9'
 Makefile:5290: recipe for target 'all' failed
 make: *** [all] Error 2
 }}}

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

Re: [tor-bugs] #29458 [Metrics/Onionperf]: Make sure that op-hk (and the other instances) do not run out of disk space

[Tor Bug Tracker & Wiki]

#29458: Make sure that op-hk (and the other instances) do not run out of disk 
space
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 I gzipped the 2017 tor and torctl logs on op-hk, op-nl, and op-us, which
 saves us roughly 10G per instance, so that there are now between 12G and
 15G free on each of them. This buys us a few weeks of time. Still, we
 should find a better solution soon.

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