Re: [tor-bugs] #26607 [Applications/Tor Browser]: verify that subpixel accuracy of window scroll properties does not add fingerprinting risk

[Tor Bug Tracker & Wiki]

#26607: verify that subpixel accuracy of window scroll properties does not add
fingerprinting risk
-+-
 Reporter:  mcs  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting, ff60-esr,|  Actual Points:
  TorBrowserTeam201904   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by Thorin):

 more from Arthur, including an old patch/solution:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1216800 "some chrome code may
 be incorrectly receiving spoofed devicePixelRatio"

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30172 [Core Tor/Tor]: Always send PADDING_NEGOTIATE if middle supports it

[Tor Bug Tracker & Wiki]

#30172: Always send PADDING_NEGOTIATE if middle supports it
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding, 041-proposed  |
Parent ID:  #28634   | Points:  4
 Reviewer:   |Sponsor:
 |  Sponsor2-can
-+-
Changes (by mikeperry):

 * points:   => 4


Comment:

 While this is simple to implement, figuring out exactly which strategy to
 use will take some experimentation.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30173 [Core Tor/Tor]: Ensure circuit padding can be safely disabled from consensus

[Tor Bug Tracker & Wiki]

#30173: Ensure circuit padding can be safely disabled from consensus
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:  0.33
  padding, 041-proposed  |
Parent ID:  #28634   | Points:  1
 Reviewer:  asn  |Sponsor:
 |  Sponsor2-can
-+-
Changes (by mikeperry):

 * points:   => 1


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30250 [Core Tor/RPM packaging]: we should retire the 'rpm packaging' trac component

[Tor Bug Tracker & Wiki]

#30250: we should retire the 'rpm packaging' trac component
+
 Reporter:  arma|  Owner:  hiviah
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Core Tor/RPM packaging  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by mikeperry):

 * owner:  (none) => hiviah
 * component:  Core Tor/Tor => Core Tor/RPM packaging


Comment:

 I disagree. If there are issues with old RPM packages in the wild, and
 some brave soul who likes RPM comes to report one, they should at least
 know that we don't have anyone currently doing this work.

 They should also know the current issues with existing, deprecated RPM
 packages, which they would presumably base their work off of, or at least
 look at for reference.

 I would only retire this component if we were forever deciding never to
 support RPM ever again, perhaps because of some kind of organizational
 decision. As Triage Overlord For A Day, this is my absolute and binding
 decree. (The next Triage Overlord For A Day can make a different call for
 completely different and unrelated reasons, of course, of course. ;)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #14389 [Core Tor/Tor]: little-t-tor: Provide support for better TBB UI of hidden service client authorization

[Tor Bug Tracker & Wiki]

#14389: little-t-tor: Provide support for better TBB UI of hidden service client
authorization
-+-
 Reporter:  asn  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tbb-usability, ux-team, hs-  |  Actual Points:
  auth   |
Parent ID:  #30237   | Points:  14-24
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by mikeperry):

 * milestone:   => Tor: 0.4.2.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] #30192 [- Select a component]: v3 onion addresses and mirrors

[Tor Bug Tracker & Wiki]

#30192: v3 onion addresses and mirrors
--+---
 Reporter:  user124   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by mikeperry):

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


Comment:

 Trac is not a support forum. I'm not actually sure if we still have
 offical technical support avenues. There is a stackexchange here:
 https://tor.stackexchange.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

[tor-bugs] #30265 [Webpages/Website]: Tor Browser download link is broken in Spanish (ES)

[Tor Bug Tracker & Wiki]

#30265: Tor Browser download link is broken in Spanish (ES)
--+
 Reporter:  ggus  |  Owner:  hiro
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #29901
   Points:|   Reviewer:
  Sponsor:|
--+
 If you go to download Tor Browser in Spanish:
 https://www.torproject.org/es/download/ all the download links (Windows,
 Linux, macOS) are pointing to a locale that doesn't exist, for example,
 Linux version is pointing to:
  https://www.torproject.org/dist/torbrowser/8.0.8/tor-browser-
 linux64-8.0.8_es.tar.xz and it should be "es-ES":
 https://www.torproject.org/dist/torbrowser/8.0.8/tor-browser-linux64-8.0
 .8_es-ES.tar.xz

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30264 [Obfuscation]: Revise list of default Tor Browser bridges

[Tor Bug Tracker & Wiki]

#30264: Revise list of default Tor Browser bridges
-+-
 Reporter:  phw  |  Owner:  phw
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Obfuscation  |Version:
 Severity:  Normal   |   Keywords:  tbb-bridges
Actual Points:   |  Parent ID:
   Points:  0.5  |   Reviewer:
  Sponsor:   |
-+-
 Six of our
 [https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/DefaultBridges
 default Tor Browser bridges] are now gone for good:

 * Over at
 [https://trac.torproject.org/projects/tor/ticket/28521#comment:12 #28521],
 kpdyer mentioned that he's no longer able to manage his three bridges.
 * Paul Pearce is also no longer able to maintain the two bridges that were
 set up at Berkeley.
 * A bridge that was originally set up by Henry de Valence is also no
 longer alive.

 I suggest that we remove all of these bridges.  The question is: do we
 want replacements? Roger mentioned on IRC that we may be able to get a
 bunch of people to run fast bridges for us.

 As for the current state of our default bridges:
 [https://metrics.torproject.org/rs.html#search/ndnop ln5's obfs4 bridges]
 hover around 70% bandwidth utilisation while
 
[https://metrics.torproject.org/rs.html#details/11A3982C417AF37230F576006405BE5338F41C09
 tvdw's obfs4 bridge] sees around 100% utilisation. Interestingly,
 
[https://metrics.torproject.org/rs.html#details/7171D44C4CEB16D4972ABAC43E199D03FADFD679
 one bridge] sees continuous growth in both bandwidth and users while
 
[https://metrics.torproject.org/rs.html#details/D9C805C955CB124D188C0D44F271E9BE57DE2109
 another bridge] sees a decline in users. While it seems tricky to assess
 the overall health of our default bridges, I think it would be a good idea
 to add a few new bridges.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30263 [Core Tor/Tor]: make shellcheck expects scripts in the build directory

[Tor Bug Tracker & Wiki]

#30263: make shellcheck expects scripts in the build directory
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.4.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  shellcheck, 040-backport, 040-must,  |  Actual Points:  0.1
  tor-ci-might-fail-on-upgrade, regression   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
 |  Sponsor31-can
-+-
Changes (by teor):

 * status:  new => needs_review
 * actualpoints:   => 0.1


Comment:

 See:
 * 0.4.0: https://github.com/torproject/tor/pull/974
 * master: https://github.com/torproject/tor/pull/975
   * clean merge, testing only

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30263 [Core Tor/Tor]: make shellcheck expects scripts in the build directory

[Tor Bug Tracker & Wiki]

#30263: make shellcheck expects scripts in the build directory
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.1.x-final
Component:  Core |Version:  Tor: 0.4.0.1-alpha
  Tor/Tor|   Keywords:  shellcheck, 040-backport, 040-must,
 Severity:  Normal   |  tor-ci-might-fail-on-upgrade, regression
Actual Points:   |  Parent ID:
   Points:  0.1  |   Reviewer:
  Sponsor:   |
  Sponsor31-can  |
-+-
 In #28058, we added shellcheck for coverage and cov-diff. But we expect
 coverage to be in the build directory, which is wrong.

 This fails the newest version of shellcheck in out-of-tree builds.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23588 [Core Tor/Tor]: Write fascist_firewall_choose_address_ls() and use it in hs_get_extend_info_from_lspecs()

[Tor Bug Tracker & Wiki]

#23588: Write fascist_firewall_choose_address_ls() and use it in
hs_get_extend_info_from_lspecs()
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion,   |  Actual Points:  1.5
  ipv6, 034-triage-20180328, |
  034-removed-20180328, 040-unreached-20190109,  |
  041-proposed, v3-onion-service-feature-|
  parity-can |
Parent ID:  #23493   | Points:  1
 Reviewer:  teor |Sponsor:
 |  Sponsor27-must
-+-
Changes (by teor):

 * milestone:  Tor: unspecified => Tor: 0.4.1.x-final
 * sponsor:   => Sponsor27-must
 * actualpoints:  0.5 => 1.5


Comment:

 This is now Sponsor27-must, because the parent is Sponsor27-must.

 I rebased the pull request to master in:
 https://github.com/torproject/tor/pull/973

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30262 [Core Tor/Stem]: stem.descriptor.remote not handling 'HTTP/1.0 404 Not found' gracefully

[Tor Bug Tracker & Wiki]

#30262: stem.descriptor.remote not handling 'HTTP/1.0 404 Not found' gracefully
---+---
 Reporter:  starlight  |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Component:  Core Tor/Stem
  Version: |   Severity:  Normal
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
 running (commit 4BE6695A)

 {{{
 torsocks download_descriptor.py -t server -f
 7FE6E24BF6058EA55717C18D34FCD049307D8D2C --orport 171.25.193.9:80
 }}}

 one receives

 {{{
 Traceback (most recent call last):
   File "/usr/local/lib/python3.7/site-packages/stem/descriptor/remote.py",
 line 560, in _download_descriptors
 Downloading server descriptor from 171.25.193.9:80...

 self.content, self.reply_headers = _download_from_orport(endpoint,
 self.compression, self.resource)
   File "/usr/local/lib/python3.7/site-packages/stem/descriptor/remote.py",
 line 973, in _download_from_orport
 raise stem.ProtocolError("Response should begin with HTTP success, but
 was '%s'" % str_tools._to_unicode(first_line))
 stem.ProtocolError: Response should begin with HTTP success, but was
 'HTTP/1.0 404 Not found'

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "/usr/local/lib/python3.7/site-packages/stem/descriptor/remote.py",
 line 560, in _download_descriptors
 self.content, self.reply_headers = _download_from_orport(endpoint,
 self.compression, self.resource)
   File "/usr/local/lib/python3.7/site-packages/stem/descriptor/remote.py",
 line 973, in _download_from_orport
 raise stem.ProtocolError("Response should begin with HTTP success, but
 was '%s'" % str_tools._to_unicode(first_line))
 stem.ProtocolError: Response should begin with HTTP success, but was
 'HTTP/1.0 404 Not found'

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "/home/tor/Downloads/../download_descriptor.py", line 137, in
 
 main()
   File "/home/tor/Downloads/../download_descriptor.py", line 116, in main
 compression = [stem.descriptor.remote.Compression.GZIP]
   File "/usr/local/lib/python3.7/site-packages/stem/descriptor/remote.py",
 line 484, in run
 return list(self._run(suppress))
   File "/usr/local/lib/python3.7/site-packages/stem/descriptor/remote.py",
 line 495, in _run
 raise self.error
   File "/usr/local/lib/python3.7/site-packages/stem/descriptor/remote.py",
 line 560, in _download_descriptors
 self.content, self.reply_headers = _download_from_orport(endpoint,
 self.compression, self.resource)
   File "/usr/local/lib/python3.7/site-packages/stem/descriptor/remote.py",
 line 973, in _download_from_orport
 raise stem.ProtocolError("Response should begin with HTTP success, but
 was '%s'" % str_tools._to_unicode(first_line))
 stem.ProtocolError: Response should begin with HTTP success, but was
 'HTTP/1.0 404 Not found'
 }}}

 could be better

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

Re: [tor-bugs] #30261 [Core Tor/Tor]: Add "How do I find bug or feature versions?" to doc/HACKING

[Tor Bug Tracker & Wiki]

#30261: Add "How do I find bug or feature versions?" to doc/HACKING
---+
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  doc, fast-fix  |  Actual Points:  0.1
Parent ID: | Points:  0.1
 Reviewer: |Sponsor:  Sponsor31-can
---+
Changes (by teor):

 * status:  assigned => needs_review


Old description:

> We need to find bugfix versions for changes files, and feature versions
> for specifications.
>
> Let's document the git commands to do that.
>
> For an example, see:
> https://trac.torproject.org/projects/tor/ticket/30224#comment:4

New description:

 We need to find bugfix versions for changes files and backports, and
 feature versions for specifications.

 Let's document the git commands to do that.

 For an example, see:
 https://trac.torproject.org/projects/tor/ticket/30224#comment:4

--

Comment:

 https://github.com/torproject/tor/pull/972

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30261 [Core Tor/Tor]: Add "How do I find bug or feature versions?" to doc/HACKING

[Tor Bug Tracker & Wiki]

#30261: Add "How do I find bug or feature versions?" to doc/HACKING
---+
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal |   Keywords:  doc, fast-fix
Actual Points:  0.1|  Parent ID:
   Points:  0.1|   Reviewer:
  Sponsor:  Sponsor31-can  |
---+
 We need to find bugfix versions for changes files, and feature versions
 for specifications.

 Let's document the git commands to do that.

 For an example, see:
 https://trac.torproject.org/projects/tor/ticket/30224#comment:4

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

Re: [tor-bugs] #30224 [Core Tor/Tor]: Add the tor versions for bridge-distribution-request

[Tor Bug Tracker & Wiki]

#30224: Add the tor versions for bridge-distribution-request
+
 Reporter:  teor|  Owner:  teor
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-spec, fast-fix  |  Actual Points:  0.2
Parent ID:  | Points:  0.1
 Reviewer:  catalyst|Sponsor:  Sponsor19-can
+
Changes (by teor):

 * actualpoints:  0.1 => 0.2


Comment:

 Here's how I found the feature version in tor:
 {{{
 $ git log -S bridge-distribution-request --reverse
 commit ebab521525
 Author: Roger Dingledine 
 Date:   Sun Nov 13 02:39:16 2016 -0500

 Add new BridgeDistribution config option

 Bridge relays can use it to add a "bridge-distribution-request" line
 to their bridge descriptor, which tells BridgeDB how they'd like their
 bridge address to be given out.

 Implements tickets 18329.
 ...
 $ git describe --contains ebab521525
 tor-0.3.2.3-alpha~15^2~4
 }}}

 And here's how I found the backport versions:
 {{{
 $ git log tp/maint-0.3.1 -S bridge-distribution-request --reverse
 commit 9f2efd02a1 (nickm/ticket18329_minimal_025)
 Author: Nick Mathewson 
 Date:   Mon Nov 13 20:44:51 2017 -0500

 Minimal implementation of bridge-distribution-request

 Just advertise the line when we're a bridge, using "any" if we're
 published or "none" if we aren't.

 This is done in lieu of a full backport of #18329.
 $ git tag --contains 9f2efd02a1 | sort -V
 tor-0.2.5.16
 tor-0.2.8.17
 tor-0.2.9.14
 tor-0.2.9.15
 tor-0.2.9.16
 tor-0.2.9.17
 tor-0.3.0.13
 tor-0.3.1.9
 tor-0.3.1.10
 tor-0.3.2.5-alpha
 ...
 }}}

 I didn't use `sort -V` when I was writing the patch, so I got the 0.3.1
 backport version wrong. I pushed a commit that changes the version to
 0.3.1.9.

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

Re: [tor-bugs] #30224 [Core Tor/Tor]: Add the tor versions for bridge-distribution-request

[Tor Bug Tracker & Wiki]

#30224: Add the tor versions for bridge-distribution-request
+
 Reporter:  teor|  Owner:  teor
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-spec, fast-fix  |  Actual Points:  0.1
Parent ID:  | Points:  0.1
 Reviewer:  catalyst|Sponsor:  Sponsor19-can
+

Comment (by catalyst):

 The text of the changes looks good. It would be great if someone who knew
 the relevant history could fact-check the change. (I think I don't know
 enough to do so without possibly extensive research.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29863 [Obfuscation/Snowflake]: Add disk space monitoring for snowflake infrastructure

[Tor Bug Tracker & Wiki]

#29863: Add disk space monitoring for snowflake infrastructure
---+--
 Reporter:  cohosh |  Owner:  (none)
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords:  snowflake  |  Actual Points:
Parent ID:  #30152 | Points:
 Reviewer: |Sponsor:  Sponsor19
---+--

Comment (by cohosh):

 Replying to [comment:21 anarcat]:
 > my current opinion (yes, it changes! :)) is that we should not export
 metrics that are sensitive in the first place. this would alleviate the
 need for stronger (but also more complex) authentication systems on the
 monitoring servers which could then stay in the "semi-public" mode they
 have always been.
 >
 > the problem is we have a two-dimension matrix of servers right now,
 based on those parameters:
 >
 >  * external/internal
 >  * private/public
 >
 > .. which would mean four monitoring servers. :p too complicated. let's
 drop that second part and stick with external/internal as a distinction.
 how does that sound? if we clear the exporters so that the stuff they
 generate is safe (a good idea anyways, given they lack authentication
 themselves, other than IP-level blocking), it seems that the
 private/public distinction isn't necessary anymore...
 This sounds good 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] #29863 [Obfuscation/Snowflake]: Add disk space monitoring for snowflake infrastructure

[Tor Bug Tracker & Wiki]

#29863: Add disk space monitoring for snowflake infrastructure
---+--
 Reporter:  cohosh |  Owner:  (none)
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords:  snowflake  |  Actual Points:
Parent ID:  #30152 | Points:
 Reviewer: |Sponsor:  Sponsor19
---+--

Comment (by cohosh):

 Here it is:
 {{{
 # HELP go_gc_duration_seconds A summary of the GC invocation durations.
 # HELP go_goroutines Number of goroutines that currently exist.
 # HELP go_info Information about the Go environment.
 # HELP go_memstats_alloc_bytes Number of bytes allocated and still in use.
 # HELP go_memstats_alloc_bytes_total Total number of bytes allocated, even
 if freed.
 # HELP go_memstats_buck_hash_sys_bytes Number of bytes used by the
 profiling bucket hash table.
 # HELP go_memstats_frees_total Total number of frees.
 # HELP go_memstats_gc_cpu_fraction The fraction of this program's
 available CPU time used by the GC since the program started.
 # HELP go_memstats_gc_sys_bytes Number of bytes used for garbage
 collection system metadata.
 # HELP go_memstats_heap_alloc_bytes Number of heap bytes allocated and
 still in use.
 # HELP go_memstats_heap_idle_bytes Number of heap bytes waiting to be
 used.
 # HELP go_memstats_heap_inuse_bytes Number of heap bytes that are in use.
 # HELP go_memstats_heap_objects Number of allocated objects.
 # HELP go_memstats_heap_released_bytes Number of heap bytes released to
 OS.
 # HELP go_memstats_heap_sys_bytes Number of heap bytes obtained from
 system.
 # HELP go_memstats_last_gc_time_seconds Number of seconds since 1970 of
 last garbage collection.
 # HELP go_memstats_lookups_total Total number of pointer lookups.
 # HELP go_memstats_mallocs_total Total number of mallocs.
 # HELP go_memstats_mcache_inuse_bytes Number of bytes in use by mcache
 structures.
 # HELP go_memstats_mcache_sys_bytes Number of bytes used for mcache
 structures obtained from system.
 # HELP go_memstats_mspan_inuse_bytes Number of bytes in use by mspan
 structures.
 # HELP go_memstats_mspan_sys_bytes Number of bytes used for mspan
 structures obtained from system.
 # HELP go_memstats_next_gc_bytes Number of heap bytes when next garbage
 collection will take place.
 # HELP go_memstats_other_sys_bytes Number of bytes used for other system
 allocations.
 # HELP go_memstats_stack_inuse_bytes Number of bytes in use by the stack
 allocator.
 # HELP go_memstats_stack_sys_bytes Number of bytes obtained from system
 for stack allocator.
 # HELP go_memstats_sys_bytes Number of bytes obtained from system.
 # HELP go_threads Number of OS threads created.
 # HELP node_exporter_build_info A metric with a constant '1' value labeled
 by version, revision, branch, and goversion from which node_exporter was
 built.
 # HELP node_filesystem_avail_bytes Filesystem space available to non-root
 users in bytes.
 # HELP node_filesystem_device_error Whether an error occurred while
 getting statistics for the given device.
 # HELP node_filesystem_files Filesystem total file nodes.
 # HELP node_filesystem_files_free Filesystem total free file nodes.
 # HELP node_filesystem_free_bytes Filesystem free space in bytes.
 # HELP node_filesystem_readonly Filesystem read-only status.
 # HELP node_filesystem_size_bytes Filesystem size in bytes.
 # HELP node_scrape_collector_duration_seconds node_exporter: Duration of a
 collector scrape.
 # HELP node_scrape_collector_success node_exporter: Whether a collector
 succeeded.
 # HELP node_systemd_socket_accepted_connections_total Total number of
 accepted socket connections
 # HELP node_systemd_socket_current_connections Current number of socket
 connections
 # HELP node_systemd_system_running Whether the system is operational (see
 'systemctl is-system-running')
 # HELP node_systemd_timer_last_trigger_seconds Seconds since epoch of last
 trigger.
 # HELP node_systemd_unit_start_time_seconds Start time of the unit since
 unix epoch in seconds.
 # HELP node_systemd_unit_state Systemd unit
 # HELP node_systemd_unit_tasks_current Current number of tasks per Systemd
 unit
 # HELP node_systemd_unit_tasks_max Maximum number of tasks per Systemd
 unit
 # HELP node_systemd_units Summary of systemd unit states
 # HELP node_time_seconds System time in seconds since epoch (1970).
 # HELP process_cpu_seconds_total Total user and system CPU time spent in
 seconds.
 # HELP process_max_fds Maximum number of open file descriptors.
 # HELP process_open_fds Number of open file descriptors.
 # HELP process_resident_memory_bytes Resident memory size in bytes.
 # HELP process_start_time_seconds Start time of the process since unix
 epoch in 

Re: [tor-bugs] #29863 [Obfuscation/Snowflake]: Add disk space monitoring for snowflake infrastructure

[Tor Bug Tracker & Wiki]

#29863: Add disk space monitoring for snowflake infrastructure
---+--
 Reporter:  cohosh |  Owner:  (none)
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords:  snowflake  |  Actual Points:
Parent ID:  #30152 | Points:
 Reviewer: |Sponsor:  Sponsor19
---+--

Comment (by anarcat):

 @cohosh do you mind dumping the result of `curl localhost:9100/metrics |
 grep '# HELP'` so that people can evaluate what metrics are currently
 available here and therefore judge the impact of a possible disclosure?

 my current opinion (yes, it changes! :)) is that we should not export
 metrics that are sensitive in the first place. this would alleviate the
 need for stronger (but also more complex) authentication systems on the
 monitoring servers which could then stay in the "semi-public" mode they
 have always been.

 the problem is we have a two-dimension matrix of servers right now, based
 on those parameters:

  * external/internal
  * private/public

 .. which would mean four monitoring servers. :p too complicated. let's
 drop that second part and stick with external/internal as a distinction.
 how does that sound? if we clear the exporters so that the stuff they
 generate is safe (a good idea anyways, given they lack authentication
 themselves, other than IP-level blocking), it seems that the
 private/public distinction isn't necessary anymore...

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29863 [Obfuscation/Snowflake]: Add disk space monitoring for snowflake infrastructure

[Tor Bug Tracker & Wiki]

#29863: Add disk space monitoring for snowflake infrastructure
---+--
 Reporter:  cohosh |  Owner:  (none)
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords:  snowflake  |  Actual Points:
Parent ID:  #30152 | Points:
 Reviewer: |Sponsor:  Sponsor19
---+--

Comment (by cohosh):

 Just to summarize some discussion in IRC:

 There are some difficulties in adding stronger authentication to access
 the grafana graphs that include but are not necessarily limited to:
 - needing to set up separate instances for TPA/3rd party resources and
 also for projects that have different authentication requirements
 - relying on LDAP is complicated (see #30023)
 - we shouldn't really be exporting metrics we aren't comfortable with
 being public in the first place

 So given that, I think we should evaluate whether or not this ticket is
 ready with the current limited prometheus exports based on the fact that
 anyone can access the exports or grafana graphs (even though there will be
 some light access control on both).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30023 [Internal Services/Tor Sysadmin Team]: improve grafana authentication

[Tor Bug Tracker & Wiki]

#30023: improve grafana authentication
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 >  Okay, HTTPS + a stronger password to access the graphs sounds fine to
 me right now. I think especially with our current policy of only exporting
 a small amount of metrics we don't have much to risk at the moment.

 So if I understand you right, the blocker for snowflake being integrated
 in Prometheus monitoring is to make sure we have proper passwords to
 protect the metrics. This currently means locking down the Prometheus web
 interface itself which is protected only by a trivial password to keep the
 bots away, and opening up Grafana to external authentication so that non-
 TSA folks can access it.

 In other words, right now we have the current situation:

  * Prometheus: trivial password, easy to guess, access to raw metrics and
 rough graphs possible for public
  * Grafana: single, strong, shared admin password, only accessible to TPA,
 full graphs and queries possible only for people with the shared password

 The new situation would be:

  * Prometheus: hard, strong, shared password only accessible to TPA for
 debug purposes (or accessible only to localhost)
  * Grafana: LDAP authentication or some other mechanism to grant people
 outside TPA access to the server

 There are two problems with this:

  1. we're hesitant in setting LDAP authentication in Grafana, because we
 don't want to have monitoring depend on LDAP to work but also because
 we're hesitant in putting more stuff in LDAP in general (the less stuff
 has access to it the better)
  2. we might *want* to provide (semi-)public (with trivial password)
 access to those graphs for transparency and ease-of-access reasons

 What TPA is proposing now is to setup another server to monitor external
 resources. It would solve problem 2 above, but not problem 1. It would
 also conflate two distinct problems

  * "external resources should not be monitored alongside internal
 resources"
  * "some metrics should stay private" problem

 Because, of course, maybe some internal resources should stay private and
 external resources should be public, and vice versa. I'm not sure how to
 resolve this conendrum.

 I don't have a clear view of what goes where, to be honest. There were a
 few requests already for external monitoring and I must admit I somehow
 have trouble keeping track of things. :) There are at least two concurrent
 requests from the anti-censorship team, one of which was resolved
 internally (#30006) so I hope you understand I can get a little
 confused... It's also unclear to me what the endgame is with snowflake:
 there was talk of migrating it inside TPO, for example...

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30023 [Internal Services/Tor Sysadmin Team]: improve grafana authentication

[Tor Bug Tracker & Wiki]

#30023: improve grafana authentication
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cohosh):

 Replying to [comment:5 anarcat]:
 > i am not familiar with configuring prometheus to fetch metrics from
 proxy. if I understand you correctly, there's a `proxy_url` setting that
 can be added to do that? I cannot confirm that, in any case.
 >
 > but sure, that could be possible. i am not sure how that relates to this
 ticket, however, which is specifically about Grafana authentication, not
 really about how Prometheus talks with its exporters, for which there is
 no ticket right now - I thought we had resolved that by selecting only a
 subset of metrics, but I haven't followed the entire conversation in
 #29863. What I saw on IRC was specifically that question:
 >
 > >  In IRC it also sounded like there was little-to-no authentication on
 the server that displays these metrics after scraping. Is that the case?
 >
 > So I thought we were talking about the "server that displays the
 metrics", ie. Grafana (or the Prometheus frontend), which is why I pointed
 you here.
 >
 > But yes, we have a similar problem with the exporters: in theory,
 someone could do IP spoofing and bypass those firewalls to scrape the
 metrics off. In practice, those stunts are actually quite hard to pull
 because you need to do pretty hardcore stuff like BGP hijacking, because
 of TCP negociations (at least, as far as I understand it, correct me if
 I'm wrong). But I'm not sure the prize (metrics) would be worth the
 trouble (upsetting the internet's routing table).
 >
 Ah, you're right. I was conflating these two separate issues. We can leave
 this ticket for the grafana access issue only.
 > As for the specific solution proposed here, I'd be tempted to simply add
 HTTPS and username/password authentication, as it's something I understand
 better and it doesn't require the Tor network to be operational. I always
 feel a little ackward using Tor to monitor internal infrastructure - I'm
 all for eating our own dogfood, but when it comes to monitoring, I feel a
 little less comfortable and prefer redundancy. ;)
 >
 > That said, the idea of setting up a secondary server would be that other
 kind of tricks could be tried by other teams, so I don't want to be
 blocking nice initiatives like this. This is just my grain of salt which I
 hope will be useful!
 Okay, HTTPS + a stronger password to access the graphs sounds fine to me
 right now. I think especially with our current policy of only exporting a
 small amount of metrics we don't have much to risk at the moment.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29968 [Webpages/Website]: new www.tpo has no favicon file

[Tor Bug Tracker & Wiki]

#29968: new www.tpo has no favicon file
--+--
 Reporter:  arma  |  Owner:  antonela
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #29901| Points:
 Reviewer:|Sponsor:
--+--

Comment (by emmapeel):

 we should copy https://2019.www.torproject.org/favicon.ico

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30257 [Core Tor/Stem]: Propagate USR1 and ABRT signals from stem tests through to tor

[Tor Bug Tracker & Wiki]

#30257: Propagate USR1 and ABRT signals from stem tests through to tor
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Stem  |Version:  Tor: 0.2.4.8-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-ci-fail-sometimes  |  Actual Points:
Parent ID:  #29437 | Points:
 Reviewer: |Sponsor:
---+

Comment (by atagar):

 Hi teor. In theory propagating the signal to our tor process should be
 easy. In the runner I tried adding the following...

 {{{
   try:
 integ_runner = test.runner.get_runner()
 os.kill(integ_runner.get_pid(), sig)
   except test.runner.RunnerStopped:
 pass  # integ testing tor instance isn't running
   except OSError as exc:
 if exc.errno == errno.ESRCH:
   pass  # already exited, no such process

 raise exc
 }}}

 However, when I send a SIGABRT while invoking the integ tests things don't
 terminate as I'd expect. This is gonna need some more investigation on my
 side.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23809 [Community/Tor Support]: Add instructions for running a relay on a Raspberry Pi

[Tor Bug Tracker & Wiki]

#23809: Add instructions for running a relay on a Raspberry Pi
-+-
 Reporter:  irl  |  Owner:  hiro
 Type:  task | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  website
 |  redesign
Component:  Community/Tor Support|Version:
 Severity:  Normal   | Resolution:
 Keywords:  docs, relays, community, |  Actual Points:
  raspberrypi|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by emmapeel):

 * keywords:   => docs, relays, community, raspberrypi


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27514 [Community/Tor Support]: Add instructions how to verify signatures on Android

[Tor Bug Tracker & Wiki]

#27514: Add instructions how to verify signatures on Android
---+-
 Reporter:  traumschule|  Owner:  traumschule
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by emmapeel):

 * parent:  #9843 =>


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #10074 [Community/Tor Support]: Make presentation slides on using Tails

[Tor Bug Tracker & Wiki]

#10074: Make presentation slides on using Tails
---+-
 Reporter:  mttp   |  Owner:  runa
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:  wontfix
 Keywords:  SponsorO outreach  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by emmapeel):

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


Comment:

 there are already slides in Tails and nobody really owned this ticket
 since its creation. Talked about it today on the community meeting also.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30260 [Metrics/ExoneraTor]: Default date picker to latest available date

[Tor Bug Tracker & Wiki]

#30260: Default date picker to latest available date
-+
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Component:  Metrics/ExoneraTor
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
 https://metrics.torproject.org/exonerator.html

 Would be nice to load the latest available date (currently two days from
 current date) automatically in the date picker, so user doesn't have to
 always manually set a date.

 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] #26597 [Metrics/Onionperf]: Investigate and document additional overhead for first hop when not using guards

[Tor Bug Tracker & Wiki]

#26597: Investigate and document additional overhead for first hop when not 
using
guards
---+--
 Reporter:  irl|  Owner:  metrics-team
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords:  acute-2019-q1-planned  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by acute):

 As per #29373, we've checked OP is always using guards as the first hop -
 and the circuits are built by a tor client process.

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

Re: [tor-bugs] #29374 [Metrics/Onionperf]: Analysis files sometimes present negative numbers in the payload_progress field

[Tor Bug Tracker & Wiki]

#29374: Analysis files sometimes present negative numbers in the 
payload_progress
field
---+--
 Reporter:  irl|  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords:  acute-2019-q1-planned  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by acute):

 Thanks for clarifying, pull request for this change submitted:
 https://github.com/torproject/onionperf/pull/14
 The request also adds tests for the parser, which will hopefully help with
 future changes.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29624 [Metrics/Exit Scanner]: New version of exit list format

[Tor Bug Tracker & Wiki]

#29624: New version of exit list format
-+
 Reporter:  irl  |  Owner:  irl
 Type:  task | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Metrics/Exit Scanner |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-roadmap-2019-q2  |  Actual Points:
Parent ID:  #29650   | Points:
 Reviewer:  irl  |Sponsor:
-+

Comment (by karsten):

 Here's a graph roughly like the one I suggested above:

 [[Image(exitips-stacked-area.png​, 700px)]]

 Here's the source code:

 {{{
 require(tidyr)
 require(dplyr)
 require(readr)
 require(ggplot2)

 read_csv("exitips.csv", col_types = cols(
   time = col_datetime(format = ""),
   consensus = col_double(),
   exitl = col_double(),
   exitlo = col_double())) %>%
   transmute(time, consensus_only = consensus - exitl + exitlo,
 both = exitl - exitlo,
 exitlist_only = exitlo) %>%
   gather(document, ips, 2:4) %>%
   mutate(document = factor(document,
 levels = c("exitlist_only", "both", "consensus_only"),
 labels = c("Found only in exit list",
   "Found in consensus and exit list", "Found only in consensus"))) %>%
   ggplot(aes(x = time, y = ips, fill = document)) +
   geom_area() +
   scale_x_datetime(name = "") +
   scale_y_continuous(name = "", limits = c(0, NA)) +
   scale_fill_manual(name = "",
 values = c("#03B3FF", "#39FF02", "#00"))
 ggsave(filename = "exitips-stacked-area.png", width = 8, height = 5, dpi =
 150)
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29624 [Metrics/Exit Scanner]: New version of exit list format

[Tor Bug Tracker & Wiki]

#29624: New version of exit list format
-+
 Reporter:  irl  |  Owner:  irl
 Type:  task | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Metrics/Exit Scanner |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-roadmap-2019-q2  |  Actual Points:
Parent ID:  #29650   | Points:
 Reviewer:  irl  |Sponsor:
-+
Changes (by karsten):

 * Attachment "exitips-stacked-area.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] #25660 [Applications/Tor Browser]: Remove "New Private Window" option from Tor Browser or make it a separate session

[Tor Bug Tracker & Wiki]

#25660: Remove "New Private Window" option from Tor Browser or make it a 
separate
session
--+--
 Reporter:  steph |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by antonela):

 * cc: ux-team (removed)
 * keywords:   => ux-team


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

Re: [tor-bugs] #30259 [UX]: Improve verify signature flow for Tor Browser

[Tor Bug Tracker & Wiki]

#30259: Improve verify signature flow for Tor Browser
-+--
 Reporter:  antonela |  Owner:  antonela
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  UX   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by antonela):

 * cc: ux-team, antonela (removed)
 * keywords:   => ux-team


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

Re: [tor-bugs] #30014 [Webpages/Website]: No links to signature files for Tor Browser

[Tor Bug Tracker & Wiki]

#30014: No links to signature files for Tor Browser
--+--
 Reporter:  pf.team   |  Owner:  antonela
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:  #29901| Points:
 Reviewer:|Sponsor:
--+--
Changes (by antonela):

 * status:  reopened => 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] #30014 [Webpages/Website]: No links to signature files for Tor Browser

[Tor Bug Tracker & Wiki]

#30014: No links to signature files for Tor Browser
--+--
 Reporter:  pf.team   |  Owner:  antonela
 Type:  defect| Status:  reopened
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #29901| Points:
 Reviewer:|Sponsor:
--+--

Comment (by antonela):

 Thanks! I agree. The verification signature flow is very painful and non
 intuitive for non technical users. Even the previous version which has the
 .sig file and the instruction beside it is not helping users who don't
 know how to open a console.

 This version helps users who know what they are looking for.

 I opened #30259 to follow this discussion and to find a better flow for
 doing it. What SimplySecure did at Tails for verification is really good,
 we could follow that user-centered intention:

 https://tails.boum.org/install/index.en.html

 This ticket will get closed, since the scope was reached.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30218 [Metrics/CollecTor]: Add bandwidth files archiving to CollecTor

[Tor Bug Tracker & Wiki]

#30218: Add bandwidth files archiving to CollecTor
-+-
 Reporter:  irl  |  Owner:
 |  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/CollecTor|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth,tor-dirauth,metrics-  |  Actual Points:
  roadmap-2019-q2|
Parent ID:  #21378   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by karsten):

 Yesterday, I wrote a little script that ran roughly once per minute for
 over an hour and fetched moria1's and longclaw's "next" bandwidth files. I
 received a bandwidth file every time, not just between, say, HH:49 and
 HH:00. More specifically, here's what I got:

 || '''Authority''' || '''Timestamp''' ||'''Digest''' || '''First
 received''' || '''Last received''' || '''Referenced from vote''' ||
 || longclaw || 1555868103 (17:35) ||`lKTscsfb..` || .. || 18:40 || 18:00
 ||
 || longclaw || 1555871704 (18:35) ||`8KuO5fcL..` || 18:43 || 19:40 ||
 19:00 ||
 || longclaw || 1555875303 (19:35) ||`laoWH3KH..` || 19:41 || .. || 20:00
 ||
 || moria1 || 1555867341 (17:22) ||`EAiqle6R..` || ..  || 18:45 || 18:00 ||
 || moria1 || 1555871524 (18:32) ||`5aZPyxPy..` || 18:46 || 19:45 || 19:00
 ||
 || moria1 || 1555875627 (19:40) ||`ZTrHiTtI..` || 19:46 || .. || 20:00 ||

 Looking at the 19:00 votes, we could fetch referenced bandwidth files from
 around 18:45 to around 19:45.

 For reference, we're currently fetching votes (and all other relay
 descriptors) starting at HH:05 and once more at HH:35 in case there was no
 consensus at HH:00.

 How about we simply download "next" bandwidth files at around HH:05 and at
 around HH:35, knowing that we're really going to receive "previous"
 bandwidth files? This would be easiest with regard to extending
 CollecTor's relaydescs module.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30259 [UX]: Improve verify signature flow for Tor Browser

[Tor Bug Tracker & Wiki]

#30259: Improve verify signature flow for Tor Browser
-+--
 Reporter:  antonela |  Owner:  antonela
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  UX   |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 Verifying signature is a painful process for regular and power users. This
 ticket aims to explore how we can improve it.

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

Re: [tor-bugs] #25688 [Obfuscation/Snowflake]: proxy-go is still deadlocking occasionally

[Tor Bug Tracker & Wiki]

#25688: proxy-go is still deadlocking occasionally
+
 Reporter:  dcf |  Owner:  cohosh
 Type:  defect  | Status:  closed
 Priority:  Low |  Milestone:
Component:  Obfuscation/Snowflake   |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  network-team-roadmap-2019-Q1Q2  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:
+

Comment (by cohosh):

 Replying to [comment:27 cypherpunks]:
 > @cohosh I'm still not a 100% sure but each 7min or so it sure looks like
 the snowflake is deadlocking (or something else?) while I'm being
 connected and I get another one, this is very visible in my browsing
 experience. It would be great if you could investigate this.
 Thanks! I've made a new ticket for this here: #30258

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30258 [Obfuscation/Snowflake]: Snowflake proxy stops working during browsing session

[Tor Bug Tracker & Wiki]

#30258: Snowflake proxy stops working during browsing session
---+---
 Reporter:  cohosh |  Owner:  cohosh
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal |   Keywords:  snowflake
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor:  Sponsor19  |
---+---
 This was a comment on #25688:
 > I'm still not a 100% sure but each 7min or so it sure looks like the
 snowflake is deadlocking (or something else?) while I'm being connected
 and I get another one, this is very visible in my browsing experience. It
 would be great if you could investigate 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] #29366 [Metrics/Onionperf]: Persistent Onion service address

[Tor Bug Tracker & Wiki]

#29366: Persistent Onion service address
---+--
 Reporter:  irl|  Owner:  metrics-team
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords:  acute-2019-q1-planned  |  Actual Points:
Parent ID:  #28271 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by acute):

 Awaiting review: https://github.com/torproject/onionperf/pull/13

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30224 [Core Tor/Tor]: Add the tor versions for bridge-distribution-request

[Tor Bug Tracker & Wiki]

#30224: Add the tor versions for bridge-distribution-request
+
 Reporter:  teor|  Owner:  teor
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-spec, fast-fix  |  Actual Points:  0.1
Parent ID:  | Points:  0.1
 Reviewer:  catalyst|Sponsor:  Sponsor19-can
+
Changes (by asn):

 * reviewer:   => catalyst


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30189 [Core Tor/Tor]: ALL_BUGS_ARE_FATAL build failures in 0.3.4 and later.

[Tor Bug Tracker & Wiki]

#30189: ALL_BUGS_ARE_FATAL build failures in 0.3.4 and later.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  035-backport  |  Actual Points:  .1
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by asn):

 * reviewer:   => dgoulet


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

Re: [tor-bugs] #30184 [Core Tor/Tor]: release-0.2.9 doesn't compile on old rhel

[Tor Bug Tracker & Wiki]

#30184: release-0.2.9 doesn't compile on old rhel
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  no-mainline-merge, regression,   |  Actual Points:  0.2
  fast-fix, consider-backport-after-0404 |
Parent ID:   | Points:  0.1
 Reviewer:  ahf  |Sponsor:
 |  SponsorQ
-+-
Changes (by asn):

 * reviewer:   => ahf


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30078 [Core Tor/Tor]: shellcheck: src/test/fuzz/fixup_filenames.sh issues

[Tor Bug Tracker & Wiki]

#30078: shellcheck: src/test/fuzz/fixup_filenames.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:|  Actual Points:
Parent ID:| Points:
 Reviewer:  mikeperry |Sponsor:
--+
Changes (by asn):

 * reviewer:   => mikeperry


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30075 [Core Tor/Tor]: shellcheck: contrib/dist/tor.sh.in issues

[Tor Bug Tracker & Wiki]

#30075: shellcheck: contrib/dist/tor.sh.in issues
--+
 Reporter:  rl1987|  Owner:  (none)
 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:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by asn):

 * reviewer:   => dgoulet


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

Re: [tor-bugs] #30173 [Core Tor/Tor]: Ensure circuit padding can be safely disabled from consensus

[Tor Bug Tracker & Wiki]

#30173: Ensure circuit padding can be safely disabled from consensus
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:  0.33
  padding, 041-proposed  |
Parent ID:  #28634   | Points:
 Reviewer:  asn  |Sponsor:
 |  Sponsor2-can
-+-
Changes (by asn):

 * reviewer:   => asn


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30119 [Core Tor/Tor]: cert-spec uses binary encodings but does not specify byte order

[Tor Bug Tracker & Wiki]

#30119: cert-spec uses binary encodings but does not specify byte order
---+---
 Reporter:  irl|  Owner:  (none)
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  dir-spec, easy, doc, fast-fix  |  Actual Points:
Parent ID: | Points:  0.1
 Reviewer:  nickm  |Sponsor:
---+---
Changes (by asn):

 * reviewer:   => nickm


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30077 [Core Tor/Tor]: shellcheck: src/test/fuzz/fuzz_multi.sh issues

[Tor Bug Tracker & Wiki]

#30077: shellcheck: src/test/fuzz/fuzz_multi.sh issues
--+
 Reporter:  rl1987|  Owner:  (none)
 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:
 Reviewer:  ahf   |Sponsor:
--+
Changes (by asn):

 * reviewer:   => ahf


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30076 [Core Tor/Tor]: shellcheck: contrib/dist/suse/tor.sh.in issues

[Tor Bug Tracker & Wiki]

#30076: shellcheck: contrib/dist/suse/tor.sh.in issues
--+
 Reporter:  rl1987|  Owner:  (none)
 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:
 Reviewer:  nickm |Sponsor:
--+
Changes (by asn):

 * reviewer:   => nickm


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29223 [Core Tor/Tor]: List canonical abbreviations to use in Tor functions and identifiers

[Tor Bug Tracker & Wiki]

#29223: List canonical abbreviations to use in Tor functions and identifiers
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  0.9
Parent ID:| Points:  1
 Reviewer:  catalyst  |Sponsor:  Sponsor31-must
--+
Changes (by asn):

 * reviewer:   => catalyst


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29203 [Core Tor/Tor]: Add a way to specify machines as reduced circuit padding

[Tor Bug Tracker & Wiki]

#29203: Add a way to specify machines as reduced circuit padding
--+
 Reporter:  mikeperry |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  wtf-pad   |  Actual Points:  0.33
Parent ID:| Points:  4
 Reviewer:  asn   |Sponsor:  Sponsor2
--+
Changes (by asn):

 * reviewer:   => asn


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28780 [Core Tor/Tor]: circpadding: Add machine flag for not closing circuit if machine is active

[Tor Bug Tracker & Wiki]

#28780: circpadding: Add machine flag for not closing circuit if machine is 
active
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:  6
  padding, 041-proposed, network-team-   |
  roadmap-2019-Q1Q2  |
Parent ID:  #28634   | Points:  5
 Reviewer:  asn  |Sponsor:
 |  Sponsor2
-+-
Changes (by asn):

 * reviewer:   => asn


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28693 [Core Tor/Tor]: Add an option to disable circuit padding

[Tor Bug Tracker & Wiki]

#28693: Add an option to disable circuit padding
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:  0.33
  padding, 041-must  |
Parent ID:  #28634   | Points:  0.5
 Reviewer:  asn  |Sponsor:
 |  Sponsor2
-+-
Changes (by asn):

 * reviewer:   => asn


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30234 [Core Tor/Tor]: Get a stacktrace from tor processes launched by stem

[Tor Bug Tracker & Wiki]

#30234: Get a stacktrace from tor processes launched by stem
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci-fail-sometimes,   |  Actual Points:  0.1
  035-backport, 040-backport |
Parent ID:  #29437   | Points:  0.5
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 Looks good.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29223 [Core Tor/Tor]: List canonical abbreviations to use in Tor functions and identifiers

[Tor Bug Tracker & Wiki]

#29223: List canonical abbreviations to use in Tor functions and identifiers
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  0.9
Parent ID:| Points:  1
 Reviewer:|Sponsor:  Sponsor31-must
--+

Comment (by teor):

 Oops, the PR is https://github.com/torproject/tor/pull/963

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24546 [Core Tor/Tor]: Use tor_addr_is_v4() rather than family, or reject all v6-mapped IPv4 addresses

[Tor Bug Tracker & Wiki]

#24546: Use tor_addr_is_v4() rather than family, or reject all v6-mapped IPv4
addresses
-+-
 Reporter:  teor |  Owner:  neel
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-dirauth, ipv6,   |  Actual Points:  1
  033-triage-20180320, 033-removed-20180320, |
  035-triaged-in-20180711,   |
  040-deferred-20190220  |
Parent ID:   | Points:  1
 Reviewer:  ahf  |Sponsor:
 |  SponsorV-can
-+-
Changes (by teor):

 * reviewer:  ahf, teor => ahf


Comment:

 Clearing myself as a reviewer.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17945 [Core Tor/Tor]: Stop single hop client connections to Single Onion Services

[Tor Bug Tracker & Wiki]

#17945: Stop single hop client connections to Single Onion Services
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor2web, tor-hs, 029-proposed, 029   |  Actual Points:  0.4
  -teor-no, needs-design, needs-proposal-maybe,  |
  single-onion, review-group-33, |
  034-triage-20180328, 034-removed-20180328  |
Parent ID:  #24962   | Points:  5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * reviewer:  asn, teor =>


Comment:

 Clearing reviewers

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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: #29280, #9390, #12500, #17949, ...

[Tor Bug Tracker & Wiki]

Batch modification to #29280, #9390, #12500, #17949, #20082, #22233, #22453, 
#22689, #27198, #27201, #27821, #28027, #28113, #28774, #29294, #29613, #30001, 
#26376 by teor:
reviewer to 

Comment:
If these tickets go back in to needs_review, and I am on leave, they will need 
another reviewer.

--
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] #29437 [Core Tor/Stem]: test-stem times out intermittently

[Tor Bug Tracker & Wiki]

#29437: test-stem times out intermittently
---+
 Reporter:  rl1987 |  Owner:  (none)
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Stem  |Version:  Tor: 0.2.4.8-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-ci-fail-sometimes  |  Actual Points:  0.2
Parent ID: | Points:  0.2
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * status:  reopened => assigned
 * owner:  teor => (none)


Comment:

 Removing myself as owner, because I will be away from the middle of this
 week, and we need to make progress while I'm away.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30092 [Core Tor/Tor]: Add a probability-to-apply field for circuitpadidng machines

[Tor Bug Tracker & Wiki]

#30092: Add a probability-to-apply field for circuitpadidng machines
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:  0.5
  padding, 041-proposed  |
Parent ID:  #28634   | Points:  2
 Reviewer:  asn  |Sponsor:
 |  Sponsor2-can
-+-

Comment (by asn):

 BTW as a more general comment in this ticket, we should think a lot before
 we use this feature because the overhead danger is high (depending on the
 probability) and reaping the benefits is not always as straightforward.

 For example, consider using this feature for ticket #28634 to make general
 circuits look more random and blend in with random-lookin HS circuits. In
 that case, it's true that we increase the false positive rate of
 identifying a single intro or rend circuit, but if you look at the whole
 HS circuit dance, you can see that an HS client starts using 2 circuits at
 the same time (intro and rend, let's ignore hsdir for now). This ticket
 won't make normal clients start using 2 circuits at once, so even tho a
 single circuit might look random if the `probability` triggers, the fact
 that it's missing the second circuit  might still act as an identifier in
 that the session is not actually an HS dance and it's faking it.

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

Re: [tor-bugs] #29223 [Core Tor/Tor]: List canonical abbreviations to use in Tor functions and identifiers

[Tor Bug Tracker & Wiki]

#29223: List canonical abbreviations to use in Tor functions and identifiers
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  task  | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  0.9
Parent ID:| Points:  1
 Reviewer:|Sponsor:  Sponsor31-must
--+
Changes (by teor):

 * reviewer:  teor =>
 * actualpoints:  .7 => 0.9


Comment:

 I have reviewed the other half of the list.

 I made some general comments on the pull request, and some specific
 comments against particular abbreviations.

 I am not sure how we plan to converge on these abbreviations. Knowing the
 use cases will help future reviewers give more helpful advice.

 I am removing myself as a reviewer, because I will be on leave from the
 middle of this week.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28634 [Core Tor/Tor]: Design a first useful padding machine (hiding client-side intro/rend circuits) (was: Design a useful padding machine that we can enable)

[Tor Bug Tracker & Wiki]

#28634: Design a first useful padding machine (hiding client-side intro/rend
circuits)
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding, 041-proposed  |
Parent ID:  #28632   | Points:  8
 Reviewer:  mikeperry|Sponsor:
 |  Sponsor2
-+-

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #27544 [Core Tor/Tor]: hs-v3: Client authorization fixes and improvements post-merge

[Tor Bug Tracker & Wiki]

#27544: hs-v3: Client authorization fixes and improvements post-merge
--+--
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by asn):

 Stole #28966 and #29338 from this ticket and crummed it into #14389 so
 that they are done as part of s27.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28966 [Core Tor/Tor]: HSv3 client auth insufficiently documented (was: HiddenServiceAuthorizeClient incompatible)

[Tor Bug Tracker & Wiki]

#28966: HSv3 client auth insufficiently documented (was:
HiddenServiceAuthorizeClient incompatible)
-+-
 Reporter:  roo  |  Owner:  asn
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.5.6-rc
 Severity:  Minor| Resolution:
 Keywords:  tor-hs, client-auth, hsv3,   |  Actual Points:
  postfreeze-ok  |
Parent ID:  #14389   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by asn):

 * points:  0.3 => 0.5
 * sponsor:   => Sponsor27-must
 * parent:  #27544 => #14389


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #14389 [Core Tor/Tor]: little-t-tor: Provide support for better TBB UI of hidden service client authorization

[Tor Bug Tracker & Wiki]

#14389: little-t-tor: Provide support for better TBB UI of hidden service client
authorization
-+-
 Reporter:  asn  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tbb-usability, ux-team, hs-  |  Actual Points:
  auth   |
Parent ID:  #30237   | Points:  14-24
 Reviewer:   |Sponsor:
 |  Sponsor27-must
-+-
Changes (by asn):

 * points:  12-22 => 14-24


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22029 [Core Tor/Tor]: Allow ed25519 keys to be banned in the approved-routers file

[Tor Bug Tracker & Wiki]

#22029: Allow ed25519 keys to be banned in the approved-routers file
-+-
 Reporter:  teor |  Owner:  neel
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-triage-20180328, |  Actual Points:
  034-removed-20180328   |
Parent ID:   | Points:  1
 Reviewer:  asn  |Sponsor:
-+-

Comment (by teor):

 Also, this pull request does not update the man page for the approved
 routers file.

 Embarassingly, there are two entries in the man page for this file:
 {{{
  DataDirectory/approved-routers

 Only used by authoritative directory servers. This file lists the
 status of routers by their identity fingerprint. Each line lists a status
 and a fingerprint separated by whitespace. See your fingerprint file in
 the DataDirectory for an example line. If the status is !reject then
 descriptors from the given identity (fingerprint) are rejected by this
 server. If it is !invalid then descriptors are accepted but marked in the
 directory as not valid, that is, not recommended.

  DataDirectory/approved-routers

 Authorities only. This file is used to configure which relays are
 known to be valid, invalid, and so forth.
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29338 [Core Tor/Tor]: restore HiddenServiceAuthorizeClient in v3

[Tor Bug Tracker & Wiki]

#29338: restore HiddenServiceAuthorizeClient in v3
+--
 Reporter:  Alan|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.1.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.3.5.7
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, hs-auth, client-auth, hsv3  |  Actual Points:
Parent ID:  #14389  | Points:  2
 Reviewer:  |Sponsor:
|  Sponsor27-must
+--

Comment (by teor):

 Replying to [comment:8 asn]:
 > Replying to [comment:3 teor]:
 > > I think this is a duplicate of #28996.
 > > But maybe the user also wants some tor changes, as well as some
 documentation changes.
 >
 > Teor maybe you mistyped the ticket? Which one do you mean?

 #28966: HSv3 client auth insufficiently documented

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29338 [Core Tor/Tor]: restore HiddenServiceAuthorizeClient in v3

[Tor Bug Tracker & Wiki]

#29338: restore HiddenServiceAuthorizeClient in v3
+--
 Reporter:  Alan|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.1.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.3.5.7
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, hs-auth, client-auth, hsv3  |  Actual Points:
Parent ID:  #14389  | Points:  2
 Reviewer:  |Sponsor:
|  Sponsor27-must
+--
Changes (by asn):

 * points:   => 2


Comment:

 Replying to [comment:3 teor]:
 > I think this is a duplicate of #28996.
 > But maybe the user also wants some tor changes, as well as some
 documentation changes.

 Teor maybe you mistyped the ticket? Which one do you mean?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29338 [Core Tor/Tor]: restore HiddenServiceAuthorizeClient in v3

[Tor Bug Tracker & Wiki]

#29338: restore HiddenServiceAuthorizeClient in v3
+--
 Reporter:  Alan|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.1.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.3.5.7
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs, hs-auth, client-auth, hsv3  |  Actual Points:
Parent ID:  #14389  | Points:
 Reviewer:  |Sponsor:
|  Sponsor27-must
+--
Changes (by asn):

 * sponsor:   => Sponsor27-must
 * parent:  #27544 => #14389


Comment:

 Thanks for this ticket. Triaged it and it will be done sooner than later.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30252 [Core Tor/sbws]: Add the tor OpenSSL and NSS versions to the sbws bandwidth file headers

[Tor Bug Tracker & Wiki]

#30252: Add the tor OpenSSL and NSS versions to the sbws bandwidth file headers
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  needs_revision
 Priority:  Medium |  Milestone:  sbws: 1.2.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #30255 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 I'm not sure what names to use here.
 We could use "nss_version" and "openssl_version".
 But if we do, we need to make sure that the OpenSSL version distinguishes
 between OpenSSL and LibreSSL.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29355 [Core Tor/sbws]: Include scanner nickname and UUID in the bandwidth file headers?

[Tor Bug Tracker & Wiki]

#29355: Include scanner nickname and UUID in the bandwidth file headers?
-+-
 Reporter:  juga |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  sbws:
 |  1.2.x-final
Component:  Core Tor/sbws|Version:
 Severity:  Normal   | Resolution:
 Keywords:  sbws-11x-final-removed-20190312  |  Actual Points:
Parent ID:  #30255   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Please use "nickname" as the key name, to match dir-spec.

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

Re: [tor-bugs] #30255 [Core Tor/sbws]: Add additional bandwidth file headers in sbws 1.2

[Tor Bug Tracker & Wiki]

#30255: Add additional bandwidth file headers in sbws 1.2
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.2.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 Replying to [comment:2 juga]:
 > The problem with small tickets that change the same parts of the code is
 the merge conflicts. Any other solution apart of reviewing them one after
 other in some order?

 Our priority for sbws is maintaining stable software. That's more
 important than writing and merging features quickly.

 Conflicts are often a sign of bad code structure. For each new key, the
 current code structure needs:
 * a key in one place
 * the same key in another place
 * the same key in a third place, with the code that implements the key
 * the same key in five other places, with the code that tests the key

 Here's a structure for this code that would be easier to change:
 * each header key value is added to the state using a line of code
 * each header key value is tested using a line of code (or perhaps two
 lines of code, a set and a test)
 * the rest of the code just accepts whatever is in the state

 Using this structure, merges add additional key value assignments, at the
 end of a list of assignments. After the code is refactored, the merge
 conflicts should be trivial.

 While the code is so complicated, we need to split up sbws features into
 separate pull requests. Small pull requests are easier to review.

 If the pull requests are hard to review, we will struggle to find all the
 bugs in sbws code.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29714 [Applications/Tor Browser]: "Save ___ as" crashes browser every time

[Tor Bug Tracker & Wiki]

#29714: "Save ___ as" crashes browser every time
--+---
 Reporter:  xxx420blazer  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by xxx420blazer):

 Replying to [comment:1 gk]:
 > Does this happen as well if you download a clean, new version of Tor
 Browser from our website, put it at a different location and start it from
 there?

 Unfortunately yes. That was one of the first things I tried and that's why
 I decided to post this. Ive been having this problem only on this PC but
 for about a year 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] #30255 [Core Tor/sbws]: Add additional bandwidth file headers in sbws 1.2

[Tor Bug Tracker & Wiki]

#30255: Add additional bandwidth file headers in sbws 1.2
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:  sbws: 1.2.x-final
Component:  Core Tor/sbws  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by juga):

 The problem with small tickets that change the same parts of the code is
 the merge conflicts. Any other solution apart of reviewing them one after
 other in some order?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #13018 [Applications/Tor Browser]: Math routines are OS fingerprintable

[Tor Bug Tracker & Wiki]

#13018: Math routines are OS fingerprintable
-+-
 Reporter:  mikeperry|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-os-version,   |  Actual Points:
  ff31-esr   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by Thorin):

 Replying to [comment:31 cypherpunks]:
 > Why isn't https://bugzilla.mozilla.org/show_bug.cgi?id=531915 added to
 RFP?

 Alrighty! I've been trying to re-find that ticket for quite a few weeks.
 Used it many months ago and promptly lost it. Thanks. I will pass on the
 ticket number to the Tor Uplift guys

 > it's possible to detect some distros such way

 Comment 18 was 5 years ago. So far, and my resources are limited (and as
 an upstream problem means more than Tor Browser, which already changes
 their math FP), I have found nothing so far that leaks anything more than
 major platform (win/linux/mac) and in some instances 32/64 bit builds or
 OS architecture (some by default: eg a 64 bit build must be on a 64bit
 OS).

 I wanted to get a ticket at bugzilla opened. I have no idea how much work
 or complexity and potential issues lie with using the same libraries over
 all platforms (which is what Chrome seems to be doing: they have the same
 FP regardless of anything I test on).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30133 [Applications/Tor Browser]: YouTube page does not load

[Tor Bug Tracker & Wiki]

#30133: YouTube page does not load
--+---
 Reporter:  oystercult|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 If you want to use youtube with NoScript blocking everyhing you can use
 one of the dozens (?) of invido.us instances such as: https://invidio.us/
 http://kgg2m7yk5aybusll.onion/
 http://axqzx4s6s54s32yentfqojs3x5i7faxza6xo3ehd4bzzsg2ii4fv2iid.onion/
 https://invidious.snopyta.org/ ...etc

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25688 [Obfuscation/Snowflake]: proxy-go is still deadlocking occasionally

[Tor Bug Tracker & Wiki]

#25688: proxy-go is still deadlocking occasionally
+
 Reporter:  dcf |  Owner:  cohosh
 Type:  defect  | Status:  closed
 Priority:  Low |  Milestone:
Component:  Obfuscation/Snowflake   |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  network-team-roadmap-2019-Q1Q2  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:
+

Comment (by cypherpunks):

 @cohosh I'm still not a 100% sure but each 7min or so it sure looks like
 the snowflake is deadlocking (or something else?) while I'm being
 connected and I get another one, this is very visible in my browsing
 experience. It would be great if you could investigate 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] #28794 [Core Tor/Fallback Scripts]: Run an opt-in process for relay operators to become fallbacks in 2019

[Tor Bug Tracker & Wiki]

#28794: Run an opt-in process for relay operators to become fallbacks in 2019
---+
 Reporter:  teor   |  Owner:  phoul
 Type:  task   | Status:  needs_revision
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:
Parent ID:  #28793 | Points:
 Reviewer: |Sponsor:
---+

Comment (by teor):

 An operator emailed me and asked me to update an address:

 The IPv6 of silentrocket has changed

 And add another relay:

 silentflash - 324E2F56E04C2329598EAC512C3455AD45CE4A8C

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30234 [Core Tor/Tor]: Get a stacktrace from tor processes launched by stem

[Tor Bug Tracker & Wiki]

#30234: Get a stacktrace from tor processes launched by stem
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci-fail-sometimes,   |  Actual Points:  0.1
  035-backport, 040-backport |
Parent ID:  #29437   | Points:  0.5
 Reviewer:  ahf  |Sponsor:
-+-

Comment (by teor):

 I opened #30257 for the signal propagation.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30257 [Core Tor/Stem]: Propagate USR1 and ABRT signals from stem tests through to tor

[Tor Bug Tracker & Wiki]

#30257: Propagate USR1 and ABRT signals from stem tests through to tor
---+---
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Stem  |Version:  Tor: 0.2.4.8-alpha
 Severity:  Normal |   Keywords:  tor-ci-fail-sometimes
Actual Points: |  Parent ID:  #29437
   Points: |   Reviewer:
  Sponsor: |
---+---
 In #30234, we got the tor logs, but the USR1 and ABRT signals sent by
 timelimit to test_stem.py aren't being propagated to tor:
 {{{
 Apr 22 03:32:30.000 [notice] Monitored process 20402 is dead.
 Apr 22 03:32:30.000 [notice] Owning controller process has vanished --
 exiting now.
 Apr 22 03:32:30.000 [notice] Catching signal TERM, exiting cleanly.
 }}}
 https://travis-ci.org/teor2345/tor/jobs/522893523#L4944

 We need to work out how to get the signals from this stem test process
 down to the tor it launches:
 {{{
 

 Signal SIGABRT received by thread MainThread in process 20402
 

 Event notifier thread stacktrace
   File "/usr/lib/python3.4/threading.py", line 888, in _bootstrap
 self._bootstrap_inner()
   File "/usr/lib/python3.4/threading.py", line 920, in _bootstrap_inner
 self.run()
   File "/usr/lib/python3.4/threading.py", line 868, in run
 self._target(*self._args, **self._kwargs)
   File "/home/travis/build/teor2345/tor/stem/stem/control.py", line 984,
 in _event_loop
 self._event_notice.wait(0.05)
   File "/usr/lib/python3.4/threading.py", line 553, in wait
 signaled = self._cond.wait(timeout)
   File "/usr/lib/python3.4/threading.py", line 294, in wait
 gotit = waiter.acquire(True, timeout)
 

 MainThread thread stacktrace
   File "/home/travis/build/teor2345/tor/stem/run_tests.py", line 451, in
 
 main()
   File "/home/travis/build/teor2345/tor/stem/run_tests.py", line 287, in
 main
 integ_runner.start(target, args.attribute_targets, args.tor_path)
   File "/home/travis/build/teor2345/tor/stem/test/runner.py", line 262, in
 start
 self._owner_controller = self.get_tor_controller(True)
   File "/home/travis/build/teor2345/tor/stem/test/runner.py", line 482, in
 get_tor_controller
 controller.authenticate(password = CONTROL_PASSWORD, chroot_path =
 self.get_chroot())
   File "/home/travis/build/teor2345/tor/stem/stem/control.py", line 1103,
 in authenticate
 stem.connection.authenticate(self, *args, **kwargs)
   File "/home/travis/build/teor2345/tor/stem/stem/connection.py", line
 530, in authenticate
 protocolinfo_response = get_protocolinfo(controller)
   File "/home/travis/build/teor2345/tor/stem/stem/connection.py", line
 1007, in get_protocolinfo
 protocolinfo_response = _msg(controller, 'PROTOCOLINFO 1')
   File "/home/travis/build/teor2345/tor/stem/stem/connection.py", line
 1036, in _msg
 return controller.msg(message)
   File "/home/travis/build/teor2345/tor/stem/stem/control.py", line 654,
 in msg
 response = self._reply_queue.get()
   File "/usr/lib/python3.4/queue.py", line 167, in get
 self.not_empty.wait()
   File "/usr/lib/python3.4/threading.py", line 290, in wait
 waiter.acquire()
   File "/home/travis/build/teor2345/tor/stem/run_tests.py", line 98, in
 log_traceback
 for thread_name, stacktrace in
 test.output.thread_stacktraces().items():
   File "/home/travis/build/teor2345/tor/stem/test/output.py", line 110, in
 thread_stacktraces
 stacktraces[thread.name] = ''.join(traceback.format_stack(frame))
 

 Tor listener thread stacktrace
   File "/usr/lib/python3.4/threading.py", line 888, in _bootstrap
 self._bootstrap_inner()
   File "/usr/lib/python3.4/threading.py", line 920, in _bootstrap_inner
 self.run()
   File "/usr/lib/python3.4/threading.py", line 868, in run
 self._target(*self._args, **self._kwargs)
   File "/home/travis/build/teor2345/tor/stem/stem/control.py", line 939,
 in _reader_loop
 control_message = self._socket.recv()
   File "/home/travis/build/teor2345/tor/stem/stem/socket.py", line 474, in
 recv
 return self._recv(lambda s, sf: recv_message(sf))
   File "/home/travis/build/teor2345/tor/stem/stem/socket.py", line 274, in
 _recv
 return handler(my_socket, my_socket_file)
   File "/home/travis/build/teor2345/tor/stem/stem/socket.py", line 474, in
 
 return self._recv(lambda s, sf: recv_message(sf))
   File "/home/travis/build/teor2345/tor/stem/stem/socket.py", line 676, in
 recv_message
 line = 

Re: [tor-bugs] #30234 [Core Tor/Tor]: Get a stacktrace from tor processes launched by stem

[Tor Bug Tracker & Wiki]

#30234: Get a stacktrace from tor processes launched by stem
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ci-fail-sometimes,   |  Actual Points:  0.1
  035-backport, 040-backport |
Parent ID:  #29437   | Points:  0.5
 Reviewer:  ahf  |Sponsor:
-+-

Comment (by teor):

 We do get the tor logs, but we're not propagating the USR1 and ABRT
 signals from stem to tor:
 {{{
 Apr 22 03:32:30.000 [notice] Monitored process 20402 is dead.
 Apr 22 03:32:30.000 [notice] Owning controller process has vanished --
 exiting now.
 Apr 22 03:32:30.000 [notice] Catching signal TERM, exiting cleanly.
 }}}
 https://travis-ci.org/teor2345/tor/jobs/522893523#L4944

 I'll open another child of #29437.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #30213 [Core Tor/Tor]: Remove sudo: false from Travis

[Tor Bug Tracker & Wiki]

#30213: Remove sudo: false from Travis
+
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt, tor-ci  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * milestone:  Tor: unspecified => Tor: 0.4.1.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] #30213 [Core Tor/Tor]: Remove sudo: false from Travis

[Tor Bug Tracker & Wiki]

#30213: Remove sudo: false from Travis
+--
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  technical-debt, tor-ci  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  |Sponsor:
+--
Changes (by teor):

 * status:  new => needs_revision


Comment:

 Each rule is an array of match criteria, starting with "-".

 These rules mean "exclude clang builds with no sudo" and "exclude gcc
 builds with sudo":
 {{{
   exclude:
 ## Clang doesn't work in containerized builds, see below.
 - compiler: clang
   sudo: false
 ## Non-containerized gcc are slow and redundant.
 - compiler: gcc
   sudo: required
 ## gcc on OSX is less useful, because the default compiler is clang.
 - compiler: gcc
   os: osx
 }}}

 Your patch replaces them with: "exclude clang builds" and "exclude gcc
 builds" (and then you reverted one of those changes):
 {{{
   exclude:
 ## Clang doesn't work in containerized builds, see below.
 - compiler: clang
 ## Non-containerized gcc are slow and redundant.
 - compiler: gcc
 ## gcc on OSX is less useful, because the default compiler is clang.
 - compiler: gcc
   os: osx
 }}}

 Instead, remove the entire rule, for every rule that mentions sudo:
 {{{
   exclude:
 ## gcc on OSX is less useful, because the default compiler is clang.
 - compiler: gcc
   os: osx
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22029 [Core Tor/Tor]: Allow ed25519 keys to be banned in the approved-routers file

[Tor Bug Tracker & Wiki]

#22029: Allow ed25519 keys to be banned in the approved-routers file
-+-
 Reporter:  teor |  Owner:  neel
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-triage-20180328, |  Actual Points:
  034-removed-20180328   |
Parent ID:   | Points:  1
 Reviewer:  asn  |Sponsor:
-+-

Comment (by teor):

 There are two major bugs in this code:

 dirserv_get_status_impl() is also called from
 dirserv_would_reject_router().
 But dirserv_would_reject_router() was not updated to check the ed25519
 identity key.

 A call to dirserv_get_status_impl() is in the wrong place.
 The ed25519 key is only checked if there is a KEYPIN_MISMATCH.

 Please add some tests for dirserv_router_get_status() and
 dirserv_would_reject_router() that fail on the current code, but succeed
 when you fix these bugs.

 Does this change fail practracker?
 The existing code is already complex, so you should not increase function
 sizes. Instead, split the new code out into new functions.
 I am not sure if you should split files: maybe we should open another
 ticket, and do that after 0.4.0 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