Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

[Tor Bug Tracker & Wiki]

#23881: Implement a way to utilise tor's logging system from Rust code
--+
 Reporter:  isis  |  Owner:  chelseakomlo
 Type:  enhancement   | Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust, rust-pilot  |  Actual Points:
Parent ID:| Points:  3
 Reviewer:|Sponsor:
--+

Comment (by chelseakomlo):

 Replying to [comment:21 manish.earth]:
 > (that commit doesn't seem to be on your oniongit repo -- got a link?)

 Apologies! Multiple remotes- it should be updated now. Thanks for taking a
 look.

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

Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

[Tor Bug Tracker & Wiki]

#23881: Implement a way to utilise tor's logging system from Rust code
--+
 Reporter:  isis  |  Owner:  chelseakomlo
 Type:  enhancement   | Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust, rust-pilot  |  Actual Points:
Parent ID:| Points:  3
 Reviewer:|Sponsor:
--+

Comment (by manish.earth):

 (that commit doesn't seem to be on your oniongit repo -- got a link?)

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

Re: [tor-bugs] #24668 [Core Tor/Tor]: sched: scheduler_compare_channels() function will never pick a channel with no active circuis.

[Tor Bug Tracker & Wiki]

#24668: sched: scheduler_compare_channels() function will never pick a channel 
with
no active circuis.
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched, tor-channel, tor-cell  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [ticket:24668 dgoulet]:
 > And we still need to make sure that the scheduler's position in the heap
 changes when the data considered by scheduler_compare_channels() changes

 Can you explain more about what you mean 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] #24668 [Core Tor/Tor]: sched: scheduler_compare_channels() function will never pick a channel with no active circuis.

[Tor Bug Tracker & Wiki]

#24668: sched: scheduler_compare_channels() function will never pick a channel 
with
no active circuis.
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched, tor-channel, tor-cell  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [ticket:24668 dgoulet]:
 > To fix this one, we probably have to fix ewma_cmp_cmux() to look at
 destroy cells too (somehow).

 Yes, agreed.

 I assume this bug was introduced by our destroy cell queue fix from #7912
 (when we separated queued destroy cells from queued other-types-of-cells).

 How hard would it be to add the circuit to the active_circuit_pqueue when
 it has a non-empty destroy queue? Then it would at least get a chance to
 be considered, even if we aren't load balancing in an optimal way
 (whatever that means) between sending data cells and destroy cells.

 Looking more at #7912, it seems like we think we already did this. So
 maybe there is some simple bug somewhere in the current code where it
 doesn't get triggered correctly, rather than a fundamentally broken
 design?

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

Re: [tor-bugs] #24667 [Core Tor/Tor]: OOM needs to consider the DESTROY queued cells

[Tor Bug Tracker & Wiki]

#24667: OOM needs to consider the DESTROY queued cells
+--
 Reporter:  dgoulet |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-cell, tor-circuit, oom  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by arma):

 Replying to [comment:1 arma]:
 > So, silently dropping destroy cells seems really bad and like we should
 really try to avoid it.
 >
 > While we're at it, we might want to get rid of the "send a truncate cell
 toward the client, and then let the client actually destroy the circuit"
 design.

 Do we have a similar issue to the "dropping destroy cells" issue here,
 where we queue up some truncated cells, and then the oom killer kills them
 before they go out, and then we've essentially dropped those truncated
 cells? In theory this one isn't so bad, since the client should eventually
 try to close the circuit too. But it's another instance where the two
 sides can become unsynced because we are mixing data and control cells on
 the same level. And it would be (much closer to) resolved by opting to get
 rid of the truncated/destroy/destroyed dance.

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

Re: [tor-bugs] #24667 [Core Tor/Tor]: OOM needs to consider the DESTROY queued cells

[Tor Bug Tracker & Wiki]

#24667: OOM needs to consider the DESTROY queued cells
+--
 Reporter:  dgoulet |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-cell, tor-circuit, oom  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by arma):

 Replying to [ticket:24667 dgoulet]:
 > But also not sending those will affects other relays hanging on dead
 circuits.

 Yeah, this is an ugly one. I was first thinking about the case where a
 relay doesn't send back a destroy cell towards the client, so the client
 ends up with an out-of-sync idea of what the circuit looks like. But in
 that case, eventually the client might still try to close the circuit, and
 things will take care of themselves.

 Where it gets really ugly is if the relay doesn't send a destroy *forward*
 on a circuit. Then the circuit essentially lives forever on the later
 relays. It will only be when the orconn that would have sent the destroy
 cell dies that the next relay will notice.

 (If some other orconn on the dangling circuit dies, it could still trigger
 splintered dangling circuits: the relay on the client side of the broken
 orconn will send a truncated data cell towards the client, which will just
 be ignored since there's no circuit that it corresponds to. And then the
 splintered dangling circuit will live forever because nobody will ever
 know to tell it to go away.)

 So, silently dropping destroy cells seems really bad and like we should
 really try to avoid it.

 One option is to queue them somewhere, using the more efficient queue that
 we put in with #24666, and then send them over the next "little while".
 That is, it's not critical to send them immediately, so long as they are
 sent sometime.

 Another option would be to rotate the long-term ORConn once an event has
 happened that caused us to drop destroy requests. That is, try to work
 towards closing the orconn, which will trigger destruction of the
 remaining circuits. But if even one long-lived circuit remains, that
 option is not so great, since it could remain for days or even weeks.

 What do we know about the pattern of destroys when we are reacting to an
 oom case? For example, do we end up making decisions like "close all the
 circuits to that relay"? In that case we could close the entire orconn,
 right there, rather than sending thousands of destroy cells. We'd probably
 want to mark it for flush for a little while so its current contents have
 a chance to go out, but that approach seems workable *if* that's the
 pattern of destroys that we want to make.

 Another option would be to make multidestroy cells that give you a huge
 pile of circids+reasons in a single cell -- basically extend the notion of
 the destroy queue into something that you can transport wholesale to a
 neighbor relay.

 Another option would be to make a destroy-except cell, where if you want
 to close a big pile of circids but leave a few open, you send over the
 ones *not* to destroy.

 While we're at it, we might want to get rid of the "send a truncate cell
 toward the client, and then let the client actually destroy the circuit"
 design. We built Tor that way so that clients could choose to have some
 smarter reaction in the future, like re-extending the circuit to some
 different next hop. But in practice we haven't figured out a smarter
 reaction that doesn't draw in a lot of complexity in terms of anonymity
 analysis, so maybe we should opt to simplify the design (and thus reduce
 network load).

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

Re: [tor-bugs] #18361 [Applications/Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 https://addons.mozilla.org/en-US/firefox/addon/block-cloudflare-mitm-
 attack/

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

Re: [tor-bugs] #24701 [Obfuscation/BridgeDB]: Unhandled error on extracting CAPTCHA solution from malicious requests

[Tor Bug Tracker & Wiki]

#24701: Unhandled error on extracting CAPTCHA solution from malicious requests
--+--
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  bridgedb-https|  Actual Points:
Parent ID:| Points:  .5
 Reviewer:|Sponsor:  SponsorV
--+--
Changes (by isis):

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


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

Re: [tor-bugs] #24701 [Obfuscation/BridgeDB]: Unhandled error on extracting CAPTCHA solution from malicious requests

[Tor Bug Tracker & Wiki]

#24701: Unhandled error on extracting CAPTCHA solution from malicious requests
--+--
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:  bridgedb-https|  Actual Points:
Parent ID:| Points:  .5
 Reviewer:|Sponsor:  SponsorV
--+--

Comment (by isis):

 Replying to [comment:1 isis]:
 > Fixed in my `fix/24701`
 [https://gitweb.torproject.org/user/isis/bridgedb.git/log/?h=fix/24701
 branch], along with a "creative" way to punish the bots sending the
 malicious requests.

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

Re: [tor-bugs] #24701 [Obfuscation/BridgeDB]: Unhandled error on extracting CAPTCHA solution from malicious requests

[Tor Bug Tracker & Wiki]

#24701: Unhandled error on extracting CAPTCHA solution from malicious requests
--+--
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal| Resolution:
 Keywords:  bridgedb-https|  Actual Points:
Parent ID:| Points:  .5
 Reviewer:|Sponsor:  SponsorV
--+--

Comment (by isis):

 Fixed in my `fix/24701`
 [https://gitweb.torproject.org/user/isis/bridgedb.git/log/?h=fix/24701
 branch]

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

Re: [tor-bugs] #24704 [Obfuscation/BridgeDB]: Filter returned bridges such that there is a max of one per /16 or /32

[Tor Bug Tracker & Wiki]

#24704: Filter returned bridges such that there is a max of one per /16 or /32
---+--
 Reporter:  isis   |  Owner:  isis
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:
Component:  Obfuscation/BridgeDB   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  bridgedb-distributors  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:  SponsorV
---+--
Changes (by isis):

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


Comment:

 Fixed in my `fix/24704`
 [https://gitweb.torproject.org/user/isis/bridgedb.git/log/?h=fix/24704
 branch].

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

Re: [tor-bugs] #22321 [Core Tor/Fallback Scripts]: Update fallback directory whitelist based on operator relay changes

[Tor Bug Tracker & Wiki]

#22321: Update fallback directory whitelist based on operator relay changes
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22271 | Points:  1
 Reviewer: |Sponsor:
---+---

Comment (by Sebastian):

 Replying to [comment:23 teor]:
 > Replying to [comment:22 Sebastian]:
 > > F8D27B163B9247B232A2EEE68DD8B698695C28DE has stable ipv6
 >
 > Please see my branch fallback_whiteblack_changes, which contains all of
 pastly's changes, the opt-ins for the last day, including all tor-relays
 emails, emails direct to me, child tickets and the IPv6 fixup in comment
 22.
 >
 > I expect we'll get a few more opt-ins over the next few days.
 > That's ok, because we need to merge some code changes as well.

 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] #22321 [Core Tor/Fallback Scripts]: Update fallback directory whitelist based on operator relay changes

[Tor Bug Tracker & Wiki]

#22321: Update fallback directory whitelist based on operator relay changes
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22271 | Points:  1
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 Replying to [comment:22 Sebastian]:
 > F8D27B163B9247B232A2EEE68DD8B698695C28DE has stable ipv6

 Please see my branch fallback_whiteblack_changes, which contains all of
 pastly's changes, the opt-ins for the last day, including all tor-relays
 emails, emails direct to me, child tickets and the IPv6 fixup in comment
 22.

 I expect we'll get a few more opt-ins over the next few days.
 That's ok, because we need to merge some code changes as well.

 pastly, the script works for me, did you run it from the tor directory?
 Because running it from tor/scripts/maint doesn't work with the file
 paths.
 {{{
 WHITELIST_FILE_NAME = 'scripts/maint/fallback.whitelist'
 BLACKLIST_FILE_NAME = 'scripts/maint/fallback.blacklist'
 FALLBACK_FILE_NAME  = 'src/or/fallback_dirs.inc'
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24706 [Core Tor/Fallback Scripts]: Add a script that creates fallback directory whitelist entries

[Tor Bug Tracker & Wiki]

#24706: Add a script that creates fallback directory whitelist entries
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal |   Keywords:
Actual Points:  0.2|  Parent ID:  #22321
   Points:  0.2|   Reviewer:
  Sponsor: |
---+---
 I've finally got sick of doing these by hand.

 Thanks to John Ricketts for inspiring this change, by sending me a list of
 ~30 potential fallbacks.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24705 [Core Tor/Stem]: stem's get_consensus().run() always returns a list, but DocumentHandler implies it returns an object

[Tor Bug Tracker & Wiki]

#24705: stem's get_consensus().run() always returns a list, but DocumentHandler
implies it returns an object
---+
 Reporter:  teor   |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 When I read the stem DocumentHandler documentation for DOCUMENT, it syas
 that it returns a NetworkStatusDocument:

 
https://stem.torproject.org/api/descriptor/descriptor.html#stem.descriptor.__init__.DocumentHandler

 But when I call:
 {{{
 stem.descriptor.remote.get_consensus(document_handler='DOCUMENT').run()
 }}}

 It actually returns a list of NetworkStatusDocuments with one entry.

 I understand why this happens (you might be reading a list of
 consensuses), but it's confusing.

 Please document this behaviour in one or more of get_consensus(), run(),
 or DocumentHandler DOCUMENT/BARE_DOCUMENT.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24704 [Obfuscation/BridgeDB]: Filter returned bridges such that there is a max of one per /16 or /32

[Tor Bug Tracker & Wiki]

#24704: Filter returned bridges such that there is a max of one per /16 or /32
--+---
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal|   Keywords:  bridgedb-distributors
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:  SponsorV  |
--+---
 To avoid certain issues, we should probably be avoiding handing bridges
 within the same IPv4/16 or IPv6/32 to the same user.

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

Re: [tor-bugs] #22321 [Core Tor/Fallback Scripts]: Update fallback directory whitelist based on operator relay changes

[Tor Bug Tracker & Wiki]

#22321: Update fallback directory whitelist based on operator relay changes
---+---
 Reporter:  teor   |  Owner:  teor
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22271 | Points:  1
 Reviewer: |Sponsor:
---+---

Comment (by Sebastian):

 F8D27B163B9247B232A2EEE68DD8B698695C28DE has stable ipv6

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

Re: [tor-bugs] #24695 [Core Tor/Fallback Scripts]: Fallback blacklist removal for 1C90D3AEADFF3BCD079810632C8B85637924A58E

[Tor Bug Tracker & Wiki]

#24695: Fallback blacklist removal for 1C90D3AEADFF3BCD079810632C8B85637924A58E
---+---
 Reporter:  hardlined  |  Owner:  teor
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback-change|  Actual Points:
Parent ID:  #22321 | Points:  0.1
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 Thanks!
 We'll track this as part of #22321.

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

Re: [tor-bugs] #24135 [Core Tor/Fallback Scripts]: fluxe4 (a fallback dir) has stable ipv6

[Tor Bug Tracker & Wiki]

#24135: fluxe4 (a fallback dir) has stable ipv6
---+---
 Reporter:  Sebastian  |  Owner:  pastly
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22321 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

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


Comment:

 pastly did this in #22321, let's track it there.

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

Re: [tor-bugs] #24695 [Core Tor/Fallback Scripts]: Fallback blacklist removal for 1C90D3AEADFF3BCD079810632C8B85637924A58E

[Tor Bug Tracker & Wiki]

#24695: Fallback blacklist removal for 1C90D3AEADFF3BCD079810632C8B85637924A58E
---+---
 Reporter:  hardlined  |  Owner:  teor
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback-change|  Actual Points:
Parent ID:  #22321 | Points:  0.1
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * status:  new => assigned
 * owner:  (none) => teor
 * points:   => 0.1
 * parent:   => #22321
 * milestone:   => Tor: 0.3.3.x-final


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

Re: [tor-bugs] #22145 [Core Tor/Tor]: Document which interface is used for DNS requests in the context of OutboundBindAddressOR/Exit

[Tor Bug Tracker & Wiki]

#22145: Document which interface is used for DNS requests in the context of
OutboundBindAddressOR/Exit
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.6
 Severity:  Normal| Resolution:
 Keywords:  easy tor-doc manpage  |  Actual Points:
Parent ID:| Points:  .5
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Please see my branch bug22145_032, which squashes the patches in this
 ticket.

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

Re: [tor-bugs] #24703 [Core Tor/Tor]: Document IPv6Exit in the sample torrcs

[Tor Bug Tracker & Wiki]

#24703: Document IPv6Exit in the sample torrcs
+
 Reporter:  teor|  Owner:  teor
 Type:  enhancement | Status:  merge_ready
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.2.4.7-alpha
 Severity:  Normal  | Resolution:
 Keywords:  ipv6, tor-exit  |  Actual Points:  0.1
Parent ID:  | Points:  0.1
 Reviewer:  |Sponsor:
+
Changes (by teor):

 * status:  assigned => merge_ready
 * actualpoints:   => 0.1


Comment:

 Please see my branch bug24703_032.
 It includes a commit that documents the OutboundBindAddress DNS exception
 from #22145.

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

Re: [tor-bugs] #23881 [Core Tor/Tor]: Implement a way to utilise tor's logging system from Rust code

[Tor Bug Tracker & Wiki]

#23881: Implement a way to utilise tor's logging system from Rust code
--+
 Reporter:  isis  |  Owner:  chelseakomlo
 Type:  enhancement   | Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust, rust-pilot  |  Actual Points:
Parent ID:| Points:  3
 Reviewer:|Sponsor:
--+

Comment (by chelseakomlo):

 Replying to [comment:18 manish.earth]:
 > Alternatively, have a `static FOO: *const YourType = 0 as *const _;` and
 allocate it at the beginning of the test program. That's basically what
 lazy_static does, except lazily.

 Good suggestion- I took a stab at implementing something similar to what
 lazy_static does (declare a static mutable pointer and allocate data on
 the heap during assignment). As this code is purely for testing, I don't
 have as many safety checks, but open to feedback.

 See commit 4cdf0c8899796582b058d289bcd21b95dd1bd452.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24703 [Core Tor/Tor]: Document IPv6Exit in the sample torrcs

[Tor Bug Tracker & Wiki]

#24703: Document IPv6Exit in the sample torrcs
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.4.7-alpha
 Severity:  Normal|   Keywords:  ipv6, tor-exit
Actual Points:|  Parent ID:
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+
 We could backport this to 0.3.2 if we want to get it in the next release.

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

Re: [tor-bugs] #21995 [Core Tor/Torflow]: Set PreferIPv6 on Bandwidth Scanner SOCKSPorts

[Tor Bug Tracker & Wiki]

#21995: Set PreferIPv6 on Bandwidth Scanner SOCKSPorts
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Torflow  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 PreferIPv6 is the default in recent Tor versions.

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

Re: [tor-bugs] #24702 [Applications/Tor Browser]: Remove Mozilla matching text from Tor Browser banner

[Tor Bug Tracker & Wiki]

#24702: Remove Mozilla matching text from Tor Browser banner
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201712R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arthuredelstein):

 * keywords:   => TorBrowserTeam201712R
 * status:  new => needs_review


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

Re: [tor-bugs] #24702 [Applications/Tor Browser]: Remove Mozilla matching text from Tor Browser banner

[Tor Bug Tracker & Wiki]

#24702: Remove Mozilla matching text from Tor Browser banner
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arthuredelstein):

 Here's a patch for review:
 https://github.com/arthuredelstein/torbutton/commit/24702

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24702 [Applications/Tor Browser]: Remove Mozilla matching text from Tor Browser banner

[Tor Bug Tracker & Wiki]

#24702: Remove Mozilla matching text from Tor Browser banner
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 The Mozilla donation matching program is completing at the end of 2017.
 While we can continue the fundraising into January, we should remove the
 comment that Mozilla will match funds.

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

Re: [tor-bugs] #24423 [Core Tor/Tor]: Fix STACK warnings in Tor

[Tor Bug Tracker & Wiki]

#24423: Fix STACK warnings in Tor
-+
 Reporter:  nickm|  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-27  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  catalyst |Sponsor:
-+
Changes (by catalyst):

 * status:  needs_review => needs_revision


Comment:

 The one_more_stack_fix changes probably aren't necessary on master.  I
 think STACK wouldn't complain about the `tt_assert(ch)` calls because they
 don't come after dereferences of `ch`.  The redundant check in the cleanup
 of `test_channel_flushmux()` on 0.3.2 probably should still be deleted if
 we would like to make 0.3.2 STACK-clean.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24701 [Obfuscation/BridgeDB]: Unhandled error on extracting CAPTCHA solution from malicious requests

[Tor Bug Tracker & Wiki]

#24701: Unhandled error on extracting CAPTCHA solution from malicious requests
--+
 Reporter:  isis  |  Owner:  isis
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/BridgeDB  |Version:
 Severity:  Normal|   Keywords:  bridgedb-https
Actual Points:|  Parent ID:
   Points:  .5|   Reviewer:
  Sponsor:  SponsorV  |
--+
 {{{
 Unhandled Error
 Traceback (most recent call last):
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python2.7/site-
 packages/twisted/protocols/basic.py", line 571, in dataReceived
 why = self.lineReceived(line)
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python2.7/site-
 packages/twisted/web/http.py", line 1688, in lineReceived
 self.allContentReceived()
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python2.7/site-
 packages/twisted/web/http.py", line 1767, in allContentReceived
 req.requestReceived(command, path, version)
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python2.7/site-
 packages/twisted/web/http.py", line 768, in requestReceived
 self.process()
 ---  ---
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python2.7/site-
 packages/twisted/web/server.py", line 183, in process
 self.render(resrc)
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python2.7/site-
 packages/twisted/web/server.py", line 234, in render
 body = resrc.render(self)
   File "/home/bridgedb/virtualenvs/bridgedb/lib/python2.7/site-
 packages/twisted/web/resource.py", line 250, in render
 return m(request)
   File "/home/bridgedb/virtualenvs/bridgedb/local/lib/python2.7/site-
 packages/bridgedb-0.6.2+0.g6ace9a3.dirty-
 py2.7.egg/bridgedb/distributors/https/server.py", line 614, in render_POST
 return CaptchaProtectedResource.render_POST(self, request)
   File "/home/bridgedb/virtualenvs/bridgedb/local/lib/python2.7/site-
 packages/bridgedb-0.6.2+0.g6ace9a3.dirty-
 py2.7.egg/bridgedb/distributors/https/server.py", line 480, in render_POST
 if self.checkSolution(request) is True:
   File "/home/bridgedb/virtualenvs/bridgedb/local/lib/python2.7/site-
 packages/bridgedb-0.6.2+0.g6ace9a3.dirty-
 py2.7.egg/bridgedb/distributors/https/server.py", line 540, in
 checkSolution
 challenge, solution = self.extractClientSolution(request)
 exceptions.ValueError: too many values to unpack

 }}}

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

Re: [tor-bugs] #22145 [Core Tor/Tor]: Document which interface is used for DNS requests in the context of OutboundBindAddressOR/Exit

[Tor Bug Tracker & Wiki]

#22145: Document which interface is used for DNS requests in the context of
OutboundBindAddressOR/Exit
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.6
 Severity:  Normal| Resolution:
 Keywords:  easy tor-doc manpage  |  Actual Points:
Parent ID:| Points:  .5
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_revision => merge_ready


Comment:

 Thanks! This looks good.
 We don't need a changes file, because it's a documentation-only change,

 We will need to squash all the patch files attacked to this ticket to get
 the final commit,

 In future, for small commits like this, can you put all the changes in
 each patch file?
 That makes it easier for us to squash.

 Or, you can tell us a branch on a public git repository, like github,com.
 Branches are also easy to squash.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #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.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal|   Keywords:  tor-sched, kist
Actual Points:|  Parent ID:
   Points:|   Reviewer:  #23993
  Sponsor:|
--+
 Here is the flow for this to happen (and it has been observed):

 The scheduler flushes 100 bytes onto the outbuf of a channel. Then the
 channel it put in the re-add list (which is to add back the channel in the
 pending list at the _end_ of the scheduler loop) because it can't write
 anymore. Its state is set to `waiting_to_write`.

 We then handle the next channel in the main loop but before that we'll try
 to write to kernel the outbuf of the previous channel which is in the re-
 add list.

 If the outbuf is fully drained, `scheduler_channel_wants_writes()` is
 called which will add the channel back in the pending list *IF* it is in
 the `waiting_to_write` state which it is because it was set to that state
 just before being added to the re-add list.

 Scheduler loop ends and we end up with twice the channel in the pending
 list. This can go on for a while resulting in the same channel being added
 many more times.

 There are two ways to fix that, one quick and one more logical.

 1. The quick one is to let the state of the channel in PENDING mode (which
 is what Vanilla does) before adding it to the re-add list. That way, it
 won't get added back in the pending list by any callbacks.

 2. Originally, the assumption was that KIST takes care of the write on the
 socket and only KIST. But the reality is different, KIST will trigger
 writes to the kernel but anything after that, any errors or retry is
 handled by libevent `write_event` (#24448, and #24449).

  So, it doesn't make sense for KIST to reschedule the channel as pending
 if it is waiting to write on the socket because from that point on, it
 will be the job of libevent to actually flush it with its `poll(POLLOUT)`
 feature. Thus the fix is to never add back a channel that is waiting to
 write.

 I personally would like to have (2) for two reasons. First, we would save
 CPU time and useless syscalls in this fast path. Second, adding a channel
 that is waiting to write back into the pending list is not really good in
 terms of priority. It should not get considered for another round in the
 loop, it should simply wait until the socket has been written since the
 assumption in (2) is false in the first place.

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

Re: [tor-bugs] #9390 [Core Tor/Tor]: Warn if you're being a public relay but have too-low file descriptor limit

[Tor Bug Tracker & Wiki]

#9390: Warn if you're being a public relay but have too-low file descriptor 
limit
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay easy dos resources |  Actual Points:
  logging|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 I'm sorry, this code isn't at the end of the function. And does it
 compile? It looks like it has an extra closing brace.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24699 [Applications/Tor Browser]: Torbrowser keeps crashing/ hanging and freezing, plus it takes a very long time to load after hibernation

[Tor Bug Tracker & Wiki]

#24699: Torbrowser keeps crashing/ hanging and freezing, plus it takes a very 
long
time to load after hibernation
-+-
 Reporter:  justmeee |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Immediate|  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  Torbrowser, freezing,
 Severity:  Critical |  frozen, lock, broken, hanging,
 |  crash
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Using Windows 7, 64-bit

 I've had these same problems on two different laptops, both running
 Windows 7, 64-bit.

 The past several versions of Torbrowser, including the recent 7.0.11 and
 7.5a.9, the browser keeps hanging up and freezing.

 When the tabs are frozen, sometimes I can ctrl+tab to the next one, but
 the screen will be white and the address in the bar doesn't change, so
 it's not really changing tabs even though the highlighted tab changes.

 Also, sometimes the window will additionally be on top of everything else
 when it's not supposed to be and I can't view any other windows.  It won't
 restore to NOT being in front of every other program, and with it being
 frozen or hanging I will have to close it and start all over.

 Additionally, when it does work it takes a very long time to load from
 hibernation to get to a point where the tabs function properly, sometimes
 as much as 20 minutes (with approx 15 open tabs, and that's really not
 many).


 I will often have several tabs open and need to hibernate the computer to
 finish later.  These problems typically occur after returning from
 hibernating.  This keeps costing me hours of lost work.

 I have Not had this problem with other browsers using as many as 25 open
 tabs. So this is definitely a Torbrowser issue, and my preference is to
 use Torbrowser so hopefully this can be fixed soon.

 I have tried reporting these issues several times before but have
 apparently not been in the right place so I hope this is the correct
 location to report these bugs so it can be fixed.

 Thanks very much.

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

Re: [tor-bugs] #24001 [Core Tor/Tor]: node_get_ed25519_id() should check if the microdesc ed25519 id is all zero

[Tor Bug Tracker & Wiki]

#24001: node_get_ed25519_id() should check if the microdesc ed25519 id is all 
zero
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy intro|  Actual Points:
Parent ID:  #23975| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Please attach a working patch that contains all your changes

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

Re: [tor-bugs] #24698 [Applications/Tor Browser]: Torbrowser keeps hanging and freezing, plus it takes a very long time to load after hibernation

[Tor Bug Tracker & Wiki]

#24698: Torbrowser keeps hanging and freezing, plus it takes a very long time to
load after hibernation
-+-
 Reporter:  justmeee |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  Torbrowser, freezing, frozen, lock,  |  Actual Points:
  broken, hanging, crash |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by justmeee):

 I have Not had this problem with other browsers using as many as 25 open
 tabs.  So this is definitely a Torbrowser issue, and my preference is to
 use Torbrowser so hopefully this can be fixed soon.  Thank you.

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

[tor-bugs] #24698 [Applications/Tor Browser]: Torbrowser keeps hanging and freezing, plus it takes a very long time to load after hibernation

[Tor Bug Tracker & Wiki]

#24698: Torbrowser keeps hanging and freezing, plus it takes a very long time to
load after hibernation
-+-
 Reporter:  justmeee |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor |Version:
  Browser|   Keywords:  Torbrowser, freezing,
 Severity:  Major|  frozen, lock, broken, hanging,
 |  crash
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Using Windows 7, 64-bit

 I've had these same problems on two different laptops, both running
 Windows 7, 64-bit.

 The past several versions of Torbrowser, including the recent 7.0.11 and
 7.5a.9, the browser keeps hanging up and freezing.

 When the tabs are frozen, sometimes I can ctrl+tab to the next one, but
 the screen will be white and the address in the bar doesn't change, so
 it's not really changing tabs even though the highlighted tab changes.

 Also, sometimes the window will additionally be on top of everything else
 when it's not supposed to be and I can't view any other windows.  It won't
 restore to NOT being in front of every other program, and with it being
 frozen or hanging I will have to close it and start all over.

 Additionally, when it does work it takes a very long time to load from
 hibernation to get to a point where the tabs function properly, sometimes
 as much as 20 minutes (with approx 15 open tabs, and that's really not
 many).


 I will often have several tabs open and need to hibernate the computer to
 finish later.  These problems typically occur after returning from
 hibernating.  This keeps costing me hours of lost work.

 I have tried reporting these issues several times before but have
 apparently not been in the right place so I hope this is the correct
 location to report these bugs so it can be fixed.

 Thanks very much.

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

Re: [tor-bugs] #23047 [Internal Services/Tor Sysadmin Team]: Please add iwakeh to the onionoo, metrics, and exonerator groups

[Tor Bug Tracker & Wiki]

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

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


Comment:

 That ticket should not have been reopened.  You already are a member of
 all the groups that were asked for.

 (That meronense hadn't successfully ran ud-replicate would have warranted
 its own ticket.)

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

Re: [tor-bugs] #22145 [Core Tor/Tor]: Document which interface is used for DNS requests in the context of OutboundBindAddressOR/Exit

[Tor Bug Tracker & Wiki]

#22145: Document which interface is used for DNS requests in the context of
OutboundBindAddressOR/Exit
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.6
 Severity:  Normal| Resolution:
 Keywords:  easy tor-doc manpage  |  Actual Points:
Parent ID:| Points:  .5
 Reviewer:|Sponsor:
--+

Comment (by aruna1234):

 Doc edited by mentioning in OutboundBindAddress that it is not used for
 DNS Requests.

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

Re: [tor-bugs] #22145 [Core Tor/Tor]: Document which interface is used for DNS requests in the context of OutboundBindAddressOR/Exit

[Tor Bug Tracker & Wiki]

#22145: Document which interface is used for DNS requests in the context of
OutboundBindAddressOR/Exit
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.6
 Severity:  Normal| Resolution:
 Keywords:  easy tor-doc manpage  |  Actual Points:
Parent ID:| Points:  .5
 Reviewer:|Sponsor:
--+
Changes (by aruna1234):

 * Attachment "0008-Doc-edited-specifying-DNS-requests.patch" added.


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

Re: [tor-bugs] #9390 [Core Tor/Tor]: Warn if you're being a public relay but have too-low file descriptor limit

[Tor Bug Tracker & Wiki]

#9390: Warn if you're being a public relay but have too-low file descriptor 
limit
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay easy dos resources |  Actual Points:
  logging|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by aruna1234):

 Added the check and the code at the end of set_max_file_descriptors().

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

Re: [tor-bugs] #9390 [Core Tor/Tor]: Warn if you're being a public relay but have too-low file descriptor limit

[Tor Bug Tracker & Wiki]

#9390: Warn if you're being a public relay but have too-low file descriptor 
limit
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay easy dos resources |  Actual Points:
  logging|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by aruna1234):

 * Attachment "0009-Check-for-publiic-relay-added.patch" added.


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

Re: [tor-bugs] #24697 [Webpages/Website]: Hide Mozilla matching text once it's 2018

[Tor Bug Tracker & Wiki]

#24697: Hide Mozilla matching text once it's 2018
--+--
 Reporter:  arthuredelstein   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #23482| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arthuredelstein):

 * status:  new => needs_review
 * cc: hiro (added)


Comment:

 hiro, could you review/merge this patch? Thank you!

 https://github.com/arthuredelstein/webml/commit/24697

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

Re: [tor-bugs] #22814 [Applications/Tor Browser]: Disable clipboard.autocopy in Tor Browser

[Tor Bug Tracker & Wiki]

#22814: Disable clipboard.autocopy in Tor Browser
--+--
 Reporter:  pqrst |  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-pref, tbb-easy|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * keywords:   => tbb-pref, tbb-easy


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24697 [Webpages/Website]: Hide Mozilla matching text once it's 2018

[Tor Bug Tracker & Wiki]

#24697: Hide Mozilla matching text once it's 2018
--+
 Reporter:  arthuredelstein   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #23482
   Points:|   Reviewer:
  Sponsor:|
--+
 The Mozilla matching program finishes at the end of 2017. (Thanks,
 Mozilla!) We should remove the text about that from our homepage donation
 banner.

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

Re: [tor-bugs] #24001 [Core Tor/Tor]: node_get_ed25519_id() should check if the microdesc ed25519 id is all zero

[Tor Bug Tracker & Wiki]

#24001: node_get_ed25519_id() should check if the microdesc ed25519 id is all 
zero
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy intro|  Actual Points:
Parent ID:  #23975| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by aruna1234):

 Replying to [comment:6 teor]:
 > I think it would be a good idea to check both the ri and md ed25519 ids
 to see if the memory they point to is zero.
 >
 > Can you copy the check from the ri ed25519 id to the md ed25519 id?
 also did this,

 if (BUG(ed25519_public_key_is_zero(md_pk)))
 md_pk = NULL;
 this is passing all tests when I run a make check

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

Re: [tor-bugs] #24001 [Core Tor/Tor]: node_get_ed25519_id() should check if the microdesc ed25519 id is all zero

[Tor Bug Tracker & Wiki]

#24001: node_get_ed25519_id() should check if the microdesc ed25519 id is all 
zero
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy intro|  Actual Points:
Parent ID:  #23975| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by aruna1234):

 Replying to [comment:8 teor]:
 > That checks if the first byte of the object is zero. We need to check if
 every byte is zero.
 > We have a function for that, I think it's called tor_mem_is_zero().
 I added this,
 if(tor_mem_is_zero((char*)node->md,
 sizeof(node->md->ed25519_identity_pkey)))

 however it is failing when I do a make check at src/test/test.

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

Re: [tor-bugs] #24555 [Core Tor/Tor]: Bug: tor_gmtime_r overflow - gmtime(9223372036854775807) failed with error No error

[Tor Bug Tracker & Wiki]

#24555: Bug: tor_gmtime_r overflow - gmtime(9223372036854775807) failed with 
error
No error
-+-
 Reporter:  s7r  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  integer-overflow time-overflow tor-  |  Actual Points:
  relay 2038-problem |
Parent ID:  #18480   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 I hit this too just now on my fast relay.

 My only hint is that maybe I was out of file descriptors at the time.

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

Re: [tor-bugs] #24696 [Applications/Tor Launcher]: Moat: network activity SVG needed for Tor Launcher

[Tor Bug Tracker & Wiki]

#24696: Moat: network activity SVG needed for Tor Launcher
---+--
 Reporter:  mcs|  Owner:  antonela
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID:  #24689 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by mcs):

 I forgot to mention that this is not urgent. The earliest that this
 feature will reach end-users is mid-to-late January 2018 that that will be
 an alpha release of Tor Browser. The placeholder image that we already
 have will work for such a release.

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

Re: [tor-bugs] #24696 [Applications/Tor Launcher]: Moat: network activity SVG needed for Tor Launcher

[Tor Bug Tracker & Wiki]

#24696: Moat: network activity SVG needed for Tor Launcher
---+--
 Reporter:  mcs|  Owner:  antonela
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID:  #24689 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by mcs):

 Our placeholder SVG is here:
 https://gitweb.torproject.org/user/brade/tor-
 launcher.git/tree/src/chrome/skin/activity.svg?h=bug23136-01

 Currently the image temporarily replaces the reload CAPTCHA button that is
 shown in the following image:
 https://trac.torproject.org/projects/tor/attachment/ticket/23136/moat-
 Dec8-A-prompt.png

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24696 [Applications/Tor Launcher]: Moat: network activity SVG needed for Tor Launcher

[Tor Bug Tracker & Wiki]

#24696: Moat: network activity SVG needed for Tor Launcher
---+--
 Reporter:  mcs|  Owner:  antonela
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal |   Keywords:  ux-team
Actual Points: |  Parent ID:  #24689
   Points: |   Reviewer:
  Sponsor: |
---+--
 As part of the work that Kathy and I did for #23136, we added an SVG that
 is displayed while the Tor Launcher code is waiting for a response from
 the network. The image we currently have is a placeholder (just a vertical
 line) and it would be nice to have something that looks better. The
 placeholder image is displayed at 20 x 20 pixels and it is animated using
 an infinite rotation.

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

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201712   |  Actual Points:
Parent ID:  #24689 | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--

Comment (by mcs):

 So that the code exists on a TPO server, Kathy and I pushed our
 development branch. Due to important dependencies such as #24614 and the
 fact that we do not yet have a public BridgeDB server to test against, it
 is probably not worthwhile for other people to try to use this yet. But if
 you want to take an early look, it is here:
 https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug23136-01=2018ac999fdaf54f00b3e3a303d167d02086e29b

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

Re: [tor-bugs] #22960 [Applications/Tor Browser]: Tor Browser is leaking IPC messages

[Tor Bug Tracker & Wiki]

#22960: Tor Browser is leaking IPC messages
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-e10s, tbb-crash, tbb-oom  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * priority:  Medium => High
 * severity:  Normal => Major


Comment:

 Unfortunately, this happens pretty often when you switch tabs on the
 latest alpha. If it happens when a child process lost connection to the
 parent, ipc queue is empty on the parent side, but it grows on the child
 side.

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

Re: [tor-bugs] #24694 [Core Tor/Tor]: sched: Use the socket RTT in KIST to compute a more accurate extra space

[Tor Bug Tracker & Wiki]

#24694: sched: Use the socket RTT in KIST to compute a more accurate extra space
-+
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, kist  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by yawning):

 ISTR suggesting to look at `tcpi_snd_ssthresh` as well back in the
 original KIST ticket as well, but I'll bring it up because this ticket is
 about "making better capacity decisions".

 While my suggestion was to increase the scheduling frequency for a
 connection while it was in Slow Start (because `SND.CWND` will double on
 each ACK), instead I would probably be less aggressive about feeding a
 connection more data while `SND.CWND < ssthresh` (because `SND.CWND` will
 overshoot what is possible by the link and you're way over buffered at
 that point).

 My assertion here is that while a connection is in slow start, the
 congestion window is an insufficiently accurate estimate of actual link
 capacity to serve as a good measure for how much buffering to do.

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

Re: [tor-bugs] #24415 [Applications/Tor Browser]: Unhandled exception at 0x6850687D (d2d1.dll) in firefox.exe (was: Tor crashes when opening new tab, reason unknown)

[Tor Bug Tracker & Wiki]

#24415: Unhandled exception at 0x6850687D (d2d1.dll) in firefox.exe
--+---
 Reporter:  kouwei32  |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 Replying to [ticket:24415 kouwei32]:
 > Tor stops working when opening new tab. I don't know why, but I have the
 debug report from Visual Studio: Unhandled exception at 0x6850687D
 (d2d1.dll) in firefox.exe: 0xC005: Access violation writing location
 0x6DCAC3F0.
 Tor is not a browser. Firefox tries to detect graphics features when
 opening new tab. Unfortunately, it activates "hardware acceleration" for
 it even when it's disabled. So, the only question here is whether Firefox
 handles this exception by design (but tbb doesn't support seh) or it's a
 bug in your setup.
 > The first tab is still completely usable, and other features are
 accessible too.
 > Version is the latest at the time of ticket creation but number is
 unknown because unable to open settings.
 So, actually, "Tor" doesn't crash, right? (only one thread crashed)

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

Re: [tor-bugs] #24694 [Core Tor/Tor]: sched: Use the socket RTT in KIST to compute a more accurate extra space

[Tor Bug Tracker & Wiki]

#24694: sched: Use the socket RTT in KIST to compute a more accurate extra space
-+
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, kist  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by yawning):

 * cc: yawning (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] #24671 [Core Tor/Tor]: sched: KISTLite should set an upper limit to write on the outbuf

[Tor Bug Tracker & Wiki]

#24671: sched: KISTLite should set an upper limit to write on the outbuf
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-sched, dos, tor-channel  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  merge_ready => 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] #24260 [Metrics/Website]: Add metrics timeline events underneath graphs

[Tor Bug Tracker & Wiki]

#24260: Add metrics timeline events underneath graphs
--+--
 Reporter:  karsten   |  Owner:  metrics-team
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Metrics/Website   |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team metrics-timeline  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by karsten):

 * status:  merge_ready => needs_review


Comment:

 Please review [https://gitweb.torproject.org/karsten/metrics-
 web.git/commit/?h=task-24260-2=4510449926e96ca8ccf19ab29919e1bf1928e6a3
 commit 4510449 in my branch task-24260-2] which adapts the new format to
 the News page:

 [[Image(news-adapted-format.png, width=700)]]

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

Re: [tor-bugs] #24260 [Metrics/Website]: Add metrics timeline events underneath graphs

[Tor Bug Tracker & Wiki]

#24260: Add metrics timeline events underneath graphs
--+--
 Reporter:  karsten   |  Owner:  metrics-team
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:
Component:  Metrics/Website   |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team metrics-timeline  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by karsten):

 * Attachment "news-adapted-format.png" added.


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

Re: [tor-bugs] #24637 [Obfuscation/BridgeDB]: moat: incorrect response if no bridges available

[Tor Bug Tracker & Wiki]

#24637: moat: incorrect response if no bridges available
-+-
 Reporter:  mcs  |  Owner:  isis
 Type:  defect   | Status:  closed
 Priority:  Immediate|  Milestone:
Component:  Obfuscation/BridgeDB |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  bridgedb-moat, bridgedb- |  Actual Points:
  distributors   |
Parent ID:  #24689   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorV
-+-

Comment (by mcs):

 Replying to [comment:4 isis]:
 > Fixed in my `fix/24637`
 [https://gitweb.torproject.org/user/isis/bridgedb.git/log/?h=fix/24637
 branch], which includes the following small spec change specifying the
 error:
 > ...

 It looks like that branch has not been pushed to gitweb.tpo yet, although
 I see it on GitHub.

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

Re: [tor-bugs] #24666 [Core Tor/Tor]: sched: Store the circuit ID instead of the full DESTROY cell in the destroy queue

[Tor Bug Tracker & Wiki]

#24666: sched: Store the circuit ID instead of the full DESTROY cell in the 
destroy
queue
-+-
 Reporter:  dgoulet  |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-sched, tor-cell, |  Actual Points:
  backport-031,backport-030, backport-029,   |
  backport-028, backport-025 |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 okay. I made a bug24666_squashed_025 branch, then merged it forward.

 Merge notes:
  * I added `cd1f708a7f44ab305c9fcda0060f55f075b98362` to free the destroy
 cell in the unit test more correctly. Otherwise, coverity would have
 complained that there were paths where it didn't get freed.
  * `7d845976e3897fac8e78a4a26688ac57b660151b` was a trivial merge conflict
 in the unit tests in 0.2.8.
  * `b8a3602b2a7114f2027d4a3af27520b109762efd` had a simple but nontrivial
 merge conflict in `channel_flush_from_first_active_circuit`.
  * We've changed the way that we handle timestamps twice since 0.2.5.  So
 in 0.2.9, I shifted the (as yet unused) timestamp to monotonic msec in
 `79a50afa0e3dd44fc5ef80806ccda501fab5a718`, and in 0.3.3 I shifted it to
 monotonic timestamp units in `1eeb505e6f08591c39e0a000efab3948ef1ef5b5`

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

Re: [tor-bugs] #24665 [Core Tor/Tor]: sched: In KIST, the extra_space kernel value needs to be allowed to be negative

[Tor Bug Tracker & Wiki]

#24665: sched: In KIST, the extra_space kernel value needs to be allowed to be
negative
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  closed
 Priority:  Very High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  merge_ready => 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] #24594 [Core Tor/Tor]: Protocol warning: Expiring stuck OR connection to fd...

[Tor Bug Tracker & Wiki]

#24594: Protocol warning: Expiring stuck OR connection to fd...
-+-
 Reporter:  dgoulet  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, libevent, tor-connection  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 This is at 99% chances that it is related to #24665 which is KIST shoving
 too many bytes in the connection's outbuf.

 Still, I think we could drastically bring this timeout down, 50 minutes is
 too high in my opinion.

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

Re: [tor-bugs] #23101 [Core Tor/Tor]: Predict and build specific HS purpose circuits (rather than GENERAL)

[Tor Bug Tracker & Wiki]

#23101: Predict and build specific HS purpose circuits (rather than GENERAL)
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-guard, guard-discovery-  |  Actual Points:
  prop247-controller, review-group-27|
Parent ID:  #13837   | Points:
 Reviewer:  asn  |Sponsor:
-+-

Comment (by asn):

 OK, thanks for fixups! I reviewed the fixups and did another round of
 review. I still haven't had time to actually test the branch tho.

 In general, this branch was '''hard''' to review IMO mainly due to the
 surrounding code being extremely hairy, the lack of concise high-level
 comments of what we are trying to achieve, and everything being done in a
 single commit (adding circ purpose && handling cannibalization &&
 launching preemptive circs). Also the lack of tests is troubling, and the
 vanguards repo that is supposed to help testing had no README and was very
 hard to understand, but thankfuly mikeperry helped me over IRC. It took me
 3 days of review to get a basic understanding of the subsystem and grasp
 the code changes that were done, and I still haven't actually tested this
 branch. I feel that no strong attempt was done to make the feature
 [https://medium.com/@9len/on-code-review-16ea85f7c585 pleasurable for
 review] and that's why it took me so long.

 I think the next steps here are to squash the `mikeperry/bug23101-rebased`
 branch, then apply my fixes (`bug23101-dev`) on top of it, and then start
 handling the latest review comments. Then we would need a fresh ''merge
 request'' on gitlab because the current one is quite dirty.

 In the next days, I'll try to test the branch on the real network to
 understand more what's going on and provide further review points, or a
 branch.

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

Re: [tor-bugs] #24665 [Core Tor/Tor]: sched: In KIST, the extra_space kernel value needs to be allowed to be negative

[Tor Bug Tracker & Wiki]

#24665: sched: In KIST, the extra_space kernel value needs to be allowed to be
negative
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  merge_ready
 Priority:  Very High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_revision => merge_ready


Comment:

 Fixed!

 Branch: `bug24665_032_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] #24665 [Core Tor/Tor]: sched: In KIST, the extra_space kernel value needs to be allowed to be negative

[Tor Bug Tracker & Wiki]

#24665: sched: In KIST, the extra_space kernel value needs to be allowed to be
negative
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_revision
 Priority:  Very High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by pastly):

 * status:  needs_review => needs_revision


Comment:

 I would change the following comment. Then it LGTM.

 {{{
 diff --git a/src/or/scheduler_kist.c b/src/or/scheduler_kist.c
 index 0bd51bed7..a50be345b 100644
 --- a/src/or/scheduler_kist.c
 +++ b/src/or/scheduler_kist.c
 @@ -266,8 +266,7 @@ update_socket_info_impl, (socket_table_ent_t *ent))

/* These values from the kernel are uint32_t, they will always fit into
 a
 * int64_t tcp_space variable but if the congestion window cwnd is
 smaller
 -   * than the unacked packets, the remaining TCP space is set to 0 so we
 don't
 -   * write more on this channel. */
 +   * than the unacked packets, the remaining TCP space is set to 0. */
if (ent->cwnd >= ent->unacked) {
  tcp_space = (ent->cwnd - ent->unacked) * (int64_t)(ent->mss);
} else {
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24695 [Core Tor/Fallback Scripts]: Fallback blacklist removal for 1C90D3AEADFF3BCD079810632C8B85637924A58E

[Tor Bug Tracker & Wiki]

#24695: Fallback blacklist removal for 1C90D3AEADFF3BCD079810632C8B85637924A58E
---+-
 Reporter:  hardlined  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal |   Keywords:  fallback-change
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 When first asked to opt-in I was in the middle of changing hosting
 providers and migrating to FreeBSD. All the work is done now, so I'd like
 the relay to be removed from the Blacklist, and if it qualifies to be
 included, great.

 Mentioned it on IRC on Sept 10th, confirmed with Teor on an email via my
 contact details on the relay.

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

Re: [tor-bugs] #24671 [Core Tor/Tor]: sched: KISTLite should set an upper limit to write on the outbuf

[Tor Bug Tracker & Wiki]

#24671: sched: KISTLite should set an upper limit to write on the outbuf
-+-
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  merge_ready
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, dos, tor-channel  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pastly):

 * status:  needs_review => merge_ready


Comment:

 I wish I would have realized the outbuf didn't enforce its own size limit.
 I think this could have been avoided.

 LGTM.

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

Re: [tor-bugs] #24665 [Core Tor/Tor]: sched: In KIST, the extra_space kernel value needs to be allowed to be negative

[Tor Bug Tracker & Wiki]

#24665: sched: In KIST, the extra_space kernel value needs to be allowed to be
negative
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Very High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Ok I made the changes recommended by Yawning on the wording (THANKS!!!)

 See branch: `bug24665_032_01`

 I've also opened #24694 for the RTT discussion.

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

Re: [tor-bugs] #24693 [Core Tor/Tor]: Coverity CID 1426750 and CID 1426749: Calling two functions without control

[Tor Bug Tracker & Wiki]

#24693: Coverity CID 1426750 and CID 1426749: Calling two functions without 
control
--+---
 Reporter:  ffmancera |  Owner:  ffmancera
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  asn   |Sponsor:
--+---
Changes (by nickm):

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


Comment:

 should be fixed in 5db94adac24a3418d6dcef0078cea330d76ae442

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24694 [Core Tor/Tor]: sched: Use the socket RTT in KIST to compute a more accurate extra space

[Tor Bug Tracker & Wiki]

#24694: sched: Use the socket RTT in KIST to compute a more accurate extra space
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-sched, kist
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 This comes from a discussion in #24665 that Yawning started:

 Assuming the scheduler is called significantly faster than the RTT of most
 links (read that as "If 10 ms is lower than the RTT of most if not all
 links"), you can/should reduce sock_buf_size_factor as well, because you
 aren't going to get a full congestion window worth of ACKs back between
 scheduler calls in common cases.

 There isn't a good "one size fits all" solution. Setting it too low will
 gimp performance on fast low latency links, setting it too high right now
 bloats the various buffers. I would personally opt more toward avoiding
 the latter given all the Fun that's happening.

 In the `struct tcp_info` we use in KIST, `tcpi_rtt` gives the smoothed RTT
 estimate (and `tcpi_rttvar` the RTT variance if you need it), which is
 probably sufficient to give a better reasonable guess here, as a first
 pass, I would recommend doing something based on the the scheduler
 interval to smoothed RTT ratio, with a hard maximum at 1.0.

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

Re: [tor-bugs] #24666 [Core Tor/Tor]: sched: Store the circuit ID instead of the full DESTROY cell in the destroy queue

[Tor Bug Tracker & Wiki]

#24666: sched: Store the circuit ID instead of the full DESTROY cell in the 
destroy
queue
-+-
 Reporter:  dgoulet  |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, tor-cell, |  Actual Points:
  backport-031,backport-030, backport-029,   |
  backport-028, backport-025 |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 Ready for merge in my opinion. Been ~20h of testing, RAM has been stable
 and not leaking anymore.

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

Re: [tor-bugs] #7449 [Applications/Tor Browser]: TorBrowser creates temp files in Linux /tmp & Windows %temp% and OSX(various places) during the file downloads dialog & when using internal browser vid

[Tor Bug Tracker & Wiki]

#7449: TorBrowser creates temp files in Linux /tmp & Windows %temp% and
OSX(various places) during the file downloads dialog & when using internal
browser video player
--+
 Reporter:  unknown   |  Owner:  mikeperry
 Type:  defect| Status:
  |  needs_revision
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-disk-leak, tbb-firefox-patch  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 It is still present. File created in TBB 7.0.11:
 /tmp/mozilla_USER0/5wcXcSTV.pdf.part, where USER is ${USER} which runs
 TBB.

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

Re: [tor-bugs] #24693 [Core Tor/Tor]: Coverity CID 1426750 and CID 1426749: Calling two functions without control

[Tor Bug Tracker & Wiki]

#24693: Coverity CID 1426750 and CID 1426749: Calling two functions without 
control
--+---
 Reporter:  ffmancera |  Owner:  ffmancera
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  asn   |Sponsor:
--+---

Comment (by ffmancera):

 Sorry, we call them in src/or/!main.c:3331 and src/or/!main.c:.

 Replying to [ticket:24693 ffmancera]:


 > We left a memory leak in #23271; We call
 `get_controller_cookie_file_name()` and
 `get_ext_or_auth_cookie_file_name()` without control.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24693 [Core Tor/Tor]: Coverity CID 1426750 and CID 1426749: Calling two functions without control

[Tor Bug Tracker & Wiki]

#24693: Coverity CID 1426750 and CID 1426749: Calling two functions without 
control
--+---
 Reporter:  ffmancera |  Owner:  ffmancera
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:  asn
  Sponsor:|
--+---
 We left a memory leak in #23271; We call
 `get_controller_cookie_file_name()` and
 `get_ext_or_auth_cookie_file_name()` without control.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24692 [Metrics/Bot]: Add JavaDoc to reach 100% coverage for public interfaces

[Tor Bug Tracker & Wiki]

#24692: Add JavaDoc to reach 100% coverage for public interfaces
-+-
 Reporter:  irl  |  Owner:  irl
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Bot  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 While metrics-bot isn't intended to be used as a library, documentation is
 always helpful and should be added wherever it makes sense.

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

Re: [tor-bugs] #24080 [Metrics/Bot]: Make metrics-bot comply with Metrics' project guidelines and java style rules

[Tor Bug Tracker & Wiki]

#24080: Make metrics-bot comply with Metrics' project guidelines and java style
rules
-+
 Reporter:  irl  |  Owner:  irl
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Bot  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by irl):

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


Comment:

 metrics-bot now uses metrics-base, included as a submodule in 178fe2cf,
 and this produces a working jar file (which is the one used to deploy on
 DO)

 Everything is formatted correctly as of f74675a1.

 The only remaining task is to complete JavaDoc, which I will make a new
 ticket for.

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

Re: [tor-bugs] #13603 [Core Tor/Tor]: Many channels closing with "IOERROR" reason given on control port.

[Tor Bug Tracker & Wiki]

#13603: Many channels closing with "IOERROR" reason given on control port.
-+-
 Reporter:  toralf   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.5.10
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay needs-analysis networking  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by toralf):

 * Attachment "fingerprints" 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] #13603 [Core Tor/Tor]: Many channels closing with "IOERROR" reason given on control port.

[Tor Bug Tracker & Wiki]

#13603: Many channels closing with "IOERROR" reason given on control port.
-+-
 Reporter:  toralf   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.5.10
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay needs-analysis networking  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by toralf):

 * Attachment "histogram" 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] #13603 [Core Tor/Tor]: Many channels closing with "IOERROR" reason given on control port.

[Tor Bug Tracker & Wiki]

#13603: Many channels closing with "IOERROR" reason given on control port.
-+-
 Reporter:  toralf   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.5.10
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay needs-analysis networking  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by toralf):

 I'd like to come back to this topic mainly due to the DoS against Tor
 relays in the last few days.

 I used [1] to gather the state of closed connections and [2] to count DONE
 IOERROR TIMEOUT CONNECTRESET counts create a histogram of those values.
 The measurement was made in the last 3 days.

 Whilst majority of relays have just few IOERRORS, there're a bunch if
 relays having hundreds or thousands of failures within 2 days w/o any
 DONE. FWIW the authority faravahar has almost CONNECTRESET.

 I'll attach the fingerprints and the histogram got from my 2 relays
 (running at the hardware)

 [1] https://github.com/toralf/torutils/blob/master/orstatus.py
 [2] https://github.com/toralf/torutils/blob/master/plot.sh

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

Re: [tor-bugs] #24351 [Applications/Tor Browser]: Block Global Active Adversary Cloudflare

[Tor Bug Tracker & Wiki]

#24351: Block Global Active Adversary Cloudflare
-+-
 Reporter:  nullius  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Very Low |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Trivial  | Resolution:
 Keywords:  security, privacy, anonymity, mitm,  |  Actual Points:
  cloudflare |
Parent ID:  #18361   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 TBB team won't care. Block Cloudflare? This will break millions of
 websites! LOFL

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

Re: [tor-bugs] #22261 [Metrics/Onionoo]: Remove the $ from family fingerprints

[Tor Bug Tracker & Wiki]

#22261: Remove the $ from family fingerprints
-+---
 Reporter:  teor |  Owner:  karsten
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Onionoo-1.9.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---
Changes (by karsten):

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


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