[tor-bugs] #25096 [Core Tor/Tor]: Bump up NumNTorsPerTAP to squeeze out v2 onion service traffic?

[Tor Bug Tracker & Wiki]

#25096: Bump up NumNTorsPerTAP to squeeze out v2 onion service traffic?
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Right now the consensus is voting NumNTorsPerTAP=100, i.e. relays will
 handle one tap handshake for every 100 ntor handshakes they handle. We put
 this feature into place during the 2013 botnet overload (#9574).

 TAP handshakes are used by obsolete clients (we don't know how many of
 these remain, but I think it might be quite few), and for v2 onion service
 clients reaching intro points, and for v2 onion services reaching
 rendezvous points.

 With the recent overload that has to do with v2 onion services, the TAP
 frequency has gone up, e.g.
 {{{
 Jan 30 11:46:23.580 [notice] Circuit handshake stats since last time:
 1350439/1350439 TAP, 68743431/68743431 NTor.
 Jan 30 17:46:23.592 [notice] Circuit handshake stats since last time:
 1183340/1183340 TAP, 71590118/71590118 NTor.
 Jan 30 23:50:19.525 [notice] Circuit handshake stats since last time:
 1069004/1069004 TAP, 72357977/72357977 NTor.
 }}}
 It's still low compared to the NTor frequency, but 1M TAP handshakes per 6
 hours is 46 second per second to my relay.

 (Also note that these log messages don't include stats from client
 connections, because we wanted to leave those out to be cautious about
 client privacy.)

 The key realization here is that we can squeeze down v2 onion service
 usage, by squeezing down the prioritization for TAP handshakes.

 Now, on my relay above, I'm able to handle all of both kinds, so changing
 the ratio will just change which cells get answered first -- and given
 that ntor cells are so much cheaper to answer than tap cells, there could
 be a moderate win there.

 But for relays that can't handle the load, if they're similarly getting
 1:70 ratios, we could potentially have a much bigger impact by cranking up
 the balance. If we got to the point where most of the ntors are handled
 and some of the taps are left unhandled, that seems like a fine balance.

 So: good idea, bad idea? And if good idea, what's a good new number? 500?
 1000?

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

Re: [tor-bugs] #25089 [Applications/Tor Launcher]: Tor bundle: Special characters not escaped in proxy password

[Tor Bug Tracker & Wiki]

#25089: Tor bundle: Special characters not escaped in proxy password
---+--
 Reporter:  ro0ter |  Owner:  tbb-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

 * component:  Core Tor/Tor => Applications/Tor Launcher


Comment:

 Looking at
 {{{
 const kSafeCharRE = /^[\x21\x23-\x7E]*$/;
 }}}
 in `_strEscape()` we should try to see if that's a TorLauncher bug first,
 I guess.

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

Re: [tor-bugs] #25089 [Applications/Tor Launcher]: Tor bundle: Special characters not escaped in proxy password

[Tor Bug Tracker & Wiki]

#25089: Tor bundle: Special characters not escaped in proxy password
---+--
 Reporter:  ro0ter |  Owner:  brade
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

 * cc: brade (removed)
 * status:  new => assigned
 * owner:  tbb-team => brade


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

Re: [tor-bugs] #25087 [Obfuscation/Snowflake]: Snowflake doesn't work on a fresh clean install of Lubuntu 17 64 bits and a fresh clean install of TB 8.0a1

[Tor Bug Tracker & Wiki]

#25087: Snowflake doesn't work on a fresh clean install of Lubuntu 17 64 bits 
and a
fresh clean install of TB 8.0a1
---+---
 Reporter:  cypherpunks|  Owner:  tbb-team
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by gk):

 * cc: dcf, arlolra (added)
 * component:  Applications/Tor Browser => Obfuscation/Snowflake


Comment:

 Hm. Be careful with posting your states file here as it usually contains
 your guard nodes which you might not want to reveal. Adding some Snowflake
 folks that might be able to help debugging this.

 Any idea what is different between those two systems?

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

Re: [tor-bugs] #25092 [Applications/Tor Browser]: check if mailto: protocol is correctly warning in Tor Browser

[Tor Bug Tracker & Wiki]

#25092: check if mailto: protocol is correctly warning in Tor Browser
--+---
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information


Comment:

 We are disabling `mailto:` by setting `network.protocol-
 handler.external.mailto` to `false`. Otherwise the user gets a dialog
 asking which tool they want to use to deal with `mailto:` links. Is that
 what you expect? Or do you want to have some different behavior?

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

Re: [tor-bugs] #25096 [Core Tor/Tor]: Bump up NumNTorsPerTAP to squeeze out v2 onion service traffic?

[Tor Bug Tracker & Wiki]

#25096: Bump up NumNTorsPerTAP to squeeze out v2 onion service traffic?
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Note that there are actually two parts to squeezing down the v2 onion
 service traffic with this approach: there's squeezing down the client
 circuits that are trying to reach the intro points (yay), and squeezing
 down the service circuits that are trying to reach the rend points (boo).
 I say yay for the first one because fewer introductions means less
 response traffic, and boo for the second one because by the time you're at
 that stage of the rendezvous, it sure would be best to just finish it.

 But I don't know of an easy way to distinguish between the two, especially
 before we've processed the create cell, so I am willing to lump them
 together 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] #24898 [Core Tor/Tor]: We have two conflicting notions of channel_is_client()

[Tor Bug Tracker & Wiki]

#24898: We have two conflicting notions of channel_is_client()
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.9.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, 032-backport, |  Actual Points:
  031-backport, 030-backport-maybe-with-21406,   |
  029-backport-maybe-with-21406  |
Parent ID:  #24902   | Points:  0.5
 Reviewer:  teor |Sponsor:
-+-
Changes (by arma):

 * status:  needs_revision => merge_ready


Comment:

 Ok, I added a second commit to my {{{bug24898-029}}} branch that backports
 that part from #22805. I think we are good to go now.

 To be clear, that means commit 4bd208b wants to make it into 0.2.9 and
 0.3.0, and its changes are already present in 0.3.1. Whereas commit
 2076db4 wants to make it into 0.2.9 and 0.3.0 and 0.3.1, and its changes
 are already present in 0.3.2.

 Sorry in advance for the mess Nick. I would just merge it all myself but I
 think I would screw up the "ours" aspects of the conflict handling. :)

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

Re: [tor-bugs] #5915 [Core Tor/Tor]: Write patch to make socks handshakes succeed instantly

[Tor Bug Tracker & Wiki]

#5915: Write patch to make socks handshakes succeed instantly
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client intro performance |  Actual Points:
  application experiment |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-
Changes (by arma):

 * milestone:  Tor: unspecified => Tor: 0.3.4.x-final


Comment:

 I independently re-came up with the idea of using a socksport option, when
 thinking about the issues on #19910. I think it is a good idea.

 I'm moving the milestone up for this one, since it is looking like Tor
 Browser is going to want to remove their hack, and have Tor pick up the
 hack burden.

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

Re: [tor-bugs] #19910 [Applications/Tor Browser]: Rip out optimistic data socks handshake variant (#3875)

[Tor Bug Tracker & Wiki]

#19910: Rip out optimistic data socks handshake variant (#3875)
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201801  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arma):

 Ok, I agree that #5915 is a promising direction to explore.

 Maybe this is also a ticket where we should involve our shiny new UX
 group? It would be smart to look at what sorts of error messages you get
 right now out of Tor Browser when Tor fails to establish a connection to
 the desired destination, and compare those to what we could get if we
 trick Tor Browser into thinking that the connection worked, and then if it
 turns out to fail, have Tor essentially mitm the connection and pretend to
 be the browser giving you an error. In particular, what are the situations
 where this idea would break down (SSL? html5? images and videos? more?),
 and what should we do then?

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

Re: [tor-bugs] #5915 [Core Tor/Tor]: Write patch to make socks handshakes succeed instantly

[Tor Bug Tracker & Wiki]

#5915: Write patch to make socks handshakes succeed instantly
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-client intro performance |  Actual Points:
  application experiment |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * cc: gk (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] #25087 [Obfuscation/Snowflake]: Snowflake doesn't work on a fresh clean install of Lubuntu 17 64 bits and a fresh clean install of TB 8.0a1

[Tor Bug Tracker & Wiki]

#25087: Snowflake doesn't work on a fresh clean install of Lubuntu 17 64 bits 
and a
fresh clean install of TB 8.0a1
---+---
 Reporter:  cypherpunks|  Owner:  tbb-team
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by yawning):

 {{{
 Jan 30 10:45:04.000 [warn] We were supposed to connect to bridge
 '0.0.3.0:1' using pluggable transport 'snowflake', but we can't find a
 pluggable transport proxy supporting 'snowflake'. This can happen if you
 haven't provided a ClientTransportPlugin line, or if your pluggable
 transport proxy stopped running.
 }}}

 Suggests the pluggable transport binary is failing to launch or crashing
 immediately.  I personally suspect the former (and have a hunch about the
 root cause).  Since PT logging sucks (and will continue to suck for the
 foreseeable future, see #9957), the next step will be manually running the
 binary to see if it's at least marginally functional.

 {{{
 $ cd tor-browser_en-US/Browser/TorBrowser/Tor/PluggableTransports
 $ LD_LIBRARY_PATH=/home/blahblahblah/tor-browser_en-
 US/Browser/TorBrowser/Tor/ ./snowflake-client
 }}}

 Note: Adjust the paths as appropriate to match your system.

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

Re: [tor-bugs] #24716 [Core Tor/DirAuth]: Try cranking up cbttestfreq consensus param, to see if it helps the current overload

[Tor Bug Tracker & Wiki]

#24716: Try cranking up cbttestfreq consensus param, to see if it helps the 
current
overload
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 I have backed out the change, so it goes back to cbttestfreq=10, on moria1
 and in the dirauth-git.

 I'm sufficiently convinced that the overload is from onion service
 circuits, not from cbt testing circuits, and while reducing the cbt test
 frequency will indeed reduce overall load on the network, it does so
 exactly by messing up everybody's cbt estimate, which isn't worth it.

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

Re: [tor-bugs] #24768 [Core Tor/DirAuth]: Increase nf_conntimeout_clients to 5 hours

[Tor Bug Tracker & Wiki]

#24768: Increase nf_conntimeout_clients to 5 hours
--+---
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #24716| Points:
 Reviewer:|Sponsor:
--+---

Comment (by arma):

 I think we should close this one as wontfix.

 Unless we were waiting for different information than that? :)

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

Re: [tor-bugs] #24714 [Core Tor/Tor]: rename conn->timestamp_lastwritten to conn->timestamp_lastwritable

[Tor Bug Tracker & Wiki]

#24714: rename conn->timestamp_lastwritten to conn->timestamp_lastwritable
+
 Reporter:  arma|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  easy, refactor  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by valentecaio):

 thanks for your answer, teor, I'll work on it.

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

Re: [tor-bugs] #24714 [Core Tor/Tor]: rename conn->timestamp_lastwritten to conn->timestamp_lastwritable

[Tor Bug Tracker & Wiki]

#24714: rename conn->timestamp_lastwritten to conn->timestamp_lastwritable
+
 Reporter:  arma|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  easy, refactor  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by arma):

 Right -- "writable" is a technical term because it's what select and poll
 say when you ask about a socket.

 But I guess there are other options we could use too, like
 "last_ready_for_write" or "last_write_allowed", if we want to use more
 characters. :)

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

Re: [tor-bugs] #24011 [Core Tor/Tor]: Attempt to open a stream on first hop of circuit

[Tor Bug Tracker & Wiki]

#24011: Attempt to open a stream on first hop of circuit
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-circuit   |  Actual Points:
Parent ID:  #24898| Points:  1
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Did we say here what versions the warnings happened on?

 I see that commit 66aff2d8f3 went into 0.3.2.2-alpha.

 And it looks like af8cadf3 is scheduled for inclusion in 0.3.2.10, which
 isn't out yet?

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

Re: [tor-bugs] #24768 [Core Tor/DirAuth]: Increase nf_conntimeout_clients to 5 hours

[Tor Bug Tracker & Wiki]

#24768: Increase nf_conntimeout_clients to 5 hours
--+---
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #24716| Points:
 Reviewer:|Sponsor:
--+---

Comment (by teor):

 This is the question I'm waiting to see answered:

 Does anyone think we should reduce nf_conntimeout_clients from 1800 to 900
 to try and free up more circuit file descriptors and RAM?

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

Re: [tor-bugs] #24011 [Core Tor/Tor]: Attempt to open a stream on first hop of circuit

[Tor Bug Tracker & Wiki]

#24011: Attempt to open a stream on first hop of circuit
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-circuit   |  Actual Points:
Parent ID:  #24898| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * version:  Tor: 0.3.2.2-alpha => Tor: 0.3.1.1-alpha


Comment:

 This affects 0.3.1.1-alpha through 0.3.2.9. The next 0.3.1 and 0.3.2 have
 the fix from #24898.

 For details, see:
 https://trac.torproject.org/projects/tor/ticket/24898#comment:14

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

Re: [tor-bugs] #24768 [Core Tor/DirAuth]: Increase nf_conntimeout_clients to 5 hours

[Tor Bug Tracker & Wiki]

#24768: Increase nf_conntimeout_clients to 5 hours
--+---
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by teor):

 * parent:  #24716 =>


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

Re: [tor-bugs] #24769 [Core Tor/Tor]: Increase client idle and connection timeouts to reduce network load

[Tor Bug Tracker & Wiki]

#24769: Increase client idle and connection timeouts to reduce network load
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  must-fix-before-033-stable, tor- |  Actual Points:
  client, dos-resistance, 032-backport,  |
  031-backport, 029-backport, 025-backport-  |
  maybe  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:  #24716 =>


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

Re: [tor-bugs] #24770 [Core Tor/Tor]: Change the circuit build time defaults to reduce network load

[Tor Bug Tracker & Wiki]

#24770: Change the circuit build time defaults to reduce network load
+--
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.3.1.1-alpha
 Severity:  Normal  | Resolution:  wontfix
 Keywords:  dos-resistance, tor-client  |  Actual Points:
Parent ID:  #24716  | Points:  1
 Reviewer:  |Sponsor:
+--
Changes (by teor):

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


Comment:

 We decided not to fix #24716, so this doesn't need fixing.

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

Re: [tor-bugs] #24716 [Core Tor/DirAuth]: Try cranking up cbttestfreq consensus param, to see if it helps the current overload

[Tor Bug Tracker & Wiki]

#24716: Try cranking up cbttestfreq consensus param, to see if it helps the 
current
overload
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

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


Comment:

 This doesn't do what we want,

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

Re: [tor-bugs] #24714 [Core Tor/Tor]: rename conn->timestamp_lastwritten to conn->timestamp_lastwritable

[Tor Bug Tracker & Wiki]

#24714: rename conn->timestamp_lastwritten to conn->timestamp_lastwritable
+
 Reporter:  arma|  Owner:  valentecaio
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  easy, refactor  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+
Changes (by valentecaio):

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


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

Re: [tor-bugs] #22212 [Core Tor/Tor]: [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel padding timeout scheduled 164729ms in the past. Did the monotonic clock just jump?

[Tor Bug Tracker & Wiki]

#22212: [warn] channelpadding_compute_time_until_pad_for_netflow(): Bug: Channel
padding timeout scheduled 164729ms in the past. Did the monotonic clock
just jump?
--+
 Reporter:  arma  |  Owner:  mikeperry
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-client|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor2
--+
Changes (by arma):

 * status:  reopened => needs_review


Comment:

 My {{{bug22212}}} branch, targeted to maint-0.3.1, fixes this bug.

 (Once we decide we like the fix, we should put it in a more recent release
 before considering backports.)

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

Re: [tor-bugs] #2667 [Core Tor/Tor]: Exits should block reentry into the tor network

[Tor Bug Tracker & Wiki]

#2667: Exits should block reentry into the tor network
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:
 Keywords:  needs-proposal, tor-relay,   |  Actual Points:
  SponsorU-deferred  | Points:
Parent ID:   |  medium/large
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 I continue to think that teaching exit relays to avoid allowing exit
 connections to known relays (IP:ORPort) is a good and useful step.

 We keep running across messy situations where letting somebody connect to
 a relay from an exit relay's IP address turns into a security surprise.

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

Re: [tor-bugs] #25096 [Core Tor/Tor]: Bump up NumNTorsPerTAP to squeeze out v2 onion service traffic?

[Tor Bug Tracker & Wiki]

#25096: Bump up NumNTorsPerTAP to squeeze out v2 onion service traffic?
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by asn):

 I think we should probably not do any drastic measures here (e.g. increase
 it tenfold to 1k), before having some sort of evaluation mechanism to see
 if this actually helps relays. I'm also saying this because I'm sorta
 afraid that throttling rend circuits might backfire by having them
 timeout, or users retrying them, which could cause more traffic on the
 network.

 I think pumping it to 200 might be a reasonable thing to do at this point
 tho.

 A way to evaluate the effects of this change from the client-side could be
 a tool that connects to a few hundred relays with TAP/ntor and checks the
 delays and success rates.

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

Re: [tor-bugs] #2667 [Core Tor/Tor]: Exits should block reentry into the tor network

[Tor Bug Tracker & Wiki]

#2667: Exits should block reentry into the tor network
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:
 Keywords:  needs-proposal, tor-relay,   |  Actual Points:
  SponsorU-deferred  | Points:
Parent ID:   |  medium/large
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Replying to [comment:5 nickm]:
 > The only implementation challenge here will be doing efficient lookup of
 nodes by address or address:port.  (My intuition is that a linear search
 here will be too expensive.)  We can do that by adding another hashmap to
 node_t.

 Nick, has the world gotten any better since this comment six years ago?
 Assuming no, how much work do you think this hashmap would be? :)

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

Re: [tor-bugs] #24587 [Core Tor/Tor]: Reset bootstrapping state on shutdown

[Tor Bug Tracker & Wiki]

#24587: Reset bootstrapping state on shutdown
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, s8-api, review-group-31  |  Actual Points:
Parent ID:  #23847   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 Hey, did some review here as part of r-g-31.

 Commit `6033538` looks very good to me.

 Commit `3809036` also looks OK, but not very happy with it. I feel like
 resetting all the global statics on `tor_free_all()` makes sense but it's
 all a very brittle logic. The moment someone adds a new global static in
 that file and doesn't know about this convention of wiping at
 `tor_free_all()`, it will introduce a bug IIUC. Furthermore, the fact that
 some of those vars get reset to 0 and others to 1 is kinda arbitrary (and
 you need to look at their definitions to see if it's correct).

 I wonder what we could do about `3809036` to make it better. Perhaps we
 should de-global those variables, put them in a struct, and initialize
 them in a function, then call that function from some entry-point and
 `tor_free_all()`? That seems like a better approach but probably not so
 trivial. Maybe subject for a future ticket on this area?

 I'll mark this as merge_ready because I think it's correct, but we should
 think about the above concerns.

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

Re: [tor-bugs] #24294 [Metrics/Website]: Rename metrics-web packages

[Tor Bug Tracker & Wiki]

#24294: Rename metrics-web packages
-+-
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+-
Changes (by iwakeh):

 * status:  needs_review => merge_ready
 * reviewer:   => iwakeh


Comment:

 Seems fine.
 I added a [https://gitweb.torproject.org/user/iwakeh/metrics-
 web.git/commit/?h=task-24294 fixup commit] that removes special treatment
 of 'ernie' packages.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25097 [Core Tor/Tor]: Remove commented functions in crypto module

[Tor Bug Tracker & Wiki]

#25097: Remove commented functions in crypto module
--+
 Reporter:  ffmancera |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor |   Keywords:  easy, intro
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I noticed there are some code commented in crypto module.

  * struct CRYPTO_dynlock_value
  * openssl_dynlock_create_cb_
  * openssl_dynlock_lock_cb_
  * openssl_dynlock_destroy_cb_

 OpenSSL never uses these callbacks anymore so the code is disabled. Should
 we remove this code?

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

Re: [tor-bugs] #24587 [Core Tor/Tor]: Reset bootstrapping state on shutdown

[Tor Bug Tracker & Wiki]

#24587: Reset bootstrapping state on shutdown
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-mobile, s8-api, review-group-31  |  Actual Points:
Parent ID:  #23847   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by asn):

 * reviewer:   => asn


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

Re: [tor-bugs] #24294 [Metrics/Website]: Rename metrics-web packages

[Tor Bug Tracker & Wiki]

#24294: Rename metrics-web packages
-+-
 Reporter:  karsten  |  Owner:  karsten
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+-
Changes (by karsten):

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


Comment:

 Fixup commit 8d5ce88 looks good! Squashed and merged. Closing. 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] #22983 [Metrics/Library]: Add a Descriptor subinterface and implementation for Tor web server logs

[Tor Bug Tracker & Wiki]

#22983: Add a Descriptor subinterface and implementation for Tor web server logs
-+---
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:  metrics-lib 2.2.0
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

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


Comment:

 Local tests pass! I squashed all commits related to this change, updated
 the change log (to reflect that we're not sanitizing logs anymore),
 rebased to master, and pushed. I'll run some more tests with files from
 webstats.tp.o, but I'll open new tickets in case I run into any bugs.
 Closing. 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] #23814 [Core Tor/Tor]: Remove non-exponential backoff directory download implementation

[Tor Bug Tracker & Wiki]

#23814: Remove non-exponential backoff directory download implementation
-+
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-31  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by asn):

 * status:  needs_review => needs_revision


Comment:

 Hey, not very familiar with this part of the codebase, but did an attempt
 to review it as part of r-g-31.

 Commit `e0049ef022b8bf` LGTM. I liked the trick with `bf74194f` unintend
 that code section on its own commit. I think we should also remove
 `max_failures` from `download_status_is_ready()` tho.

 I'm a bit curious on why we needed to do `5b55e15` if the function works
 fine and we had tests for it. Is it to simplify the code? Should we do it
 as part of another ticket, or we feel fine doing it in this one? Code
 looks reasonable anyhow. We should also remove mention of `max_delay` from
 func doc of `next_random_exponential_delay()`.

 Marking this as `needs_rev` for the trivial fixes above. Feel free to put
 it in `merge_ready` after that.

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

Re: [tor-bugs] #23814 [Core Tor/Tor]: Remove non-exponential backoff directory download implementation

[Tor Bug Tracker & Wiki]

#23814: Remove non-exponential backoff directory download implementation
-+
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-31  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by asn):

 * cc: asn (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] #23814 [Core Tor/Tor]: Remove non-exponential backoff directory download implementation

[Tor Bug Tracker & Wiki]

#23814: Remove non-exponential backoff directory download implementation
-+
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-31  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+
Changes (by asn):

 * cc: asn (removed)
 * reviewer:   => asn


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

Re: [tor-bugs] #24849 [Core Tor/Tor]: Added -1 signatures to consensus

[Tor Bug Tracker & Wiki]

#24849: Added -1 signatures to consensus
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-sr, tor-ddos, 032-backport,  |  Actual Points:
  logs, review-group-31  |
Parent ID:  #24815   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by asn):

 * reviewer:   => asn


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

Re: [tor-bugs] #24972 [Core Tor/Tor]: Bug: src/or/hs_descriptor.c:2357: hs_desc_encode_descriptor: Non-fatal assertion !(ret < 0) failed.

[Tor Bug Tracker & Wiki]

#24972: Bug: src/or/hs_descriptor.c:2357: hs_desc_encode_descriptor: Non-fatal
assertion !(ret < 0) failed.
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:
  |  merge_ready
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, prop224, review-group-31  |  Actual Points:
Parent ID:| Points:  2
 Reviewer:  asn   |Sponsor:
--+
Changes (by asn):

 * reviewer:   => asn


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

Re: [tor-bugs] #24996 [Metrics/Statistics]: OnionPerf showing >200% timeouts

[Tor Bug Tracker & Wiki]

#24996: OnionPerf showing >200% timeouts
+-
 Reporter:  irl |  Owner:  karsten
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+-
Changes (by iwakeh):

 * status:  needs_review => merge_ready


Comment:

 Fine to be merged.

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

Re: [tor-bugs] #24217 [Metrics/Statistics]: Specify data format and aggregation process of new IPv6 relay statistics

[Tor Bug Tracker & Wiki]

#24217: Specify data format and aggregation process of new IPv6 relay statistics
+--
 Reporter:  karsten |  Owner:  karsten
 Type:  enhancement | Status:  needs_review
 Priority:  High|  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+--

Comment (by iwakeh):

 Replying to [comment:9 karsten]:
 > Thanks for the quick feedback!
 >
 > I figured it's going to be much easier to discuss this content when it's
 on a Google Doc and not in Git, especially when we want to ask folks like
 t0mmy or our target audience to help us with comments, edits, or
 suggestions.
 >
 > I put everything in the following Google Doc, including your comments
 and my comments to yours:
 >
 > https://docs.google.com/document/d/19A98ymeidOcmHKl-
 3OUXkM8ZC7_VuooPTEZSW8DV7SI/edit?usp=sharing
 >

 Taking a look.  (Weird, I just checked my inbox and the last mail I
 received about this from from comment 3 ???)
 > Please take another look. There are some suggested next steps at the
 end. 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] #24996 [Metrics/Statistics]: OnionPerf showing >200% timeouts

[Tor Bug Tracker & Wiki]

#24996: OnionPerf showing >200% timeouts
+-
 Reporter:  irl |  Owner:  karsten
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+-

Comment (by karsten):

 Thanks for looking, merged! Starting a new module run now. We'll see in a
 few hours if this fixed the issue.

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

[tor-bugs] #25098 [Webpages/Website]: download warnings tell you to use a bridge so a local adversary can't learn you're a tor user

[Tor Bug Tracker & Wiki]

#25098: download warnings tell you to use a bridge so a local adversary can't 
learn
you're a tor user
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 The last warning in the warnings list says

 """
 Use bridges and/or find company

 Tor tries to prevent attackers from learning what destination websites you
 connect to. However, by default, it does not prevent somebody watching
 your Internet traffic from learning that you're using Tor. If this matters
 to you, you can reduce this risk by configuring Tor to use a Tor bridge
 relay rather than connecting directly to the public Tor network.
 Ultimately the best protection is a social approach: the more Tor users
 there are near you and the more diverse their interests, the less
 dangerous it will be that you are one of them. Convince other people to
 use Tor, too!
 """

 But simply using a bridge probably doesn't help much. Maybe if there were
 special pluggable transports that helped especially well. It really
 depends what *your* adversary is doing to discern Tor users. Are they
 using a list of destination IP addresses? Probably not. Are they using
 DPI? Maybe, if they bought some DPI box and configured it to do that.

 Using a VPN can help, sometimes, but it also just shifts the problem to
 some other place that gets to track you.

 I wonder how best to capture all of these nuances in a sentence or two for
 the warnings list.

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

Re: [tor-bugs] #24217 [Metrics/Statistics]: Specify data format and aggregation process of new IPv6 relay statistics

[Tor Bug Tracker & Wiki]

#24217: Specify data format and aggregation process of new IPv6 relay statistics
+--
 Reporter:  karsten |  Owner:  karsten
 Type:  enhancement | Status:  needs_review
 Priority:  High|  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+--

Comment (by iwakeh):

 Replying to [comment:9 karsten]:
 > Thanks for the quick feedback!
 >
 > I figured it's going to be much easier to discuss this content when it's
 on a Google Doc and not in Git, especially when we want to ask folks like
 t0mmy or our target audience to help us with comments, edits, or
 suggestions.

 Hmm, I added as first next step (there too):
   Agree on a format: the G-doc is very cumbersome to edit&read. Let’s use
 a common format like LaTeX, Markdown, whatever.  Especially, if we want
 reviewers to comment rather than edit (as suggested below).  The more
 common formats will also be easier to transform and we should keep the git
 versioning.

 When we want comments and edits in the doc let's stay with markdown.
 Keeping git I find essential.  The editors/commenters don't need to use
 it, but it will be easier for us to keep track of versions.

 The shortcut/complete discussion should be resolved, too. (I commented in
 the G-doc)

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

Re: [tor-bugs] #24729 [Metrics/Onionoo]: Find reason for 'null' values in Onionoo document

[Tor Bug Tracker & Wiki]

#24729: Find reason for 'null' values in Onionoo document
-+--
 Reporter:  Dbryrtfbcbhgf|  Owner:  karsten
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #24155   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+--

Comment (by iwakeh):

 The suggestion in comment:4 seems ok, technically all data for shorter
 graphs can be taken from there.
 Can the clients using the data provide all useful/needed graphs with this
 change and deal with possibly omitted data?

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

Re: [tor-bugs] #24823 [Metrics/Website]: Avoid sending an error after a (partial) response

[Tor Bug Tracker & Wiki]

#24823: Avoid sending an error after a (partial) response
-+--
 Reporter:  karsten  |  Owner:  karsten
 Type:  defect   | Status:  needs_review
 Priority:  Low  |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+--

Comment (by iwakeh):

 The general idea and coded suggestion make sense and should be continued.
 (try-with-resources is in use now)

 Does this answer the question, or is there another point to review that I
 missed?

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

Re: [tor-bugs] #2667 [Core Tor/Tor]: Exits should block reentry into the tor network

[Tor Bug Tracker & Wiki]

#2667: Exits should block reentry into the tor network
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:
 Keywords:  needs-proposal, tor-relay,   |  Actual Points:
  SponsorU-deferred  | Points:
Parent ID:   |  medium/large
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Replying to [comment:49 arma]:
 > Replying to [comment:5 nickm]:
 > > The only implementation challenge here will be doing efficient lookup
 of nodes by address or address:port.  (My intuition is that a linear
 search here will be too expensive.)  We can do that by adding another
 hashmap to node_t.
 >
 > Nick, has the world gotten any better since this comment six years ago?
 Assuming no, how much work do you think this hashmap would be? :)

 About a day's work.

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

Re: [tor-bugs] #7532 [Obfuscation/Obfsproxy]: Count unique IPs in an anonymous way

[Tor Bug Tracker & Wiki]

#7532: Count unique IPs in an anonymous way
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Obfuscation/Obfsproxy|Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:
 Keywords:  research, term-project-ideas maybe-  |  Actual Points:
  bad-idea needs-discussion  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by beastr0):

 * cc: beastr0@… (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] #22428 [Metrics/CollecTor]: Add webstats module

[Tor Bug Tracker & Wiki]

#22428: Add webstats module
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  closed
 Priority:  High   |  Milestone:  CollecTor 1.5.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  metrics-2018   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

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


Comment:

 Local tests pass! I squashed all commits related to this change, updated
 the change log, updated `build.xml` to use metrics-lib 2.2.0, updated
 copyrights, rebased to master, and pushed. I'll run some more tests with
 files from webstats.tp.o, but I'll open new tickets in case I run into any
 bugs. Closing. 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] #15469 [Core Tor/Tor]: Remove data structure containing unique IP address sets

[Tor Bug Tracker & Wiki]

#15469: Remove data structure containing unique IP address sets
--+
 Reporter:  karsten   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:  Tor:
  |  unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-relay, privacy, research  |  Actual Points:
Parent ID:  #7532 | Points:
 Reviewer:|Sponsor:
--+
Changes (by beastr0):

 * cc: beastr0@… (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] #24217 [Metrics/Statistics]: Specify data format and aggregation process of new IPv6 relay statistics

[Tor Bug Tracker & Wiki]

#24217: Specify data format and aggregation process of new IPv6 relay statistics
+--
 Reporter:  karsten |  Owner:  karsten
 Type:  enhancement | Status:  needs_review
 Priority:  High|  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+--

Comment (by karsten):

 I commented on the Google Doc. Do you receive notifications for that?

 Independent of these discussions, do you mind if I publish a PDF of the
 state by end of day to metrics-team@, so that we have something to
 reference in the January report for Sponsor 13?

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

Re: [tor-bugs] #24972 [Core Tor/Tor]: Bug: src/or/hs_descriptor.c:2357: hs_desc_encode_descriptor: Non-fatal assertion !(ret < 0) failed.

[Tor Bug Tracker & Wiki]

#24972: Bug: src/or/hs_descriptor.c:2357: hs_desc_encode_descriptor: Non-fatal
assertion !(ret < 0) failed.
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:
  |  needs_information
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs, prop224, review-group-31  |  Actual Points:
Parent ID:| Points:  2
 Reviewer:  asn   |Sponsor:
--+
Changes (by nickm):

 * status:  merge_ready => needs_information


Comment:

 Replying to [comment:6 asn]:
 > LGTM!

 Thanks!  I've merged it to 0.3.2 and forward.

 > Should we let this ticket open until someone hits this issue with the
 debugging patch?

 Yeah, I think that's about all we can do. (unless you can reproduce the
 bug somehow?)

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

Re: [tor-bugs] #25066 [Core Tor/Tor]: Rendezvous points should return signed proof of the established rend point

[Tor Bug Tracker & Wiki]

#25066: Rendezvous points should return signed proof of the established rend 
point
+
 Reporter:  arma|  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  needs-proposal  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+

Comment (by nickm):

 If we were to do this, we'd also have to make sure that these tokens are
 non-replayable... and possibly bound to a single onion service?

 To be clear, this issue is "just" a DoS multiplier, right?  At the cost of
 building a circuit and sending an introduce cell, the attacker causes the
 onion service to build another circuit?

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

Re: [tor-bugs] #25094 [Core Tor/Tor]: 24902 fix breaks on clang

[Tor Bug Tracker & Wiki]

#25094: 24902 fix breaks on clang
--+
 Reporter:  catalyst  |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-dos   |  Actual Points:  0.2
Parent ID:  #24902| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * keywords:   => tor-dos
 * status:  needs_review => merge_ready


Comment:

 I've taken teor patch and fixed very minor thing (mostly syntax) and made
 the `circuit_rate` to be a `uint64_t` instead of casting it. The getter
 returns the `uin32_t` value so we are good in conversion there. Just one
 less cast.

 I've re-arranged the commit to have 3 of them, (1) teor's test fix, (2)
 refill over/underflow checks, (3) add unit tests.

 gcc and clang seems happy here.

 Commits are in branch: `ticket24902_029_05` so it is easy for nick to
 merge it forward into master. Let me know if you want me to move them to
 the _033_02 branch or just plain latest master.

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

Re: [tor-bugs] #25094 [Core Tor/Tor]: 24902 fix breaks on clang

[Tor Bug Tracker & Wiki]

#25094: 24902 fix breaks on clang
--+
 Reporter:  catalyst  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-dos   |  Actual Points:  0.2
Parent ID:  #24902| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Merges cleanly to master, and passes tests for me.  Merging to master.

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

Re: [tor-bugs] #24849 [Core Tor/Tor]: Added -1 signatures to consensus

[Tor Bug Tracker & Wiki]

#24849: Added -1 signatures to consensus
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-sr, tor-ddos, 032-backport,  |  Actual Points:
  logs, review-group-31  |
Parent ID:  #24815   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Merging to master only; marking for possible backport; not recommending
 backport yet.

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

Re: [tor-bugs] #1877 [Applications/Tor Browser]: Create repository and package signing keys

[Tor Bug Tracker & Wiki]

#1877: Create repository and package signing keys
--+--
 Reporter:  erinn |  Owner:  tbb-team
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by boklm):

 * parent:  #18867 =>


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25099 [Applications/Tor Browser]: Update nightly version number

[Tor Bug Tracker & Wiki]

#25099: Update nightly version number
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-rbm
Actual Points:|  Parent ID:  #18867
   Points:|   Reviewer:
  Sponsor:|
--+--
 In order to be able to update Tor Browser nightly builds each day, we need
 each build to have a different version number.

 Currently the version for nightly builds is set to `tbb-nightly`. I think
 we could change it to the current day with something like `2018.01.31`.

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

Re: [tor-bugs] #24927 [Core Tor/Tor]: if (n_chan_id) in circuit_build_failed() can't fail

[Tor Bug Tracker & Wiki]

#24927: if (n_chan_id) in circuit_build_failed() can't fail
-+
 Reporter:  arma |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.2.4.4-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  review-group-31  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+
Changes (by nickm):

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


Comment:

 Merged!

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

Re: [tor-bugs] #24859 [Core Tor/Tor]: Bug: Non-fatal assertion !(ent == NULL) failed in store_multiple at src/or/consdiffmgr.c

[Tor Bug Tracker & Wiki]

#24859: Bug: Non-fatal assertion !(ent == NULL) failed in store_multiple at
src/or/consdiffmgr.c
-+-
 Reporter:  dgoulet  |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-relay, consdiff, 031-backport,   |  Actual Points:
  032-backport, review-group-31  |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 good point.  I've merged to 0.3.1 and forward, adding a rate-limiter.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25100 [Metrics/CollecTor]: Make CollecTor's webstats module use less RAM and CPU time

[Tor Bug Tracker & Wiki]

#25100: Make CollecTor's webstats module use less RAM and CPU time
---+--
 Reporter:  karsten|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 I re-processed 516 xz-compressed log files downloaded from webstats.tp.o
 with a total size of 4.4M. Here's what I found:

 My first attempt to process these log files with 4G RAM failed after 10
 minutes with a `java.lang.OutOfMemoryError`:

 {{{
 2018-01-31 13:42:18,189 INFO o.t.c.cron.Scheduler:73 Prepare single run
 for org.torproject.collector.webstats.SanitizeWeblogs.
 2018-01-31 13:42:18,193 INFO o.t.c.cron.Scheduler:150 New Thread created:
 CollecTor-Scheduled-Thread-1
 2018-01-31 13:42:18,194 INFO o.t.c.c.CollecTorMain:66 Starting webstats
 module of CollecTor.
 2018-01-31 13:42:18,302 INFO o.t.c.w.SanitizeWeblogs:98 Found log files
 for 1 virtual hosts.
 2018-01-31 13:42:18,302 INFO o.t.c.w.SanitizeWeblogs:105 Processing logs
 for metrics.torproject.org on meronense.torproject.org.
 2018-01-31 13:53:02,368 ERROR o.t.c.c.CollecTorMain:71 The webstats module
 failed: null
 java.lang.OutOfMemoryError: null
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
 Method)
 at
 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
 at
 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
 at
 java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:598)
 at
 java.util.concurrent.ForkJoinTask.reportException(ForkJoinTask.java:677)
 at java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:735)
 at
 java.util.stream.ReduceOps$ReduceOp.evaluateParallel(ReduceOps.java:714)
 at
 java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233)
 at
 java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
 at
 
org.torproject.collector.webstats.SanitizeWeblogs.findCleanWrite(SanitizeWeblogs.java:110)
 at
 
org.torproject.collector.webstats.SanitizeWeblogs.startProcessing(SanitizeWeblogs.java:87)
 at
 org.torproject.collector.cron.CollecTorMain.run(CollecTorMain.java:67)
 at
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
 at
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
 at
 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
 at
 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
 at
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
 at
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
 at java.lang.Thread.run(Thread.java:745)
 Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded
 at java.util.Arrays.copyOf(Arrays.java:3236)
 at sun.misc.IOUtils.readFully(IOUtils.java:60)
 at java.util.jar.JarFile.getBytes(JarFile.java:425)
 at
 java.util.jar.JarFile.getManifestFromReference(JarFile.java:193)
 at java.util.jar.JarFile.getManifest(JarFile.java:180)
 at
 sun.misc.URLClassPath$JarLoader$2.getManifest(URLClassPath.java:981)
 at java.net.URLClassLoader.defineClass(URLClassLoader.java:450)
 at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
 at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
 at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
 at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
 at
 ch.qos.logback.classic.spi.LoggingEvent.(LoggingEvent.java:119)
 at
 ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:419)
 at ch.qos.logback.classic.Logger.filterAndLog_2(Logger.java:414)
 at ch.qos.logback.classic.Logger.debug(Logger.java:490)
 at
 
org.torproject.descriptor.log.WebServerAccessLogLine.makeLine(WebServerAccessLogLine.java:1

Re: [tor-bugs] #9313 [Applications/Tor bundles/installation]: RunAsDaemon=1 reported as "Unneeded torrc entry"

[Tor Bug Tracker & Wiki]

#9313: RunAsDaemon=1 reported as "Unneeded torrc entry"
-+-
 Reporter:  amontero |  Owner:  erinn
 Type:  defect   | Status:  closed
 Priority:  Low  |  Milestone:
Component:  Applications/Tor |Version:
  bundles/installation   |
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  needs-triage |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arma):

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


Comment:

 I'm going to close this ticket as no longer relevant now that arm doesn't
 exist anymore.

 If somebody wants to find the same bug in nyx, please open a new ticket.
 :)

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

[tor-bugs] #25101 [Applications/Tor Browser]: Generate incremental mar files for nightly builds

[Tor Bug Tracker & Wiki]

#25101: Generate incremental mar files for nightly builds
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-rbm
Actual Points:|  Parent ID:  #18867
   Points:|   Reviewer:
  Sponsor:|
--+--
 We have some nightly builds being done at http://f4amtbsowhix7rrf.onion/.
 However, there is no incremental mar files.

 To avoid users downloading a complete mar file each day, we should
 generate incremental mar files from the previous days. I think we can
 start with incrementals for the previous 2 days.

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

Re: [tor-bugs] #25097 [Core Tor/Tor]: Remove commented functions in crypto module

[Tor Bug Tracker & Wiki]

#25097: Remove commented functions in crypto module
--+
 Reporter:  ffmancera |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  easy, intro   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Yes, we should IMO.

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

Re: [tor-bugs] #25071 [Core Tor/Tor]: Add a test-rust make target to the Makefile

[Tor Bug Tracker & Wiki]

#25071: Add a test-rust make target to the Makefile
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 I think that setting the "abs_top_builddir" variable will be key -- that,
 or replacing the the "../../.." default with maybe "." ?  I'm not sure.

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

Re: [tor-bugs] #24902 [Core Tor/Tor]: Denial of Service mitigation subsystem

[Tor Bug Tracker & Wiki]

#24902: Denial of Service mitigation subsystem
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  enhancement  | Status:
 |  accepted
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ddos, tor-relay, review-group-30,|  Actual Points:
  029-backport, 031-backport, 032-backport,  |
  review-group-31|
Parent ID:   | Points:
 Reviewer:  arma |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_revision => accepted


Comment:

 Fixes in #25904 has been merged and they are in the _029_05 branch.

 Putting back in `accepted` state waiting for backport.

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

[tor-bugs] #25102 [Applications/Tor Browser]: Add script to sign nightly build mar files

[Tor Bug Tracker & Wiki]

#25102: Add script to sign nightly build mar files
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-rbm
Actual Points:|  Parent ID:  #18867
   Points:|   Reviewer:
  Sponsor:|
--+--
 We need a script that will fetch the latest nightly build from the build
 machine, then sign the mar files and publish them.

 Later we can improve it to fetch builds from multiple builders and only do
 the signing if they match.

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

Re: [tor-bugs] #24983 [Metrics/CollecTor]: Inaccessible semi-recent consensus files

[Tor Bug Tracker & Wiki]

#24983: Inaccessible semi-recent consensus files
---+-
 Reporter:  robgjansen |  Owner:  karsten
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by karsten):

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


Comment:

 No obvious issues from changing the cronjob from every 3 to every 2 days.
 Closing. 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] #24918 [Applications/Tor Browser]: Help users finding the new circuit display

[Tor Bug Tracker & Wiki]

#24918: Help users finding the new circuit display
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:  #24309| Points:
 Reviewer:|Sponsor:
--+--

Comment (by antonela):

 Hi! The UX team have been working on this ticket.

 Since [about:toris about:tor is] going to be taken in your roadmaps later
 than circuits, we are sharing a proposal that doesn't modify anything
 existent on our [currentabout:torpage current about:torpage].

 You can try the flow here https://marvelapp.com/59a164g/screen/37879856

 A successful user flow looks like this:

 0) User finds a top banner at [about:torpage about:tor page]
 1) User clicks the main CTA [Try Now]
 2) A new tab with the TPO onion service opens
 3) User clicks [i]

 Also, we made a mockup of a similar idea but using a smaller banner:
 You can see here https://marvelapp.com/59a164g/screen/37879878

 Another option could use a small full-page banner at the bottom like
 current [new:tabon new:tab on] Firefox.
 You can see a mockup here https://marvelapp.com/59a164g/screen/37879882

 Some considerations that apply to all options:

  * Learn More link should open a new tab with the related documentation.
  * Banners should be able to be closed/dismissed.

 All the copy text is up to review and right now is just a draft.

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

Re: [tor-bugs] #25100 [Metrics/CollecTor]: Make CollecTor's webstats module use less RAM and CPU time

[Tor Bug Tracker & Wiki]

#25100: Make CollecTor's webstats module use less RAM and CPU time
---+--
 Reporter:  karsten|  Owner:  iwakeh
 Type:  enhancement| Status:  accepted
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by iwakeh):

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


Comment:

 I could reproduce this behavior; heap usage quickly goes up to just below
 6G and stays there during the processing time with a few peaks below
 6.671G.
 Looking further.

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

Re: [tor-bugs] #24823 [Metrics/Website]: Avoid sending an error after a (partial) response

[Tor Bug Tracker & Wiki]

#24823: Avoid sending an error after a (partial) response
-+-
 Reporter:  karsten  |  Owner:  karsten
 Type:  defect   | Status:  closed
 Priority:  Low  |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+-
Changes (by karsten):

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


Comment:

 That answers the question. The fixup commit was not yet reviewed, but now
 it is. Squashed, merged to master, and deployed. Closing. 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] #25099 [Applications/Tor Browser]: Update nightly version number

[Tor Bug Tracker & Wiki]

#25099: Update nightly version number
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:  #18867| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 For the updater to work correctly, the version number needs to conform to
 Mozilla's standard format (and newer releases need to have a higher
 number). See: https://developer.mozilla.org/en-
 US/docs/Mozilla/Toolkit_version_format

 I am not sure what Mozilla uses for nightly Firefox builds, but maybe we
 can do something similar.

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

Re: [tor-bugs] #24918 [Applications/Tor Browser]: Help users finding the new circuit display

[Tor Bug Tracker & Wiki]

#24918: Help users finding the new circuit display
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:  #24309| Points:
 Reviewer:|Sponsor:
--+--
Changes (by antonela):

 * cc: tor@… (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] #25099 [Applications/Tor Browser]: Update nightly version number

[Tor Bug Tracker & Wiki]

#25099: Update nightly version number
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:  #18867| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 Replying to [comment:1 mcs]:
 > I am not sure what Mozilla uses for nightly Firefox builds, but maybe we
 can do something similar.

 Apparently they use an alpha version number, e.g., `appVersion="60.0a1"`
 and rely on the fact that they change the buildID for each nightly build,
 e.g., `buildID="20180131100706"`.

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

Re: [tor-bugs] #24977 [Core Tor/Tor]: Non-fatal assertion !(tor_mem_is_zero((const char*)node->hsdir_index->fetch, DIGEST256_LEN))

[Tor Bug Tracker & Wiki]

#24977: Non-fatal assertion !(tor_mem_is_zero((const
char*)node->hsdir_index->fetch, DIGEST256_LEN))
+
 Reporter:  asn |  Owner:  dgoulet
 Type:  defect  | Status:  accepted
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs prop224  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+

Comment (by dgoulet):

 Hmmm I have not seen that on any of my v3 services for a _while_ now.

 What I can see that makes me wonder. We can have `node_t` without an
 ed25519 known ID that is before we get the descriptor.

 Notice `node_set_hsdir_index()`, it doesn't set anything if the
 `node_get_ed25519_id()` returns NULL. We only set HSDir index if
 `rs->supports_v3_hsdir` meaning when we have a `rs`. But the
 `hs_get_responsible_hsdirs()` looks up the node by `identity_digest` ...

 And `node_supports_v3_hsdir()` can return true with only using the `ri`
 and not the `rs` ... so we have this difference here where we only set the
 indexes if we have a `rs` but then we can also validate HSDir support by
 `ri`.

 Although, in this situation, we loop over the `rs` list so any `node_t` we
 look at from the `rs->identity_digest` should return a node that has a
 valid `rs`

 Very puzzling!

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

Re: [tor-bugs] #24976 [Core Tor/Tor]: Bug: src/or/hs_cache.c:628: cache_store_as_client: Non-fatal assertion !(cache_entry->desc->plaintext_data.revision_counter > client_desc->desc->plaintext_data.re

[Tor Bug Tracker & Wiki]

#24976: Bug: src/or/hs_cache.c:628: cache_store_as_client: Non-fatal assertion
!(cache_entry->desc->plaintext_data.revision_counter >
client_desc->desc->plaintext_data.revision_counter) failed
+
 Reporter:  asn |  Owner:  dgoulet
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:  Tor: unspecified
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs prop224  |  Actual Points:
Parent ID:  | Points:  0.4
 Reviewer:  |Sponsor:
+
Changes (by dgoulet):

 * status:  accepted => merge_ready


Comment:

 Oneliner fix. Branch: `bug24976_033_01`

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

Re: [tor-bugs] #24983 [Metrics/CollecTor]: Inaccessible semi-recent consensus files

[Tor Bug Tracker & Wiki]

#24983: Inaccessible semi-recent consensus files
---+-
 Reporter:  robgjansen |  Owner:  karsten
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by robgjansen):

 Thanks for taking care of this so quickly, Karsten! :)

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

Re: [tor-bugs] #24975 [Core Tor/Tor]: sched: scheduler_notify_networkstatus_changed() calls select_scheduler() without the new consensus

[Tor Bug Tracker & Wiki]

#24975: sched: scheduler_notify_networkstatus_changed() calls select_scheduler()
without the new consensus
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  032-backport, tor-sched  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by dgoulet):

 * status:  assigned => needs_review


Comment:

 See branch: `bug24975_032_01`

 Important bug that affects any values set by the consensus for the KIST
 scheduler so we need to backport it.

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

Re: [tor-bugs] #24976 [Core Tor/Tor]: Bug: src/or/hs_cache.c:628: cache_store_as_client: Non-fatal assertion !(cache_entry->desc->plaintext_data.revision_counter > client_desc->desc->plaintext_data.re

[Tor Bug Tracker & Wiki]

#24976: Bug: src/or/hs_cache.c:628: cache_store_as_client: Non-fatal assertion
!(cache_entry->desc->plaintext_data.revision_counter >
client_desc->desc->plaintext_data.revision_counter) failed
+
 Reporter:  asn |  Owner:  dgoulet
 Type:  defect  | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor|Version:  Tor: unspecified
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs prop224  |  Actual Points:
Parent ID:  | Points:  0.4
 Reviewer:  |Sponsor:
+

Comment (by asn):

 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

[tor-bugs] #25103 [Metrics/Library]: Improve webstats performance

[Tor Bug Tracker & Wiki]

#25103: Improve webstats performance
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #25100
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 See parent for background.

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

Re: [tor-bugs] #25103 [Metrics/Library]: Improve webstats performance

[Tor Bug Tracker & Wiki]

#25103: Improve webstats performance
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #25100   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

 * status:  new => needs_review


Comment:

 Please review the [https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/commit/?h=next last commit] on the current release branch.  The
 commit avoid preparing the date string prematurely.

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

Re: [tor-bugs] #25100 [Metrics/CollecTor]: Make CollecTor's webstats module use less RAM and CPU time

[Tor Bug Tracker & Wiki]

#25100: Make CollecTor's webstats module use less RAM and CPU time
---+--
 Reporter:  karsten|  Owner:  iwakeh
 Type:  enhancement| Status:  accepted
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by iwakeh):

 See the patch in the child ticket for metrics-lib.
 It shortens processing time of 516 meronense logs to four minutes.
 {{{
 2018-01-31 16:31:37,805 INFO o.t.c.c.CollecTorMain:66 Starting webstats
 module of CollecTor.
 2018-01-31 16:31:37,910 INFO o.t.c.w.SanitizeWeblogs:98 Found log files
 for 1 virtual hosts.
 2018-01-31 16:31:37,911 INFO o.t.c.w.SanitizeWeblogs:105 Processing logs
 for metrics.torproject.org on meronense.torproject.org.
 2018-01-31 16:35:21,428 INFO o.t.c.c.CollecTorMain:68 Terminating webstats
 module of CollecTor.
 2018-01-31 16:35:21,430 INFO o.t.c.c.ShutdownHook:23 Shutdown in progress
 ...
 2018-01-31 16:35:21,432 INFO o.t.c.cron.Scheduler:127 Waiting at most 10
 minutes for termination of running tasks ...
 2018-01-31 16:35:21,432 INFO o.t.c.cron.Scheduler:132 Shutdown of all
 scheduled tasks completed successfully.
 2018-01-31 16:35:21,433 INFO o.t.c.c.ShutdownHook:25 Shutdown finished.
 Exiting.
 }}}

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

Re: [tor-bugs] #24860 [Core Tor/Tor]: Bug: Assertion cmux failed in circuitmux_get_policy at src/or/circuitmux.c

[Tor Bug Tracker & Wiki]

#24860: Bug: Assertion cmux failed in circuitmux_get_policy at 
src/or/circuitmux.c
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:
 |  accepted
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-sched, cmux, tor- |  Actual Points:
  channel|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * priority:  Medium => High


Comment:

 Replying to [comment:1 nickm]:
 > Could this be caused by #24700 ?

 Hmm! Actually, it is possible and it might be it... Need to think for
 a fix but I believe that it is very probable.

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

Re: [tor-bugs] #25100 [Metrics/CollecTor]: Make CollecTor's webstats module use less RAM and CPU time

[Tor Bug Tracker & Wiki]

#25100: Make CollecTor's webstats module use less RAM and CPU time
---+--
 Reporter:  karsten|  Owner:  iwakeh
 Type:  enhancement| Status:  accepted
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 I'll take a look in a bit. But let me ask anyway: does it affect the
 memory requirement, too?

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

Re: [tor-bugs] #25100 [Metrics/CollecTor]: Make CollecTor's webstats module use less RAM and CPU time

[Tor Bug Tracker & Wiki]

#25100: Make CollecTor's webstats module use less RAM and CPU time
---+--
 Reporter:  karsten|  Owner:  iwakeh
 Type:  enhancement| Status:  accepted
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by iwakeh):

 Less noticeably, but that requirement might not at all increase linearly
 with the log amount to process.  I'm running tests with more logs
 (meronense.torproject.org and weschniakowii.torproject.org) once my
 download finishes.

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

Re: [tor-bugs] #25103 [Metrics/Library]: Improve webstats performance

[Tor Bug Tracker & Wiki]

#25103: Improve webstats performance
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #25100   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  needs_review => merge_ready


Comment:

 Commit f16477f looks good. Not merging to master yet, in case there are
 even more/better changes to improve webstats performance. But if not, this
 one is good to go.

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

Re: [tor-bugs] #25013 [Applications/Tor Browser]: Move TorButton code to the tor browser repository

[Tor Bug Tracker & Wiki]

#25013: Move TorButton code to the tor browser repository
--+--
 Reporter:  igt0  |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201801R |  Actual Points:
Parent ID:  #24855| Points:
 Reviewer:  gk, sysrqb, mcs,  |Sponsor:
--+--

Comment (by igt0):

 I updated the code with the latest changes in Tor button, here are the new
 commits:

   **Move Tor Button source code to the browser/extensions directory**
   https://github.com/igortoliveira/tor-
 browser/commit/94279657dd8f0a4c999814155633ffe5d1b1d421

   **Integrate Tor Button in the browser build system**
   https://github.com/igortoliveira/tor-
 browser/commit/6813ba382253fd5b031bb1602cf64ce214bd274a

   **Use anonymous function to keep the torbutton.js and prefereces.js
 scope limited to the parent function**
   https://github.com/igortoliveira/tor-
 browser/commit/7c77dc04844fabb2ed8ed7e4d22edc1df03b76e9

   **Initialize startup.homepage in the startup-observer component**
   https://github.com/igortoliveira/tor-
 browser/commit/a4c6a58d287b87d8dd0736d67d7be6e87e3a30ab

 Replying to [comment:2 igt0]:
 > The code can be seen here: https://github.com/igortoliveira/tor-
 browser/commits/tbb-dev-desktop:
 >
 >  **Move Tor Button source code to the browser/extensions directory**
 >  https://github.com/igortoliveira/tor-
 browser/commit/eb2e1cec3b027647d3a873e8ce2e18102c926b7f
 >
 >  **Integrate Tor Button in the browser build system**
 >  https://github.com/igortoliveira/tor-
 browser/commit/d41ab6c701cbcaf00512061b05fb1e5e106a0923
 >
 >  **Use anonymous function to keep the torbutton.js and prefereces.js
 scope limited to the parent function**
 >  https://github.com/igortoliveira/tor-
 browser/commit/2c09ab0d4010c78af52a5655d865971600a215ed
 >
 >  **Initialize startup.homepage in the startup-observer component**
 >  https://github.com/igortoliveira/tor-
 browser/commit/b73742421735d6fea70ba4d7d550dcea22c1642c
 >

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

Re: [tor-bugs] #24857 [Core Tor/Tor]: tor 0.3.1.9 100% cpu load

[Tor Bug Tracker & Wiki]

#24857: tor 0.3.1.9 100% cpu load
-+--
 Reporter:  Eugene646|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Tor |Version:  Tor: 0.3.2.9
 Severity:  Normal   | Resolution:
 Keywords:  cpu, windows, linux  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by arma):

 Replying to [comment:4 creideiki]:
 > Jan 24 05:17:24.000 [warn] Failing because we have 4063 connections
 already. Please read doc/TUNING for guidance. [over 1601 similar
 message(s) suppressed in last 21600 seconds]

 You need to give Tor access to more file descriptors. Tor relays need to
 be able to reach the other Tor relays, and 4096-or-so descriptors is not
 enough.

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

Re: [tor-bugs] #19910 [Applications/Tor Browser]: Rip out optimistic data socks handshake variant (#3875)

[Tor Bug Tracker & Wiki]

#19910: Rip out optimistic data socks handshake variant (#3875)
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201801  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by antonela):

 * cc: tor@… (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] #19910 [Applications/Tor Browser]: Rip out optimistic data socks handshake variant (#3875)

[Tor Bug Tracker & Wiki]

#19910: Rip out optimistic data socks handshake variant (#3875)
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201801 ux-team  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arma):

 * keywords:  TorBrowserTeam201801 => TorBrowserTeam201801 ux-team


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

Re: [tor-bugs] #25099 [Applications/Tor Browser]: Update nightly version number

[Tor Bug Tracker & Wiki]

#25099: Update nightly version number
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:  #18867| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 Replying to [comment:1 mcs]:
 > For the updater to work correctly, the version number needs to conform
 to Mozilla's standard format (and newer releases need to have a higher
 number). See: https://developer.mozilla.org/en-
 US/docs/Mozilla/Toolkit_version_format

 Thanks for the link. If I understand it correctly, it seems a version
 number like `2018.01.31` would conform to this standard format. We could
 also include the alpha version number in addition to the date, like
 `8.0a1.2018.01.31`.

 Replying to [comment:2 mcs]:
 > Replying to [comment:1 mcs]:
 > > I am not sure what Mozilla uses for nightly Firefox builds, but maybe
 we can do something similar.
 >
 > Apparently they use an alpha version number, e.g., `appVersion="60.0a1"`
 and rely on the fact that they change the buildID for each nightly build,
 e.g., `buildID="20180131100706"`.

 I think it would be possible for us to do it like this, but would require
 some changes in our tools:

 * change the mar file names to include the buildID number
 * change the script we use to generate incremental mars to be able to do
 it from two builds that have the same version number but a different
 buildID
 * change the script we use to generate XML update responses to handle URLs
 with a buildID

 I think updating the version number only would require less changes. So
 I'm wondering if there is some other reason that would still make us
 prefer doing it with the buildID like Mozilla.

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

Re: [tor-bugs] #13379 [Applications/Tor Browser]: Sign our MAR files

[Tor Bug Tracker & Wiki]

#13379: Sign our MAR files
-+-
 Reporter:  mikeperry|  Owner:  mcs
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Blocker  | Resolution:  fixed
 Keywords:  tbb-security,|  Actual Points:
  TorBrowserTeam201412,TorBrowserTeam201412R,|
  tbb-no-uplift  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * keywords:  tbb-security, TorBrowserTeam201412,TorBrowserTeam201412R =>
 tbb-security, TorBrowserTeam201412,TorBrowserTeam201412R, tbb-no-
 uplift
 * severity:   => Blocker


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

Re: [tor-bugs] #13379 [Applications/Tor Browser]: Sign our MAR files

[Tor Bug Tracker & Wiki]

#13379: Sign our MAR files
-+-
 Reporter:  mikeperry|  Owner:  mcs
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-security,|  Actual Points:
  TorBrowserTeam201412,TorBrowserTeam201412R,|
  tbb-no-uplift  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * 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] #21724 [Applications/Tor Browser]: Distinguish between Tor Browser and Firefox when macOS opens documents

[Tor Bug Tracker & Wiki]

#21724: Distinguish between Tor Browser and Firefox when macOS opens documents
-+-
 Reporter:  teor |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201703R, tbb-no-   |  Actual Points:
  uplift |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arthuredelstein):

 * keywords:  TorBrowserTeam201703R => TorBrowserTeam201703R, tbb-no-uplift
 * parent:  #17670 =>


Old description:

> Please see my branch fix-macos-bundle-signature on
> https://github.com/teor2345/tor-browser.git , which deals with the core
> issue of #17670, the MOZB CFBundleSignature change.

New description:

 Please see my branch fix-macos-bundle-signature on
 https://github.com/teor2345/tor-browser.git , which deals with the core
 issue of #17670, the MOZB CFBundleSignature change.

 Note: #17670 was parent

--

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

Re: [tor-bugs] #24976 [Core Tor/Tor]: Bug: src/or/hs_cache.c:628: cache_store_as_client: Non-fatal assertion !(cache_entry->desc->plaintext_data.revision_counter > client_desc->desc->plaintext_data.re

[Tor Bug Tracker & Wiki]

#24976: Bug: src/or/hs_cache.c:628: cache_store_as_client: Non-fatal assertion
!(cache_entry->desc->plaintext_data.revision_counter >
client_desc->desc->plaintext_data.revision_counter) failed
+
 Reporter:  asn |  Owner:  dgoulet
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:  Tor: unspecified
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tor-hs prop224  |  Actual Points:
Parent ID:  | Points:  0.4
 Reviewer:  |Sponsor:
+
Changes (by nickm):

 * status:  merge_ready => closed
 * resolution:   => fixed
 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.2.x-final


Comment:

 Cherry-picked to 0.3.2.x, since that's where the bug is.  Merged forward.
 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] #25099 [Applications/Tor Browser]: Update nightly version number

[Tor Bug Tracker & Wiki]

#25099: Update nightly version number
--+--
 Reporter:  boklm |  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:  #18867| Points:
 Reviewer:|Sponsor:
--+--

Comment (by mcs):

 Replying to [comment:3 boklm]:
 > Replying to [comment:1 mcs]:
 > > For the updater to work correctly, the version number needs to conform
 to Mozilla's standard format (and newer releases need to have a higher
 number). See: https://developer.mozilla.org/en-
 US/docs/Mozilla/Toolkit_version_format
 >
 > Thanks for the link. If I understand it correctly, it seems a version
 number like `2018.01.31` would conform to this standard format. We could
 also include the alpha version number in addition to the date, like
 `8.0a1.2018.01.31`.

 I think that would work.

 > Replying to [comment:2 mcs]:
 > > Replying to [comment:1 mcs]:
 > > > I am not sure what Mozilla uses for nightly Firefox builds, but
 maybe we can do something similar.
 > >
 > > Apparently they use an alpha version number, e.g.,
 `appVersion="60.0a1"`  and rely on the fact that they change the buildID
 for each nightly build, e.g., `buildID="20180131100706"`.
 >
 > I think it would be possible for us to do it like this, but would
 require some changes in our tools:
 >
 > * change the mar file names to include the buildID number
 > * change the script we use to generate incremental mars to be able to do
 it from two builds that have the same version number but a different
 buildID
 > * change the script we use to generate XML update responses to handle
 URLs with a buildID
 >
 > I think updating the version number only would require less changes. So
 I'm wondering if there is some other reason that would still make us
 prefer doing it with the buildID like Mozilla.

 I don't know of any reason to favor one approach over another, except
 doing it like Mozilla does might make it less likely that things will
 break for us in the future. But that is only a theoretical concern, and if
 our nightly updates break it would not be the end of the world.

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

Re: [tor-bugs] #24700 [Core Tor/Tor]: sched: With KIST, a channel can be added more than once in the pending list

[Tor Bug Tracker & Wiki]

#24700: sched: With KIST, a channel can be added more than once in the pending 
list
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, kist  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  #23993   |Sponsor:
-+
Changes (by dgoulet):

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


Comment:

 Moving this to 033 so we notice it!

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

Re: [tor-bugs] #24700 [Core Tor/Tor]: sched: With KIST, a channel can be added more than once in the pending list

[Tor Bug Tracker & Wiki]

#24700: sched: With KIST, a channel can be added more than once in the pending 
list
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, kist  |  Actual Points:
Parent ID:  #23993   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by dgoulet):

 * reviewer:  #23993 =>
 * parent:   => #23993


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

Re: [tor-bugs] #24257 [Core Tor/Tor]: We should specify what is means for a Tor version to be obsolete

[Tor Bug Tracker & Wiki]

#24257: We should specify what is means for a Tor version to be obsolete
---+---
 Reporter:  arma   |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords:  review-group-31, tor-spec  |  Actual Points:
Parent ID: | Points:
 Reviewer:  dgoulet|Sponsor:
---+---
Changes (by nickm):

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


Comment:

 Replying to [comment:4 dgoulet]:
 > * `[Will become mandatory.]` when... ? Like when we decide or there is a
 date or when which ticket is resolved?
 >
 >  Considering this comment, I think we can deduce a date no?
 >
 > {{{
 > +   This field was first added in Tor 0.2.9.x. Some time after all
 earlier
 > +   Tor relay versions are obsolete, it will become mandatory.
 > }}}

 I think this was in #24023 though.  I'll fix it.

 > * Double white space at the end of the commit.

 Merging and fixing that too.

 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] #24975 [Core Tor/Tor]: sched: scheduler_notify_networkstatus_changed() calls select_scheduler() without the new consensus

[Tor Bug Tracker & Wiki]

#24975: sched: scheduler_notify_networkstatus_changed() calls select_scheduler()
without the new consensus
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  032-backport, tor-sched  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

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


Comment:

 merged to 0.3.2 and forward.

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

Re: [tor-bugs] #24700 [Core Tor/Tor]: sched: With KIST, a channel can be added more than once in the pending list

[Tor Bug Tracker & Wiki]

#24700: sched: With KIST, a channel can be added more than once in the pending 
list
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, kist  |  Actual Points:
Parent ID:  #23993   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by dgoulet):

 See branch `bug24700_032_01`.

 For the 032 fix, I went for the quick one detailed in (1).

 Please, DO NOT merge forward this fix. For 033, this is resolved with
 #24554 which includes more fixes.

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