Re: [tor-bugs] #22050 [Metrics/Consensus Health]: Consensus health is concerned about missing reveal values but it shouldn't

[Tor Bug Tracker & Wiki]

#22050: Consensus health is concerned about missing reveal values but it 
shouldn't
-+
 Reporter:  asn  |  Owner:  tom
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Consensus Health |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs consensus health tor-srv  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by tom):

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


Comment:

 
https://gitweb.torproject.org/depictor.git/commit/?id=d23a06ca4ae5d8263828c3662347b733ae2b7fff

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22233 [Core Tor/Tor]: Reconsider behavior on .z URLs with Accept-Encoding header

[Tor Bug Tracker & Wiki]

#22233: Reconsider behavior on .z URLs  with Accept-Encoding header
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4
--+

Comment (by yawning):

 ahf points out that prop 278 specifies sending `415` on negotiation
 failure, the proposal should be changed to `406`, because it's the correct
 error code to use when a request is is impossible to fulfill due to
 `Accept-*` headers.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21666 [Core Tor/Tor]: Prop278: Code to decide whether we want to request and/or provide CPU-intensive compression methods

[Tor Bug Tracker & Wiki]

#21666: Prop278: Code to decide whether we want to request and/or provide CPU-
intensive compression methods
+--
 Reporter:  ahf |  Owner:
 Type:  task| Status:  closed
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  TorCoreTeam201703, prop278  |  Actual Points:
Parent ID:  | Points:  4
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by ahf):

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


Comment:

 Yes, this can be closed. The solutions are in #21668 (background
 compression of consensus) and #21667 (will ensure LZMA isn't used for any
 non-precompressed data) respectively.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22233 [Core Tor/Tor]: Reconsider behavior on .z URLs with Accept-Encoding header

[Tor Bug Tracker & Wiki]

#22233: Reconsider behavior on .z URLs  with Accept-Encoding header
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4
--+

Comment (by yawning):

 Replying to [comment:3 arma]:
 > FYI, my wget didn't send any accept-encoding header. Neither did
 Sebastian's. Maybe Yawning's did? You can tell it to *add* an accept-
 encoding header, but then what do you expect.

 `wget http://example.com` on my system does this:

 {{{
 GET / HTTP/1.1
 User-Agent: Wget/1.19.1 (linux-gnu)
 Accept: */*
 Accept-Encoding: identity
 Host: example.com
 Connection: Keep-Alive
 }}}

 Python's HTTP client also includes the header with `identity`.

 > I think the issue here is more that there are two ways to indicate you
 want compression -- adding a .z to the url, and saying so in the accept-
 encoding header -- and we should build the two by two decision matrix and
 do the smart thing for all four cases.

 Yes.  The existing code tries to treat `.z` as `Accept-Encoding: deflate`,
 which is a shortcut, and not always correct.  Assuming we do not want to
 double compress, what I would consider working behavior looks like:

 || File || Accept-Encoding || Action
 ||
 || `foo`|| N/A || `foo`
 ||
 || `foo`|| `identity`  || `Content-Encoding: identity`,
 `foo`  ||
 || `foo`|| `deflate`   || `Content-Encoding: deflate`,
 `deflate(foo)` ||
 || `foo`|| `identity, deflate` || `Content-Encoding: deflate`,
 `deflate(foo)` ||
 || `foo`|| `identity, gzip`|| `Content-Encoding: gzip`,
 `gzip(foo)`||
 || `foo`|| `gzip`  || `Content-Encoding: gzip`,
 `gzip(foo)`||
 || `foo`|| `deflate, gzip` || `Content-Encoding: gzip`,
 `gzip(foo)`||
 || `foo.z`  || N/A || `deflate(foo)`
 ||
 || `foo.z`  || `identity`  || `Content-Encoding: identity`,
 `deflate(foo)` ||
 || `foo.z`  || `deflate`   || `406 Not Acceptable`
 ||
 || `foo.z`  || `identity, deflate` || `Content-Encoding: identity`,
 `deflate(foo)` ||
 || `foo.z`  || `identity, gzip`|| `Content-Encoding: identity`,
 `deflate(foo)` ||
 || `foo.z`  || `gzip`  || `406 Not Acceptable`
 ||
 || `foo.z`  || `deflate, gzip` || `406 Not Acceptable`
 ||

 (`gzip` used as a placeholder algorithm for "Something that is supported
 that is not `deflate`)

 The current code mishandles the cases in the table that should either
 double compress or return `406`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18100 [Core Tor/Tor]: src/or/connection_edge.c typo

[Tor Bug Tracker & Wiki]

#18100: src/or/connection_edge.c typo
-+-
 Reporter:  jirib|  Owner:
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.9
 Severity:  Normal   | Resolution:
 Keywords:  isaremoved, nickwants029, lorax, |  Actual Points:
  tor-03-unspecified-201612  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by d4fq0fQAgoJ):

 I've been using the patched version (0001-trans_tproxy.patch) with a
 TPROXY iptables setup since I commented here and so far it's been working
 as expected for me.

 The only real documentation about the TPROXY feature I found is from the
 kernel documentation (Documentation/networking/tproxy.txt). Unfortunately
 it does not say anything about getsockname() or
 getsockopt(SO_ORIGINAL_DST).

 It seems that the TPROXY kernel feature enables transparent proxy
 capabilities without the need to DNAT (what else would be it's purpose
 then?). The above experiment backs this up because TPROXYing works without
 conntrack kernel modules loaded (conntracking is required for NAT). This
 only works with the above patch applied which utilizes getsockname()
 instead of getsockopt(SO_ORIGINAL_DST). Therefore it seems that
 getsockname() is the correct way.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22234 [Applications/Tor Browser]: Remove Disconnect Search from search engines

[Tor Bug Tracker & Wiki]

#22234: Remove Disconnect Search from search engines
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Since it redirects to duckduckgo by default it is redundant.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22209 [Core Tor/Tor]: Channelpadding tests fail on kevent-based systems

[Tor Bug Tracker & Wiki]

#22209: Channelpadding tests fail on kevent-based systems
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by mikeperry):

 I am having trouble finding the branch that matches those line numbers
 exactly, but those asserts are checking to see if cells were written due
 to timers firing. If not re-initting libevent was causing timers not to
 fire, that would explain those test assert fails.

 The backtrace assert is also hard to tell. Is chan null, or is
 channels_pending NULL? It might make sense that channels_pending was NULL
 if libevent never got set up properly for anything to ever get written?

 Or is the backtrace still happening and is something different?

 (Also, do we have jenkins bots to watch for this? I don't see any for
 freebsd, unless they are just named weird).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #10286 [Applications/Tor Browser]: Touch events leak absolute screen coordinates

[Tor Bug Tracker & Wiki]

#10286: Touch events leak absolute screen coordinates
-+-
 Reporter:  mikeperry|  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-resolution,   |  Actual Points:
  ff52-esr, tbb-testcase, tbb-firefox-patch, |
  tbb-7.0-must-alpha, TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by mcs):

 Replying to [comment:31 mcs]:
 > I am not yet sure why the failures are occuring. Unfortunately I am out
 of time for now, but I will try to investigate more later tonight or early
 tomorrow.

 The test failures occurred in the "fingerprinting resistance off" case.
 Kathy came up with a good theory: maybe the doubling of the radius
 occurred because I ran the tests on a Mac with a Retina (2x) display. If
 that is what is happening, this seems like a Firefox bug (maybe in the
 test code that synthesizes events?) since all distance units within the
 Touch Events are supposed to be CSS pixels. This should not prevent us
 from merging these patches.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21688 [Applications/Tor Browser]: Investigate whether the search service update feature needs to be disabled/modified

[Tor Bug Tracker & Wiki]

#21688: Investigate whether the search service update feature needs to be
disabled/modified
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must-alpha,|  Actual Points:
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by arthuredelstein):

 * status:  new => needs_review
 * keywords:  ff52-esr, tbb-7.0-must-alpha, TorBrowserTeam201705 =>
 ff52-esr, tbb-7.0-must-alpha, TorBrowserTeam201705R


Comment:

 I looked at `nsSearchService.js` and it appears that setting the pref
 "browser.search.update" to false already disables any search engine
 updates:
 https://dxr.mozilla.org/mozilla-
 esr52/search?q=BROWSER_SEARCH_PREF+%2B+%22update%22%2C&redirect=false

 In `browser/app/profile/000-tor-browser.js` in Tor Browser, we already
 have
 {{{
 pref("browser.search.update", false);
 }}}
 so I think no action is needed.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20625 [Core Tor/Tor]: When a consensus doesn't have enough signatures, write it (and sigs) to a file

[Tor Bug Tracker & Wiki]

#20625: When a consensus doesn't have enough signatures, write it (and sigs) to 
a
file
---+
 Reporter:  teor   |  Owner:
 Type:  enhancement| Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  easy, tor-dirauth  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+
Changes (by arma):

 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.2.x-final


Comment:

 Deferring to 0.3.2 for the same reason.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21762 [Applications/Tor Browser]: Check new Firefox favicon code for first-party isolation

[Tor Bug Tracker & Wiki]

#21762: Check new Firefox favicon code for first-party isolation
-+-
 Reporter:  arthuredelstein  |  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  accepted
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must-alpha,|  Actual Points:
  TorBrowserTeam201705   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by arthuredelstein):

 * owner:  tbb-team => arthuredelstein
 * status:  new => accepted


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

Re: [tor-bugs] #21542 [Applications/Tor Launcher]: use Subprocess.jsm to launch tor

[Tor Bug Tracker & Wiki]

#21542: use Subprocess.jsm to launch tor
---+---
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-usability, ff52-esr|  Actual Points:
Parent ID:  #10059 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by arma):

 Replying to [comment:5 mcs]:
 > Firefox's Subprocess.jsm allows access to both stdout and stderr, so I
 don't think the network team needs to make any changes. I just assumed the
 log was being sent to stderr. Is anything sent to stderr?

 Nothing is sent to stderr. It's all stdout by default, unless there is
 some other log line defined, in which case it is whatever that log line
 is.

 > Obviously the advantage of this approach (capture tor's stdout) over the
 one described in ticket:10059#comment:17 is that in most cases
 '''something''' will be logged to stdout even if tor never gets to the
 point of opening a control port listener.

 Makes sense!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #13612 [Applications/Tor Browser]: social.remote-install.enabled option in Tor Browser

[Tor Bug Tracker & Wiki]

#13612: social.remote-install.enabled option in Tor Browser
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must,  |  Actual Points:
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by arthuredelstein):

 * keywords:  ff52-esr, tbb-7.0-must => ff52-esr, tbb-7.0-must,
 TorBrowserTeam201705R
 * status:  new => needs_review


Comment:

 Have looked at the `social.*` prefs and the associated code, I think it
 makes sense to disable these. Here's a patch to do that:

 https://github.com/arthuredelstein/tor-browser/commit/13612

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22227 [Applications/Tor Browser]: Netmonitor Gives the Wrong Remote Address

[Tor Bug Tracker & Wiki]

#7: Netmonitor Gives the Wrong Remote Address
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:1 yawning]:
 > The client's tor instance doesn't actually ever see the IP address when
 it connects to a FQDN, which is why `0.0.0.0` is returned.  So this would
 be moderately annoying to fix, because it's an extra SOCKS request at a
 minimum (assuming `RESOLVE` works as expected).

 Ok, so I can understand why it wouldn't show the real remote address if
 the client doesn't see the DNS response, but it also shows it as 0.0.0.0
 even when browsing directly to an IP URL (see screenshot).

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

Re: [tor-bugs] #22226 [Applications/Tor Browser]: Exploiting the TOR-Browser reporting security bugs issues

[Tor Bug Tracker & Wiki]

#6: Exploiting the TOR-Browser reporting security bugs issues
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by Dbryrtfbcbhgf):

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


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

Re: [tor-bugs] #10286 [Applications/Tor Browser]: Touch events leak absolute screen coordinates

[Tor Bug Tracker & Wiki]

#10286: Touch events leak absolute screen coordinates
-+-
 Reporter:  mikeperry|  Owner:
 |  arthuredelstein
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting-resolution,   |  Actual Points:
  ff52-esr, tbb-testcase, tbb-firefox-patch, |
  tbb-7.0-must-alpha, TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by mcs):

 I reviewed the patches and they look okay. But for some reason when I run
 the tests on OSX two of them fail:
 {{{
 6 INFO TEST-UNEXPECTED-FAIL |
 dom/events/test/test_touchevent_resist_fingerprinting.html | touch.radiusX
 - got 4, expected 2
 7 INFO TEST-UNEXPECTED-FAIL |
 dom/events/test/test_touchevent_resist_fingerprinting.html | touch.radiusY
 - got 6, expected 3
 }}}
 I am not yet sure why the failures are occuring. Unfortunately I am out of
 time for now, but I will try to investigate more later tonight or early
 tomorrow.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22226 [Applications/Tor Browser]: Exploiting the TOR-Browser reporting security bugs issues

[Tor Bug Tracker & Wiki]

#6: Exploiting the TOR-Browser reporting security bugs issues
--+---
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by Dbryrtfbcbhgf):

 The vulnerabilities in the blog post were not addressed in this ticket.
 ​http://www.hackerfactor.com/blog/index.php?/archives/761-Exploiting-the-
 TOR-Browser.html

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

Re: [tor-bugs] #21666 [Core Tor/Tor]: Prop278: Code to decide whether we want to request and/or provide CPU-intensive compression methods

[Tor Bug Tracker & Wiki]

#21666: Prop278: Code to decide whether we want to request and/or provide CPU-
intensive compression methods
+--
 Reporter:  ahf |  Owner:
 Type:  task| Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, prop278  |  Actual Points:
Parent ID:  | Points:  4
 Reviewer:  |Sponsor:  Sponsor4
+--
Description changed by arma:

Old description:

> We need some code in Tor to decide if or when we want to use and provide
> CPU-intensive compression operations. The biggest concer in Prop278 is
> LZMA2.

New description:

 We need some code in Tor to decide if or when we want to use and provide
 CPU-intensive compression operations. The biggest concern in Prop278 is
 LZMA2.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22233 [Core Tor/Tor]: Reconsider behavior on .z URLs with Accept-Encoding header

[Tor Bug Tracker & Wiki]

#22233: Reconsider behavior on .z URLs  with Accept-Encoding header
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4
--+

Comment (by arma):

 FYI, my wget didn't send any accept-encoding header. Neither did
 Sebastian's. Maybe Yawning's did? You can tell it to *add* an accept-
 encoding header, but then what do you expect.

 I think the issue here is more that there are two ways to indicate you
 want compression -- adding a .z to the url, and saying so in the accept-
 encoding header -- and we should build the two by two decision matrix and
 do the smart thing for all four cases.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22232 [Applications/Tor Launcher]: gather info on how Tor Launcher uses bootstrap status messages

[Tor Bug Tracker & Wiki]

#22232: gather info on how Tor Launcher uses bootstrap status messages
---+---
 Reporter:  catalyst   |  Owner:  brade
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  usability, ux  |  Actual Points:
Parent ID:  #21951 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by mcs):

 * cc: mcs (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] #22233 [Core Tor/Tor]: Reconsider behavior on .z URLs with Accept-Encoding header

[Tor Bug Tracker & Wiki]

#22233: Reconsider behavior on .z URLs  with Accept-Encoding header
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4
--+
Description changed by arma:

Old description:

> In proposal 278, I said:
> {{{
>   If a directory server receives a request to a document with the ".z"
>   suffix, where the client does not include an "Accept-Encoding" header,
>   the server should respond with the zlib compressed version of the
>   document for backwards compatibility with client that does not support
>   this proposal.
> }}}
>
> But on #22206 it became apparent that we've got a problem there: there
> are already tools (built e.g. on wget) that ask for the .z URL but which
> send "Accept-Encodings: Identity."
>
> And onn #22206, Yawning says:
> > an error (or a double compressed payload) should be returned when the
> .z request contains an Accept-Encoding header that specifies anything
> other than identity/deflate.
>
> We'd like the end result here to be something where new Tor clients can
> interoperate with older directory caches without breaking anything, and
> getting the new compression type of they support it.  And we certainly
> don't want anybody doing two layers of compression: that's a waste of
> cycles.  But we should see if there's a way where we can be more
> standards compliant without breaking anything we care about.

New description:

 In proposal 278, I said:
 {{{
   If a directory server receives a request to a document with the ".z"
   suffix, where the client does not include an "Accept-Encoding" header,
   the server should respond with the zlib compressed version of the
   document for backwards compatibility with client that does not support
   this proposal.
 }}}

 But on #22206 it became apparent that we've got a problem there: there are
 already tools (built e.g. on wget) that ask for the .z URL but which send
 "Accept-Encodings: Identity."

 And onn #22206, Yawning says:
 > an error (or a double compressed payload) should be returned when the .z
 request contains an Accept-Encoding header that specifies anything other
 than identity/deflate.

 We'd like the end result here to be something where new Tor clients can
 interoperate with older directory caches without breaking anything, and
 getting the new compression type if they support it.  And we certainly
 don't want anybody doing two layers of compression: that's a waste of
 cycles.  But we should see if there's a way where we can be more standards
 compliant without breaking anything we care about.

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21953 [Core Tor/Tor]: Dealing with Tor hardening on Windows properly

[Tor Bug Tracker & Wiki]

#21953: Dealing with Tor hardening on Windows properly
---+---
 Reporter:  cypherpunks|  Owner:
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  030-backport 029-backport  |  Actual Points:
Parent ID: | Points:  0.1
 Reviewer: |Sponsor:
---+---

Comment (by tom):

 Replying to [comment:6 nickm]:
 > Okay; I've written a branch here as branch `ticket21953_029` in my
 public git repository. Is it what people had in mind?  Please confirm if
 so, and correct if I've got it wrong.

 LGTM

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #20761 [Applications/Tor Launcher]: Tor Browser 6.5a4 is ignoring additional SocksPorts

[Tor Bug Tracker & Wiki]

#20761: Tor Browser 6.5a4 is ignoring additional SocksPorts
---+--
 Reporter:  gk |  Owner:  mcs
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201705R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by mcs):

 * status:  needs_revision => needs_review
 * keywords:  TorBrowserTeam201705 => TorBrowserTeam201705R


Comment:

 Here is a new patch to use TCP by default:
 https://gitweb.torproject.org/user/brade/tor-
 
launcher.git/commit/?h=bug20761-disable-01&id=df026f154ebf8f5e971ce43a2f78515fbe9e3b26

 For the sake of completeness, here are the other patches (unchanged):
 https://gitweb.torproject.org/user/brade/tor-browser-
 bundle.git/commit/?h=bug20761-02&id=5c44ae3568b9f42fcebb8426d567c0311c4c9b19
 https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug20761-05&id=5154173e0facfff26bede4c37d2c47669350d0ff

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22233 [Core Tor/Tor]: Reconsider behavior on .z URLs with Accept-Encoding header

[Tor Bug Tracker & Wiki]

#22233: Reconsider behavior on .z URLs  with Accept-Encoding header
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor4
--+
Changes (by ahf):

 * cc: ahf (added)


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

[tor-bugs] #22233 [Core Tor/Tor]: Reconsider behavior on .z URLs with Accept-Encoding header

[Tor Bug Tracker & Wiki]

#22233: Reconsider behavior on .z URLs  with Accept-Encoding header
--+
 Reporter:  nickm |  Owner:
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  Sponsor4  |
--+
 In proposal 278, I said:
 {{{
   If a directory server receives a request to a document with the ".z"
   suffix, where the client does not include an "Accept-Encoding" header,
   the server should respond with the zlib compressed version of the
   document for backwards compatibility with client that does not support
   this proposal.
 }}}

 But on #22206 it became apparent that we've got a problem there: there are
 already tools (built e.g. on wget) that ask for the .z URL but which send
 "Accept-Encodings: Identity."

 And onn #22206, Yawning says:
 > an error (or a double compressed payload) should be returned when the .z
 request contains an Accept-Encoding header that specifies anything other
 than identity/deflate.

 We'd like the end result here to be something where new Tor clients can
 interoperate with older directory caches without breaking anything, and
 getting the new compression type of they support it.  And we certainly
 don't want anybody doing two layers of compression: that's a waste of
 cycles.  But we should see if there's a way where we can be more standards
 compliant without breaking anything we care about.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22206 [Core Tor/Tor]: Fetching compressed consensus gives it uncompressed if Accept-Encoding header is specified

[Tor Bug Tracker & Wiki]

#22206: Fetching compressed consensus gives it uncompressed if Accept-Encoding
header is specified
--+
 Reporter:  Sebastian |  Owner:  ahf
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  regression|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Added #22233 to track that and related discussion; probably missed
 something significant in my summary.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22232 [Applications/Tor Launcher]: gather info on how Tor Launcher uses bootstrap status messages

[Tor Bug Tracker & Wiki]

#22232: gather info on how Tor Launcher uses bootstrap status messages
---+---
 Reporter:  catalyst   |  Owner:  brade
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal |   Keywords:  usability, ux
Actual Points: |  Parent ID:  #21951
   Points: |   Reviewer:
  Sponsor: |
---+---
 As part of the effort to improve the user experience during Tor Launcher
 bootstrap (#21951), it would be helpful to know some details of how Tor
 Launcher currently uses bootstrap status messages (`STATUS_CLIENT
 BOOTSTRAP` asynchronous messages from the control protocol).  Among other
 things, it could help Core Tor make short-term incremental changes to
 vastly improve the user experience.

 * Does the progress bar currently map phase numbers directly into percent-
 done on the bar?
 * Does it do anything with `TAG=` keywords in the BOOTSTRAP messages?
 * Does it do anything with `SUMMARY=` strings other than displaying them
 in the dialog box?
 * How does it know when to display the "copy logs" button with the warning
 icon?
 * Which other of the `BOOTSTRAP` keywords does it use and how?
 * Does it use any other asynchronous control protocol messages?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22165 [Applications/Tor Browser]: Rip out the option to collect local IP addresses

[Tor Bug Tracker & Wiki]

#22165: Rip out the option to collect local IP addresses
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must,  |  Actual Points:
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * keywords:  ff52-esr, tbb-7.0-must => ff52-esr, tbb-7.0-must,
 TorBrowserTeam201705R
 * status:  new => needs_review


Comment:

 Here's a patch for review:
 https://github.com/arthuredelstein/tor-browser/commit/22165

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21940 [Applications/Tor Browser]: OSX updater: consider disabling privilege escalation

[Tor Bug Tracker & Wiki]

#21940: OSX updater: consider disabling privilege escalation
-+-
 Reporter:  mcs  |  Owner:  mcs
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must,  |  Actual Points:
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by linda):

 > Usability aspect here is that many users want to make TBB the default
 web browser, also to make it more secure to open web content from any app,
 and as a part of that, there is the need to install TBB as usual app,
 usually to the default location which usually needs admin privileges on
 any OS.

 I don't think that there is a usability issue here, but that it is a
 security issue that the browser team will make a decision on. A decision
 can be made without my consultation.

 The average internet user (which is different from the average Tor user)
 will likely not know the difference between an application requiring admin
 privileges or not, and will not notice if it does request it. They just
 want to install the thing so that they can use it. Unless it requires a
 different installation pattern than everything they are used to, I don't
 think they will notice.

 Generally, I think we should still do what is best in terms of security.

 (I would like to clarify that "if we de-escalate then things will break
 and we need to fix them" != a usability issue, that's just technical work
 as a result of decisions made. Also "a decision that will have security
 implications" != a usability issue (even if people have preferences over
 it, and if you honor those preferences. I think that's just catering to
 the right userbase. A usability issue is when everything is technically
 working fine, and people still have a hard time using it--i.e. when tor
 launcher asks a user to choose bridges but they don't know what they are
 and choose randomly.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21953 [Core Tor/Tor]: Dealing with Tor hardening on Windows properly

[Tor Bug Tracker & Wiki]

#21953: Dealing with Tor hardening on Windows properly
---+---
 Reporter:  cypherpunks|  Owner:
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  030-backport 029-backport  |  Actual Points:
Parent ID: | Points:  0.1
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * keywords:  030-backport => 030-backport 029-backport
 * status:  assigned => merge_ready


Comment:

 Okay; I've written a branch here as branch `ticket21953_029` in my public
 git repository. Is it what people had in mind?  Please confirm if so, and
 correct if I've got it wrong.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #10059 [Core Tor/Tor]: capture tor log messages before control connection is opened

[Tor Bug Tracker & Wiki]

#10059: capture tor log messages before control connection is opened
-+-
 Reporter:  mcs  |  Owner:  nickm
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, extdev-interview, |  Actual Points:
  tor-03-unspecified-201612, tbb-wants   |
Parent ID:  #9675| Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Replying to [comment:9 nickm]:
 > I'm okay with doing an in-tor solution for this if you decide one is
 necessary; just let me know.  It would probably involve adding a log type
 that lets you store the last N kb of log messages in a queue, and later
 query them via the control port.

 For historical context, check out #6938 where we built something quite
 similar. So a lot of the structure for this goal already exists, should we
 choose to proceed.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21953 [Core Tor/Tor]: Dealing with Tor hardening on Windows properly

[Tor Bug Tracker & Wiki]

#21953: Dealing with Tor hardening on Windows properly
--+
 Reporter:  cypherpunks   |  Owner:
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  030-backport  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+

Comment (by tom):

 I can review for Windows.

 Patch is good hygiene and worth taking, but it's not going to radically
 improve tor's security.

 As noted, HeapEnableTerminationOnCorruption is enabled by default in
 Win8+.

 PROCESS_DEP_DISABLE_ATL_THUNK_EMULATION I do not believe is needed because
 we're not using ATL library/framework stuff. But it's fine to have, and
 like I said, good hygiene.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22204 [Core Tor/Tor]: I can't list a relay in my EntryNodes if it doesn't have the Guard flag

[Tor Bug Tracker & Wiki]

#22204: I can't list a relay in my EntryNodes if it doesn't have the Guard flag
-+
 Reporter:  arma |  Owner:  nickm
 Type:  defect   | Status:  accepted
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.0.6
 Severity:  Normal   | Resolution:
 Keywords:  030-backport regression  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

 * owner:   => nickm
 * status:  new => accepted


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

Re: [tor-bugs] #21117 [Core Tor/Tor]: can't migrate onion services to single-hop onion services

[Tor Bug Tracker & Wiki]

#21117: can't migrate onion services to single-hop onion services
--+
 Reporter:  weasel|  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.9.8
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, single-onion  |  Actual Points:  0.1
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:   => teor
 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.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] #13339 [Core Tor/Tor]: Prop140: Complete Consensus diffs / Merge GSoC project

[Tor Bug Tracker & Wiki]

#13339: Prop140: Complete Consensus diffs / Merge GSoC project
-+-
 Reporter:  mvdan|  Owner:  nickm
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  High |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:
 Keywords:  gsoc, merge, tor-client, prop140,|  Actual Points:
  027-triaged-1-in, 028-triaged, pre028-patch,   |
  tor-dos, low-bandwidth, nickm- |
  deferred-20160905, tor-03-unspecified-201612,  |
  sponsor4, TorCoreTeam201703|
Parent ID:   | Points:  parent
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-
Changes (by nickm):

 * status:  assigned => needs_review


Comment:

 We can close this when its children are closed. :)

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

[Tor Bug Tracker & Wiki]

Batch modification to #21031, #21522 by nickm:
milestone to Tor: 0.3.2.x-final

Comment:
A better refactoring here will need to wait for 0.3.2

--
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] #21215 [Core Tor/Tor]: Lower the directory overhead for low-bandwidth clients

[Tor Bug Tracker & Wiki]

#21215: Lower the directory overhead for low-bandwidth clients
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  project   | Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sponsor4  |  Actual Points:
Parent ID:| Points:  parent
 Reviewer:|Sponsor:  Sponsor4
--+
Changes (by nickm):

 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.2.x-final


Comment:

 A lot of this has happened in 0.3.1; the rest will go in 0.3.2

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

Re: [tor-bugs] #20534 [Core Tor/Tor]: Revise hard-coded download schedules

[Tor Bug Tracker & Wiki]

#20534: Revise hard-coded download schedules
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  regression, CoreTorTeam201611,   |  Actual Points:
  triaged-out-20170124, 031-reach|
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.2.x-final


Comment:

 I'm not going to be able to get this right in 0.3.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] #22172 [Core Tor/Tor]: prop140: What to do when a diff fails to apply?

[Tor Bug Tracker & Wiki]

#22172: prop140: What to do when a diff fails to apply?
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #13339| Points:
 Reviewer:|Sponsor:  Sponsor4
--+

Comment (by nickm):

 I think we can treat a non-applying diff as if we had downloaded a bogus
 consensus. Rationale: we provided the source SHA3 digest that the diff is
 supposed to apply to; if it doesn't apply, then the cache is deeply
 confused, or we are.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21769 [User Experience/Website]: CSP blocks Tor Debian Instructions' Javascript

[Tor Bug Tracker & Wiki]

#21769: CSP blocks Tor Debian Instructions' Javascript
-+--
 Reporter:  tom  |  Owner:  hiro
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by arma):

 Replying to [comment:7 hiro]:
 > This is actually happening in other pages. Ex:
 > https://www.torproject.org/getinvolved/volunteer.html.en
 > https://www.torproject.org/index.html.en

 How could that be the case, since those pages don't have javascript in
 them? Or am I wrong?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21940 [Applications/Tor Browser]: OSX updater: consider disabling privilege escalation

[Tor Bug Tracker & Wiki]

#21940: OSX updater: consider disabling privilege escalation
-+-
 Reporter:  mcs  |  Owner:  mcs
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must,  |  Actual Points:
  TorBrowserTeam201705R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * status:  assigned => needs_review
 * keywords:  ff52-esr, tbb-7.0-must, TorBrowserTeam201705 => ff52-esr,
 tbb-7.0-must, TorBrowserTeam201705R


Comment:

 Here is the patch:
 https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug21940-01&id=9d7f583bd7aeea524c9ca0f8c83016b348e11e37
 Some of the changes involve C++ code, so two reviews are needed. The patch
 is fairly small though.

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

Re: [tor-bugs] #22112 [Metrics/Metrics website]: Replace torperf.csv with onionperf.csv

[Tor Bug Tracker & Wiki]

#22112: Replace torperf.csv with onionperf.csv
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Cool!  Just one more thing: do you feel strongly about calling the new
 data file [https://trac.torproject.org/projects/tor/ticket/22122#comment:7
 torperf2.csv rather than onionperf.csv]?  If not, I'd rename it.  Sorry
 for mixing tickets here, but that question is what remains before we can
 call this stable.  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] #22228 [Metrics/metrics-lib]: Deprecate setFailUnrecognizedDescriptorLines()

[Tor Bug Tracker & Wiki]

#8: Deprecate setFailUnrecognizedDescriptorLines()
-+---
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

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


Comment:

 Great, thanks for looking!  Tweaked a single word in the change log and
 pushed to master.  Closing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22217 [Metrics/metrics-lib]: Parse new padding-counts lines

[Tor Bug Tracker & Wiki]

#22217: Parse new padding-counts lines
-+---
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * status:  accepted => needs_review
 * cc: Samdney (added)


Comment:

 Please find [https://gitweb.torproject.org/user/karsten/metrics-
 lib.git/commit/?h=task-22217&id=a3639005adc04820fa8bad6a4c7530f7c53a9d73
 this commit in my task-22217 branch].  I hear Samdney would like to take
 this one.  Samdney, whatever you find, please just comment on this ticket
 and write down your thoughts or questions.  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] #22112 [Metrics/Metrics website]: Replace torperf.csv with onionperf.csv

[Tor Bug Tracker & Wiki]

#22112: Replace torperf.csv with onionperf.csv
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/Metrics website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

 * status:  needs_review => merge_ready


Comment:

 Replying to [comment:3 karsten]:
 >[snip]
 > Well, I'm not a big fan of how we used string constants there, because
 they give a false sense of code robustness by protecting against typos,
 but they cannot be used in prepared statements and also don't provide any
 type safety.  And at least during development I ran much more often into
 the latter two issues than into typos.  But maybe you're right and string
 constants are better than nothing.  Changed.

 Thanks!  It is mostly the 'better than nothing' reason and also more
 readability (using the same constant is clearly saying these strings mean
 the same).  Of course all the improvements for db access will need their
 own little project.

 >
 > Please find [https://gitweb.torproject.org/karsten/metrics-
 web.git/log/?h=task-22112 my task-22112 branch] with the fixes.  What do
 you think?  Ready to remove the beta label and call this done? :)

 Yep, ready for non-beta.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21940 [Applications/Tor Browser]: OSX updater: consider disabling privilege escalation

[Tor Bug Tracker & Wiki]

#21940: OSX updater: consider disabling privilege escalation
-+-
 Reporter:  mcs  |  Owner:  mcs
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must,  |  Actual Points:
  TorBrowserTeam201705   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * owner:  tbb-team => mcs
 * cc: arthuredelstein, boklm (added)
 * status:  new => assigned


Comment:

 Replying to [comment:7 gk]:
 > So, do we think the risk of privilege escalation support is worth it? If
 not, how much work would it be to "back" this out?

 Sorry for the delayed response. Kathy and I have been working on a patch
 to disable the OSX elevation code, similar to what we do on Windows (a
 complete back out of the Mozilla patches that added this feature would be
 quite painful). Changing the code as little as possible while still
 achieving the correct error reporting behavior turned out to be a little
 tricky, but I think we have a good patch now. We will post it here as soon
 as we finish one more round of testing.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22231 [Core Tor/Tor]: prevent recurrence of CID 1397192

[Tor Bug Tracker & Wiki]

#22231: prevent recurrence of CID 1397192
--+--
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nickm):

 Looks good; tests pass; merging!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22231 [Core Tor/Tor]: prevent recurrence of CID 1397192

[Tor Bug Tracker & Wiki]

#22231: prevent recurrence of CID 1397192
--+
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => closed
 * resolution:   => fixed
 * milestone:  Tor: unspecified => Tor: 0.3.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] #22231 [Core Tor/Tor]: prevent recurrence of CID 1397192

[Tor Bug Tracker & Wiki]

#22231: prevent recurrence of CID 1397192
--+--
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by catalyst):

 * status:  new => needs_review


Comment:

 Proposed fix in https://gitlab.com/argonblue/tor/merge_requests/12

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21557 [Applications/Tor Browser]: fteproxy failed to launch

[Tor Bug Tracker & Wiki]

#21557: fteproxy failed to launch
--+---
 Reporter:  djgend|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by djgend):

 UPDATED, i encountered this problem once again, and figured out that its
 not regarding about the path variable as mentioned above. Its simply need
 to change the line "TorBrowser\Tor\PluggableTransports\fteproxy" to
 "PluggableTransports\fteproxy" within torrc-defaults, then everything
 works like a charm. Nothing need to be entered to the cmd.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22231 [Core Tor/Tor]: prevent recurrence of CID 1397192

[Tor Bug Tracker & Wiki]

#22231: prevent recurrence of CID 1397192
--+--
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by nickm):

 Agreed; we shouldn't call tt_assert() or any of its kin in a done: block.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22231 [Core Tor/Tor]: prevent recurrence of CID 1397192

[Tor Bug Tracker & Wiki]

#22231: prevent recurrence of CID 1397192
--+--
 Reporter:  catalyst  |  Owner:  catalyst
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Coverity found a possible double free in CID 1397192, which dgoulet
 dismissed as a False Positive.  I think I found the logic by which
 Coverity considered a double free possible.  The `done` block in
 `test_intro_point_registration()` has some calls to `tt_assert()` that can
 jump backwards if the assertion fails, causing a double free in that
 unlikely event.

 The block that tests `hs_circuitmap_free_all()` should probably be in a
 helper function with its own `done` label that doesn't lead to a double
 free if the assertion fails.

 For reasons I don't understand, it looks like the renames in
 6bacc3c7a88509043613d3bc29534c0ecf8803b1 caused Coverity to no longer see
 this potential double free, even though it looks like it changed nothing
 relevant.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #17598 [Core Tor/Tor]: Trace cell queue times in Tor to measure Tor application "congestion"

[Tor Bug Tracker & Wiki]

#17598: Trace cell queue times in Tor to measure Tor application "congestion"
-+-
 Reporter:  robgjansen   |  Owner:  pastly
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  kist, tor-03-unspecified-201612  |  Actual Points:
Parent ID:  #12541   | Points:  4
 Reviewer:   |Sponsor:
-+-
Changes (by pastly):

 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.2.x-final


Comment:

 This will not make it into 031. In addition to the above bug, it does not
 trace cells that originate at an exit (and I suspect cells that originate
 at the OP).

 It only traces cells that come in from
 `connection_or_process_cells_from_inbuf`. It probably should trace cells
 that are created in `relay_send_command_from_edge_` too.

 This is a big deal for our needs.

 Maybe tracing cells that don't go through the inbuf and start already
 halfway through Tor is different enough that they should be logged
 differently. For us right now, I don't think the difference is important
 and we really want the data from the additional cells.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21766 [Applications/Tor Browser]: Tor Browser based on ESR52 with e10s enabled crashed while trying to download a file

[Tor Bug Tracker & Wiki]

#21766: Tor Browser based on ESR52 with e10s enabled crashed while trying to
download a file
-+-
 Reporter:  gk   |  Owner:  mcs
 Type:  defect   | Status:
 |  assigned
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must-alpha, tbb-   |  Actual Points:
  e10s, tbb-crash, TorBrowserTeam201705  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by mcs):

 Replying to [comment:24 gk]:
 > While pondering #21886 I was wondering whether it would help to just get
 rid of the observer idea and leave the extension out of the picture: could
 we just show a dialog at places where we are currently using the observer
 mechanism?

 We could try that, but I think the main problem is that a modal dialog is
 displayed (as a cypherpunk mentioned somewhere). With e10s enabled, it
 seems that while a modal dialog is open events related to the IPC
 mechanism are not handled correctly. This causes the chrome process to
 kill the content process (to the user, this appears as a tab crash).
 Therefore I think we will still have a problem if we move the dialog into
 the browser/C++ code.

 Mozilla does show dialogs during a download, but they are not modal and
 they do not block the network activity (so, for example, the download
 proceeds while the user is answering the "What would you like to do with
 this file? open/save" prompt. I assume we want to stop the network
 activity as in Tor Browser 6.5.2.

 The most promising approach seems to be to suspend and then resume the
 request, but when e10s is enabled that does not work reliably when we try
 it from any of the obvious locations, e.g., not from `DoContent()` inside
 `uriloader/exthandler/nsExternalHelperAppService.cpp`, not from
 `OnStartRequest()`, not inside the first call to `OnDataAvailable()`.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #10059 [Core Tor/Tor]: capture tor log messages before control connection is opened

[Tor Bug Tracker & Wiki]

#10059: capture tor log messages before control connection is opened
-+-
 Reporter:  mcs  |  Owner:  nickm
 Type:  defect   | Status:  new
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tbb-usability, extdev-interview, |  Actual Points:
  tor-03-unspecified-201612, tbb-wants   |
Parent ID:  #9675| Points:
 Reviewer:   |Sponsor:
-+-
Changes (by catalyst):

 * priority:  Medium => Low


Comment:

 Lowering priority for now; if #21542 turns out to not be suitable, we can
 bump it back up.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #1623 [Applications/Tor Browser]: Block protocol handler enumeration

[Tor Bug Tracker & Wiki]

#1623: Block protocol handler enumeration
-+-
 Reporter:  mikeperry|  Owner:  tbb-team
 Type:  enhancement  | Status:  new
 Priority:  High |  Milestone:  TorBrowserBundle
Component:  Applications/Tor |  2.3.x-stable
  Browser|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting,  |  Actual Points:
  tbb-torbutton  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by tom):

 * severity:  Blocker => Normal


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #1623 [Applications/Tor Browser]: Block protocol handler enumeration

[Tor Bug Tracker & Wiki]

#1623: Block protocol handler enumeration
-+-
 Reporter:  mikeperry|  Owner:  tbb-team
 Type:  enhancement  | Status:  new
 Priority:  High |  Milestone:  TorBrowserBundle
Component:  Applications/Tor |  2.3.x-stable
  Browser|Version:
 Severity:  Blocker  | Resolution:
 Keywords:  tbb-fingerprinting,  |  Actual Points:
  tbb-torbutton  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by tom):

 * severity:   => Blocker


Comment:

 We ran across this in the mozilla bugtracker, and Jonathan updated the POC
 to work again: https://bugzilla.mozilla.org/show_bug.cgi?id=680300#c5

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22149 [Core Tor/Tor]: prop140: Update dir-spec with prop140 protocols

[Tor Bug Tracker & Wiki]

#22149: prop140: Update dir-spec with prop140 protocols
---+
 Reporter:  nickm  |  Owner:  nickm
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorCoreTeam201705  |  Actual Points:  .3
Parent ID:  #13339 | Points:  .3
 Reviewer: |Sponsor:  Sponsor4
---+

Comment (by catalyst):

 Looks reasonable to me at first glance.  I haven't exhaustively checked
 how faithfully the new dir-spec.txt reflects the prop140 content.  I just
 noticed that the following diff chunk seems like a possible typo, though.

 {{{
 @@ -216,7 +217,7 @@ Status: Accepted

The following parameters govern how relays and clients use this
 protocol.

 - min-consensuses-age-to-cache-for-diff
 +b min-consensuses-age-to-cache-for-diff
 (min 0, max 744, default 6)
   max-consensuses-age-to-cache-for-diff
 (min 0, max 8192, default 72)
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22179 [Community/Tor Support]: Website redesign/Support portal: Instructions - Setting up a mirror

[Tor Bug Tracker & Wiki]

#22179: Website redesign/Support portal: Instructions - Setting up a mirror
---+-
 Reporter:  Samdney|  Owner:
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22150 | Points:
 Reviewer: |Sponsor:
---+-

Comment (by linda):

 1. I think that the instructions can live inside a doc/wiki. I would want
 this to be easy to update, which the website is not. We can link to it
 from the website or give a quick link somewhere, but that's all I would
 want.
 2. Good question. I don't know what it takes to set one up, so a detailed
 tutorial would be nice.
 3. Maybe, but we will prioritize the current topics for now (download,
 install, use, common errors), and add more if we have the resources. I
 think it's more important that we get these basic sets of answers out as
 soon as possible and to translate them into different languages.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21752 [Metrics/Atlas]: put "Current Status" under an Android Browser on top

[Tor Bug Tracker & Wiki]

#21752: put "Current Status" under an Android Browser on top
---+--
 Reporter:  toralf |  Owner:  irl
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Minor  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by irl):

 Note to self: #22160 would benefit from 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] #22177 [Core Tor/Tor]: CID 1405875 dead code in test_options_validate_impl() (was: Remove dead code in test_options_validate_impl())

[Tor Bug Tracker & Wiki]

#22177: CID 1405875 dead code in test_options_validate_impl()
--+
 Reporter:  ahf   |  Owner:  catalyst
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Old description:

> Coverity found some dead code in CID 1405875, which we should fix.

New description:

 Coverity found some dead code in CID 1405875, which we should fix.  The
 dead code is to handle an error condition in `config_get_lines()`, which
 we weren't testing.  The short-term fix is to remove the offending code,
 and a longer-term fix is to actually test the relevant error conditions so
 that the dead code would execute.

--

Comment (by catalyst):

 Updated description.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21183 [User Experience]: Basic Usability Issues

[Tor Bug Tracker & Wiki]

#21183: Basic Usability Issues
+-
 Reporter:  ninavizz|  Owner:
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  User Experience |Version:
 Severity:  Normal  | Resolution:
 Keywords:  UX, UI, torbrowser  |  Actual Points:
Parent ID:  #20843  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by linda):

 I don't think we have a specific plan to deploy it, but these do look like
 great changes we want to integrate sometime.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22163 [User Experience/Website]: Make it more obvious how to report security related bugs

[Tor Bug Tracker & Wiki]

#22163: Make it more obvious how to report security related bugs
-+--
 Reporter:  gk   |  Owner:  hiro
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  User Experience/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by linda):

 I'll keep this in mind.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21752 [Metrics/Atlas]: put "Current Status" under an Android Browser on top

[Tor Bug Tracker & Wiki]

#21752: put "Current Status" under an Android Browser on top
---+--
 Reporter:  toralf |  Owner:  irl
 Type:  enhancement| Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Minor  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by irl):

 * status:  reopened => needs_review


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

Re: [tor-bugs] #22217 [Metrics/metrics-lib]: Parse new padding-counts lines

[Tor Bug Tracker & Wiki]

#22217: Parse new padding-counts lines
-+---
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

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


Comment:

 I have a patch, but I want to take another look before putting it here for
 review.  Just saying so that nobody else starts writing a patch 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] #21667 [Core Tor/Tor]: Prop278: Handle new headers in directory.c

[Tor Bug Tracker & Wiki]

#21667: Prop278: Handle new headers in directory.c
+--
 Reporter:  ahf |  Owner:  ahf
 Type:  task| Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, prop278  |  Actual Points:
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by ahf):

 Works for me.

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

Re: [tor-bugs] #21766 [Applications/Tor Browser]: Tor Browser based on ESR52 with e10s enabled crashed while trying to download a file

[Tor Bug Tracker & Wiki]

#21766: Tor Browser based on ESR52 with e10s enabled crashed while trying to
download a file
-+-
 Reporter:  gk   |  Owner:  mcs
 Type:  defect   | Status:
 |  assigned
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Critical | Resolution:
 Keywords:  ff52-esr, tbb-7.0-must-alpha, tbb-   |  Actual Points:
  e10s, tbb-crash, TorBrowserTeam201705  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by gk):

 While pondering #21886 I was wondering whether it would help to just get
 rid of the observer idea and leave the extension out of the picture: could
 we just show a dialog at places where we are currently using the observer
 mechanism?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21667 [Core Tor/Tor]: Prop278: Handle new headers in directory.c

[Tor Bug Tracker & Wiki]

#21667: Prop278: Handle new headers in directory.c
+--
 Reporter:  ahf |  Owner:  ahf
 Type:  task| Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, prop278  |  Actual Points:
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by nickm):

 Yes, that sounds good.  Maybe srv_meth_pref_streaming ?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21667 [Core Tor/Tor]: Prop278: Handle new headers in directory.c

[Tor Bug Tracker & Wiki]

#21667: Prop278: Handle new headers in directory.c
+--
 Reporter:  ahf |  Owner:  ahf
 Type:  task| Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, prop278  |  Actual Points:
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by ahf):

 That will arrive in a separate commit; working on that right now while
 having pulled your changes from the `compress_consensus_more_ways` branch
 in.

 Do you agree on having a variable like `srv_meth_pref_precompressed` where
 we define the available order, excluding LZMA, for non-precompressed
 documents?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22213 [Core Tor/Tor]: ROUTER_ADDED_NOTIFY_GENERATOR unused and can be removed

[Tor Bug Tracker & Wiki]

#22213: ROUTER_ADDED_NOTIFY_GENERATOR unused and can be removed
--+
 Reporter:  arma  |  Owner:
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => closed
 * resolution:   => fixed
 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.1.x-final


Comment:

 Applied

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22223 [Core Tor/Tor]: MyFamily manual page update

[Tor Bug Tracker & Wiki]

#3: MyFamily manual page update
--+
 Reporter:  cypherpunks   |  Owner:
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Minor | Resolution:  fixed
 Keywords:  doc easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Replying to [comment:5 cypherpunks]:
 > This is still in the man page even though "node" has been replaced by
 "fingerprint" so it is no longer needed:

 I think it's still useful; there are lots of old configurations out there
 where people will do it wrong.

 > Still no examples for relay operators.

 Right: Like I said, "I've tried to apply it, though I couldn't get the
 examples to look okay; maybe a unified diff would make them clearer"

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21859 [Core Tor/Tor]: prop224: Rendezvous circuit e2e crypto

[Tor Bug Tracker & Wiki]

#21859: prop224: Rendezvous circuit e2e crypto
-+
 Reporter:  dgoulet  |  Owner:  asn
 Type:  enhancement  | Status:  assigned
 Priority:  Very High|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #21888   | Points:  9
 Reviewer:  dgoulet  |Sponsor:  SponsorR-must
-+
Changes (by asn):

 * status:  needs_revision => assigned


Comment:

 OK pushed branch `bug21859_v2`, which includes all of David's review
 fixes.

 Putting ticket in neutral state. Not sure if this should be in
 `needs_review` as it's 0.3.2 material and part of #21888.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18718 [Metrics/metrics-lib]: remove last impl. dependency from api

[Tor Bug Tracker & Wiki]

#18718: remove last impl. dependency from api
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:  duplicate
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * milestone:  metrics-lib 2.0.0 =>


Comment:

 removing milestone b/c this is a duplication.
 (seem I cannot batch change 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] #17831 [Metrics/metrics-lib]: investigate, if using java.nio would improve metrics-lib

[Tor Bug Tracker & Wiki]

#17831: investigate, if using java.nio would improve metrics-lib
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  closed
 Priority:  Low  |  Milestone:
Component:  Metrics/metrics-lib  |Version:
 Severity:  Minor| Resolution:  duplicate
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * milestone:  metrics-lib 2.0.0 =>


Comment:

 removing milestone b/c this is a duplication.
 (seem I cannot batch change 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] #17831 [Metrics/metrics-lib]: investigate, if using java.nio would improve metrics-lib

[Tor Bug Tracker & Wiki]

#17831: investigate, if using java.nio would improve metrics-lib
-+---
 Reporter:  iwakeh   |  Owner:  karsten
 Type:  enhancement  | Status:  closed
 Priority:  Low  |  Milestone:  metrics-lib 2.0.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Minor| Resolution:  duplicate
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

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


Comment:

 Ticket #20395 is going to use NIO.  This ticker was meant as a placeholder
 and now there is a concrete issue.
 Closing.
 Please re-open, if I missed anything.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22228 [Metrics/metrics-lib]: Deprecate setFailUnrecognizedDescriptorLines()

[Tor Bug Tracker & Wiki]

#8: Deprecate setFailUnrecognizedDescriptorLines()
-+---
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by iwakeh):

 * status:  needs_review => merge_ready


Comment:

 Looks good.
 Merge ready!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22216 [Metrics/CollecTor]: Decide whether to sanitize padding-counts lines

[Tor Bug Tracker & Wiki]

#22216: Decide whether to sanitize padding-counts lines
---+-
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  needs_review
 Priority:  High   |  Milestone:  CollecTor 1.2.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

 * status:  new => needs_review


Comment:

 I believe we can just copy over these lines.  Please find
 [https://gitweb.torproject.org/karsten/metrics-
 db.git/commit/?h=task-22216&id=1e80ef7fb995058d0eb1995ed72413111a58e08a
 the last commit in my task-22216 branch].

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21871 [Core Tor/Tor]: prop224: Change descriptor format for legacy encryption key

[Tor Bug Tracker & Wiki]

#21871: prop224: Change descriptor format for legacy encryption key
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #21888   | Points:  3
 Reviewer:  asn  |Sponsor:  SponsorR-must
-+
Changes (by nickm):

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


Comment:

 Tests pass now.  Merging.  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] #21871 [Core Tor/Tor]: prop224: Change descriptor format for legacy encryption key

[Tor Bug Tracker & Wiki]

#21871: prop224: Change descriptor format for legacy encryption key
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #21888   | Points:  3
 Reviewer:  asn  |Sponsor:  SponsorR-must
-+
Changes (by dgoulet):

 * status:  needs_revision => needs_review


Comment:

 Oh my that's embarrassing... Sorry about that!

 Fixup commit `b8452e20` in `ticket21871_031_03`

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22230 [Internal Services/Tor Sysadmin Team]: Please add iwakeh to the collector group

[Tor Bug Tracker & Wiki]

#22230: Please add iwakeh to the collector group
-+
 Reporter:  karsten  |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


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

Re: [tor-bugs] #20319 [Internal Services/Tor Sysadmin Team]: set HPKP headers on onionoo

[Tor Bug Tracker & Wiki]

#20319: set HPKP headers on onionoo
-+-
 Reporter:  weasel   |  Owner:  tpa
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by weasel):

 * status:  merge_ready => needs_revision


Comment:

 Unfortunately, again, not useful.  We don't want to hardcode keys in the
 varnish config.  This needs to come out of config management that knows
 the key and backup key hashes.  It seems unlikely you can help in this
 matter, and all you're doing here is make the ticket noisy and useless.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22230 [Internal Services/Tor Sysadmin Team]: Please add iwakeh to the collector group

[Tor Bug Tracker & Wiki]

#22230: Please add iwakeh to the collector group
-+-
 Reporter:  karsten  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 {{{
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Please add iwakeh to the collector group, so that they can log in to
 colchicifolium.torproject.org and corsicum.torproject.org.  Thanks!
 -BEGIN PGP SIGNATURE-
 Comment: GPGTools - http://gpgtools.org

 iQEcBAEBCAAGBQJZFFcAAAoJEO85p7J7H00Bb48IALO+iwl5hUbBUzlo1/iGZW3U
 +6NhSx4LaKWruv8m0d8GCXvrJFqlH4aZ60otTX7FQkGR4Z41q17wzNDvJbiZSjBw
 iIGOOa8MWHIdVSm6T51hBSD34o/4TfUs+KgLpUo09/nRlJIhyxAxy/M8edbQ4OWs
 hxKANgcFwtWsd8IVxyBJVrZ+4H0JzY3DVUEjRXbbzLxgLVqpU66AWIagpjzv99lq
 AUKZHuwS2OoWFuE0Ij8adH19UBa4rFsGm3NiUEfMIDD8f0TFs2SbqxasGOgicmms
 99VRU9PKyT6TfLjaqXdbwFAy72n8ejrep6FnRsda3gq/KCJN1dP/GP109Q3IysI=
 =G8cN
 -END PGP SIGNATURE-
 }}}

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

Re: [tor-bugs] #22186 [Internal Services/Tor Sysadmin Team]: Apache HTTP Server

[Tor Bug Tracker & Wiki]

#22186: Apache HTTP Server
-+-
 Reporter:  sainslie |  Owner:  tpa
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by weasel):

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


Comment:

 As explained previously, the way these proposed changes are provided are
 not helpful.  They cannot be applied to our setup this way.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22186 [Internal Services/Tor Sysadmin Team]: Apache HTTP Server

[Tor Bug Tracker & Wiki]

#22186: Apache HTTP Server
-+-
 Reporter:  sainslie |  Owner:  tpa
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sainslie):

 * status:  closed => reopened
 * cc: scott@… (added)
 * resolution:  invalid =>


Comment:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 I rebuilt the Apache HTTP Server Content Security Policy for the
 organization's canonical domain name. I rebuilt it because it's outdated
 and unsafe. I added Cascading Style Sheets Secure Hash Algorithm 2 output.
 -BEGIN PGP SIGNATURE-

 iQIcBAEBCgAGBQJZFFWBAAoJEM18vpeSzTzCM3AQAJG6OVonJdbg+LMSARmi5BkW
 q3xGDDzwQiJ3QtwugXOWocv8GjIvpupX6ACkK7H+gtiQ/i/VolUZwQur49jQEzWN
 zuKpft+fIItHtEE05wRxfhTnD1XDDhiWawU0vOsosHIzBMZlNHkD18ZpSSoBXCJI
 2y9uaI0siZcDx1BJzMRW2Lmia8QrXJtnvoK9boAtFeN+lyT8NnJARyeDfPz4PID+
 wvFvbebvRKCt9M82f8FngMdigykO31Qus8kP3nuAso//MVmcXEQWTcHcU+ibG9qK
 ddyQgBPdP6YXuRhM00lcFRCHJsyKw3D+MvzA+WBJ4vcIGQ757J9cJpS1x2e5mV3O
 OJGiYXtpJ2KMrqNGEAwIb48QQJA2vwdgirwWJ97pq0DSAer8VnPozJxOhsGYZ5yR
 b2dimt4OxsHt1zkJeZ8OlFciXA/4HOK1tU2Z+Szfw5/a22bdpumdpC2dUkAONnm6
 Vu2uaJ51M4ednBtvnM53aRSiGztMa/2ATGe4c6ukmUEPXmvoDAnbEPzWTf53XlCm
 LYNzrYW+8HpUjQKgQ91uL4EEegjMeKtJ+6CqQ1ejBoObgBy/fom06fpCVKIuyOwc
 9oT125mYZn0uXVQvLuFTJK13bxciOy9XxyjCARqi1pdBHPOONEvuH/Vq95KEfMXz
 AOey1dbbWWQVwWZLMNGK
 =i2fD
 -END PGP SIGNATURE-

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

Re: [tor-bugs] #21667 [Core Tor/Tor]: Prop278: Handle new headers in directory.c

[Tor Bug Tracker & Wiki]

#21667: Prop278: Handle new headers in directory.c
+--
 Reporter:  ahf |  Owner:  ahf
 Type:  task| Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, prop278  |  Actual Points:
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 I added some comments there, but one thing I don't understand -- when does
 this ever actually serve compressed consensus documents correctly?  It
 changes streaming compression, but it doesn't serve the right
 spooled_resource_t objects for cached consensuses. Is that coming in a
 separate commit?

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

Re: [tor-bugs] #22223 [Core Tor/Tor]: MyFamily manual page update

[Tor Bug Tracker & Wiki]

#3: MyFamily manual page update
--+
 Reporter:  cypherpunks   |  Owner:
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Minor | Resolution:  fixed
 Keywords:  doc easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 This is still in the man page even though "node" has been replaced by
 "fingerprint" so it is no longer needed:
 {{{
 When listing a node, it's better to list it by fingerprint than by
 nickname: fingerprints are more reliable.
 }}}

 
https://gitweb.torproject.org/tor.git/commit/?id=18e59fdc1cfa4757c8b440a344b11bd521143a00

 Still no examples for relay operators.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22006 [Core Tor/Tor]: prop224: Validate ed25519 pubkeys to remove torsion component

[Tor Bug Tracker & Wiki]

#22006: prop224: Validate ed25519 pubkeys to remove torsion component
+
 Reporter:  asn |  Owner:  asn
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs prop224 ed25519  |  Actual Points:
Parent ID:  #21888  | Points:
 Reviewer:  |Sponsor:  SponsorR-can
+
Changes (by asn):

 * status:  needs_revision => needs_review


Comment:

 OK pushed a fixup commit that adds the `ALIGN` calls that Yawning
 suggested in the donna code. It seems to be a common idiom in the donna
 code so it should be the right thing. I tried to reproduce the SSE2 crash
 but I couldn't repro it. Yawning said that he didn't see the crash
 himself, but he thought that it would crash because of the lack of `ALIGN`
 calls.

 So now, the last issue is whether we want our validation (which includes a
 scalar mult) running 7k times everytime we receive a consensus, and also
 everytime we receive a descriptor etc. It's currently the case, since
 [https://lists.torproject.org/pipermail/tor-dev/2017-April/012230.html Ian
 suggested we do so] and he said the validation is not particularly
 expensive. I tested it on my laptop and I didn't notice any speed
 difference from validating 7k ed25519 keys when receiving the consensus,
 however perhaps this might be more battery-drain in mobile devices, etc.
 Nick any opinions here?

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

Re: [tor-bugs] #22227 [Applications/Tor Browser]: Netmonitor Gives the Wrong Remote Address

[Tor Bug Tracker & Wiki]

#7: Netmonitor Gives the Wrong Remote Address
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by yawning):

 The client's tor instance doesn't actually ever see the IP address when it
 connects to a FQDN, which is why `0.0.0.0` is returned.  So this would be
 moderately annoying to fix, because it's an extra SOCKS request at a
 minimum (assuming `RESOLVE` works as expected).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22205 [Applications/Tor Browser Sandbox]: Figure out how to fix `crypto/tls`.

[Tor Bug Tracker & Wiki]

#22205: Figure out how to fix `crypto/tls`.
--+-
 Reporter:  yawning   |  Owner:  yawning
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser Sandbox  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by yawning):

 My AES package has a constant time GCM-AES, but replacing the one that
 `crypto/tls` uses requires forking the package.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22223 [Core Tor/Tor]: MyFamily manual page update

[Tor Bug Tracker & Wiki]

#3: MyFamily manual page update
--+
 Reporter:  cypherpunks   |  Owner:
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Minor | Resolution:  fixed
 Keywords:  doc easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #22223 [Core Tor/Tor]: MyFamily manual page update

[Tor Bug Tracker & Wiki]

#3: MyFamily manual page update
--+
 Reporter:  cypherpunks   |  Owner:
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Minor | Resolution:
 Keywords:  doc easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 I've tried to apply it, though I couldn't get the examples to look okay;
 maybe a unified diff would make them clearer?  I also edited the text a
 little.  (See 18e59fdc1cfa47)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22229 [Applications/Tor Messenger]: Compile Linux 64bits versions of Tor Messenger with Selfrando?

[Tor Bug Tracker & Wiki]

#9: Compile Linux 64bits versions of Tor Messenger with Selfrando?
+-
 Reporter:  blockflare  |  Owner:
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+-

Comment (by arlolra):

 Sure, but let's say it depends on #22194

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22177 [Core Tor/Tor]: Remove dead code in test_options_validate_impl()

[Tor Bug Tracker & Wiki]

#22177: Remove dead code in test_options_validate_impl()
--+
 Reporter:  ahf   |  Owner:  catalyst
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Looks fine; tests pass.  Merged!  Feel free to edit ticket as you see fit.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #18100 [Core Tor/Tor]: src/or/connection_edge.c typo

[Tor Bug Tracker & Wiki]

#18100: src/or/connection_edge.c typo
-+-
 Reporter:  jirib|  Owner:
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.1.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.9
 Severity:  Normal   | Resolution:
 Keywords:  isaremoved, nickwants029, lorax, |  Actual Points:
  tor-03-unspecified-201612  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Hm.  Okay, I will need some confirmation about what to actually merge and
 what has actually been tested.  Teor's branch?  The small patch from
 d4fq0fQAgoJ above?  Both? Neither?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21871 [Core Tor/Tor]: prop224: Change descriptor format for legacy encryption key

[Tor Bug Tracker & Wiki]

#21871: prop224: Change descriptor format for legacy encryption key
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #21888   | Points:  3
 Reviewer:  asn  |Sponsor:  SponsorR-must
-+
Changes (by nickm):

 * status:  merge_ready => needs_revision


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #21871 [Core Tor/Tor]: prop224: Change descriptor format for legacy encryption key

[Tor Bug Tracker & Wiki]

#21871: prop224: Change descriptor format for legacy encryption key
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:  #21888   | Points:  3
 Reviewer:  asn  |Sponsor:  SponsorR-must
-+

Comment (by nickm):

 Spec merged.

 Tried to merge ticket21871_031_03, but the unit tests fail for me; do they
 work for you?

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

Re: [tor-bugs] #21642 [Core Tor/Tor]: Prop275: Eliminate "published" times from microdescriptor consensus

[Tor Bug Tracker & Wiki]

#21642: Prop275: Eliminate "published" times from microdescriptor consensus
+--
 Reporter:  nickm   |  Owner:  nickm
 Type:  enhancement | Status:  assigned
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorCoreTeam201703, review-group-17  |  Actual Points:  .5
Parent ID:  | Points:  2
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by nickm):

 * status:  merge_ready => assigned
 * milestone:  Tor: 0.3.1.x-final => Tor: 0.3.2.x-final


Comment:

 Deferring the rest.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22221 [Core Tor/Tor]: CID 1405983 test_channelpadding.c dead code

[Tor Bug Tracker & Wiki]

#1: CID 1405983 test_channelpadding.c dead code
--+
 Reporter:  catalyst  |  Owner:
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Merged; 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

[tor-bugs] #22229 [Applications/Tor Messenger]: Compile Linux 64bits versions of Tor Messenger with Selfrando?

[Tor Bug Tracker & Wiki]

#9: Compile Linux 64bits versions of Tor Messenger with Selfrando?
+-
 Reporter:  blockflare  |  Owner:
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Messenger  |Version:
 Severity:  Normal  |   Keywords:
Actual Points:  |  Parent ID:
   Points:  |   Reviewer:
  Sponsor:  |
+-
 Selfrando has already been (finally!) integrated into alpha Linux 64bits
 versions of the Tor Browser
 https://trac.torproject.org/projects/tor/ticket/20683

 So why not for Tor Messenger?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #22228 [Metrics/metrics-lib]: Deprecate setFailUnrecognizedDescriptorLines()

[Tor Bug Tracker & Wiki]

#8: Deprecate setFailUnrecognizedDescriptorLines()
-+---
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:  metrics-lib 1.7.0
Component:  Metrics/metrics-lib  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

 * status:  new => needs_review


Comment:

 Please review [https://gitweb.torproject.org/user/karsten/metrics-
 lib.git/commit/?h=task-8&id=e23af05b7952147a6ae127cf494803350fc5c073
 this commit in my task-8 branch].

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