[tor-bugs] #23980 [Core Tor/Tor]: Provide torrc option to kill hidden service circuits after $TIMEOUT

[Tor Bug Tracker & Wiki]

#23980: Provide torrc option to kill hidden service circuits after $TIMEOUT
--+
 Reporter:  mikeperry |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  guard-discovery
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  SponsorV-can  |
--+
 HTTP hidden services and other short-lived protocols do not need to keep
 their circuits open very long. Somewhere between 10min and 1 hour ought to
 be plenty. Since long-lived circuits are a vector for guard discovery (see
 #22728), we should provide a torrc option to set a max hidden service
 circuit lifetime.

 Note that making this timeout too low effectively enables new forms of
 #20212, so we should err towards an hour for the timeout here until that
 fix is landed.

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

Re: [tor-bugs] #11096 [Applications/Tor Browser]: Randomize MAC address before start of Tor

[Tor Bug Tracker & Wiki]

#11096: Randomize MAC address before start of Tor
--+--
 Reporter:  csoghoian |  Owner:  tbb-team
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-security  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:5 bugzilla]:
 > Meaningful part of this ticket is
 > > TBB exploits
 > So, propose renaming it to something like "Investigate methods of
 hardening of Firefox to prevent MAC stealing".
 This is not too difficult. A MAC address is obtained by using either an
 IOCTL (SIOCGIFHWADDR), or the NETLINK protocol (AF_NETLINK). Just blocking
 those syscalls when that argument is used should be sufficient, assuming
 other more obvious issues like arbitrary filesystem access or the ability
 to bypass Tor to phone home is mitigated.

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

Re: [tor-bugs] #13873 [Applications/Tor Browser]: hard lock tails/torbrowser

[Tor Bug Tracker & Wiki]

#13873: hard lock tails/torbrowser
--+--
 Reporter:  ioerror   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  security, usability, fuzzing  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 There are a million and one ways to DoS a browser. Fixing them all is
 likely out of scope (and Mozilla hasn't even started considering it as a
 serious issue). Even excluding various types of "bombs" like SVG bombs or
 XML bombs, merely loading a huge page is sufficient to crash a browser.
 This is far beyond the abilities of Tor Project.

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

Re: [tor-bugs] #22728 [Core Tor/Tor]: Long-lived onion service circuits can enable guard discovery (was: Periodically close long-lived onion service circuits)

[Tor Bug Tracker & Wiki]

#22728: Long-lived onion service circuits can enable guard discovery
-+--
 Reporter:  mikeperry|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery, tor-hs  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by mikeperry):

 Ok, I agree. It seems like simply closing circuits is not going to buy us
 much here.

 How about providing the ability for clients to migrate circuits to an
 IP/RP? That way, if a client *should* rotate away from a node, it can.
 Additionally, if a node goes down because of DoS or any byzantine reason,
 this would mean that the circuit doesn't have to be destroyed. Basically,
 we could do conflux (https://www.cypherpunks.ca/~iang/pubs/conflux-
 pets.pdf) without the split-flow control stuff (at least not at first,
 though I suspect that the flow control pieces will be useful against
 congestion attacks).

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

Re: [tor-bugs] #23979 [Core Tor/Tor]: Write performance simulator for Prop247

[Tor Bug Tracker & Wiki]

#23979: Write performance simulator for Prop247
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery-prop247-experiments  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-
Changes (by mikeperry):

 * keywords:  guard-discovery => guard-discovery-prop247-experiments


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

Re: [tor-bugs] #23978 [Core Tor/Tor]: Write simulator to evaluate security of Prop247 parameter choices

[Tor Bug Tracker & Wiki]

#23978: Write simulator to evaluate security of Prop247 parameter choices
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery-prop247-experiments  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-
Changes (by mikeperry):

 * keywords:  guard-discovery => guard-discovery-prop247-experiments


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23979 [Core Tor/Tor]: Write performance simulator for Prop247

[Tor Bug Tracker & Wiki]

#23979: Write performance simulator for Prop247
--+--
 Reporter:  mikeperry |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  guard-discovery
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  SponsorV-can  |
--+--
 We need to evaluate the performance consequences of various parameter
 choices for Prop247. The plan is to make a plan, and use
 https://github.com/mikeperry-tor/vanguards to do the testing.

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

Re: [tor-bugs] #23856 [Core Tor/Tor]: Reduce relay bandwidth stats interval to 24 hours

[Tor Bug Tracker & Wiki]

#23856: Reduce relay bandwidth stats interval to 24 hours
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  guard-discovery-stats  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:  SponsorQ
---+

Comment (by jvsg):

 What happens in those cases where client and adversary are one and the
 same? An adversary could create many connections to the service, which
 could lead to the spike in stats. Would 24 hour interval be immune to
 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] #23978 [Core Tor/Tor]: Write simulator to evaluate security of Prop247 parameter choices

[Tor Bug Tracker & Wiki]

#23978: Write simulator to evaluate security of Prop247 parameter choices
-+--
 Reporter:  mikeperry|  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  SponsorV-can
-+--
Changes (by mikeperry):

 * Attachment "design-sketch.jpg" added.

 Sketch of prop247 security simulator

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23978 [Core Tor/Tor]: Write simulator to evaluate security of Prop247 parameter choices

[Tor Bug Tracker & Wiki]

#23978: Write simulator to evaluate security of Prop247 parameter choices
--+--
 Reporter:  mikeperry |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  guard-discovery
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  SponsorV-can  |
--+--
 At Wilmington, we decided to write a simulator to evaluate the security of
 various parameter choices. We even made a pseudocode sketch of it. A
 picture of the pseudocode sketch is attached.

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

Re: [tor-bugs] #23870 [Core Tor/Tor]: Authorities: document what happens when relays have misconfigured IPv6

[Tor Bug Tracker & Wiki]

#23870: Authorities: document what happens when relays have misconfigured IPv6
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.4.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  ipv6, doc |  Actual Points:  0.1
Parent ID:  #23826| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * parent:  #20916 => #23826


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

Re: [tor-bugs] #23898 [Core Tor/Tor]: tor-spec: move IPv6 addresses from microdescs to microdesc consensus

[Tor Bug Tracker & Wiki]

#23898: tor-spec: move IPv6 addresses from microdescs to microdesc consensus
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  proposal, ipv6, tor-spec  |  Actual Points:  1.0
Parent ID:  #20916| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by teor):

 This is under review on tor-dev@ , here is the link:
 https://lists.torproject.org/pipermail/tor-dev/2017-October/012518.html

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

Re: [tor-bugs] #20916 [Core Tor/Tor]: Proposal: Put Relay IPv6 Addresses in the microdesc consensus

[Tor Bug Tracker & Wiki]

#20916: Proposal: Put Relay IPv6 Addresses in the microdesc consensus
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  needs-proposal, ipv6, regression  |  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_revision => new


Comment:

 This is now a parent ticket, we're tracking all the changes in child
 tickets.

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

Re: [tor-bugs] #23856 [Core Tor/Tor]: Reduce relay bandwidth stats interval to 24 hours

[Tor Bug Tracker & Wiki]

#23856: Reduce relay bandwidth stats interval to 24 hours
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  guard-discovery-stats  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:  SponsorQ
---+

Comment (by teor):

 See https://lists.torproject.org/pipermail/tor-
 dev/2017-October/012517.html

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

Re: [tor-bugs] #23577 [Core Tor/Tor]: Make setup_introduce1_data() take a node instead of an extend_info

[Tor Bug Tracker & Wiki]

#23577: Make setup_introduce1_data() take a node instead of an extend_info
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:  1
Parent ID:  #23493   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-
Changes (by teor):

 * status:  needs_revision => needs_review
 * points:   => 1
 * sponsor:   => SponsorV-can
 * actualpoints:   => 1


Comment:

 Thanks for this patch, it looks good.

 We'll need to test it along with the other parts of #23493, so it might be
 a while before it merges.

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

Re: [tor-bugs] #19610 [Core Tor/Tor]: IPv6-only clients fetch microdescriptors from a small number of IPv6 fallbacks

[Tor Bug Tracker & Wiki]

#19610: IPv6-only clients fetch microdescriptors from a small number of IPv6
fallbacks
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.4-rc
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, microdesc, fallbacks, tor- |  Actual Points:
  client network-health user-enumeration |
Parent ID:  #20916   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:  #17217 => #20916
 * milestone:  Tor: 0.3.5.x-final => Tor: 0.3.3.x-final


Comment:

 I think we should just close this when #20916 closes.

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

Re: [tor-bugs] #22729 [Core Tor/TorDNSEL]: Revisit relay read/write history resolution (for onion services)

[Tor Bug Tracker & Wiki]

#22729: Revisit relay read/write history resolution (for onion services)
---+---
 Reporter:  mikeperry  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/TorDNSEL  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, guard-discovery-stats  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by mikeperry):

 * milestone:   => Tor: unspecified


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

Re: [tor-bugs] #20212 [Applications/Tor Browser]: Tor can be forced to open too many circuits by embedding .onion resources

[Tor Bug Tracker & Wiki]

#20212: Tor can be forced to open too many circuits by embedding .onion 
resources
--+--
 Reporter:  gacar |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  guard-discovery   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by mikeperry):

 * milestone:   => Tor: unspecified


Comment:

 Unlike the generic or custom-built Tor client case (CDNs and status
 pingers will likely customize their Tor client for performance), Tor
 Browser specifies a SOCKS username and password for url bar domain
 isolation. When this u+p is set, we should be able to safely limit the
 number of onion hostnames for a single SOCKS username + password to some
 low number (5? 10?).

 Do we need a separate limit if third party hidden services are malicious
 and deliberately fail either HSDIR, IP, or RP attempts in a way that
 causes the client to retry them? Maybe there should be a total rend
 circuit limit per SOCKS u+p?

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

Re: [tor-bugs] #23856 [Core Tor/Tor]: Reduce relay bandwidth stats interval to 24 hours

[Tor Bug Tracker & Wiki]

#23856: Reduce relay bandwidth stats interval to 24 hours
---+
 Reporter:  teor   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  guard-discovery-stats  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:  SponsorQ
---+
Changes (by mikeperry):

 * keywords:  guard-discovery-033 => guard-discovery-stats


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

Re: [tor-bugs] #23870 [Core Tor/Tor]: Authorities: document what happens when relays have misconfigured IPv6

[Tor Bug Tracker & Wiki]

#23870: Authorities: document what happens when relays have misconfigured IPv6
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.4.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  ipv6, doc |  Actual Points:  0.1
Parent ID:  #20916| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  new => needs_review
 * version:   => Tor: 0.2.4.1-alpha


Comment:

 This is implemented in my tor branch bug23826-23828 along with #23826 and
 #23828.

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

Re: [tor-bugs] #13043 [Core Tor/Tor]: torspec lies about accepting both IPv4 and IPv6 for ORAddress lines

[Tor Bug Tracker & Wiki]

#13043: torspec lies about accepting both IPv4 and IPv6 for ORAddress lines
-+-
 Reporter:  isis |  Owner:  massar
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, spec, 032-unreached, ipv6  |  Actual Points:
Parent ID:  #23898   | Points:  .1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:  #20916 => #23898


Comment:

 #23898 fixes this.

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

Re: [tor-bugs] #23512 [Core Tor/Tor]: Bandwidth stats watermark can be induced using OOM killer

[Tor Bug Tracker & Wiki]

#23512: Bandwidth stats watermark can be induced using OOM killer
-+-
 Reporter:  asn  |  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-bug-bounty, congestion-attack,   |  Actual Points:
  research, watermark, tor-stats, guard- |
  discovery-stats|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-

Comment (by arma):

 Mike: I talked to Jaym about this topic at PETS. I think at the time I was
 under the impression that we are incrementing the *write* counter, that
 is, the outbound connection, even though we never actually push the bytes
 out to the network because we kill the outbuf in the oom killer.

 So I had thought that the bug was "we say that we wrote out the bytes even
 though we didn't", which allows an attacker to queue up a bunch of bytes
 for us to outbuf, and generate an artificially large signal.

 If that is the issue (which contradicts asn's summary above I think), then
 there would be a second piece to the fix, since if we only decremented the
 write count to stop including the bytes we didn't actually write, then we
 would have an asymmetry between the (still much higher) read count and the
 (now corrected) write count. So the second part of the fix would be to
 decrement the read count by the corresponding amount too, so things match
 up.

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

Re: [tor-bugs] #23898 [Core Tor/Tor]: tor-spec: move IPv6 addresses from microdescs to microdesc consensus

[Tor Bug Tracker & Wiki]

#23898: tor-spec: move IPv6 addresses from microdescs to microdesc consensus
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  proposal, ipv6, tor-spec  |  Actual Points:  1.0
Parent ID:  #20916| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * keywords:  needs-proposal, ipv6, tor-spec => proposal, ipv6, tor-spec
 * status:  new => needs_review
 * actualpoints:  0.5 => 1.0


Comment:

 This proposal and some updates to dir-spec that document the new consensus
 methods and the current state of IPv6 ORPort support are in my torspec
 branch bug23826-23828.

 This is the spec for the tor branch in #23826 and #23828.

 I'm just about to send it to tor-dev@ for 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] #23512 [Core Tor/Tor]: Bandwidth stats watermark can be induced using OOM killer

[Tor Bug Tracker & Wiki]

#23512: Bandwidth stats watermark can be induced using OOM killer
-+-
 Reporter:  asn  |  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-bug-bounty, congestion-attack,   |  Actual Points:
  research, watermark, tor-stats, guard- |
  discovery-stats|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-
Changes (by mikeperry):

 * keywords:
 tor-bug-bounty, congestion-attack, research, watermark, tor-stats,
 guard-discovery
 =>
 tor-bug-bounty, congestion-attack, research, watermark, tor-stats,
 guard-discovery-stats


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

Re: [tor-bugs] #22729 [Core Tor/TorDNSEL]: Revisit relay read/write history resolution (for onion services)

[Tor Bug Tracker & Wiki]

#22729: Revisit relay read/write history resolution (for onion services)
---+
 Reporter:  mikeperry  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/TorDNSEL  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, guard-discovery-stats  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by mikeperry):

 * keywords:  tor-hs, guard-discovery => tor-hs, guard-discovery-stats


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

Re: [tor-bugs] #23826 [Core Tor/Tor]: Authorities: Put Relay IPv6 addresses in the microdesc consensus

[Tor Bug Tracker & Wiki]

#23826: Authorities: Put Relay IPv6 addresses in the microdesc consensus
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6  |  Actual Points:  0.2
Parent ID:  #20916| Points:  0.5
 Reviewer:|Sponsor:  SponsorV-can
--+
Changes (by teor):

 * status:  new => needs_review


Comment:

 That branch also has a commit for #23828. The corresponding torspec entry
 is in my torspec branch bug23826-23828, and is tracked in ticket #23898.

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

Re: [tor-bugs] #23828 [Core Tor/Tor]: Authorities: Remove IPv6 addresses from microdescriptors

[Tor Bug Tracker & Wiki]

#23828: Authorities: Remove IPv6 addresses from microdescriptors
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6  |  Actual Points:  0.2
Parent ID:  #20916| Points:  0.5
 Reviewer:|Sponsor:  SponsorV-can
--+
Changes (by teor):

 * status:  new => needs_review


Comment:

 Actually, it's safe for us to do this in the next consensus method after
 #23826.

 This is implemented in my tor branch bug23826-23828 along with #23826. The
 corresponding torspec entry is in my torspec branch bug23826-23828, and is
 tracked in ticket #23898.

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

Re: [tor-bugs] #23826 [Core Tor/Tor]: Authorities: Put Relay IPv6 addresses in the microdesc consensus

[Tor Bug Tracker & Wiki]

#23826: Authorities: Put Relay IPv6 addresses in the microdesc consensus
--+
 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:  ipv6  |  Actual Points:  0.2
Parent ID:  #20916| Points:  0.5
 Reviewer:|Sponsor:  SponsorV-can
--+

Comment (by teor):

 This is implemented in my tor branch bug23826-23828. The corresponding
 torspec entry is in my torspec branch bug23826-23828.

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

Re: [tor-bugs] #23512 [Core Tor/Tor]: Bandwidth stats watermark can be induced using OOM killer

[Tor Bug Tracker & Wiki]

#23512: Bandwidth stats watermark can be induced using OOM killer
-+-
 Reporter:  asn  |  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-bug-bounty, congestion-attack,   |  Actual Points:
  research, watermark, tor-stats, guard- |
  discovery  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorQ
-+-
Changes (by mikeperry):

 * cc: arma (added)


Comment:

 During Montreal, Roger mentioned there is a second piece to this. I tried
 to save it here but trac ate my changes. Roger, can you say what that was
 again?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  (none)
 Type:  enhancement  | Status:  new
 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 |
Parent ID:  #9001| Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mikeperry):

 * keywords:  tor-hs, tor-guard, guard-discovery => tor-hs, tor-guard,
 guard-discovery-prop247-controller
 * milestone:  Tor: unspecified => 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] #23100 [Core Tor/Tor]: Circuit Build Timeout needs to count hidden service circuits

[Tor Bug Tracker & Wiki]

#23100: Circuit Build Timeout needs to count hidden service circuits
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, path-bias, guard-discovery-  |  Actual Points:
  prop247-controller, needs-proposal, mike-can,  |
  prop247, tor-guard |
Parent ID:  #9001| Points:
 Reviewer:   |Sponsor:
-+-
Changes (by mikeperry):

 * keywords:
 tor-hs, path-bias, guard-discovery, needs-proposal, mike-can, prop247,
 tor-guard
 =>
 tor-hs, path-bias, guard-discovery-prop247-controller, needs-proposal,
 mike-can, prop247, tor-guard
 * milestone:  Tor: 0.3.2.x-final => 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] #23114 [Core Tor/Tor]: Circuit Build Timeout should apply at circuit completion

[Tor Bug Tracker & Wiki]

#23114: Circuit Build Timeout should apply at circuit completion
+--
 Reporter:  mikeperry   |  Owner:
|  mikeperry
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  guard-discovery-prop247-controller  |  Actual Points:
Parent ID:  #23100  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by mikeperry):

 * keywords:   => guard-discovery-prop247-controller
 * milestone:  Tor: unspecified => 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] #13837 [Core Tor/Tor]: Mitigate guard discovery by pinning middle node

[Tor Bug Tracker & Wiki]

#13837: Mitigate guard discovery by pinning middle node
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  assigned
 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 |
Parent ID:  #9001| Points:
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-
Changes (by mikeperry):

 * keywords:  tor-hs, tor-guard, guard-discovery-033 => tor-hs, tor-guard,
 guard-discovery-prop247-controller
 * milestone:  Tor: unspecified => 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] #23856 [Core Tor/Tor]: Reduce relay bandwidth stats interval to 24 hours

[Tor Bug Tracker & Wiki]

#23856: Reduce relay bandwidth stats interval to 24 hours
-+
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery-033  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:  SponsorQ
-+
Changes (by mikeperry):

 * keywords:  guard-discovery => guard-discovery-033


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

Re: [tor-bugs] #13837 [Core Tor/Tor]: Mitigate guard discovery by pinning middle node

[Tor Bug Tracker & Wiki]

#13837: Mitigate guard discovery by pinning middle node
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-guard, guard-|  Actual Points:
  discovery-033  |
Parent ID:  #9001| Points:
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-
Changes (by mikeperry):

 * keywords:  tor-hs, tor-guard, guard-discovery, SponsorV-033 => tor-hs,
 tor-guard, guard-discovery-033


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

Re: [tor-bugs] #13837 [Core Tor/Tor]: Mitigate guard discovery by pinning middle node

[Tor Bug Tracker & Wiki]

#13837: Mitigate guard discovery by pinning middle node
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor-guard, guard-discovery,  |  Actual Points:
  SponsorV-033   |
Parent ID:  #9001| Points:
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-
Changes (by mikeperry):

 * keywords:  tor-hs, tor-guard, guard-discovery => tor-hs, tor-guard,
 guard-discovery, SponsorV-033


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

Re: [tor-bugs] #23500 [Core Tor/Tor]: check-spaces.pl should check spaces after a comma when in functions.

[Tor Bug Tracker & Wiki]

#23500: check-spaces.pl should check spaces after a comma when in functions.
-+-
 Reporter:  ewong|  Owner:  (none)
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Trivial  | Resolution:
 Keywords:  code-style, review-group-24  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by ewong):

 Replying to [comment:18 nickm]:
 > Hm. Did you use a script to add the missing spaces, or did you do it by
 hand?

 I did it by hand.

 >
 > Ideally, there should be:
 >   * one commit that changes checkSpace.pl and nothing else.
 >   * a script that we can run on master to add the missing spaces when we
 merge.  This way, we don't get any conflicts, and it's easy to verify that
 the script does only what it claims.  Maybe something like this?
 > {{{
 > perl -i -pe 's/,(\S)/, $1/g' src/{common,or,ext,test,tools}/*.[ch]
 > }}}
 >   * And then we can just run wrap the lines by hand.
 >
 > I've extracted the script as its own commit in a branch
 `ticket23500_033` in my public repository at
 https://gitweb.torproject.org/nickm/tor.git .  If it looks okay, and
 somebody confirms the steps above, I can merge it and do the rest.
 >
 > Also, is there a reason to have the checkSpaces script check for
 `[\w|\d]+` instead of just `\S`?

 My regex-fu is basic at the best, so that's what I came up with.  I had a
 major
 issue with figuring out how to get sed to regex properly.

 sorry for the mess.

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

Re: [tor-bugs] #18329 [Core Tor/Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

[Tor Bug Tracker & Wiki]

#18329: Let bridges indicate when they don't want BridgeDB to distribute their
address
---+---
 Reporter:  karsten|  Owner:  nickm
 Type:  enhancement| Status:
   |  merge_ready
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bridge, stem, review-group-24  |  Actual Points:
Parent ID: | Points:  .2
   |  remaining
 Reviewer:  isis   |Sponsor:  SponsorM
---+---

Comment (by isis):

 Replying to [comment:50 nickm]:
 > Looks good!  One question:  Are you sure about the commit "config: Only
 allow specified characters in BridgeDistribution lines."?  The way I read
 dir-spec, I thought that "-" was included as an allowable KeywordChar.
 >
 > Right now, after we resolve that issue, here's what I'm planning: I'll
 squash the fixup commit and we'll have a new branch.  We can take the
 whole branch in 0.3.2 immediately, and if it works out, we can backport to
 029 and earlier.  But we probably won't make (and shouldn't try to make)
 the releases planned for tomorrow with this patch. Sound ok with you?

 Yep, sounds good! Thanks!

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

[tor-bugs] #23977 [Core Tor/Tor]: control-spec.txt should document which "signals" don't actually exist as Unix signals

[Tor Bug Tracker & Wiki]

#23977: control-spec.txt should document which "signals" don't actually exist as
Unix signals
--+--
 Reporter:  catalyst  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-control tor-spec
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Section 3.7 of control-spec.txt documents the `SIGNAL` command, which can
 cause some actions that correspond to Unix signals that one can send to
 the tor process.  Some of these actions have no corresponding Unix
 signals, so can only be invoked via the control protocol.  We should
 document these facts to avoid confusion.

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

Re: [tor-bugs] #23976 [Core Tor/Chutney]: Stop setting CircuitIdleTimeout in chutney, it's obsolete

[Tor Bug Tracker & Wiki]

#23976: Stop setting CircuitIdleTimeout in chutney, it's obsolete
--+-
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+-
Changes (by teor):

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


Comment:

 Oops, this was in an experimental branch that was never merged to master.
 So it 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

[tor-bugs] #23976 [Core Tor/Chutney]: Stop setting CircuitIdleTimeout in chutney, it's obsolete

[Tor Bug Tracker & Wiki]

#23976: Stop setting CircuitIdleTimeout in chutney, it's obsolete
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Chutney  |Version:
 Severity:  Normal|   Keywords:  easy
Actual Points:|  Parent ID:
   Points:  0.1   |   Reviewer:
  Sponsor:|
--+


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

Re: [tor-bugs] #23092 [Core Tor/Tor]: Stop ignoring CircuitIdleTimeout when it's lower than IDLE_TIMEOUT_WHILE_LEARNING

[Tor Bug Tracker & Wiki]

#23092: Stop ignoring CircuitIdleTimeout when it's lower than
IDLE_TIMEOUT_WHILE_LEARNING
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.2.2-alpha
 Severity:  Normal| Resolution:  wontfix
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by teor):

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


Comment:

 The CircuitIdleTimeout is now obsolete, so we simply have a fixed 60
 second time when learning. I think that's ok for chutney.

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

Re: [tor-bugs] #23016 [Applications/Tor Browser]: "Print to File" does not create the expected file in non-English locales

[Tor Bug Tracker & Wiki]

#23016: "Print to File" does not create the expected file in non-English locales
-+-
 Reporter:  intrigeri|  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  AffectsTails, tbb-7.0-issues, tbb-   |  Actual Points:
  regression, tbb-e10s   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pospeselr):

 Ok, some good progress today.  A couple things to note: this bug *does*
 repro with the javascript.use_us_english_locale setting, but it takes some
 finagling to get that setting to stick (and regardless of what the *real*
 value is, it will always appear as *true* on browser start).  To get it to
 stick you need to toggle it to false, exit the tab and browser and come
 back.  To toggle it back to true, you have to toggle it twice, exit the
 tab and browser and come back.

 So, the reason this is happening is in part due to localization and multi-
 process printing.  In the multi-process case, the 'Web Content' process
 has to enumerate the printers for itself to find the target printer the
 'firefox' process wants us to print to.  To identify said printer, we're
 doing a string compare on the name of the printers GTK is aware of and
 continues on with printing once it finds the name provided by the parent
 'firefox' process.

 The reason why we fail is that with javascript.use_us_english_locale=true
 is that the firefox process names the 'Print to File' printer as 'Print to
 File' whereas gtk has a GTKPrinter named (in the French case) 'Imprimer
 dans un fichier' due to the system's language settings (which explains why
 this bug does not happen in localized tor-browser on an English system).
 In order for printing to work, we have to send down the name GTK is
 expecting.

 Knowing all this should be relatively straight-forward to track down where
 we're not localizing when we should.

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

Re: [tor-bugs] #20532 [Core Tor/Tor]: Make sure directory_initiate_request handles pluggable transports correctly

[Tor Bug Tracker & Wiki]

#20532: Make sure directory_initiate_request handles pluggable transports 
correctly
--+
 Reporter:  teor  |  Owner:  catalyst
 Type:  defect| Status:  merge_ready
 Priority:  High  |  Milestone:  Tor:
  |  0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  bridge-client, bridge-bypass  |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:  SponsorM
--+
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 Merging to 0.3.2 and forward; marking for potential 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

Re: [tor-bugs] #18329 [Core Tor/Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

[Tor Bug Tracker & Wiki]

#18329: Let bridges indicate when they don't want BridgeDB to distribute their
address
---+---
 Reporter:  karsten|  Owner:  nickm
 Type:  enhancement| Status:
   |  merge_ready
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bridge, stem, review-group-24  |  Actual Points:
Parent ID: | Points:  .2
   |  remaining
 Reviewer:  isis   |Sponsor:  SponsorM
---+---

Comment (by nickm):

 Oops. I meant "merging that 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] #18329 [Core Tor/Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

[Tor Bug Tracker & Wiki]

#18329: Let bridges indicate when they don't want BridgeDB to distribute their
address
---+---
 Reporter:  karsten|  Owner:  nickm
 Type:  enhancement| Status:
   |  merge_ready
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.1.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bridge, stem, review-group-24  |  Actual Points:
Parent ID: | Points:  .2
   |  remaining
 Reviewer:  isis   |Sponsor:  SponsorM
---+---
Changes (by nickm):

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


Comment:

 Squashed, with commit removed, as `feature18329_029_squashed`.

 Merging that to 0.2.8 and forward; marking for possible 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] #23975 [Core Tor/Tor]: Make node_get_*_orport() check addresses in the right order

[Tor Bug Tracker & Wiki]

#23975: Make node_get_*_orport() check addresses in the right order
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.1-alpha
 Severity:  Normal|   Keywords:  ipv6, regression
Actual Points:|  Parent ID:  #20916
   Points:  1 |   Reviewer:
  Sponsor:|
--+
 node_get_pref_ipv6_orport() and node_get_prim_orport() check addresses in
 the following order:
 * routerinfo / descriptor (modified by rewrite_bridge_address_for_node())
 * routerstatus / consensus
 * microdesc

 Clients, bridge clients, and relays usually get the correct address from
 node_get_pref_ipv6_orport() and node_get_prim_orport(), whether they are
 using microdescriptors or not.

 But there are a few cases when this breaks:
 * bridge clients should only check routerinfo for configured bridges
 * all clients and relays that use microdescs should never check full
 descriptors (and vice versa, except for the bridge case)
 * all clients and relays that use full descriptors should ignore the IPv6
 address in the descriptor
 * all clients and relays that use microdescriptors should ignore the IPv6
 address in the microdescriptor, when using a consensus method that puts
 IPv6 addresses in the microdesc consensus, otherwise they should use the
 microdescriptor

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

Re: [tor-bugs] #23827 [Core Tor/Tor]: Clients/Relays: Use IPv6 Addresses from microdesc consensus

[Tor Bug Tracker & Wiki]

#23827: Clients/Relays: Use IPv6 Addresses from microdesc consensus
--+
 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:  ipv6, regression  |  Actual Points:
Parent ID:  #20916| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:2 teor]:
 > We should probably revise node_get_pref_ipv6_orport() so that it's a bit
 smarter, but let's do that in a different ticket.

 This is now #23975.

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

Re: [tor-bugs] #20532 [Core Tor/Tor]: Make sure directory_initiate_request handles pluggable transports correctly

[Tor Bug Tracker & Wiki]

#20532: Make sure directory_initiate_request handles pluggable transports 
correctly
--+
 Reporter:  teor  |  Owner:  catalyst
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:  Tor:
  |  0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  bridge-client, bridge-bypass  |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:  SponsorM
--+

Comment (by nickm):

 Looks plausible!  Is this tested?  If so, I say we merge it to 0.3.2, and
 (barring misadventure) backport it in the next 0.3.1 release (not the one
 from tomorrow).

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

Re: [tor-bugs] #18329 [Core Tor/Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

[Tor Bug Tracker & Wiki]

#18329: Let bridges indicate when they don't want BridgeDB to distribute their
address
---+---
 Reporter:  karsten|  Owner:  nickm
 Type:  enhancement| Status:
   |  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bridge, stem, review-group-24  |  Actual Points:
Parent ID: | Points:  .2
   |  remaining
 Reviewer:  isis   |Sponsor:  SponsorM
---+---

Comment (by nickm):

 Looks good!  One question:  Are you sure about the commit "config: Only
 allow specified characters in BridgeDistribution lines."?  The way I read
 dir-spec, I thought that "-" was included as an allowable KeywordChar.

 Right now, after we resolve that issue, here's what I'm planning: I'll
 squash the fixup commit and we'll have a new branch.  We can take the
 whole branch in 0.3.2 immediately, and if it works out, we can backport to
 029 and earlier.  But we probably won't make (and shouldn't try to make)
 the releases planned for tomorrow with this patch. Sound ok with you?

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

Re: [tor-bugs] #23870 [Core Tor/Tor]: Authorities: document what happens when relays have misconfigured IPv6 (was: Authorities: When relays have misconfigured IPv6, mark them as running and IPv4 only)

[Tor Bug Tracker & Wiki]

#23870: Authorities: document what happens when relays have misconfigured IPv6
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6, doc |  Actual Points:  0.1
Parent ID:  #20916| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * keywords:  needs-proposal, ipv6, regression => ipv6, doc


Old description:

> Otherwise, we lose useful relays when authorities set
> AuthDirHasIPv6Connectivity.

New description:

 ~~~Otherwise, we lose useful relays when authorities set
 AuthDirHasIPv6Connectivity.~~~

--

Comment:

 I spoke with the directory authority operators about this, and they are
 happy with the existing behaviour. But we need to document it:
 * if no voting authorities set AuthDirHasIPv6Connectivity, there will be
 no IPv6 addresses in the consensus
 * if a minority of voting authorities set AuthDirHasIPv6Connectivity,
 relays with unreachable IPv6 addresses will have those addresses removed
 from the consensus
 * if a majority of voting authorities set AuthDirHasIPv6Connectivity,
 relays with unreachable IPv6 addresses will not be listed as running

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

Re: [tor-bugs] #22511 [Community]: Tor Code of Conduct

[Tor Bug Tracker & Wiki]

#22511: Tor Code of Conduct
---+
 Reporter:  alison |  Owner:  (none)
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:
Component:  Community  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #22079 | Points:
 Reviewer: |Sponsor:
---+

Comment (by alison):

 Replying to [comment:17 gk]:
 > Replying to [comment:16 alison]:
 > > Hey there folks! I'm happy to report that we did a lot of work on the
 draft code of conduct at the Montreal meeting. If you want to be involved
 in finishing this up before it goes out to a vote among core contributors,
 please contact me directly at alison (at) torproject (dot) org.
 >
 > I think there should be drafts available to tor-internal folks way
 before a final one goes out to a vote. And I think it should not be
 necessary that each of those tor-internal members not being able to be at
 the Code of Conduct session is contacting you. Or maybe that comment was
 only meant for non tor-internal community folks?

 Yeah, sorry to be unclear, when I said "goes out to a vote" I was
 referring to the whole discussion + voting period to which atagar refers.
 I was planning to give two weeks for discussion on the list, but anyone is
 welcome to review it before that if they contact me.

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

Re: [tor-bugs] #20532 [Core Tor/Tor]: Make sure directory_initiate_request handles pluggable transports correctly

[Tor Bug Tracker & Wiki]

#20532: Make sure directory_initiate_request handles pluggable transports 
correctly
--+
 Reporter:  teor  |  Owner:  catalyst
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:  Tor:
  |  0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  bridge-client, bridge-bypass  |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:  SponsorM
--+
Changes (by catalyst):

 * status:  accepted => needs_review


Comment:

 Patch for 0.3.1 at https://oniongit.eu/catalyst/tor/merge_requests/13 and
 it looks like it should merge cleanly with anything newer.

 Patches for the other stable releases are on the branches bug20532_030,
 bug20532_029, and bug20532_025.

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

Re: [tor-bugs] #16564 [Core Tor/Tor]: Add a line to bridge descriptors specifying they're bridges?

[Tor Bug Tracker & Wiki]

#16564: Add a line to bridge descriptors specifying they're bridges?
---+--
 Reporter:  arma   |  Owner:  isis
 Type:  enhancement| Status:  accepted
 Priority:  High   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bridge easy intro  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:  SponsorM
---+--
Changes (by isis):

 * owner:  (none) => isis
 * status:  new => accepted
 * points:  .1 => 1
 * sponsor:   => SponsorM
 * priority:  Medium => High


Comment:

 A nicer way to do this, once #18329 is merged, would be to have the
 dirauths check the uploaded server descriptors for "bridge-distribution-
 request" lines, since all bridges will have them. I can make a patch that
 rejects bridges from the consensus, which we should probably be doing.

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

Re: [tor-bugs] #18329 [Core Tor/Tor]: Let bridges indicate when they don't want BridgeDB to distribute their address

[Tor Bug Tracker & Wiki]

#18329: Let bridges indicate when they don't want BridgeDB to distribute their
address
---+---
 Reporter:  karsten|  Owner:  nickm
 Type:  enhancement| Status:
   |  needs_review
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bridge, stem, review-group-24  |  Actual Points:
Parent ID: | Points:  .2
   |  remaining
 Reviewer:  isis   |Sponsor:  SponsorM
---+---

Comment (by isis):

 Okay, I reviewed your code, nickm, and it LGTM.  I made two new commits on
 top of it, in my `feature18329_029` branch, one to steal a docstring from
 my patch, and another to steal the unittests I made. If you want to merge
 just your commit or also the tests/docs, either's fine by me.

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

Re: [tor-bugs] #18105 [Core Tor/Tor]: Replace getsockname with tor_getsockname

[Tor Bug Tracker & Wiki]

#18105: Replace getsockname with tor_getsockname
-+-
 Reporter:  teor |  Owner:
 |  eewayhsu
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, intro, api, code-  |  Actual Points:
  simplification |
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 I don't think that's what we're going for here.  The idea was to change
 tor_getsockname, or to create a new wrapper for tor_getsockname, so that
 it would put its result into a tor_addr_t rather than into a struct
 sockaddr.

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

Re: [tor-bugs] #23261 [Applications/Tor Launcher]: implement configuration portion of new Tor Launcher UI

[Tor Bug Tracker & Wiki]

#23261: implement configuration portion of new Tor Launcher UI
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  ux-team, TorBrowserTeam201710R  |  Actual Points:
Parent ID:  #21951  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by phoul):

 Replying to [comment:23 mcs]:
 > We are going to make patches for this ticket and for #23262 available
 for review very soon. We do have a couple of questions for the UX team
 (these can be addressed with follow up patches):
 > * Should the "For assistance" text that appears on the current setup
 wizard and Network Settings window be kept or removed? It is not included
 in the design. This may also be a question for our community people
 (Colin, I am looking at you)

 I think leaving this off for now would be best. On the contact page, we
 currently advise users not to contact frontdesk@ for support requests
 (https://www.torproject.org/about/contact.html.en).

 One thing we could do is direct users to the support portal in that
 location.

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

Re: [tor-bugs] #23500 [Core Tor/Tor]: check-spaces.pl should check spaces after a comma when in functions.

[Tor Bug Tracker & Wiki]

#23500: check-spaces.pl should check spaces after a comma when in functions.
-+-
 Reporter:  ewong|  Owner:  (none)
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Trivial  | Resolution:
 Keywords:  code-style, review-group-24  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


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

Re: [tor-bugs] #23637 [Core Tor/Tor]: Make exit flag depend on ports 80 and 443, not 6667

[Tor Bug Tracker & Wiki]

#23637: Make exit flag depend on ports 80 and 443, not 6667
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * keywords:  review-group-24 =>


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

Re: [tor-bugs] #23168 [Core Tor/Tor]: Guard sample calls relay descriptors a "consensus"

[Tor Bug Tracker & Wiki]

#23168: Guard sample calls relay descriptors a "consensus"
+--
 Reporter:  teor|  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.9
 Severity:  Normal  | Resolution:
 Keywords:  tor-log, easy, review-group-24  |  Actual Points:
Parent ID:  | Points:  0.5
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Thanks for the patch!  Maybe it would make more sense to say "Updating
 sampled guard status based on directory documents received at %s."?

 Also, there's something I don't understand: why are we reporting
 `gs->last_time_on_internet` as the time when the documents were received?

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

Re: [tor-bugs] #23571 [Core Tor/Tor]: Stop closing channels out from under OR connections in hibernate_go_dormant()

[Tor Bug Tracker & Wiki]

#23571: Stop closing channels out from under OR connections in
hibernate_go_dormant()
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.7-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-client, hibernate,|  Actual Points:  0.2
  review-group-24|
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 (Otherwise, looks plausible. I assume this is reasonably chutney-tested?)

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

Re: [tor-bugs] #23571 [Core Tor/Tor]: Stop closing channels out from under OR connections in hibernate_go_dormant()

[Tor Bug Tracker & Wiki]

#23571: Stop closing channels out from under OR connections in
hibernate_go_dormant()
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.7-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay, tor-client, hibernate,|  Actual Points:  0.2
  review-group-24|
Parent ID:   | Points:  0.2
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Do we want to be setting the hold_open_until_flushed flag here, really?  I
 don't think we did that before...

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

Re: [tor-bugs] #23573 [Core Tor/Tor]: Do we want to close all connections when tor closes?

[Tor Bug Tracker & Wiki]

#23573: Do we want to close all connections when tor closes?
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  shutdown, privcount, correctness,|  Actual Points:
  chutney-wants, review-group-24 |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-

Comment (by nickm):

 > Is the connection_mark_for_close() in hibernate_go_dormant enough here?
 It only marks the connections; it doesn't necessarily close them.

 Oh! Does this patch assume that #23571 is also 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] #23637 [Core Tor/Tor]: Make exit flag depend on ports 80 and 443, not 6667

[Tor Bug Tracker & Wiki]

#23637: Make exit flag depend on ports 80 and 443, not 6667
-+
 Reporter:  arma |  Owner:  (none)
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-24  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by nickm):

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


Comment:

 taking in master, marking for possible 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] #23974 [Metrics/Atlas]: Atlas behaves strangely

[Tor Bug Tracker & Wiki]

#23974: Atlas behaves strangely
---+-
 Reporter:  Lovegiver  |  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal |   Keywords:  backend error,browser,proxy
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 Hi,

 I own a Tor relay that is actually running fine.

 I use to monitor its performances using Atlas.
 The URL I use is :
 https://atlas.torproject.org/#details/7E0AE5C9FC09B569DC1FE3F7647577EDEFD1C639

 For about 2 weeks, Atlas seems to be down as I get an error message :


 Backend error!

 Atlas is unable to get a response from its backend server. This probably
 means that the backend server is unavailable right now. This can also
 happen, however, if you did not format your query correctly. Please have a
 look at the About page that explains what type of search queries are
 supported by Atlas.


 What I do not understand is the following :

 Error occurs when I'm using Firefox Developper Edition (up to date) or IE
 11.
 Those 2 browsers are using default network parameters (no proxy).

 But if I'm using Firefox Standard Edition (up to date), using my Tor relay
 as a proxy, it's working !
 It is also working when using the Tor Browser (up to date) with default
 network parameters (I do not use my own Tor relay as a proxy, I let Tor
 manage everything).

 Until now I didn't notice anything wrong with my personal network, that's
 why I really don't understand why all my browsers do not behave the same
 way and why Atlas seems to be working only when using a Tor proxy.

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

Re: [tor-bugs] #21816 [Core Tor/Tor]: Add support for Pluggable Transports 2.0

[Tor Bug Tracker & Wiki]

#21816: Add support for Pluggable Transports 2.0
-+-
 Reporter:  chelseakomlo |  Owner:
 |  dasyatid1
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, tor-pt, tor-bridge,  |  Actual Points:
  design, pt2, review-group-23, review-group-24  |
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
 |  SponsorM-can
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Okay, I've left comments on the ticket.  It looks like a good start!

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

Re: [tor-bugs] #23862 [Core Tor/Tor]: Tor only updates guard state after a consensus if it has enough directory info

[Tor Bug Tracker & Wiki]

#23862: Tor only updates guard state after a consensus if it has enough 
directory
info
-+-
 Reporter:  teor |  Owner:  asn
 Type:  defect   | Status:
 |  assigned
 Priority:  Very High|  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.0.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-guard, tor-bridge, tor-client,   |  Actual Points:
  030-backport, 031-backport |
Parent ID:  #21969   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorV
-+-

Comment (by asn):

 Worked many hours today making a nice unittest here. Almost there but not
 quite there yet. Will try to have something here tomorrow.

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

Re: [tor-bugs] #23817 [Core Tor/Tor]: Tor re-tries directory mirrors that it knows are missing microdescriptors

[Tor Bug Tracker & Wiki]

#23817: Tor re-tries directory mirrors that it knows are missing 
microdescriptors
+--
 Reporter:  teor|  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-guard, tor-hs, prop224  |  Actual Points:
Parent ID:  #21969  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by asn):

 Here is a draft of a suggested technical solution here which involves a
 cache tracking failed md downloads:

 1) Introduce an `md_failure_cache` cache which tracks failed or missing
 mds downloads per relays. That is a cache with entries as follows: "We
 failed to fetch md  from relays X, Y, Z".

   engineering XXX: how to figure out missing mds from received batches

 2) When we want to fetch a batch of mds from relay X, check
 `md_failure_cache` to see if any of the batched mds is included in the
 cache for relay X. if that's the case, add relay X to the excluded list of
 nodes for dirservers, so that our directory subsystems skips relay X and
 moves to the next one in line.

          engineering XXX: is there an exclude list for dirserver
 downloads?

 3) When we succeed in fetching an md, remove its entries from the cache
 (so that we retry in the future from  relay X which is probably our top
 primary guard).

 4) Finally, to address #23863, when we detect that we are missing mds from
 our primary guards, order an immediate download of those missing mds, so
 that the previous steps get done.

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

Re: [tor-bugs] #22428 [Metrics/CollecTor]: Add webstats module

[Tor Bug Tracker & Wiki]

#22428: Add webstats module
---+-
 Reporter:  iwakeh |  Owner:  iwakeh
 Type:  enhancement| Status:  needs_revision
 Priority:  High   |  Milestone:  CollecTor 1.5.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-2017   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Just for the record there is now a name and javadoc tweaking
 [https://gitweb.torproject.org/user/iwakeh/collector.git/commit/?h=task-22428-4
 fixup commit].  But, review is not necessary immediately as the changes in
 #23243 will lead to more changes 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] #21816 [Core Tor/Tor]: Add support for Pluggable Transports 2.0

[Tor Bug Tracker & Wiki]

#21816: Add support for Pluggable Transports 2.0
-+-
 Reporter:  chelseakomlo |  Owner:
 |  dasyatid1
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, tor-pt, tor-bridge,  |  Actual Points:
  design, pt2, review-group-23, review-group-24  |
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
 |  SponsorM-can
-+-

Comment (by nickm):

 Starting review.   I've opened a code review ticket at
 https://oniongit.eu/nickm/tor/merge_requests/8 so I can comment on the
 commits. Please let me know if you have any problems reading them :)

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

Re: [tor-bugs] #21816 [Core Tor/Tor]: Add support for Pluggable Transports 2.0

[Tor Bug Tracker & Wiki]

#21816: Add support for Pluggable Transports 2.0
-+-
 Reporter:  chelseakomlo |  Owner:
 |  dasyatid1
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-client, tor-pt, tor-bridge,  |  Actual Points:
  design, pt2, review-group-23, review-group-24  |
Parent ID:   | Points:
 Reviewer:  nickm|Sponsor:
 |  SponsorM-can
-+-
Changes (by nickm):

 * reviewer:   => nickm


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

Re: [tor-bugs] #23243 [Metrics/Website]: Write a specification for Tor web server logs

[Tor Bug Tracker & Wiki]

#23243: Write a specification for Tor web server logs
-+
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by iwakeh):

 Replying to [comment:48 karsten]:
 > Replying to [comment:47 iwakeh]:
 > > Replying to [comment:46 karsten]:
 > > > I'm not sure if we can resolve these questions by hard thinking.
 > >
 > > Well, we need to work on thoughtful decision making.
 >
 > Unfortunately, I'm not a good person these days to dive deep enough into
 this topic to make thoughtful decisions. Too many topics, too little time
 to do any of them well enough. That's why I hoped you'd just solve all
 problems here and I could then review the solution. :)

 There are always many solutions. So, you'd also need to be involved in
 choosing ;-)

 >
 > ...
 > > The current webstat code and the spec require a log per day.
 >
 > Well, no. The spec says "Tor's web servers are configured to rotate logs
 ''at least'' once per day". If we didn't mean that, let's phrase it
 differently. But how?

 The spec indirectly only allows at most one log per day and virtual-
 physical host combination by its naming requirements `/-access.log-MMDD[.gz]`.  Combining this with the at-
 least-once-per-day yields exactly one log per day.  It might be useful to
 write this explicitly.
 (If more logs for the same date are supplied, the first wins.)

 >
 > And we should write down possible failure modes for the case that logs
 are rotated less often or more often.

 The naming requirements don't allow for more than one log per day.
 Logs that don't match the requirements are dropped (which can be logged as
 warning but that's part of the implementation not part of the spec).

 >
 > In any case, we should warn in case we run into one of these cases,
 rather than silently continuing operation and simply producing
 fewer/smaller sanitized logs.

 There will be warnings in the logs, if suddenly the naming of logs doesn't
 comply anymore to the specs requirements.  And, that would inevitably
 happen, if logs are rotated more often than once per day.

 >
 > > [...]
 > > 1. Make sure by outside means that there is no day without a log (e.g.
 by providing an empty file for that day using 'touch').  This would work
 without additional implementation for CollecTor and this works for bulk
 imports as well as daily processing.  As a result there will be a
 sanitized log for each day offered by CollecTor, some might be empty.
 >
 > I'd say we need to do something that doesn't require any upstream
 changes. In other words, whatever ends up in `in/webstats/` is what we
 should be able to work with. We shouldn't require upstream to touch files
 for us.
 >
 > > 2. For bulk processing a property could signal CollecTor to use all
 logs without insisting on an uninterrupted chain.  This still requires
 outside measures for making sure no log lines are lost and might result in
 days without any logs, unless CollecTor creates empty ones.
 > > 3. Think out a mechanism that enables more automated processing of an
 interrupted chain of logs.  This seems error prone an will result in many
 edge cases.
 >
 > I don't know, maybe we can do something with system time or state files.
 Or we could process everything in `in/webstats/` and write everything to
 `out/` and `recent/` except the first and last encountered UTC days. Just
 some ideas.
 >
 > Again, I'm not deep enough into this to make a good decision. I just
 hope that whatever thing we'll build here is robust enough to either
 handle all of the cases or warns loudly whenever it runs into an
 unforeseen case.
 >
 > I'm very concerned about silently losing data. That's the worst thing
 that could happen to us, in particular given that we don't keep archives
 of the input data in this case.


 From the above I infer that you think we should opt for number 3, i.e.,
 automate as much as possible, warn whenever there is some unforeseen
 naming etc.
 Is this correct?

 If that's the case, my next steps would be to provide a patch for the spec
 for making the one log per day requirement explicit and also discuss what
 happens if logs are missing; and secondly, based on that I will extend the
 implementation in #22428 to address the new requirements.

 Does that sound like a plan?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org

Re: [tor-bugs] #20424 [Core Tor/Tor]: Remove --enable-openbsd-malloc (Tor maxes CPU when --enable-openbsd-malloc is used) (was: Tor maxes CPU when --enable-openbsd-malloc is used)

[Tor Bug Tracker & Wiki]

#20424: Remove --enable-openbsd-malloc (Tor maxes CPU when 
--enable-openbsd-malloc
is used)
+
 Reporter:  icanhasaccount  |  Owner:  (none)
 Type:  defect  | Status:  needs_review
 Priority:  Low |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Minor   | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:  .2
 Reviewer:  |Sponsor:
+
Changes (by Hello71):

 * Attachment "0001-Add-with-malloc-configure-option.-20424-23777.patch"
 removed.


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

Re: [tor-bugs] #20424 [Core Tor/Tor]: Remove --enable-openbsd-malloc (Tor maxes CPU when --enable-openbsd-malloc is used)

[Tor Bug Tracker & Wiki]

#20424: Remove --enable-openbsd-malloc (Tor maxes CPU when 
--enable-openbsd-malloc
is used)
+
 Reporter:  icanhasaccount  |  Owner:  (none)
 Type:  defect  | Status:  needs_review
 Priority:  Low |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Minor   | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:  .2
 Reviewer:  |Sponsor:
+
Changes (by Hello71):

 * Attachment "0001-Add-with-malloc-configure-option.-20424-23777.patch"
 added.

 so apparently autoconf calls it LIBS

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

Re: [tor-bugs] #23716 [Metrics/Website]: Rename Operation section to Services

[Tor Bug Tracker & Wiki]

#23716: Rename Operation section to Services
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:  implemented
 Keywords:  ux-team  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

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


Comment:

 I just renamed "Operation" to "Services" on the website and opened #23973
 for discussing adding a new "Analysis" category. Closing. Thanks,
 everyone!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23973 [Metrics/Website]: Add "Analysis" as new first category next to "News"

[Tor Bug Tracker & Wiki]

#23973: Add "Analysis" as new first category next to "News"
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 From [https://trac.torproject.org/projects/tor/ticket/23716#comment:10
 #23716]:

 > irl, let's talk more about your suggestion regarding "swapping out the
 secondary-nav depending on the section at the top of the page and adding
 an Analysis section for the things currently on the home page." Do you
 mean adding "Analysis" as new first category next to "News", with "Users",
 "Servers", etc. as subitems under "Analysis" and a separate (possibly
 empty) set of subitems under "News", "Sources", etc.? Happy to talk about
 that, but let's move to a new ticket, as it's somewhat unrelated to the
 renaming question here. Note that we'll likely want to talk to a/our web
 designer and that we might want to wait and see what the main Tor website
 redesign produces.

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

Re: [tor-bugs] #18105 [Core Tor/Tor]: Replace getsockname with tor_getsockname

[Tor Bug Tracker & Wiki]

#18105: Replace getsockname with tor_getsockname
-+-
 Reporter:  teor |  Owner:
 |  eewayhsu
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, intro, api, code-  |  Actual Points:
  simplification |
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * milestone:  Tor: unspecified => 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

[tor-bugs] #23972 [Webpages/Website]: Add a link to torproject.org's onion service at the bottom

[Tor Bug Tracker & Wiki]

#23972: Add a link to torproject.org's onion service at the bottom
--+-
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:  ux-team
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Many sites already do that, for example ProPublica.org has at the bottom a
 "Browse via Tor" link to its onion service

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

Re: [tor-bugs] #23261 [Applications/Tor Launcher]: implement configuration portion of new Tor Launcher UI

[Tor Bug Tracker & Wiki]

#23261: implement configuration portion of new Tor Launcher UI
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  ux-team, TorBrowserTeam201710R  |  Actual Points:
Parent ID:  #21951  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by mcs):

 * Attachment "tor-launcher-redesign-v10.pdf" 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] #18105 [Core Tor/Tor]: Replace getsockname with tor_getsockname

[Tor Bug Tracker & Wiki]

#18105: Replace getsockname with tor_getsockname
-+-
 Reporter:  teor |  Owner:
 |  eewayhsu
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, intro, api, code-  |  Actual Points:
  simplification |
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-
Changes (by callumw):

 * status:  assigned => needs_review


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

Re: [tor-bugs] #23262 [Applications/Tor Launcher]: implement integrated progress bar for new Tor Launcher UI

[Tor Bug Tracker & Wiki]

#23262: implement integrated progress bar for new Tor Launcher UI
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  ux-team, TorBrowserTeam201710R  |  Actual Points:
Parent ID:  #21951  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--

Comment (by mcs):

 The multi-step progress bar now has its own ticket: #23971.

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

Re: [tor-bugs] #23261 [Applications/Tor Launcher]: implement configuration portion of new Tor Launcher UI

[Tor Bug Tracker & Wiki]

#23261: implement configuration portion of new Tor Launcher UI
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  ux-team, TorBrowserTeam201710R  |  Actual Points:
Parent ID:  #21951  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by mcs):

 * status:  needs_information => needs_review


Comment:

 Replying to [comment:29 gk]:
 > First part of the review. This only covers comparing the attached design
 spec with the layout implemented. Apart from nits which probably don't
 matter (slightly different "Quit" button positioning etc.):

 The position of the Quit button varies by platform due to our use of
 Mozilla's XUL wizard element. We could change it to be consistent across
 platforms, but it would be extra work and might make things less
 consistent with other parts of Tor Browser.

 > 1) The design shows that `obfs4` is selected by default and that it is
 the recommended bridge type. Both is missing in the layout implemented but
 it seems worthwhile to have, no?

 We implemented v10 of Linda's design. I think you may be looking at v9. I
 will attach the v10 PDF to this ticket (it was sent by Linda to some of us
 via email on Sept 26th).

 > 2) Is there are ticket somewhere tracking the fancy icons and progress
 implementation as shown on page 9 and 10 of the design doc? If not, could
 you create one?

 I created #23971.

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

Re: [tor-bugs] #18105 [Core Tor/Tor]: Replace getsockname with tor_getsockname

[Tor Bug Tracker & Wiki]

#18105: Replace getsockname with tor_getsockname
-+-
 Reporter:  teor |  Owner:
 |  eewayhsu
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, intro, api, code-  |  Actual Points:
  simplification |
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-
Changes (by callumw):

 * Attachment "0001-changed-getsockname-calls-to-tor_getsockname.patch"
 added.

 renamed all references to getsockname() to use the tor_getsockname()
 wrapper function

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

Re: [tor-bugs] #23486 [Applications/Tor Launcher]: nice icons for the progress bar

[Tor Bug Tracker & Wiki]

#23486: nice icons for the progress bar
---+---
 Reporter:  isabela|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team, TorBrowserTeam201710  |  Actual Points:
Parent ID:  #23971 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by mcs):

 * parent:  #23262 => #23971


Comment:

 We created a new ticket for the implementation of the multi-step progress
 bar, so I adjusted this ticket's 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] #23971 [Applications/Tor Launcher]: implement multi-step progress bar for new Tor Launcher UI

[Tor Bug Tracker & Wiki]

#23971: implement multi-step progress bar for new Tor Launcher UI
---+---
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #21951 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by mcs):

 * parent:   => #21951


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23971 [Applications/Tor Launcher]: implement multi-step progress bar for new Tor Launcher UI

[Tor Bug Tracker & Wiki]

#23971: implement multi-step progress bar for new Tor Launcher UI
---+---
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+---
 The new Tor Launcher design includes a phased or multi-step progress bar.
 See: https://marvelapp.com/3f6102d/screen/31457651

 This work will require improved bootstrap status/progress reporting from
 core Tor.

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

Re: [tor-bugs] #23958 [Metrics/Onionoo]: Onionoo not fetching the bridge descriptor correctly?

[Tor Bug Tracker & Wiki]

#23958: Onionoo not fetching the bridge descriptor correctly?
-+--
 Reporter:  dgoulet  |  Owner:  metrics-team
 Type:  defect   | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:  not a bug
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by dgoulet):

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


Comment:

 Yes big thanks dcf! That makes complete sense now. :)

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

Re: [tor-bugs] #23243 [Metrics/Website]: Write a specification for Tor web server logs

[Tor Bug Tracker & Wiki]

#23243: Write a specification for Tor web server logs
-+
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_revision
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2017 |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by karsten):

 Replying to [comment:47 iwakeh]:
 > Replying to [comment:46 karsten]:
 > > I'm not sure if we can resolve these questions by hard thinking.
 >
 > Well, we need to work on thoughtful decision making.

 Unfortunately, I'm not a good person these days to dive deep enough into
 this topic to make thoughtful decisions. Too many topics, too little time
 to do any of them well enough. That's why I hoped you'd just solve all
 problems here and I could then review the solution. :)

 > There're not that many questions above except yours:
 > > ... what happens if a web server rotates logs more often than once per
 day? At least that's something that we write in the specification. I'm not
 sure how this would work with file names, so maybe we in fact require that
 logs are rotated exactly once per day, and we just didn't write that in
 the specification yet. However, it seems rather restrictive to prescribe
 exact log rotation intervals in order to sanitize logs subsequently. Maybe
 we should be less restrictive here.
 >
 > The current webstat code and the spec require a log per day.

 Well, no. The spec says "Tor's web servers are configured to rotate logs
 ''at least'' once per day". If we didn't mean that, let's phrase it
 differently. But how?

 And we should write down possible failure modes for the case that logs are
 rotated less often or more often.

 In any case, we should warn in case we run into one of these cases, rather
 than silently continuing operation and simply producing fewer/smaller
 sanitized logs.

 > [...]
 > 1. Make sure by outside means that there is no day without a log (e.g.
 by providing an empty file for that day using 'touch').  This would work
 without additional implementation for CollecTor and this works for bulk
 imports as well as daily processing.  As a result there will be a
 sanitized log for each day offered by CollecTor, some might be empty.

 I'd say we need to do something that doesn't require any upstream changes.
 In other words, whatever ends up in `in/webstats/` is what we should be
 able to work with. We shouldn't require upstream to touch files for us.

 > 2. For bulk processing a property could signal CollecTor to use all logs
 without insisting on an uninterrupted chain.  This still requires outside
 measures for making sure no log lines are lost and might result in days
 without any logs, unless CollecTor creates empty ones.
 > 3. Think out a mechanism that enables more automated processing of an
 interrupted chain of logs.  This seems error prone an will result in many
 edge cases.

 I don't know, maybe we can do something with system time or state files.
 Or we could process everything in `in/webstats/` and write everything to
 `out/` and `recent/` except the first and last encountered UTC days. Just
 some ideas.

 Again, I'm not deep enough into this to make a good decision. I just hope
 that whatever thing we'll build here is robust enough to either handle all
 of the cases or warns loudly whenever it runs into an unforeseen case.

 I'm very concerned about silently losing data. That's the worst thing that
 could happen to us, in particular given that we don't keep archives of the
 input data in this case.

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

Re: [tor-bugs] #23261 [Applications/Tor Launcher]: implement configuration portion of new Tor Launcher UI

[Tor Bug Tracker & Wiki]

#23261: implement configuration portion of new Tor Launcher UI
+--
 Reporter:  mcs |  Owner:  brade
 Type:  defect  | Status:
|  needs_information
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Launcher   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  ux-team, TorBrowserTeam201710R  |  Actual Points:
Parent ID:  #21951  | Points:
 Reviewer:  |Sponsor:  Sponsor4
+--
Changes (by gk):

 * status:  needs_review => needs_information


Comment:

 First part of the review. This only covers comparing the attached design
 spec with the layout implemented. Apart from nits which probably don't
 matter (slightly different "Quit" button positioning etc.):

 1) The design shows that `obfs4` is selected by default and that it is the
 recommended bridge type. Both is missing in the layout implemented but it
 seems worthwhile to have, no?

 2) Is there are ticket somewhere tracking the fancy icons and progress
 implementation as shown on page 9 and 10 of the design doc? If not could
 you create one?

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

Re: [tor-bugs] #23577 [Core Tor/Tor]: Make setup_introduce1_data() take a node instead of an extend_info

[Tor Bug Tracker & Wiki]

#23577: Make setup_introduce1_data() take a node instead of an extend_info
-+-
 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:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:
Parent ID:  #23493   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by neel):

 I have a new patch with the filename {{004-desriptive_msg.patch}}.

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

Re: [tor-bugs] #23577 [Core Tor/Tor]: Make setup_introduce1_data() take a node instead of an extend_info

[Tor Bug Tracker & Wiki]

#23577: Make setup_introduce1_data() take a node instead of an extend_info
-+-
 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:  prop224, tor-hs, single-onion, ipv6  |  Actual Points:
Parent ID:  #23493   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by neel):

 * Attachment "004-desriptive_msg.patch" added.

 Revised Patch (Revision 3)

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

Re: [tor-bugs] #23961 [Webpages/Website]: Upload fundraising images to media.torproject.org

[Tor Bug Tracker & Wiki]

#23961: Upload fundraising images to media.torproject.org
--+
 Reporter:  steph |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by steph):

 missing one: "Tor Open Graph Card"

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

Re: [tor-bugs] #23930 [Applications/Tor Browser]: Tor Browser 7.x for Mac crashes at startup

[Tor Bug Tracker & Wiki]

#23930: Tor Browser 7.x for Mac crashes at startup
--+---
 Reporter:  wga   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by wga):

 (lldb) bt
 * thread #1: tid = 0x162e1d, 0x0001024f8d30
 XUL`___lldb_unnamed_symbol47072$$XUL + 64, queue = 'com.apple.main-
 thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
   * frame #0: 0x0001024f8d30 XUL`___lldb_unnamed_symbol47072$$XUL + 64
 frame #1: 0x0001024f88bb XUL`___lldb_unnamed_symbol47066$$XUL +
 315
 frame #2: 0x0001024f8736 XUL`___lldb_unnamed_symbol47065$$XUL +
 678
 frame #3: 0x0001024a7a76 XUL`___lldb_unnamed_symbol45337$$XUL + 70
 frame #4: 0x000102340488 XUL`___lldb_unnamed_symbol39517$$XUL +
 360
 frame #5: 0x000102336424 XUL`___lldb_unnamed_symbol39397$$XUL +
 244
 frame #6: 0x00010233687c XUL`___lldb_unnamed_symbol39402$$XUL +
 140
 frame #7: 0x000103907194 XUL`___lldb_unnamed_symbol132738$$XUL +
 436
 frame #8: 0x000103906fd3 XUL`___lldb_unnamed_symbol132737$$XUL +
 83
 frame #9: 0x0001039fbc03 XUL`___lldb_unnamed_symbol136070$$XUL +
 4115
 frame #10: 0x0001039f9fef XUL`___lldb_unnamed_symbol136068$$XUL +
 559
 frame #11: 0x0001039ffc88 XUL`___lldb_unnamed_symbol136086$$XUL +
 1800
 frame #12: 0x000103a10222 XUL`___lldb_unnamed_symbol136183$$XUL +
 82
 frame #13: 0x000103a1114e XUL`___lldb_unnamed_symbol136184$$XUL +
 686
 frame #14: 0x00010395f912 XUL`___lldb_unnamed_symbol134099$$XUL +
 914
 frame #15: 0x00010399a1d1 XUL`___lldb_unnamed_symbol134630$$XUL +
 177
 frame #16: 0x00010399ac92 XUL`___lldb_unnamed_symbol134633$$XUL +
 130
 frame #17: 0x000103ad3245 XUL`___lldb_unnamed_symbol139202$$XUL +
 421
 frame #18: 0x000103aadd8c XUL`___lldb_unnamed_symbol138502$$XUL +
 124
 frame #19: 0x000103ad3245 XUL`___lldb_unnamed_symbol139202$$XUL +
 421
 frame #20: 0x000103aadd8c XUL`___lldb_unnamed_symbol138502$$XUL +
 124
 frame #21: 0x000103ad3245 XUL`___lldb_unnamed_symbol139202$$XUL +
 421
 frame #22: 0x000103aadd8c XUL`___lldb_unnamed_symbol138502$$XUL +
 124
 frame #23: 0x000103ad3245 XUL`___lldb_unnamed_symbol139202$$XUL +
 421
 frame #24: 0x000103aadd8c XUL`___lldb_unnamed_symbol138502$$XUL +
 124
 frame #25: 0x0001039a8796 XUL`___lldb_unnamed_symbol134867$$XUL +
 38
 frame #26: 0x000103ad3c6d XUL`___lldb_unnamed_symbol139214$$XUL +
 109
 frame #27: 0x000103aadd8c XUL`___lldb_unnamed_symbol138502$$XUL +
 124
 frame #28: 0x000103ad2a38 XUL`___lldb_unnamed_symbol139197$$XUL +
 392
 frame #29: 0x000103ad1166 XUL`___lldb_unnamed_symbol139193$$XUL +
 422
 frame #30: 0x000103aae165 XUL`___lldb_unnamed_symbol138507$$XUL +
 69
 frame #31: 0x000103aac7fe XUL`___lldb_unnamed_symbol138470$$XUL +
 30
 frame #32: 0x000103ad47c1 XUL`___lldb_unnamed_symbol139219$$XUL +
 769
 frame #33: 0x000103aae165 XUL`___lldb_unnamed_symbol138507$$XUL +
 69
 frame #34: 0x000103aadbf6 XUL`___lldb_unnamed_symbol138501$$XUL +
 790
 frame #35: 0x00010397e39a XUL`___lldb_unnamed_symbol134351$$XUL +
 106
 frame #36: 0x000103a1a9d2 XUL`___lldb_unnamed_symbol136251$$XUL +
 530
 frame #37: 0x00010391daf3 XUL`___lldb_unnamed_symbol133004$$XUL +
 1571
 frame #38: 0x000103924127 XUL`___lldb_unnamed_symbol133111$$XUL +
 407
 frame #39: 0x000103923d84 XUL`___lldb_unnamed_symbol133110$$XUL +
 804
 frame #40: 0x0001038445a6 XUL`___lldb_unnamed_symbol130947$$XUL +
 2406
 frame #41: 0x000103848365 XUL`___lldb_unnamed_symbol131005$$XUL +
 421
 frame #42: 0x0001038480dc XUL`___lldb_unnamed_symbol131004$$XUL +
 188
 frame #43: 0x000103848e48 XUL`___lldb_unnamed_symbol131020$$XUL +
 40
 frame #44: 0x000101af6823 XUL`___lldb_unnamed_symbol3410$$XUL +
 739
 frame #45: 0x000101b1ef43 XUL`___lldb_unnamed_symbol4293$$XUL + 51
 frame #46: 0x000103bc50a6 XUL`___lldb_unnamed_symbol144134$$XUL +
 422
 frame #47: 0x000103b87e3b XUL`___lldb_unnamed_symbol142466$$XUL +
 6299
 frame #48: 0x000103b863fc XUL`___lldb_unnamed_symbol142464$$XUL +
 172
 frame #49: 0x000101b0270f XUL`NS_InvokeByIndex + 511
 frame #50: 0x0001021ae684 XUL`___lldb_unnamed_symbol33048$$XUL +
 4372
 frame #51: 0x0001021aff8b XUL`___lldb_unnamed_symbol33068$$XUL +
 

Re: [tor-bugs] #23930 [Applications/Tor Browser]: Tor Browser 7.x for Mac crashes at startup

[Tor Bug Tracker & Wiki]

#23930: Tor Browser 7.x for Mac crashes at startup
--+---
 Reporter:  wga   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by wga):

 Here is the lldb output after upgrading Xcode:

 $ lldb ./Contents/MacOS/firefox
 (lldb) target create "./Contents/MacOS/firefox"
 Current executable set to './Contents/MacOS/firefox' (x86_64).
 (lldb) run
 Process 39786 launched: './Contents/MacOS/firefox' (x86_64)
 1508847722100   addons.webextension.   WARNLoading extension
 'null': Reading manifest: Error processing devtools_page: An unexpected
 property was found in the WebExtension manifest.
 1508847722900   addons.webextension.   WARNLoading extension
 'null': Reading manifest: Error processing permissions.1: Unknown
 permission "privacy"
 1508847722900   addons.webextension.   WARNLoading extension
 'null': Reading manifest: Error processing permissions.4: Unknown
 permission "unlimitedStorage"
 Oct 24 14:22:03.849 [notice] Tor 0.3.1.7 (git-6babd3d9ba9318b3) running on
 Darwin with Libevent 2.0.22-stable, OpenSSL 1.0.2k, Zlib 1.2.5, Liblzma
 N/A, and Libzstd N/A.
 Oct 24 14:22:03.850 [notice] Tor can't help you if you use it wrong! Learn
 how to be safe at https://www.torproject.org/download/download#warning
 Oct 24 14:22:03.851 [notice] Read configuration file
 "/Users/gander/Desktop/TorBrowser.app/Contents/Resources/TorBrowser/Tor
 /torrc-defaults".
 Oct 24 14:22:03.851 [notice] Read configuration file
 "/Users/gander/Desktop/TorBrowser-Data/Tor/torrc".
 Oct 24 14:22:03.863 [notice] Opening Control listener on 127.0.0.1:9151
 Oct 24 14:22:03.864 [notice] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 1508847723800   addons.webextension.{73a6fe31-595d-460b-a920-fcc0f8843232}
 WARNLoading extension '{73a6fe31-595d-460b-a920-fcc0f8843232}':
 Reading manifest: Error processing permissions.1: Unknown permission
 "privacy"
 Oct 24 14:22:03.000 [notice] Parsing GEOIP IPv4 file
 /Users/gander/Desktop/TorBrowser.app/Contents/Resources/TorBrowser/Tor/geoip.
 1508847723800   addons.webextension.{73a6fe31-595d-460b-a920-fcc0f8843232}
 WARNLoading extension '{73a6fe31-595d-460b-a920-fcc0f8843232}':
 Reading manifest: Error processing permissions.4: Unknown permission
 "unlimitedStorage"
 Oct 24 14:22:04.000 [notice] Parsing GEOIP IPv6 file
 /Users/gander/Desktop/TorBrowser.app/Contents/Resources/TorBrowser/Tor/geoip6.
 Oct 24 14:22:04.000 [notice] Bootstrapped 0%: Starting
 Oct 24 14:22:04.000 [notice] Delaying directory fetches: DisableNetwork is
 set.
 Oct 24 14:22:04.000 [notice] New control connection opened from 127.0.0.1.
 Oct 24 14:22:04.000 [notice] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 Oct 24 14:22:04.000 [notice] Starting with guard context "default"
 Oct 24 14:22:04.000 [notice] New control connection opened from 127.0.0.1.
 1508847724900   addons.webextension.https-everywhere-...@eff.org
 WARNLoading extension 'https-everywhere-...@eff.org': Reading
 manifest: Error processing devtools_page: An unexpected property was found
 in the WebExtension manifest.
 1508847725000   addons.webextension.https-everywhere-...@eff.org
 WARNPlease specify whether you want browser_style or not in your
 browser_action options.
 0 migrated.
 Process 39786 stopped
 * thread #1: tid = 0x162e1d, 0x0001024f8d30
 XUL`___lldb_unnamed_symbol47072$$XUL + 64, queue = 'com.apple.main-
 thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
 frame #0: 0x0001024f8d30 XUL`___lldb_unnamed_symbol47072$$XUL + 64
 XUL`___lldb_unnamed_symbol47072$$XUL:
 ->  0x1024f8d30 <+64>: movq   (%r13), %rax
 0x1024f8d34 <+68>: leaq   0x30(%r14), %rsi
 0x1024f8d38 <+72>: leaq   0x20(%rsp), %rdx
 0x1024f8d3d <+77>: leaq   0x17(%rsp), %rcx
 (lldb)


 Note that there is a "world" icon in the Dock while firefox is running in
 lldb. The icon goes away when I quit lldb.

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

Re: [tor-bugs] #23924 [Core Tor/Tor]: Improve control-spec.txt

[Tor Bug Tracker & Wiki]

#23924: Improve control-spec.txt
--+
 Reporter:  tom   |  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Very Low  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  tor-control tor-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #23924 [Core Tor/Tor]: Improve control-spec.txt

[Tor Bug Tracker & Wiki]

#23924: Improve control-spec.txt
--+
 Reporter:  tom   |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Very Low  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-control tor-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 lgtm; merging.  I've also added c912116e9bc300a867a180364765bac10e9fd779
 tried to make the paragraph about AUTHENTICATE read more clearly.

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

Re: [tor-bugs] #23930 [Applications/Tor Browser]: Tor Browser 7.x for Mac crashes at startup

[Tor Bug Tracker & Wiki]

#23930: Tor Browser 7.x for Mac crashes at startup
--+---
 Reporter:  wga   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  tbb-crash |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by wga):

 * Attachment "Screen Shot 2017-10-24 at 14.22.40.png" added.

 torbrowser icon in dock - lldb

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

Re: [tor-bugs] #23952 [Core Tor/Tor]: LOG_PROTOCOL_WARN can call get_options() during an options transition.

[Tor Bug Tracker & Wiki]

#23952: LOG_PROTOCOL_WARN can call get_options() during an options transition.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by nickm):

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


Comment:

 merging 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] #23924 [Core Tor/Tor]: Improve control-spec.txt

[Tor Bug Tracker & Wiki]

#23924: Improve control-spec.txt
--+
 Reporter:  tom   |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Very Low  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-control tor-spec  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:  Tor: unspecified => 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] #22719 [Core Tor/Tor]: Bug: src/common/compress.c:576: tor_compress_process:

[Tor Bug Tracker & Wiki]

#22719: Bug: src/common/compress.c:576: tor_compress_process:
--+
 Reporter:  toralf|  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.7
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 It is indeed expected that this is happening in 0.3.1.7: the fix is
 scheduled for 0.3.1.8. It should be out later this week or early next.

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