Re: [tor-bugs] #28752 [Applications/Tor Browser]: Gradle sometimes downloads tor-android-binary resources during build (or the build is failing)

[Tor Bug Tracker & Wiki]

#28752: Gradle sometimes downloads tor-android-binary resources during build (or
the build is failing)
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-mobile, tbb-rbm, |  Actual Points:
  TorBrowserTeam201812R, TBA-a3  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by gk):

 * keywords:  tbb-mobile, tbb-rbm, TorBrowserTeam201812, TBA-a3 => tbb-
 mobile, tbb-rbm, TorBrowserTeam201812R, TBA-a3
 * status:  needs_review => closed
 * resolution:   => fixed


Comment:

 Cherry-picked to `master` (9b0b7b5159e670e04d5705350f33f8b2aa056634) (and
 I shortened the subject line of your commit message a bit).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24264 [Core Tor/DirAuth]: Enable IPv6 reachability testing for the Bridge Authority

[Tor Bug Tracker & Wiki]

#24264: Enable IPv6 reachability testing for the Bridge Authority
---+---
 Reporter:  isis   |  Owner:  (none)
 Type:  task   | Status:  assigned
 Priority:  High   |  Milestone:  Tor:
   |  0.4.0.x-final
Component:  Core Tor/DirAuth   |Version:
 Severity:  Normal | Resolution:
 Keywords:  dirauth, bridgeauth, ipv6  |  Actual Points:
Parent ID: | Points:  .2
 Reviewer: |Sponsor:  SponsorM
---+---
Changes (by darkspirit):

 * cc: jan@… (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] #26542 [Obfuscation/BridgeDB]: Distribute IPv6 bridges though bridges.torproject.org

[Tor Bug Tracker & Wiki]

#26542: Distribute IPv6 bridges though bridges.torproject.org
--+--
 Reporter:  teor  |  Owner:  isis
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #24264| Points:
 Reviewer:|Sponsor:
--+--
Changes (by darkspirit):

 * cc: jan@… (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] #28732 [Obfuscation/Snowflake]: Standardize on ArrayBuffer as the type of WebRTC messages

[Tor Bug Tracker & Wiki]

#28732: Standardize on ArrayBuffer as the type of WebRTC messages
---+
 Reporter:  dcf|  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dcf):

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


Comment:

 Merged this in [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/log/?id=01bdcd6b28a497895e28fcf0b43dfa158506eec1
 01bdcd6b28] and deployed to snowflake.torproject.org.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28902 [Core Tor/Nyx]: GETINFO commands with huge outputs slow down interpreter curses interface

[Tor Bug Tracker & Wiki]

#28902: GETINFO commands with huge outputs slow down interpreter curses 
interface
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:  curses|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by wagon):

 > Ah! So that ticket was about the control interpreter.
 Surely. I thought it [[#28877|was always clear]]:
 > If UseMicrodescriptors is set to 0 in Tor client, the command GETINFO
 desc/all-recent returns very huge listing which **interpreter cannot
 manage** properly. If amount of memory is big, after finishing this
 command Nyx starts to response slowly on any keyboard input everywhere and
 in all its windows, **not only in interpreter window**

 > I'd be happy to merge the fix if you'd care to whip it up. Otherwise
 I'll get to it when I have time.
 Probably you will find time faster than I will find time to learn python
 and its libraries...

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28877 [Core Tor/Tor]: Paginate large controller commands like 'GETINFO desc/all-recent'

[Tor Bug Tracker & Wiki]

#28877: Paginate large controller commands like 'GETINFO desc/all-recent'
--+--
 Reporter:  wagon |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by wagon):

 > Do you have a SSD?

 > I suspect this might be a matter of disk iops.
 No, I don't have SSD. However, disk cache should work (further invocations
 of the same commands are faster than the first ones, I think it is because
 of disk cache). Now I cannot make an ideal test with the whole system
 residing in RAM, but I copied Nyx/Stem directory to /tmp (which resides in
 RAM) and compared it with my above initial tests. I didn't find any
 difference. Shell is still at least two times faster than `tor-prompt`.

 > Again, this command is reading fourteen megabytes of data from disk then
 dumping it on the socket.
 I thought this data is read from memory of tor process, i.e. from RAM. Are
 you sure Tor makes request to hard drive each time it needs to provide
 this data?

 > get ran in low resource environments (arduino and such) where such
 commands can easily block the control connection for tens of seconds to
 minutes.
 Do you think it also explains the crash of `tor-prompt --run 'GETINFO desc
 /all-recent >/dev/null` command?

 If pipe is used, shell will also break (this is the reason I had to use
 descriptors in `test.sh`). For example, success of the command
 {{{
 ( echo AUTHENTICATE \"pass\" ; echo GETINFO ns/all ; echo QUIT ) | nc
 127.0.0.1 9051
 }}}
 depends on the time of invocation, existence of redirection to some file
 or to `/dev/null`, weather, and so on. If I redirect the output of this
 command to some file in RAM, I see that it stops after roughly 20k lines
 are printed. However, it works nice with short output commands.

 > these commands are no-gos if distributing an application more broadly.
 I agree. Let us wait what Tor core people will say.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28784 [Applications/Tor Browser]: Assembling WebRTC sources fails with error "You have unstaged changes"

[Tor Bug Tracker & Wiki]

#28784: Assembling WebRTC sources fails with error "You have unstaged changes"
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm, snowflake|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * status:  new => needs_review


Comment:

 I found some helpful options of `gclient sync`:
 {{{
 $ gclient help sync
   -f, --force   force update even for unchanged modules
   -D, --delete_unversioned_trees
 Deletes from the working copy any dependencies
 that
 have been removed since the last sync, as long as
 there are no local modifications. When used with
 --force, such dependencies are removed even if
 they
 have local modifications. When used with --reset,
 all
 untracked directories are removed from the working
 copy, excluding those which are explicitly ignored
 in
 the repository.
   -R, --reset   resets any local changes before updating (git
 only)
 }}}
 Adding these three options seems to take care of the gmock and gtest
 directories, no matter their current status.

 I tested this with a gclient/webrtc that had been manually set up with
 branch-heads/58 (`gclient sync --nohooks --no-history --with_branch_heads
 -r c279861207c5b15fc51069e96595782350e0ac12`) in order to simulate a
 webrtc upgrade, and I also tested after manually deleting
 src/testing/gmock and src/testing/gtest.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28784 [Applications/Tor Browser]: Assembling WebRTC sources fails with error "You have unstaged changes"

[Tor Bug Tracker & Wiki]

#28784: Assembling WebRTC sources fails with error "You have unstaged changes"
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm, snowflake|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by dcf):

 * Attachment "0001-Bug-28784-Pass-force-delete_unversioned_trees-
 reset-.patch" added.


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

Re: [tor-bugs] #23605 [Core Tor/Tor]: expired consensus causes guard selection to stall at BOOTSTRAP PROGRESS=80

[Tor Bug Tracker & Wiki]

#23605: expired consensus causes guard selection to stall at BOOTSTRAP 
PROGRESS=80
-+-
 Reporter:  catalyst |  Owner:
 |  catalyst
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bootstrap, clock-skew, tor-guard,|  Actual Points:
  usability, ux, s8-errors, 035-roadmap- |
  subtask, 035-triaged-in-20180711,  |
  s8-bootstrap   |
Parent ID:  #28018   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by teor):

 * owner:  teor => catalyst


Comment:

 catalyst, does your bootstrap stage rewrite cover this ticket?

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

Re: [tor-bugs] #28568 [Core Tor/Tor]: Stop running stem's unit tests in Tor's stem test

[Tor Bug Tracker & Wiki]

#28568: Stop running stem's unit tests in Tor's stem test
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.6.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  029-backport-maybe, 033-backport-|  Actual Points:  0.2
  maybe, 034-backport-maybe, 035-backport,   |
  fast-fix   |
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * keywords:  035-backport, fast-fix =>
 029-backport-maybe, 033-backport-maybe, 034-backport-maybe,
 035-backport, fast-fix
 * status:  assigned => needs_review
 * points:   => 0.2
 * version:  Tor: 0.3.5.1-alpha => Tor: 0.2.6.3-alpha
 * actualpoints:   => 0.2


Comment:

 See my pull request to merge to maint-0.3.5:
 https://github.com/torproject/tor/pull/607

 0.3.5 is the first release series that calls "make test-stem" in travis.

 The branch is based on maint-0.2.9, so we can backport to 0.2.9 if we want
 to.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28910 [Core Tor/Stem]: stem's jenkins CI runs the stem unit tests and the tor tests

[Tor Bug Tracker & Wiki]

#28910: stem's jenkins CI runs the stem unit tests and the tor tests
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:  #28568
   Points: |   Reviewer:
  Sponsor: |
---+
 Hi atagar,

 Does your advice about using `--integ`:
 https://trac.torproject.org/projects/tor/ticket/28552#comment:4

 Apply to the jenkins stem-tor-ci job?

 It's currently using `--all --target RUN_ALL`:
 {{{
 timeout -k 5m 60m python ./run_tests.py --all --tor ./RESULT/tor --target
 RUN_ALL --log NOTICE
 }}}
 https://jenkins.torproject.org/job/stem-tor-ci/lastBuild/console

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28909 [Core Tor/Stem]: jenkins stem ci jobs are missing some dependencies

[Tor Bug Tracker & Wiki]

#28909: jenkins stem ci jobs are missing some dependencies
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 Do the stem CI jobs on jenkins need these missing dependencies to run the
 full suite of tests?

 stem-ci-linux and stem-tor-ci are missing cryptography, pynacl, and
 pycodestyle:
 {{{
 18:52:27   stem version...  1.7.0-dev
 18:52:27   python version...2.7.9
 18:52:27   operating system version...  Linux
 (debian 8.11)
 18:52:27   cryptography version...  missing
 18:52:27   pynacl version...missing
 18:52:27   mock version...  1.0.1
 18:52:27   pyflakes version...  0.8.1
 18:52:27   pycodestyle version...   missing
 18:52:27   checking for orphaned .pyc files...  done
 (0.0s)
 18:52:27   checking for unused tests... done
 (0.0s)
 18:52:27   importing test modules...done
 (0.2s)
 18:52:27   running pyflakes...  running
 18:52:27   running pycodestyle...
 unavailable
 }}}
 https://jenkins.torproject.org/job/stem-ci-
 linux/lastBuild/ARCHITECTURE=amd64,SUITE=jessie/console

 And similar output for:
 https://jenkins.torproject.org/job/stem-tor-ci/lastBuild/console

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28908 [Webpages/Website]: Please remove/deactivate job posting on website (Software Developer, Anti-Censorship Team)

[Tor Bug Tracker & Wiki]

#28908: Please remove/deactivate job posting on website (Software Developer, 
Anti-
Censorship Team)
--+--
 Reporter:  ewyatt|  Owner:  hiro
 Type:  task  | Status:  needs_review
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by traumschule):

 * status:  new => needs_review


Comment:

 https://github.com/torproject/webwml/pull/70

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28907 [Webpages/Website]: Please remove/deactivate job postings on website

[Tor Bug Tracker & Wiki]

#28907: Please remove/deactivate job postings on website
--+--
 Reporter:  ewyatt|  Owner:  hiro
 Type:  task  | Status:  needs_review
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by traumschule):

 * status:  new => needs_review


Comment:

 https://github.com/torproject/webwml/pull/70

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28900 [Webpages/Website]: Upload press clips to website

[Tor Bug Tracker & Wiki]

#28900: Upload press clips to website
--+--
 Reporter:  steph |  Owner:  hiro
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by traumschule):

 * status:  new => needs_review


Comment:

 I found out about the reason for the newline issue and committed a patch
 for the script as well: https://github.com/torproject/webwml/pull/69

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28908 [Webpages/Website]: Please remove/deactivate job posting on website (Software Developer, Anti-Censorship Team)

[Tor Bug Tracker & Wiki]

#28908: Please remove/deactivate job posting on website (Software Developer, 
Anti-
Censorship Team)
--+--
 Reporter:  ewyatt|  Owner:  hiro
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512


 Please remove/deactivate the Software Developer (Anti-Censorship Team) job
 posting from the website. Thank you!

 -BEGIN PGP SIGNATURE-
 Comment: GPGTools - https://gpgtools.org

 iQIzBAEBCgAdFiEENecqn2ZVRfkstmYkugyUAPgPkc4FAlwa6nIACgkQugyUAPgP
 kc7KJxAAm/BcVEWg2FaP8pjOwvfDypJ5Br5n13QnybwWHWf7QqCR8wMhdjEmW31r
 /f/SP/RDQimYy35jjD82XIrCYN+qLnunwWmwO4PS4w30vbMYqIPBFDYRVjdCXeVS
 ECrTRqfdfHCVjm7/z516GfjZk4nuluk7lbRz4n9Z2pbxxD5pvjwbl4DncE/h377t
 r4VPIYtfgRwyBoB0eMgQUqvUKoHeHA6iYbddrMMGH9ATipi+fBN5h+aLIXAZno7P
 5aSUT8AHKTsfnhco6VBow44hmIVZ2rFnDO6FyM6FsVWS1KsieEn1FPBDxXH4V+pW
 bDmkz5WWtIbuPItwZkjn8KA9xuA6SkNFCxUOzj29KUnwV8ASAR2hLHtsL1YYncdD
 evu6XaUeDJueD9S7wzJ5/a5zYSpcNwGP8oQnIuIQtoPiiKGGGryGEErYkP59AMTD
 qS8j3qIpON7A3vnw07HO59sjUyqPZtBoWOrRP1XV/zg0lprwM3yDZ02dPuM9mqPy
 qR9bk9niK1qI70B7sVlp3s9S0766RPz9cMN1wJx9Qy0bdfkCUyU1kAU7qG1eMRzQ
 gIHThzDZUDW+XnALHUtDeIrkXlx0amlmmQKd2Zsjdwwf3HFLZ/oFCl20y0T5OCDj
 z9bZoyyaxDbLHuTq+E6vm9xzZMpezT2xpq10w1uRq1dJc49WAtA=
 =MY1p
 -END PGP SIGNATURE-
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28907 [Webpages/Website]: Please remove/deactivate job postings on website

[Tor Bug Tracker & Wiki]

#28907: Please remove/deactivate job postings on website
--+--
 Reporter:  ewyatt|  Owner:  hiro
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512


 Please remove/deactivate the following job listings on the website. Email
 update to follow.

 1. Metrics Data Architect
 2. Senior Systems Administrator

 Thank you!

 -BEGIN PGP SIGNATURE-
 Comment: GPGTools - https://gpgtools.org

 iQIzBAEBCgAdFiEENecqn2ZVRfkstmYkugyUAPgPkc4FAlwa6OgACgkQugyUAPgP
 kc5/tQ//clI5124Sim4Qi59XSmDLDQFI3T2FrN1cS3nMXJh+ggVRlNyA+tswL2Tl
 nM7Am2ygUIjLQSPt05a9Q+JZwXT7UmcOO+OWmoXS7ltiEMBPYuQqgVOxseXkYBdf
 UcekauV4EpFto4IEEQApZaeRDzmR2kKu96OFMm7uph2TJvSoeyrltxYnLXB+jjpp
 yLXjtruqv/iaotepWEKNOL4pJYAaI8zb943Jsnl3ZbR5Ap41l1MR6WRWCpzfvwwh
 jnNR7WoxpML/FyhCqjGJLovO78giTJ6aIyE8zM1f9fKVLFKUcgHBrj2xyi5YiQBQ
 NlSnElgXi8rv+T1l2WTAoAcMChrst2tkZeBNDv1pEug2iOxDSOg9Hltr0v+v/Opp
 PPUa8ZRz8gkgauuw3b7vYpkeTd4wV4rp2XyiTzt91R49C+sJCbD3iVgjRfx3lH3+
 0jXd4cb6oftBoMcPe4kN3PjS6YPXz7IrukJkC2Qu/B3CWerTe8uflUKJFkqogUcm
 T/YNCYVbfHana9+SPXq+aW8Cah1nOe9zljsdXtvfY7E9Z7arlktECFkl87EwAoQp
 b3bMLNHo2pfAU9jfMAotsMoswh8rpKYR8zZZnyA56ESOeQG4s7zPq1BdxhBZs1l9
 FCSKXVFBbmSIEv7oI3FH06T5j8ar8y+uXkLGWiAbX7Pq55ZtaNk=
 =y3pb
 -END PGP SIGNATURE-
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28861 [Core Tor/Torsocks]: torsocks: Unsupported syscall number 217

[Tor Bug Tracker & Wiki]

#28861: torsocks: Unsupported syscall number 217
+--
 Reporter:  ilf |  Owner:  dgoulet
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Torsocks   |Version:  Tor: 0.3.4.9
 Severity:  Normal  | Resolution:
 Keywords:  torsocks, syscall, 217  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by onirony):

 As a side note for why I think this merits whitelisting (unless there's a
 security issue with torsocks enabling getdents that I'm not aware of): A
 quick Google of the error msg plus the getdents and getdents64 syscall
 numbers reveals that a lot of people complain about applications failing
 bc of lack of getdents support in torsocks.

 Pretty lengthy threads can be found on a number of forums in which people
 unsuccessfully guess at why torsocks fails on some system call, to the
 point where it seems prudent that we amend the error message to include a
 link to some torsocks documentation explaining the nature of the whitelist
 system. Most forum threads I found re the error message came to
 ''incorrect'' conclusions about the cause of the error. But for now,
 considering getdents/getdents64 seem to be a very major cause of
 application incompatibility I think it's a great candidate for inclusion
 in the whitelist.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26630 [Core Tor/Tor]: Profile-driven work to reduce memory usage, focusing on clients and mobile.

[Tor Bug Tracker & Wiki]

#26630: Profile-driven work to reduce memory usage, focusing on clients and 
mobile.
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-roadmap-master, 035-triaged- |  Actual Points:
  in-20180711|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor19
-+-
Changes (by gaba):

 * sponsor:  Sponsor8-must => Sponsor19


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27691 [Core Tor/Tor]: reset bootstrap progress when enough things change

[Tor Bug Tracker & Wiki]

#27691: reset bootstrap progress when enough things change
-+-
 Reporter:  catalyst |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  usability, ux, ux-team, bootstrap,   |  Actual Points:
  035-roadmap-master, 035-triaged-in-20180711,   |
  s8-bootstrap, 035-deferred-20180930|
Parent ID:  #28018   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-

Comment (by catalyst):

 #2878 is a duplicate.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #2878 [Core Tor/Tor]: Don't bootstrap from an old consensus if we're about to replace it

[Tor Bug Tracker & Wiki]

#2878: Don't bootstrap from an old consensus if we're about to replace it
-+-
 Reporter:  Sebastian|  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Major| Resolution:
 Keywords:  performance, bootstrap, tor-client,  |  duplicate
  s8-performance, s8-errors, 040-roadmap-|  Actual Points:
  proposed   |
Parent ID:  #23605   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Changes (by catalyst):

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


Comment:

 At this point this mostly seems like a duplicate of #27691.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #2878 [Core Tor/Tor]: Don't bootstrap from an old consensus if we're about to replace it

[Tor Bug Tracker & Wiki]

#2878: Don't bootstrap from an old consensus if we're about to replace it
-+-
 Reporter:  Sebastian|  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Major| Resolution:
 Keywords:  performance, bootstrap, tor-client,  |  Actual Points:
  s8-performance, s8-errors, 040-roadmap-|
  proposed   |
Parent ID:  #23605   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-

Comment (by gaba):

 Yes. Feel free to close it if this is a duplicate.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28906 [Metrics/Relay Search]: host_name search failing

[Tor Bug Tracker & Wiki]

#28906: host_name search failing
--+--
 Reporter:  phoul |  Owner:  metrics-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Searching by host_name does not appear to be functioning.

 If you are on the details page for a relay, the link provided for
 host_name will take you to a failed search page.

 Example:

 
https://metrics.torproject.org/rs.html#details/C90CA3B7FE01A146B8268D56977DC4A2C024B9EA
 
https://metrics.torproject.org/rs.html#search/host_name:cowcat.relay.coldhak.com

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28861 [Core Tor/Torsocks]: torsocks: Unsupported syscall number 217

[Tor Bug Tracker & Wiki]

#28861: torsocks: Unsupported syscall number 217
+--
 Reporter:  ilf |  Owner:  dgoulet
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Torsocks   |Version:  Tor: 0.3.4.9
 Severity:  Normal  | Resolution:
 Keywords:  torsocks, syscall, 217  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by onirony):

 * status:  assigned => needs_review


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

Re: [tor-bugs] #28861 [Core Tor/Torsocks]: torsocks: Unsupported syscall number 217

[Tor Bug Tracker & Wiki]

#28861: torsocks: Unsupported syscall number 217
+--
 Reporter:  ilf |  Owner:  dgoulet
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Core Tor/Torsocks   |Version:  Tor: 0.3.4.9
 Severity:  Normal  | Resolution:
 Keywords:  torsocks, syscall, 217  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by onirony):

 I'm working on a seccomp based torsocks that should eliminate issues of
 this sort. Syscalls in torsocks are explicitly whitelisted and
 getdents/getdents64 are not on the whitelist. getdents seems very harmless
 to me and I think it should be whitelisted.

 @ilf, in the meantime here is a patched torsocks that can run getdents and
 getdents64 (the syscall it's rejecting in your error message):
 https://github.com/seisvelas/torsocks/tree/getdent_fix

 The getdents code I used to test my patch is just the example from the
 Linux man page and can be found here: http://man7.org/linux/man-
 pages/man2/getdents.2.html#EXAMPLE

 When I compiled that getdents example code and attempted to run it through
 standard torsocks this happened:


 {{{
 hc01@HC01:~$ /usr/bin/torsocks ./a.out
 [Dec 19 16:31:02] WARNING torsocks[16567]: [syscall] Unsupported syscall
 number 78.
 Denying the call (in tsocks_syscall() at syscall.c:465)
 getdents: Function not implemented
 }}}


 Then, using my patched torsocks:

 {{{
 hc01@HC01:~$ torsocks ./a.out
 --- nread=1008 ---
 i-node#  file type  d_reclen  d_off   d_name
 23068679  directory32 22651653883364612  .cache
 23069803  directory32 72324196525406672  .compiz
 ...
 }}}

 When I modified the code to use getdents64, I received the same error from
 torsocks. With my patch it ran properly. I'm going to bother David Goulet
 and set this ticket to 'needs review' to see if my patch is safe and can
 be accepted!

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

Re: [tor-bugs] #24264 [Core Tor/DirAuth]: Enable IPv6 reachability testing for the Bridge Authority

[Tor Bug Tracker & Wiki]

#24264: Enable IPv6 reachability testing for the Bridge Authority
---+---
 Reporter:  isis   |  Owner:  (none)
 Type:  task   | Status:  assigned
 Priority:  High   |  Milestone:  Tor:
   |  0.4.0.x-final
Component:  Core Tor/DirAuth   |Version:
 Severity:  Normal | Resolution:
 Keywords:  dirauth, bridgeauth, ipv6  |  Actual Points:
Parent ID: | Points:  .2
 Reviewer: |Sponsor:  SponsorM
---+---

Comment (by gman999):

 All seems fine almost 24 hours later.  Can someone confirm on the bridgedb
 end?

 It would be nice if the heartbeat showed ipv6 vs. ipv4, but I think that's
 been discussed.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28883 [Core Tor/Tor]: If many log messages are sent, test_rebind.py does not wait for 60 seconds

[Tor Bug Tracker & Wiki]

#28883: If many log messages are sent, test_rebind.py does not wait for 60 
seconds
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:  0
 Reviewer:  ahf   |Sponsor:
--+
Changes (by nickm):

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


Comment:

 Thanks!  Merging to 0.3.5 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] #28883 [Core Tor/Tor]: If many log messages are sent, test_rebind.py does not wait for 60 seconds

[Tor Bug Tracker & Wiki]

#28883: If many log messages are sent, test_rebind.py does not wait for 60 
seconds
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0
 Reviewer:  ahf   |Sponsor:
--+

Comment (by rl1987):

 Patch seems correct to 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] #28905 [Internal Services/Tor Sysadmin Team]: Please install packages for twisted gettor

[Tor Bug Tracker & Wiki]

#28905: Please install packages for twisted gettor
-+-
 Reporter:  ilv  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  gettor, twisted, refactor|  Actual Points:
Parent ID:  #28152   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by ln5):

 This is on getulum.torproject.org, right?

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

Re: [tor-bugs] #28752 [Applications/Tor Browser]: Gradle sometimes downloads tor-android-binary resources during build (or the build is failing)

[Tor Bug Tracker & Wiki]

#28752: Gradle sometimes downloads tor-android-binary resources during build (or
the build is failing)
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, |  Actual Points:
  TorBrowserTeam201812, TBA-a3   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by sisbell):

 * status:  needs_revision => needs_review


Comment:

 Changes (android-1219)

  * Changes as suggested in !comment:11

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

Re: [tor-bugs] #28799 [Metrics/Website]: Use readr's read_csv() to speed up drawing graphs

[Tor Bug Tracker & Wiki]

#28799: Use readr's read_csv() to speed up drawing graphs
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  assigned
 Priority:  Low  |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * owner:  karsten => metrics-team
 * status:  accepted => assigned


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28799 [Metrics/Website]: Use readr's read_csv() to speed up drawing graphs (was: Use R.cache to speed up drawing graphs)

[Tor Bug Tracker & Wiki]

#28799: Use readr's read_csv() to speed up drawing graphs
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  accepted
 Priority:  Low  |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  merge_ready => accepted
 * priority:  Medium => Low


Old description:

> Let's use R.cache to speed up drawing graphs. I already prepared a patch
> that I'm going to post here as soon as I have a ticket number. From the
> commit message:
>
> Over two years ago, in commit 1f90b72 from October 2016, we made our user
> graphs faster by avoiding to read the large .csv file on demand.  Instead
> we read it once as part of the daily update, saved it to disk as .RData
> file using R's save() function, and loaded it back to memory using R's
> load() function when drawing a graph.
>
> This approach worked okay. It just had two disadvantages:
>
>  1. We had to write a small amount of R code for each graph type, which
> is why we only did it for graphs with large .csv files.
>  2. Running these small R script as part of the daily update made it
> harder to move away from Ant towards a Java-only execution model.
>
> The new approach implemented in this commit uses R.cache, which caches
> data for use by concurrent Rserve clients. The first time we read a .csv
> file we save it to the cache, and all subsequent times we just load it
> back from the cache. We're using the file name and last modified time as
> key in the cache to avoid using stale data. We're also clearing the cache
> on startup to avoid running out of disk space.
>
> One somewhat unwanted side effect is that drawing the first graph from a
> new .csv file may take a few more seconds as compared to drawing
> subsequent graphs. This seems acceptable, though.
>
> Requires installing the R.cache package from CRAN, which is available on
> Debian as r-cran-r.cache.

New description:

 Let's use R.cache to speed up drawing graphs. I already prepared a patch
 that I'm going to post here as soon as I have a ticket number. From the
 commit message:

 Over two years ago, in commit 1f90b72 from October 2016, we made our user
 graphs faster by avoiding to read the large .csv file on demand.  Instead
 we read it once as part of the daily update, saved it to disk as .RData
 file using R's save() function, and loaded it back to memory using R's
 load() function when drawing a graph.

 This approach worked okay. It just had two disadvantages:

  1. We had to write a small amount of R code for each graph type, which is
 why we only did it for graphs with large .csv files.
  2. Running these small R script as part of the daily update made it
 harder to move away from Ant towards a Java-only execution model.

 The new approach implemented in this commit uses R.cache, which caches
 data for use by concurrent Rserve clients. The first time we read a .csv
 file we save it to the cache, and all subsequent times we just load it
 back from the cache. We're using the file name and last modified time as
 key in the cache to avoid using stale data. We're also clearing the cache
 on startup to avoid running out of disk space.

 One somewhat unwanted side effect is that drawing the first graph from a
 new .csv file may take a few more seconds as compared to drawing
 subsequent graphs. This seems acceptable, though.

 Requires installing the R.cache package from CRAN, which is available on
 Debian as r-cran-r.cache.

 '''Edit: Turns out that we don't want R.cache but readr's read_csv()
 instead. See comments below.'''

--

Comment:

 Thanks for looking! Merged with a small
 [https://gitweb.torproject.org/user/karsten/metrics-
 web.git/commit/?h=task-28799-2=fecafc07b99798946308bbb3615c15bb0ce6a30f
 tweak], and deployed.

 Setting back to accepted for the remaining graphs after we gathered some
 more experience with this new approach. That could easily happen in 2019.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28905 [Internal Services/Tor Sysadmin Team]: Please install packages for twisted gettor

[Tor Bug Tracker & Wiki]

#28905: Please install packages for twisted gettor
-+-
 Reporter:  ilv  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  gettor, twisted, refactor|  Actual Points:
Parent ID:  #28152   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by ilv):

 * parent:   => #28152


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28905 [Internal Services/Tor Sysadmin Team]: Please install packages for twisted gettor

[Tor Bug Tracker & Wiki]

#28905: Please install packages for twisted gettor
-+-
 Reporter:  ilv  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Component:  Internal
 |  Services/Tor Sysadmin Team
  Version:   |   Severity:  Normal
 Keywords:  gettor, twisted, |  Actual Points:
  refactor   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
 A code refactor has been made to gettor using twisted (see #28152). The
 following packages are needed for it to work:

 gcc python2.7 python-dev virtualenv sqlite3 python-pip

 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] #27723 [Obfuscation/Censorship analysis]: Obfs4 stopped working 16 Sept 18

[Tor Bug Tracker & Wiki]

#27723: Obfs4 stopped working 16 Sept 18
-+-
 Reporter:  mwolfe   |  Owner:  dcf
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block ae obfs4 meek   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mwolfe):

 Replying to [comment:14 anadahz]:
 > Replying to [comment:13 mwolfe]:
 > > Replying to [comment:11 anadahz]:
 > > > Replying to [comment:5 mwolfe]:
 > >  > Do you know if Tor vanilla (no usage of bridges) is blocked in UAE?
 > > As of today, 18 Dec 2018, Tor is not blocked.
 > It will be really interesting to find out if there is any pattern on how
 often/which date/time interval they use to block.
 Today, 19 Dec 2018, Tor is blocked. I have attached a copy of the log
 showing Tor trying to connect, failing until I turned on obfs4, then
 connecting. I have no idea when Tor is blocked and unblocked, but at least
 I can connect just by clicking obfs4. For now.

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

Re: [tor-bugs] #27723 [Obfuscation/Censorship analysis]: Obfs4 stopped working 16 Sept 18

[Tor Bug Tracker & Wiki]

#27723: Obfs4 stopped working 16 Sept 18
-+-
 Reporter:  mwolfe   |  Owner:  dcf
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block ae obfs4 meek   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mwolfe):

 * Attachment "torlog19122018.doc" added.

 log trying to connnect without and with bridge

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28868 [Core Tor/sbws]: best_priority() can starve the worker threads of good relays

[Tor Bug Tracker & Wiki]

#28868: best_priority() can starve the worker threads of good relays
---+---
 Reporter:  teor   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28663 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by juga):

 * owner:  (none) => juga
 * status:  new => assigned


Comment:

 I've this branch https://github.com/juga0/sbws/commits/bug28868, but it's
 missing the test.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28866 [Core Tor/sbws]: ResultDump.queue.put() can hang if the queue is full

[Tor Bug Tracker & Wiki]

#28866: ResultDump.queue.put() can hang if the queue is full
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28663 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by juga):

 After looking more at this.

 Replying to [ticket:28866 teor]:
 > sbws calls `ResultDump.queue.put()` in blocking mode:
 >
 
https://github.com/torproject/sbws/blob/ee64d76df54ceb3a3c9e1e2a797fd70d68bb0035/sbws/core/scanner.py#L303

 put is not blocking because it happens in result_dump's thread
 (result_dump launches its own thread before the the pool is instantiated)

 >
 > But multiprocessing callbacks need to return immediately:
 >
 
https://docs.python.org/3/library/multiprocessing.html#multiprocessing.pool.Pool.apply_async
 >
 > So sbws should call put() without blocking, or with a (very small)
 timeout:
 > https://docs.python.org/3/library/queue.html#queue.Queue.put

 With put timeout it will always return Full unless the slot is inmediatly
 available (https://docs.python.org/3/library/queue.html#queue.Queue.put)
 It's also very unlikely that the queue will be full, since results happen
 with a difference of seconds and worst case there're only 6000.
 A way to solve this without a different thread, queue and lock in
 result_putter, would be to use a deque, but i don't think it's necessary,
 since i think the bug is in #28897.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28902 [Core Tor/Nyx]: GETINFO commands with huge outputs slow down interpreter curses interface

[Tor Bug Tracker & Wiki]

#28902: GETINFO commands with huge outputs slow down interpreter curses 
interface
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:  curses|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by atagar):

 Ah! So that ticket was about the control interpreter. That makes a lot
 more sense (I thought you were talking about an internal 'GETINFO desc
 /all-recent' invocation).

 If you're running that command three times the control interpreter has
 accumulated roughly 1080078 lines of content. The draw method then
 iterates over that which is probably the source of the problem...

 https://gitweb.torproject.org/nyx.git/tree/nyx/panel/interpreter.py#n133

 This should be easy to fix. Rather than looping over the whole list we
 should splice to the visible range.

 Honestly I won't be getting to this any time soon, but I'd be happy to
 merge the fix if you'd care to whip it up. Otherwise I'll get to it when I
 have time.

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

Re: [tor-bugs] #28865 [Core Tor/sbws]: sbws keeps the number of AsyncResults less than the number of threads

[Tor Bug Tracker & Wiki]

#28865: sbws keeps the number of AsyncResults less than the number of threads
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28663 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by juga):

 Replying to [ticket:28865 teor]:
 [...]
 > There are two different ways that this code blocks execution:
 > * when a result finishes, the `time.sleep(5)` call blocks the thread
 from getting a new `AsyncResult` for up to 5 seconds

 the main thread blocks, but not the workers.

 > * if `max_pending_results` `AsyncResult`s ever block, the process hangs

 and that would mean there's a deadlock or a bug somewhere else. Probably
 the cause (or at least the main one) is #28897.
 What i would to detect future bugs, is give a maximum timeout to both
 while loops, then print a backtrace and ask the user to open a ticket with
 the backtrace.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28864 [Core Tor/sbws]: sbws AsyncResults have no timeout

[Tor Bug Tracker & Wiki]

#28864: sbws AsyncResults have no timeout
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28663 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by juga):

 I looked more at this.
 `wait` is the method of an `event`
 
(https://github.com/python/cpython/blob/master/Lib/multiprocessing/pool.py#L662),
 and it blocks
 
(https://docs.python.org/3/library/threading.html?highlight=threading#threading.Event.wait)
 `sleep` is not blocking because happen in the main thread.
 Probably the cause (or at least the main one) is #28897.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28897 [Core Tor/sbws]: Stop running twice destination usability tests

[Tor Bug Tracker & Wiki]

#28897: Stop running twice destination usability tests
---+---
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28663 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by juga):

 * status:  assigned => needs_review


Comment:

 I think this is what is making sbws stalls.
 A backtrace [0] in the moment it's stalled shows two threads trying to get
 the  next destination.
 It locks
 
https://github.com/torproject/sbws/blob/ee64d76df54ceb3a3c9e1e2a797fd70d68bb0035/sbws/lib/destination.py#L248,
 then while True, then if it enters in _perform_usability_test, will lock
 again, then call _is_usable, which call connect_destination_over_circuit
 which locks again. If it fails then it sleep.
 Many times connect_to_destination_over_circuit fails several times in a
 row, cause it's not reliable to do it through Tor and random relays.
 If _usable_dests is not overwritten every time that a destination is
 chosen, then a lock is only needed in connect_destination_over_circuit.
 It would be better to refactor all this code to trace it and debug it
 easier.
 As a temporal solution, the "usability" can be tracked out of the class
 and without locks.
 For now i'd just disable checking for usability, and prioritize the
 refactoring ticket as soon as 1.0 is 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

Re: [tor-bugs] #28870 [Core Tor/sbws]: Stop asserting when there's not a descriptor for a relay being measured

[Tor Bug Tracker & Wiki]

#28870: Stop asserting when there's not a descriptor for a relay being measured
---+---
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28663 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by juga):

 * status:  needs_revision => needs_review


Comment:

 Add one more commit

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #26630 [Core Tor/Tor]: Profile-driven work to reduce memory usage, focusing on clients and mobile.

[Tor Bug Tracker & Wiki]

#26630: Profile-driven work to reduce memory usage, focusing on clients and 
mobile.
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-roadmap-master, 035-triaged- |  Actual Points:
  in-20180711|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-must
-+-

Comment (by gaba):

 Yes. This one will not fit in sponsor 8. I will move it back to s19 and
 then we decide if it can get in that roadmap.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28877 [Core Tor/Tor]: Paginate large controller commands like 'GETINFO desc/all-recent'

[Tor Bug Tracker & Wiki]

#28877: Paginate large controller commands like 'GETINFO desc/all-recent'
--+--
 Reporter:  wagon |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by atagar):

 > Hello, atagar. Thank you for the explanation, now it is more clear for
 me.

 Thanks wagon! These are interesting stats.

 > Could you explain why it is a problem?

 Do you have a SSD? When I run on my newish laptop I get similar results...

 {{{
 atagar@morrigan:~$ time tor-prompt --run 'GETINFO ns/all' 1>/dev/null

 real0m0.236s
 user0m0.108s
 sys 0m0.045s
 }}}

 ... but when I run on my admittedly ancient PC it's not so rosy...

 {{{
 atagar@odin:~$ time tor-prompt --run 'GETINFO ns/all' 1>/dev/null

 real0m1.466s
 user0m0.240s
 sys 0m0.116s
 }}}

 I suspect this might be a matter of disk iops. Again, this command is
 reading fourteen megabytes of data from disk then dumping it on the
 socket. Stem (and by extension Nyx) get ran in low resource environments
 (arduino and such) where such commands can easily block the control
 connection for tens of seconds to minutes.

 You're absolutely right that in your case (and most people's) these are
 fine, but these commands are no-gos if distributing an application more
 broadly.

 > People always say that shell is too slow and inconvenient, while python
 is really fast and convenient. However...

 These are interesting numbers. I should profile our controller code with
 this input to figure out where the time's being spent (I made several
 optimizations for the Stem 1.7 release, but there's probably more room for
 improvement).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28180 [Core Tor/Tor]: Signal mechanism from PT processes to Tor

[Tor Bug Tracker & Wiki]

#28180: Signal mechanism from PT processes to Tor
-+-
 Reporter:  ahf  |  Owner:  dgoulet
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-pt, 040-roadmap-subtask  |  Actual Points:
Parent ID:  #25502   | Points:
 Reviewer:   |Sponsor:  Sponsor8
-+-

Comment (by gaba):

 Can we close this ticket then?

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

Re: [tor-bugs] #28020 [Core Tor/Tor]: Run another memory profile in late 0.4.0 to figure out how much memory we saved.

[Tor Bug Tracker & Wiki]

#28020: Run another memory profile in late 0.4.0 to figure out how much memory 
we
saved.
-+-
 Reporter:  nickm|  Owner:  dgoulet
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-roadmap-master, 035-triaged- |  Actual Points:
  in-20180711|
Parent ID:  #26630   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by dgoulet):

 * points:   => 0.5


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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: #28801, #28859

[Tor Bug Tracker & Wiki]

Batch modification to #28801, #28859 by irl:
reviewer to irl

--
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] #28020 [Core Tor/Tor]: Run another memory profile in late 0.4.0 to figure out how much memory we saved.

[Tor Bug Tracker & Wiki]

#28020: Run another memory profile in late 0.4.0 to figure out how much memory 
we
saved.
-+-
 Reporter:  nickm|  Owner:  dgoulet
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-roadmap-master, 035-triaged- |  Actual Points:
  in-20180711|
Parent ID:  #26630   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by dgoulet):

 Results are here:
 https://people.torproject.org/~dgoulet/volatile/perf/0.4.0-ed0bc85ed0ac/
 (Only the `inuse` for now, skipping the `flamegraph`).

 Big takeaways:

 * The 10 min loop 10MB and 100MB file download through an '''Exit'''
 profile shows that we've reduced our memory usage by `~73%`.

 * The 10 min loop 10MB and 100MB file download through an '''Onion'''
 profile shows that we've reduced our memory usage by `~50%`.

 * The one time 100MB file over an '''Exit''' and '''Onion''' profile shows
 that we've reduced our memory usage by `~73%`.

 (0.3.5 results:
 https://people.torproject.org/~dgoulet/volatile/perf/0.3.5/)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28799 [Metrics/Website]: Use R.cache to speed up drawing graphs

[Tor Bug Tracker & Wiki]

#28799: Use R.cache to speed up drawing graphs
-+-
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by irl):

 * status:  needs_review => merge_ready


Comment:

 Glad to hear that this is fast enough that we don't need to cache. That is
 awesome!

 The commit looks good to me. It is nice to see the new code looking a lot
 clearer and more readable.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28356 [Core Tor/Tor]: DataDirectoryGroupReadable and CacheDirectoryGroupReadable conflicts forcing sandboxed Tor to crash

[Tor Bug Tracker & Wiki]

#28356: DataDirectoryGroupReadable and CacheDirectoryGroupReadable conflicts
forcing sandboxed Tor to crash
-+-
 Reporter:  wagon|  Owner:  arma
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.4.9
 Severity:  Normal   | Resolution:
 Keywords:  tor-crash, regression, 035-roadmap-  |  Actual Points:
  proposed, 035-backport, 034-backport, 033  |
  -backport-maybe, 029-backport-maybe, 035-can   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by wagon):

 > what's the goal to be able to read directory's content, bit be unable to
 read any file inside it?
 I'll
 [[http://ea5faa5po25cf7fb.onion/projects/tor/ticket/28877#comment:3|quote]]
 atagar:
 > any direct use of tor's data directory is a bad idea
 Do we have anything useful that can be obtained only from Tor data
 directory directly, i.e. cannot be learnt from `ControlPort`? Some
 historical data about guard use written in `state` file?

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

Re: [tor-bugs] #28020 [Core Tor/Tor]: Run another memory profile in late 0.4.0 to figure out how much memory we saved. (was: Run another memory profile in late 0.3.6 to figure out how much memory we s

[Tor Bug Tracker & Wiki]

#28020: Run another memory profile in late 0.4.0 to figure out how much memory 
we
saved.
-+-
 Reporter:  nickm|  Owner:  dgoulet
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-roadmap-master, 035-triaged- |  Actual Points:
  in-20180711|
Parent ID:  #26630   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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 lead image bottom spacing; reduce top spacing

[Tor Bug Tracker & Wiki]

#23022: Increase lead image bottom spacing; reduce top spacing
---+
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  ux-team|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by steph):

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


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

Re: [tor-bugs] #24440 [Webpages/Blog]: Match blog title post spacing to archive post title spacing

[Tor Bug Tracker & Wiki]

#24440: Match blog title post spacing to archive post title spacing
---+--
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by steph):

 * Attachment "Screen Shot 2018-12-19 at 10.24.53 AM.png" added.


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

Re: [tor-bugs] #24440 [Webpages/Blog]: Match blog title post spacing to archive post title spacing

[Tor Bug Tracker & Wiki]

#24440: Match blog title post spacing to archive post title spacing
---+--
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by steph):

 The spacing is still off -- it widens between the title and the authoring
 information. Will upload screenshot.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28904 [Applications/Quality Assurance and Testing]: tbb-testsuite: fix the settings test

[Tor Bug Tracker & Wiki]

#28904: tbb-testsuite: fix the settings test
-+-
 Reporter:  boklm|  Owner:
 |  cypherpunks
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Normal   | Resolution:
 Keywords:  tbb-testsuite, boklm201812,  |  Actual Points:
  TorBrowserTeam201812   |
Parent ID:  #27105   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 `security.enable_tls_session_tickets` was changed by #17252. I removed
 this pref from the test in commit
 `d2f3b5528f42b192386f84eb1794e722e8cef7cc`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28904 [Applications/Quality Assurance and Testing]: tbb-testsuite: fix the settings test

[Tor Bug Tracker & Wiki]

#28904: tbb-testsuite: fix the settings test
-+-
 Reporter:  boklm|  Owner:
 |  cypherpunks
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Normal   | Resolution:
 Keywords:  tbb-testsuite, boklm201812,  |  Actual Points:
  TorBrowserTeam201812   |
Parent ID:  #27105   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 `network.http.pipelining.*` prefs have been removed with #26603 and
 #27262.

 I removed those prefs from the test in commit
 `92d6e38db9db71d54634c94879ccfda7ed67f37e`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28904 [Applications/Quality Assurance and Testing]: tbb-testsuite: fix the settings test

[Tor Bug Tracker & Wiki]

#28904: tbb-testsuite: fix the settings test
-+-
 Reporter:  boklm|  Owner:  cypherpunks
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:   |Version:
  Applications/Quality Assurance |
  and Testing|   Keywords:  tbb-testsuite,
 Severity:  Normal   |  boklm201812, TorBrowserTeam201812
Actual Points:   |  Parent ID:  #27105
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 The settings test currently fails with the following error:
 {{{
 TEST-UNEXPECTED-FAIL | test_settings.py Test.test_settings |
 AssertionError: network.http.proxy.pipelining: None != True
 layers.acceleration.disabled: False != True
 network.http.pipelining.read-timeout: None != 6
 network.http.pipelining.reschedule-timeout: None != 15000
 network.http.pipelining: None != True
 security.enable_tls_session_tickets: None != False
 network.http.spdy.enabled: True != False
 network.http.pipelining.ssl: None != True
 network.http.pipelining.aggressive: None != True
 security.tls.version.max: 4 != 3
 network.http.spdy.enabled.v3: None != False
 network.http.spdy.enabled.v2: None != False
 gfx.direct2d.disabled: None != True
 network.http.pipelining.max-optimistic-requests: None != 3
 network.http.pipelining.maxrequests: None != 12
 webgl.min_capability_mode: False != 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] #28870 [Core Tor/sbws]: Stop asserting when there's not a descriptor for a relay being measured

[Tor Bug Tracker & Wiki]

#28870: Stop asserting when there's not a descriptor for a relay being measured
---+---
 Reporter:  juga   |  Owner:  (none)
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28663 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by juga):

 * status:  needs_review => needs_revision


Comment:

 i realized there's a bug 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] #25702 [Applications/Tor Browser]: Activity 1.1 Update Tor Browser icon to follow design guidelines.

[Tor Bug Tracker & Wiki]

#25702: Activity 1.1 Update Tor Browser icon to follow design guidelines.
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-mobile, |  Actual Points:
  TorBrowserTeam201812   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by gk):

 * keywords:  ux-team, tbb-mobile, TorBrowserTeam201812R => ux-team, tbb-
 mobile, TorBrowserTeam201812
 * status:  needs_review => needs_revision


Comment:

 Sorry for the delay. I made bundles and looked closer at them. Overall
 they look good to me (I just tested Windows and Linux, though) but there
 are some small things we should fix.

 1) The icon is cropped at the upper left corner and on the URL bar (the
 latter is visible on your screenshots in comment:13, too) (and actually on
 my Linux task bar, too)

 [[Image(cropped_browser.png)]]

 2) On my Linux box when I am cycling through my open windows I see a
 cropped (and kind of ragged at the borders) image if the window is not
 selected

 [[Image(open_windows_unselected.png)]]

 but an uncropped one once it is selected

 [[Image(open_windows_selected.png)]]

 Not sure if we need adapted icons for that but it might be the case.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25702 [Applications/Tor Browser]: Activity 1.1 Update Tor Browser icon to follow design guidelines.

[Tor Bug Tracker & Wiki]

#25702: Activity 1.1 Update Tor Browser icon to follow design guidelines.
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-mobile, |  Actual Points:
  TorBrowserTeam201812R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by gk):

 * Attachment "open_windows_selected.png" added.


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

Re: [tor-bugs] #25702 [Applications/Tor Browser]: Activity 1.1 Update Tor Browser icon to follow design guidelines.

[Tor Bug Tracker & Wiki]

#25702: Activity 1.1 Update Tor Browser icon to follow design guidelines.
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-mobile, |  Actual Points:
  TorBrowserTeam201812R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by gk):

 * Attachment "cropped_browser.png" added.


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

Re: [tor-bugs] #25702 [Applications/Tor Browser]: Activity 1.1 Update Tor Browser icon to follow design guidelines.

[Tor Bug Tracker & Wiki]

#25702: Activity 1.1 Update Tor Browser icon to follow design guidelines.
-+-
 Reporter:  isabela  |  Owner:
 |  antonela
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-mobile, |  Actual Points:
  TorBrowserTeam201812R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor17
-+-
Changes (by gk):

 * Attachment "open_windows_unselected.png" added.


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

Re: [tor-bugs] #28902 [Core Tor/Nyx]: GETINFO commands with huge outputs slow down interpreter curses interface

[Tor Bug Tracker & Wiki]

#28902: GETINFO commands with huge outputs slow down interpreter curses 
interface
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:  curses|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by wagon):

 Now I cannot reproduce the slowing down of all Nyx windows (this is what I
 wrote in #28877), as I see problems only in interpreter Nyx window. If I
 do `desc/all-recent` test on a system which has about 1GB of RAM (I don't
 think it is too small, because I don't run browsers or any heavy
 applications in this system), it is still not sufficient for Nyx `desc
 /all-recent` command. System hangs for few minutes until OS find a way to
 stop Nyx.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28785 [Webpages/Website]: Update contact page

[Tor Bug Tracker & Wiki]

#28785: Update contact page
--+-
 Reporter:  steph |  Owner:  hiro
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Major | Resolution:  implemented
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by hiro):

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


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28752 [Applications/Tor Browser]: Gradle sometimes downloads tor-android-binary resources during build (or the build is failing)

[Tor Bug Tracker & Wiki]

#28752: Gradle sometimes downloads tor-android-binary resources during build (or
the build is failing)
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, tbb-rbm, |  Actual Points:
  TorBrowserTeam201812, TBA-a3   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by gk):

 The fix looks good and works for me. Please address the nits in comment:11
 and we can get this landed, 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] #28877 [Core Tor/Tor]: Paginate large controller commands like 'GETINFO desc/all-recent'

[Tor Bug Tracker & Wiki]

#28877: Paginate large controller commands like 'GETINFO desc/all-recent'
--+--
 Reporter:  wagon |  Owner:  (none)
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by wagon):

 Hello, atagar. Thank you for the explanation, now it is more clear for me.

 > saturates the control connection, preventing further commands and events
 from being transmitted.
 What it actually saturates? Indeed, in some setups I did see this problem,
 but `tor-prompt` doesn't have  it. Is it some internal TCP or socket thing
 that is saturated? Can that limit be increased by setting some preference
 in the system?

 > but I've been cautioned that any direct use of tor's data directory is a
 bad idea.
 I agree. Furthermore, you cannot use tor's data directory if you are not
 running Nyx as `debian-tor` user. If your user is just a member of
 `debian-tor` group (this is recommended setup, see discussion in #25890),
 you still cannot read files in that directory because of #28356.

 > We need some way of breaking up these responses. Pagination probably
 isn't a good fit so ideas welcome.

 > The above is a long time problem I've had with tor's 'get all
 descriptor' commands
 Could you explain why it is a problem? Yes, it may block controller for a
 few seconds if user type this command in Nyx interpreter, but only in this
 case. This blocking would happen anyway because printing the output to a
 terminal always requires some time. If you need this output internally in
 some functions in Stem or Nyx, you can get it almost immediately. In
 addition you don't need to run such commands very often. Maybe you need to
 run them only once, when Nyx is started (then response can be cached for
 some time).

 To be clear, let us check exact numbers. To be sure we are not wrong here
 because of specifics in implementation of Nyx or Stem, we can use the
 following simple script `test.sh` for these tests:
 {{{
 #!/bin/bash -e

 cmd="$@"
 pass="ControlPortPassword"

 function test_tor() {
 echo "$1" >&3
 sed "/^250 OK\r$/q" <&3
 echo QUIT >&3
 exec 3<&-
 }

 exec 3<>/dev/tcp/127.0.0.1/9051
 echo AUTHENTICATE \"$pass\" >&3
 read -u 3
 test_tor "$cmd"
 }}}
 Now fun begins. Let us check some simple fast command:

 {{{
 $ time tor-prompt --run 'GETINFO version' 1>/dev/null
   0.14s user 0.04s system 77% cpu 0.227 total
 $ time ./test.sh 'GETINFO version' 1>/dev/null
   0.00s user 0.00s system 36% cpu 0.011 total
 }}}

 Compare it with more heavy output such as `ns/all`:
 {{{
 $ time tor-prompt --run 'GETINFO ns/all' 1>/dev/null
   0.28s user 0.07s system 58% cpu 0.591 total
 $ time ./test.sh 'GETINFO ns/all' 1>/dev/null
   0.02s user 0.00s system  8% cpu 0.230 total
 }}}

 Now check it with the most resource consuming command, `desc/all-recent`:
 {{{
 $ time tor-prompt --run 'GETINFO desc/all-recent' 1>/dev/null
 Traceback (most recent call last):
   File "/path/to/stem/tor-prompt", line 8, in 
 stem.interpreter.main()
   File "/path/to/stem/stem/interpreter/__init__.py", line 151, in main
 interpreter.run_command(args.run_cmd, print_response = True)
   File "/path/to/stem/stem/util/conf.py", line 289, in wrapped
 return func(*args, config = config, **kwargs)
   File "/path/to/stem/stem/interpreter/commands.py", line 381, in
 run_command
 print(output)
 UnicodeEncodeError: 'ascii' codec can't encode character u'\u021b' in
 position 1237805: ordinal not in range(128)

 $ time ./test.sh 'GETINFO desc/all-recent' 1>/dev/null
   0.21s user 0.03s system 60% cpu 0.391 total
 }}}

 People always say that shell is too slow and inconvenient, while python is
 really fast and convenient. However, as you see, simple shell is 20-30
 times faster than python on simple commands, about 2-3 times faster than
 python on heavy commands, and gets many megabytes output of `desc/all-
 recent` within less that half of second. Old UNIX style still rocks. Had
 you choose Bash or some other shell instead of python for writing Stem?

 If I don't redirect output to `/dev/null`, terminal becomes a bottleneck
 for these commands. It will take about 5-6 seconds to print `decs/all-
 recent` output to a terminal. Nyx interpreter is even more slow than `tor-
 prompt` (I think it is due to curses), it will take 15 seconds or like
 that for this printing. If I don't redirect output to `/dev/null`, the
 last `tor-prompt` command doesn't  crash.

 Thus, I still doubt we need to ask tor network people to do something with
 it. As you see, well written tools work fast with current `ControlPort`
 implementation.

 > Feel free to file a separate ticket with the 'nyx 

Re: [tor-bugs] #24187 [Webpages/Blog]: Reduce bullet spacing on blog

[Tor Bug Tracker & Wiki]

#24187: Reduce bullet spacing on blog
---+--
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by hiro):

 * status:  new => needs_review


Comment:

 Please confirm that this is now fixed.

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

Re: [tor-bugs] #23022 [Webpages/Blog]: Increase lead image bottom spacing; reduce top spacing

[Tor Bug Tracker & Wiki]

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

 * status:  reopened => needs_review


Comment:

 Please confirm that this is now fixed.

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

Re: [tor-bugs] #24440 [Webpages/Blog]: Match blog title post spacing to archive post title spacing

[Tor Bug Tracker & Wiki]

#24440: Match blog title post spacing to archive post title spacing
---+--
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by hiro):

 * status:  assigned => needs_review


Comment:

 Please confirm that this is now fixed.

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

Re: [tor-bugs] #28882 [Webpages/Blog]: Create blog account for emmapeel

[Tor Bug Tracker & Wiki]

#28882: Create blog account for emmapeel
---+-
 Reporter:  steph  |  Owner:  hiro
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Major  | Resolution:  implemented
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by hiro):

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


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28903 [- Select a component]: windows issue.

[Tor Bug Tracker & Wiki]

#28903: windows issue.
--+-
 Reporter:  vector0012|  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by gk):

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


Comment:

 Please check out our support options at
 https://www.torproject.org/about/contact.html.en#support and get in touch
 with us. Stating what the issue is and on what Windows version this shows
 up and what you tried would help us helping you.

 I am closing this ticket as this is a bug tracker where we coordinate our
 development efforts.

 Good luck!

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