Re: [tor-bugs] #24898 [Core Tor/Tor]: We have two conflicting notions of channel_is_client()

[Tor Bug Tracker & Wiki]

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

 * status:  merge_ready => needs_revision


Comment:

 Replying to [comment:19 arma]:
 > Replying to [comment:18 teor]:
 > > Do we still use CREATE_FAST to mark clients in 029? Or did we backport
 that fix as well?
 >
 > We still do it. That is, anybody who sends you a create-fast cell when
 you're running 029 or 030 now gets counted as a client, meaning the DoS
 defenses will be triggered against them (once #24902 gets backported), and
 meaning when we consider whether a channel can satisfy an extend request,
 this one can't.
 >
 > Why, are we going to regret that? :) See also the discussions in #22805.

 I think we are going to regret that, and we should backport the parts of
 #22805 that remove the CREATE_FAST mark client.

 We should also take them out on general principles, because it reduces the
 number of connections between relays.

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

Re: [tor-bugs] #24898 [Core Tor/Tor]: We have two conflicting notions of channel_is_client()

[Tor Bug Tracker & Wiki]

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

Comment (by arma):

 Replying to [comment:18 teor]:
 > Do we still use CREATE_FAST to mark clients in 029? Or did we backport
 that fix as well?

 We still do it. That is, anybody who sends you a create-fast cell when
 you're running 029 or 030 now gets counted as a client, meaning the DoS
 defenses will be triggered against them (once #24902 gets backported), and
 meaning when we consider whether a channel can satisfy an extend request,
 this one can't.

 Why, are we going to regret that? :) See also the discussions in #22805.

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

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

[Tor Bug Tracker & Wiki]

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

 * points:   => 0.2
 * actualpoints:   => 0.2


Comment:

 I added another commit that skips the entire function if the current time
 is equal to the last refill time.

 This makes the `time == 0` edge case nicer.

 The behaviour was:
 * new clients get a full refill on every cell as long as `time == 0`
 * existing clients get a full refill on every cell as long as `time == 0`

 Now it is:
 * new clients don't get refills as long as `time == 0`
 * new clients get one full refill as soon as `time >= 1`
 * existing clients get one normal refill if they have any cells when `time
 == 0`
 * existing clients get one full refill as soon as `time >= 1`, if they had
 a refill when `time == 0`

 And I think that's about as much time as it's worth spending on this edge
 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] #24902 [Core Tor/Tor]: Denial of Service mitigation subsystem

[Tor Bug Tracker & Wiki]

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

Comment (by teor):

 If the previous and current times are zero, you get infinite refills.
 Your suggestion in #25094 to return early will fix both bugs.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by teor):

 I think we should return if we don't do anything.
 And we should return if the old time is zero, and the current time is
 zero.
 Then I can turn those unit tests back on.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by arma):

 Replying to [comment:57 teor]:
 > Also, I found another bug: when the previous time is zero, clients get
 infinite refills. This probably only affects shadow.

 Shouldn't you get one refill at the beginning, and not after that? Surely
 shadow doesn't spend all of its time at midnight the morning of Jan 1
 1970?

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by arma):

 teor: while you're messing with that function, what would you think of
 adding an "if elapsed time is zero, just return" line in there? That way
 we only do the log_debug when we actually refilled something.

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

Re: [tor-bugs] #24898 [Core Tor/Tor]: We have two conflicting notions of channel_is_client()

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => merge_ready
 * parent:   => #24902


Comment:

 This looks fine to me, I've been running a similar patch on 030 for a
 while now.

 Do we still use CREATE_FAST to mark clients in 029? Or did we backport
 that fix as well?

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

Re: [tor-bugs] #25081 [Core Tor/Tor]: use get_uptime() consistently

[Tor Bug Tracker & Wiki]

#25081: use get_uptime() consistently
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_revision => needs_review


Comment:

 This should get reviewed in the next week or two

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  merge_ready => needs_revision


Comment:

 See #25094 for fixes to clang errors, including better overflow checks in
 cc_stats_refill_bucket, and some more unit tests.

 dgoulet, can you review my bug25094, and rebase it onto your
 ticket24902_029_05?

 Also, I found another bug: when the previous time is zero, clients get
 infinite refills. This probably only affects shadow.

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  new => needs_review
 * milestone:  Tor: 0.2.9.x-final => Tor: 0.3.3.x-final


Comment:

 Let's target master with this ticket, and do the backport in #24902.

 Also, the round here is redundant and can be removed:
 {{{
 src/test/test_dos.c:179:19: error: implicit conversion loses integer
 precision:
   'long' to 'int' [-Werror,-Wshorten-64-to-32]
   int circ_rate = tor_lround(get_circuit_rate_per_second());
   ~   ^
 }}}

 See my branch bug25094 for fixes to clang errors, including better
 overflow checks in cc_stats_refill_bucket, and some more unit tests.

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

Re: [tor-bugs] #25081 [Core Tor/Tor]: use get_uptime() consistently

[Tor Bug Tracker & Wiki]

#25081: use get_uptime() consistently
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by valentecaio):

 * status:  new => 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] #25081 [Core Tor/Tor]: use get_uptime() consistently

[Tor Bug Tracker & Wiki]

#25081: use get_uptime() consistently
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by valentecaio):

 It's my first time contributing to Tor Project, but I think I've done this
 ticket.

 Please take a look at my patch here
 https://github.com/valentecaio/torproject-
 tor/commit/a4c85312604c1d215f9f46a24ac242baf666ed56

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by arthuredelstein):

 Replying to [comment:15 arthuredelstein]:
 > Replying to [comment:13 arma]:
 >
 > > I think it would be worth exploring whether we can do the same
 behavior in a smarter way from the browser though -- the feature
 essentially removes a round-trip across the Tor network from page loads.
 >
 > Instead of implementing a patch in the browser, I wonder if we could
 patch the tor proxy instead with roughly the same speedup.

 I see now this approach was discussed in #3875 and also proposed in #5915.
 There was a proposed patch for tor here:
 https://trac.torproject.org/projects/tor/attachment/ticket/3875/tor-
 optimistic-data.patch . I think it still looks like a possible solution
 but there are some concerns expressed about error messages which would
 need to be considered.

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

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

[Tor Bug Tracker & Wiki]

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

 * parent:   => #24902


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25095 [Core Tor/Tor]: Update dir-spec.txt with recent consensus param additions

[Tor Bug Tracker & Wiki]

#25095: Update dir-spec.txt with recent consensus param additions
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  torspec
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 We have a section in dir-spec.txt that tries to describe the possible
 consensus parameters, and their ranges, and their meanings.

 We just added a bunch of new ones in #24902. And maybe we missed a few
 recently, like hs_service_max_rdv_failures.

 We should patch dir-spec.txt to specify all of 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

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

[Tor Bug Tracker & Wiki]

#25094: 24902 fix breaks on clang
--+
 Reporter:  catalyst  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.2.9.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 https://travis-ci.org/torproject/tor/jobs/335395212#L1716
 {{{
 src/or/dos.c:277:40: error: implicit conversion loses integer precision:
 'long'
   to 'uint32_t' (aka 'unsigned int') [-Werror,-Wshorten-64-to-32]
   num_token = elapsed_time_last_refill * circuit_rate;
 ~ ~^~
 }}}

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

Re: [tor-bugs] #24898 [Core Tor/Tor]: We have two conflicting notions of channel_is_client()

[Tor Bug Tracker & Wiki]

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

 * status:  merge_ready => needs_review


Comment:

 I have made a {{{bug24898-029}}} branch, designed for inclusion in 029 and
 030. It will conflict with 031 because stuff is already fixed there, so
 you'll want to do the right version of 'merge -ours' after 030.

 We will want this branch merged when we put the #24902 DoS patch into 029.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by nickm):

 I've merged the 24902_033_02 branch into master.  If it doesn't explode in
 the next alpha, we can do a 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] #25093 [Webpages/Website]: https://newsletter-master.torproject.org is down

[Tor Bug Tracker & Wiki]

#25093: https://newsletter-master.torproject.org is down
--+
 Reporter:  steph |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   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] #24714 [Core Tor/Tor]: rename conn->timestamp_lastwritten to conn->timestamp_lastwritable

[Tor Bug Tracker & Wiki]

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

Comment (by teor):

 "write permission" means something very specific in a systems context.
 If we really need a specific term, try "last write allowed" and "last read
 allowed".

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by teor):

 Using a QuotedString:
 https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n90

 If "#" doesn't work, let us know, we might have a bug.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by valentecaio):

 I totally agree it sounds like we flushed something... But maybe
 timestamp_lastwritable is neither not clear enough.
 What do you think about timestamp_last_write_permission ?

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by arma):

 Love it!

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

Re: [tor-bugs] #23247 [Applications/Tor Browser]: Communicating security expectations for .onion: what to say about different padlock states for .onion services

[Tor Bug Tracker & Wiki]

#23247: Communicating security expectations for .onion: what to say about 
different
padlock states for .onion services
--+--
 Reporter:  isabela   |  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by phw):

 * cc: phw (added)


Comment:

 The following SOUPS 2016 paper seems very relevant to this ticket.  It was
 written by people from the Chrome security team and their work resulted in
 the indicators we see in Chrome today:
 https://www.usenix.org/system/files/conference/soups2016/soups2016-paper-
 porter-felt.pdf

 I skimmed parts of the paper and found the following two takeaways
 relevant:

 Section 1:
 > The indicator's meaning needs to be taught with words when possible.
 Millions of new Internet users have recently come online via smartphones
 without learning "standard" iconography from desktop browsers.

 We may also want to change the text next to the onion icon. In the paper,
 in Table 4, they evaluated what string users most associate with security
 and "secure" won, closely followed by "https," which they deemed too
 technical. Another of their candidates was "secure and private" which may
 be suitable in our case. I worry that just replacing the lock icon with an
 onion may not make it clear what's different -- in particular because
 onions are typically not associated with security.

 Section 3.1:
 > Making major modifications to this [lock] symbol, such as using a
 different object, may be disorienting: users now expect to find a lock in
 a browser window.

 I wonder if the presence of an onion will confuse some people? Another way
 forward would be to use the lock icon for onion services too but change
 the string from "secure" to "secure and private."

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

Re: [tor-bugs] #16106 [Core Tor/Tor]: Sandbox causes crash when creating a hidden service through the control port

[Tor Bug Tracker & Wiki]

#16106: Sandbox causes crash when creating a hidden service through the control
port
-+-
 Reporter:  micahlee |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Low  |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.5.12
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, client, crash, sandbox,  |  Actual Points:
  review-group-31|
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => merge_ready
 * reviewer:   => dgoulet
 * points:  small/medium =>


Comment:

 lgtm;

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

Re: [tor-bugs] #25008 [Core Tor/Tor]: Call protocol_list_supports_protocol less often to save time and allocation

[Tor Bug Tracker & Wiki]

#25008: Call protocol_list_supports_protocol less often to save time and 
allocation
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  032-backport?, malloc, performance,  |  Actual Points:
  protover, review-group-31  |
Parent ID:  #23777   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => needs_revision
 * reviewer:   => dgoulet


Comment:

 Oh hello wonderful patch! I very much like this! It adds a nice semantic
 to the code and optimize it at the same time.

 I may ask if we can get the documentation of which protocol version value
 each member of `protover_summary_flags_t` is for. For instance,
 `supports_ed25519_hs_intro` requires ` HSIntro=4` but half of them aren't
 documented. And easy map with the spec would rock.

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

Re: [tor-bugs] #24952 [Core Tor/Tor]: channel: channel_tls_get_remote_addr_method() should return the "real_addr" of the connection

[Tor Bug Tracker & Wiki]

#24952: channel: channel_tls_get_remote_addr_method() should return the 
"real_addr"
of the connection
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-channel, review-group-31  |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by dgoulet):

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


Comment:

 There seems to be 3 callsites:

 1. `connection_exit_begin_conn()`

  The address of the `or_circ->p_chan` is returned which I think in this
 case is good to use `real_addr` because it is used to actually connect to
 the directory.

 2. `channel_do_open_actions()`

  That is actually the part where this ticket is important because it is
 where we note down the TCP connection client address into the geoip cache.

 3. `channel_dump_statistics()`

  The address is used to print a log with the remote connected address so
 again, the `real_addr` is what we probably want.

 So I think we are good. Patch lgtm;

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

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

[Tor Bug Tracker & Wiki]

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

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


Comment:

 lgtm;

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

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

[Tor Bug Tracker & Wiki]

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

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


Comment:

 This lgtm but I have a quick question.

 If we do run out of space, is this log statement will spam like crazy or
 it should be in a reasonable amount? If too crazy, we should ratelimit or
 just get rid of it?

 {{{
 +log_warn(LD_FS, "Unable to store object %s compressed with %s.",
 + description, methodname);
 }}}

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => needs_revision
 * keywords:  review-group-31 => review-group-31, tor-spec
 * reviewer:   => dgoulet


Comment:

 * `[Will become mandatory.]` when... ? Like when we decide or there is a
 date or when which ticket is resolved?

  Considering this comment, I think we can deduce a date no?

 {{{
 +   This field was first added in Tor 0.2.9.x. Some time after all
 earlier
 +   Tor relay versions are obsolete, it will become mandatory.
 }}}

 * Double white space at the end of the commit.

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

Re: [tor-bugs] #24000 [Core Tor/Tor]: circuit_send_intermediate_onion_skin() and extend_cell_format() should check for IPv6

[Tor Bug Tracker & Wiki]

#24000: circuit_send_intermediate_onion_skin() and extend_cell_format() should
check for IPv6
---+
 Reporter:  teor   |  Owner:  nickm
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  ipv6, review-group-31  |  Actual Points:
Parent ID:  #24403 | Points:  0.5
 Reviewer:  dgoulet|Sponsor:
---+
Changes (by dgoulet):

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


Comment:

 We only check `orport_ipv4` in `check_extend_cell()` so this is only a
 gate keeping for the `extend_cell_format()` that does this:

 {{{
   tor_addr_copy(&ec.orport_ipv4.addr, &hop->extend_info->addr);
   ec.orport_ipv4.port = hop->extend_info->port;
 }}}

 All in all, if the `extend_info->addr` is not an IPv4, we have trouble in
 the woods which could happen with a coding error and sending non IPv4 in
 those cells in a release would be bad.

 I think that check is OK to have and ultimately we will have a proper
 "extend_info_t -> extend cell" layer.

 lgtm;

 I just wonder if teor is OK with this considering is comment: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] #23954 [Core Tor/Tor]: Race condition in LOG_PROTOCOL_WARN

[Tor Bug Tracker & Wiki]

#23954: Race condition in LOG_PROTOCOL_WARN
-+
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-31  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+
Changes (by dgoulet):

 * status:  needs_review => needs_revision
 * reviewer:   => dgoulet


Comment:

 * Nitpick: I would wrap this in its own function like the init and cleanup
 functions:

 {{{
 +  {
 +int warning_severity = options->ProtocolWarnings ? LOG_WARN :
 LOG_INFO;
 +atomic_counter_exchange(&protocol_warning_severity_level,
 +warning_severity);
 +  }
 }}}

  Like a "set" function that wraps the `exchange()` so we have one function
 that is allow to set `protocol_warning_severity_level` so
 `init_protocol_warning_severity_level()` can also use it.

 * Quick thing also, I would document the reason why we use an atomic
 counter for that value that is at least explaining what the possible race
 is exactly:

 {{{
 +static atomic_counter_t protocol_warning_severity_level;
 }}}

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

Re: [tor-bugs] #23909 [Core Tor/Tor]: dirauths write corrupted keypin journal

[Tor Bug Tracker & Wiki]

#23909: dirauths write corrupted keypin journal
-+
 Reporter:  Sebastian|  Owner:  nickm
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-31  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+
Changes (by dgoulet):

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


Comment:

 lgtm;

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

Re: [tor-bugs] #23750 [Core Tor/Tor]: Isolate libevent usage to a few locations

[Tor Bug Tracker & Wiki]

#23750: Isolate libevent usage to a few locations
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  refactoring, technical-debt, |  Actual Points:
  review-group-31|
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

 * status:  needs_review => needs_revision
 * reviewer:   => dgoulet


Comment:

 From commit `6c5a4bef4e77cf37`:

 * I would propose that `mainloop_event_new()` validates at least the `cb`
 argument passed with a `tor_assert()` (seems it can't be NULL nor it makes
 sense to be NULL).

  I would also document the function that the `userdata` ownership is
 passed to the returned `mainloop_event_`.

 * Can we use `mainloop_event_activate()` if the event was never
 scheduled/added to the main loop?

 * Can I use `tv = NULL` in `mainloop_event_schedule()` to tell it "now" or
 `tv` must be a valid pointer?

 * I would document what this does if called multiple time:
 `mainloop_event_cancel()`.

 * Maybe we should have this using the `FREE_AND_NULL` macro scheme?
 `mainloop_event_free()`

 From commit `3edf64a95f91d9be`:

 * This function `threadpool_register_reply_event()` doesn't use the nice
 `mainloop_event_t` API and I can see that is because we create an event
 with specific flags (EV_PERSIST | EV_READ).

  And then it goes on using `event_add()` directly. Couldn't we remove all
 this and make it that it would use that mainloop interface created prior?

 * Also, why is `threadpool_register_reply_event()` is taking a base event,
 can't we abstract that to always use `tor_libevent_get_base()` or that
 doesn't play nice in multi thread?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25092 [Applications/Tor Browser]: check if mailto: protocol is correctly warning in Tor Browser

[Tor Bug Tracker & Wiki]

#25092: check if mailto: protocol is correctly warning in Tor Browser
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 https://bugzilla.mozilla.org/show_bug.cgi?id=440892 suggests we may not be
 showing the user any warning for mailto: protocols, etc. Maybe our
 external app warning patch covers this? Or maybe not.

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

Re: [tor-bugs] #22163 [Webpages/Website]: Make it more obvious how to report security related bugs

[Tor Bug Tracker & Wiki]

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

Comment (by kat5):

 A fix that may address this was applied for
 https://trac.torproject.org/projects/tor/ticket/9186 (Document how to
 report security vulnerabilities).

 There is now a mailing list for reporting security bugs. The address and
 gpg key are on the Contact page, as well as the mailing list wiki page.

 Not sure if we want to close this ticket or keep it as a placeholder for
 the redesign.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  easy, intro, api, code-  |  Actual Points:
  simplification, review-group-31|
Parent ID:   | Points:  small
 Reviewer:  dgoulet  |Sponsor:
-+-
Changes (by dgoulet):

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


Comment:

 lgtm;

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

Re: [tor-bugs] #25090 [Applications/Tor Browser]: Make sure IPFS & co in addons are shoved up through Tor and don't leak in ESR60

[Tor Bug Tracker & Wiki]

#25090: Make sure IPFS & co in addons are shoved up through Tor and don't leak 
in
ESR60
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff60-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Not OP.
 I think these protocols would just increase the surface of attack. We
 can't trust file:// in firefox, why would we trust these? Frankly I think
 this junk should be ripped from the tor-browser and 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] #23108 [Core Tor/Tor]: prop224: Don't rotate all service descriptors at once

[Tor Bug Tracker & Wiki]

#23108: prop224: Don't rotate all service descriptors at once
---+
 Reporter:  asn|  Owner:  dgoulet
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  prop224-extra, tor-hs  |  Actual Points:
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:
---+
Changes (by dgoulet):

 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.4.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] [Tor Bug Tracker & Wiki] Batch modify: #21678, #23980, #20832, #20700, ...

[Tor Bug Tracker & Wiki]

Batch modification to #21678, #23980, #20832, #20700, #19566, #17521, #15059, 
#24774, #13258, #2681 by dgoulet:
milestone to Tor: 0.3.4.x-final

--
Tickets URL: 

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

Re: [tor-bugs] #23858 [Core Tor/Tor]: Create a local tool that provides detailed statistics for relay operators

[Tor Bug Tracker & Wiki]

#23858: Create a local tool that provides detailed statistics for relay 
operators
--+--
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-relay |  Actual Points:
Parent ID:| Points:  5
 Reviewer:|Sponsor:  SponsorQ-can
--+--
Changes (by dgoulet):

 * milestone:  Tor: 0.3.3.x-final => 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] #23891 [Core Tor/Tor]: Write blogpost on future/expectations for Rust in tor?

[Tor Bug Tracker & Wiki]

#23891: Write blogpost on future/expectations for Rust in tor?
---+--
 Reporter:  isis   |  Owner:  (none)
 Type:  task   | Status:  new
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-blog-post  |  Actual Points:
Parent ID: | Points:  .5
 Reviewer: |Sponsor:
---+--
Changes (by dgoulet):

 * milestone:  Tor: 0.3.3.x-final => 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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #21446, #24712, #24668, #24667, ...

[Tor Bug Tracker & Wiki]

Batch modification to #21446, #24712, #24668, #24667, #24610, #24594, #24299, 
#24298, #24047, #23869, #23818, #23501, #23493, #23378, #22769, #22745, #22685, 
#22408 by dgoulet:
milestone to Tor: 0.3.4.x-final

Comment:
Moving a bunch of tickets from 033 to 034.

--
Tickets URL: 

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

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

[Tor Bug Tracker & Wiki]

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

 * keywords:   => easy, refactor
 * milestone:  Tor: 0.3.3.x-final => Tor: 0.3.4.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] #24860 [Core Tor/Tor]: Bug: Assertion cmux failed in circuitmux_get_policy at src/or/circuitmux.c

[Tor Bug Tracker & Wiki]

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

 * owner:  (none) => dgoulet
 * status:  new => accepted


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

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

[Tor Bug Tracker & Wiki]

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

 * owner:  (none) => dgoulet
 * status:  new => accepted


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

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

[Tor Bug Tracker & Wiki]

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

 * owner:  (none) => dgoulet
 * status:  new => accepted


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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #24448

[Tor Bug Tracker & Wiki]

Batch modification to #24448 by dgoulet:
milestone to Tor: 0.3.4.x-final

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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #24694, #24193, #24182, #24181, ...

[Tor Bug Tracker & Wiki]

Batch modification to #24694, #24193, #24182, #24181, #24008, #23988, #23764, 
#23759, #23711, #23579, #23576, #23507, #23502, #23307, #23306, #23301, #22893, 
#21117 by dgoulet:
milestone to Tor: 0.3.4.x-final

Comment:
Move 033 ticket I own to 034

--
Tickets URL: 

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

Re: [tor-bugs] #25002 [Metrics/Onionoo]: Make data and results from Onionoo deterministic

[Tor Bug Tracker & Wiki]

#25002: Make data and results from Onionoo deterministic
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Replying to [comment:11 karsten]:
 > ...
 > > Last modified time of `status/summary` is not deterministic across
 instances.  What about using the latest time of the two valid after
 timestamps?  This would sort of synchronize Onionoo with 'Tor time'?
 >
 > Yes, sounds good!

 Child ticket #25091.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25091 [Metrics/Onionoo]: Make 'out/update' deterministic across instances

[Tor Bug Tracker & Wiki]

#25091: Make 'out/update' deterministic across instances
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #25002
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 Derived from comments 9 to 11 in #25002.
 Summary:
 Instead of current system time use the latest time of the two valid after
 timestamps (relays and bridges).

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

Re: [tor-bugs] #24130 [Webpages/Website]: Design/layout for support.tpo based on wireframe

[Tor Bug Tracker & Wiki]

#24130: Design/layout for support.tpo based on wireframe
--+--
 Reporter:  isabela   |  Owner:  antonela
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  website redesign
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team,  |  Actual Points:
Parent ID:  #24129| Points:
 Reviewer:|Sponsor:
--+--

Comment (by antonela):

 I added mobile mockups to the mobile
 prototype.[[BR]][[BR]]!https://marvelapp.com/3i2hggg/screen/37876933
 [[BR]][[BR]]Some comments:[[BR]][[BR]]- The main menu and the topics menus
 are collapsable.[[BR]][[BR]]- Once the user selects a topic, the menu
 collapses, and the name of the chosen topic shows there.[[BR]][[BR]]- When
 the user has a topic selected, the topic select changes to a light purple
 background to have visual feedback about the selection.[[BR]][[BR]]Feel
 free to make comments on the prototype.[[BR]][[BR]][[BR]]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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_review
 Priority:  High   |  Milestone:  CollecTor 1.5.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-2018   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Amended commit e9f6c4e looks good.

 Great, I'll run another test 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

[tor-bugs] #25090 [Applications/Tor Browser]: Make sure IPFS & co in addons are shoved up through Tor and don't leak in ESR60

[Tor Bug Tracker & Wiki]

#25090: Make sure IPFS & co in addons are shoved up through Tor and don't leak 
in
ESR60
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  ff60-esr
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Starting from FF59,

 https://blog.mozilla.org/addons/2018/01/26/extensions-firefox-59/

 >
 > Support for Decentralization Protocols
 >
 > Mozilla has always been a proponent of decentralization, recognizing
 that it is a key ingredient of a healthy Internet. Starting with Firefox
 59, several protocols that support decentralized architectures are
 approved for use by extensions.  The newly approved protocols are:
 >
 > - Dat Project (dat://)
 > - IPFS (dweb://  ipfs://  ipns://)
 > - Secure Scuttlebutt (ssb://)
 >
 > Firefox itself does not implement these protocols, but having them on
 the approved list means the browser recognizes them as valid protocols and
 extensions are free to provide implementations.

 Firefox will allow addons to support IPFS, ..etc. There's a need to be
 sure that all those things when implemented in addons are shoved up
 through Tor and don't leak.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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_review
 Priority:  High   |  Milestone:  CollecTor 1.5.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-2018   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by iwakeh):

 Replying to [comment:57 karsten]:
 > Commit d18424a:
 >  - It looks like we're adding `sorted.first().minusDays(1)` but not
 `sorted.last().plusDays(1)`. I didn't try this out, but from looking at
 the code using this method it seems like we're excluding interval ends.
 Can you take another look?

 Good catch!  Amended the fix to the last fixup-commit.

 >  - Rest looks good.
 >
 > Commit 2dee32c looks good.

 Seems this module approaches finalization :-)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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_review
 Priority:  High   |  Milestone:  CollecTor 1.5.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-2018   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by karsten):

 Commit d18424a:
  - It looks like we're adding `sorted.first().minusDays(1)` but not
 `sorted.last().plusDays(1)`. I didn't try this out, but from looking at
 the code using this method it seems like we're excluding interval ends.
 Can you take another look?
  - Rest looks good.

 Commit 2dee32c looks good.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by mcs):

 R.e. how to handle the '#' character, here is a question for the network
 team: how should Tor Launcher encode '#" characters when it issues a
 SETCONF command? Maybe \23 or enclose the value in double quotes?

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by ro0ter):

 Please classify this defect as required.

 Looking forward for its fix...

 Thank you!

 NOTE: it would be nice if neither the user or the password would be stored
 in clear text... Hint: xtea?

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => merge_ready


Comment:

 Replying to [comment:50 teor]:
 > "dos.h" already exists in some Windows environments. We might want to
 pick another name.

 We don't use it in the tor code base so I doubt there could be any kind of
 confusion with the `dos.h` Windows?... Maybe if we would use `#include
 ` ?

 Else we could rename with something like `defense.c` or `mitigation.c` or
 dunno... ? I think we can do this after the upstream merge.

 > (A) I think this one is missing a !.

 Indeed. Fixup: 12761ce3685c9d57

 > (C), it wants a changes file. Here's a start:

 Very nice! I've added it in commit: ea5d3bf4d5188511

 > I pushed a commit to my ticket24902_029_04-fixup branch that you might
 like -- it cleans up the heartbeat messages a bit.

 Very nice again, I've cherry-picked it in commit: 8c6833be7d6e631d

 Ok, I think with teor and arma happy now, we can proceed with a
 `merge_ready` state. For this, I've created a _05 branch squashing the _04
 branch fixup commits and created an OnionGit MR in case Nick wants to
 comment on it.

 Branch: `ticket24902_029_05`
 Oniongit: https://oniongit.eu/dgoulet/tor/merge_requests/20

 Then we have an 0.3.3 branch as well (based on latest master) in case Nick
 wants to pick that one and not deal with the 029 merge into master.

 Branch: `ticket24902_033_02`

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

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

[Tor Bug Tracker & Wiki]

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

 * cc: mcs, brade (added)
 * status:  needs_information => new
 * component:  Applications/Tor Browser => Core Tor/Tor


Comment:

 If you look at the `torrc` spec
 (https://gitweb.torproject.org/tor.git/tree/doc/torrc_format.txt) then
 you'll see that `#` is only used for comments right now. So, this seems to
 be a Tor core bug.

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

Re: [tor-bugs] #20951 [Applications/Tor Browser]: Back out Unix domain socket related patches for Tor Browser 6.5

[Tor Bug Tracker & Wiki]

#20951: Back out Unix domain socket related patches for Tor Browser 6.5
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  TorBrowserTeam201701R,   |  Actual Points:
  GeorgKoppen201701  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mcs):

 Unix domain socket support is available starting with Tor Browser 7.0 (and
 alphas before then). This ticket was about backing the code out because we
 found some problems before we shipped Tor Browser 6.5 (the code was left
 in the alpha and shipped as stable with 7.0). The relevant prefs are:
  extensions.torlauncher.control_port_use_ipc
  extensions.torlauncher.socks_port_use_ipc

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by ro0ter):

 really, just do this test:
 1. start tor, click cancel in the initial dialog (be fast if you have
 direct connection)
 2. click configure, type some ip/port for the proxy and add a user and a
 password (the password must contain the pound/hashtag character)
 3. save the proxy settings by allowing it to connect agian
 4. close tor
 5. inspect the configuration file...

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by ro0ter):

 I am using the start-up dialog.

 I also tried changing the torrc file directly, but after startup and
 editing configuration, the password gets truncated in the same place..

 For instance, authentication "usr:!2#pas$word" becomes "usr:!2"...

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  new => needs_information


Comment:

 How are you configuring the proxy? Are you changing the `torrc` file
 directly? I am asking as Tor Browser lets you configure your HTTP proxy
 directly during start-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] #25089 [Applications/Tor Browser]: Tor bundle: Special characters not escaped in proxy password

[Tor Bug Tracker & Wiki]

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

 * owner:  (none) => tbb-team
 * component:  - Select a component => Applications/Tor Browser


Comment:

 some log excerpt caused by wrong proxy password:

 1/30/2018 15:26:35 PM.700 [NOTICE] DisableNetwork is set. Tor will not
 make or accept non-control network connections. Shutting down all existing
 connections.
 1/30/2018 15:26:35 PM.700 [NOTICE] DisableNetwork is set. Tor will not
 make or accept non-control network connections. Shutting down all existing
 connections.
 1/30/2018 15:26:35 PM.700 [NOTICE] DisableNetwork is set. Tor will not
 make or accept non-control network connections. Shutting down all existing
 connections.
 1/30/2018 15:26:35 PM.700 [NOTICE] Opening Socks listener on
 xx.xx.xx.xx:xxx
 1/30/2018 15:26:36 PM.600 [NOTICE] Bootstrapped 5%: Connecting to
 directory server
 1/30/2018 15:26:36 PM.600 [NOTICE] Bootstrapped 10%: Finishing handshake
 with directory server
 1/30/2018 15:26:36 PM.800 [WARN] The https proxy sent back an unexpected
 status code 407 ("Proxy Authentication Required"). Closing.
 1/30/2018 15:26:36 PM.800 [WARN] Proxy Client: unable to connect to
 xx.xx.xx.xx:xxx
 1/30/2018 15:26:37 PM.600 [WARN] The https proxy sent back an unexpected
 status code 407 ("Proxy Authentication Required"). Closing.
 1/30/2018 15:26:37 PM.600 [WARN] Proxy Client: unable to connect to
 xx.xx.xx.xx:xxx
 1/30/2018 15:26:37 PM.700 [WARN] The https proxy sent back an unexpected
 status code 407 ("Proxy Authentication Required"). Closing.

 [ ... ]

 1/30/2018 15:27:36 PM.900 [WARN] Proxy Client: unable to connect to
 xx.xx.xx.xx:xxx
 1/30/2018 15:27:46 PM.900 [WARN] The https proxy sent back an unexpected
 status code 407 ("Proxy Authentication Required"). Closing.
 1/30/2018 15:27:46 PM.900 [WARN] Proxy Client: unable to connect to
 xx.xx.xx.xx:xxx

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25089 [- Select a component]: Tor bundle: Special characters not escaped in proxy password

[Tor Bug Tracker & Wiki]

#25089: Tor bundle: Special characters not escaped in proxy password
--+
 Reporter:  ro0ter|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Major |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 First of all, the proxy password (if any) is stored plain-text in the torc
 file (\Browser\TorBrowser\Data\Tor\torrc)..

 Using the pound character "#" inside the proxy password (line
 HTTPSProxyAuthenticator) will not save anything which is after the pound
 character (including the character). Some companies have a strict policy
 regarding passwords therefore it is required to use such characters
 (unfortunately I managed to get to this character as well, forced by the
 password expiry policy + old password policy).

 This is also reproducible with version 7.5 (2018-01-23 build) of Tor
 bundle.

 Currently I am unable to use Tor on my PC with my user+password.

 Is there an easy fix? Are there some escape characters?

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

Re: [tor-bugs] #25088 [Applications/Tor Browser]: NoScript failed to load worker script on higher security levels

[Tor Bug Tracker & Wiki]

#25088: NoScript failed to load worker script on higher security levels
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 May affect #23840.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25088 [Applications/Tor Browser]: NoScript failed to load worker script on higher security levels

[Tor Bug Tracker & Wiki]

#25088: NoScript failed to load worker script on higher security levels
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major |   Keywords:  noscript
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 See https://www.google.com/recaptcha/api2/demo
 {{{
 NetworkError: Failed to load worker script at
 https://www.gstatic.com/recaptcha/api2/v1515997865826/recaptcha__en.js
 (nsresult = 0x805e0006)  webworker.js:1
 }}}

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

Re: [tor-bugs] #24126 [Applications/Tor Browser]: "Temporarily allow all this page" breaks JS on all already opened HTTPS sites (on Medium Security)

[Tor Bug Tracker & Wiki]

#24126: "Temporarily allow all this page" breaks JS on all already opened HTTPS
sites (on Medium Security)
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Adding an item to the whitelist has the same effect. NoScript 5.1.8.4.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by cypherpunks):

 Replying to [comment:2 gk]:
 > I wonder what is different to my Debian where it is working as
 expected... Do you have a `snowflake.log` in /path/to/your/tor-
 browser/Browser/TorBrowser/Data/Tor/pt_state directory that could explain
 what is going on?
 None, even when I use `./start-tor-browser --debug`; there's a state file
 tho

 {{{
 Guard in=bridges rsa_id=2B280B23E1107BB62ABFC40DDCC8824814F80A72
 bridge_addr=0.0.3.0:1 sampled_on=2018-01-20T08:15:11 sampled_by=0.3.2.9
 listed=1
 Guard in=bridges rsa_id=B9E7141C594AF25699E0079C1F0146F409495296
 bridge_addr=0.0.2.0:2 sampled_on=2018-01-28T02:54:45 sampled_by=0.3.2.9
 unlisted_since=2018-01-27T06:16:34 listed=0
 confirmed_on=2018-01-20T20:16:48 confirmed_idx=0 pb_use_attempts=32.00
 pb_use_successes=26.00 pb_circ_attempts=153.00
 pb_circ_successes=148.00 pb_successful_circuits_closed=139.00
 pb_collapsed_circuits=3.00 pb_unusable_circuits=6.00
 pb_timeouts=5.00
 TorVersion Tor 0.3.2.9
 LastWritten 2018-01-30 12:06:26
 TotalBuildTimes 149
 CircuitBuildAbandonedCount 2
 CircuitBuildTimeBin 775 1
 CircuitBuildTimeBin 825 5
 CircuitBuildTimeBin 875 5
 CircuitBuildTimeBin 925 4
 CircuitBuildTimeBin 975 6
 CircuitBuildTimeBin 1025 5
 CircuitBuildTimeBin 1075 8
 .
 .
 .
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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_review
 Priority:  High   |  Milestone:  CollecTor 1.5.0
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-2018   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by iwakeh):

 * status:  needs_revision => needs_review


Comment:

 Please review
 [https://gitweb.torproject.org/user/iwakeh/collector.git/log/?h=task-22428-5
 two commit] on top of your branch, which together with the latest
 branch/commit for #22983 solve all open issues (on my list).

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  new => needs_information


Comment:

 I wonder what is different to my Debian where it is working as expected...
 Do you have a `snowflake.log` in /path/to/your/tor-
 browser/Browser/TorBrowser/Data/Tor/pt_state directory that could explain
 what is going on?

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

Re: [tor-bugs] #24881 [Webpages/Website]: consolidate relay setup instruction pages and link to new guide

[Tor Bug Tracker & Wiki]

#24881: consolidate relay setup instruction pages and link to new guide
--+--
 Reporter:  cypherpunks   |  Owner:  hiro
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by hiro):

 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] #22983 [Metrics/Library]: Add a Descriptor subinterface and implementation for Tor web server logs

[Tor Bug Tracker & Wiki]

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

Comment (by karsten):

 Replying to [comment:71 iwakeh]:
 > Replying to [comment:70 iwakeh]:
 > > Lines like `0.0.0.0 - - [22/Jan/2018:00:00:00 +] "GET
 /collector/archive HTTP/1.1" 301 -` should be valid (cf. comments 50, 51
 on #22428).
 >
 > Please review [https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/commit/?h=task-22983-5 this commit] on the current task branch for
 adding this feature.

 Commit 9b4516f looks good!

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

Re: [tor-bugs] #25087 [Applications/Tor Browser]: Snowflake doesn't on a fresh clean install of Lubuntu 17 64 bits and a fresh clean install of TB 8.0a1 (was: Snowflake stops working on a fresh clean

[Tor Bug Tracker & Wiki]

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

Comment (by cypherpunks):

 oops; it never worked in the first place: better wording

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25087 [Applications/Tor Browser]: Snowflake stops working on a fresh clean install of Lubuntu 17 64 bits and a fresh clean install of TB 8.0a1

[Tor Bug Tracker & Wiki]

#25087: Snowflake stops working on a fresh clean install of Lubuntu 17 64 bits 
and
a fresh clean install of TB 8.0a1
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Logs/

 {{{
 Jan 30 10:45:02.000 [notice] Opening Socks listener on 127.0.0.1:9150
 Jan 30 10:45:03.000 [warn] The communication stream of managed proxy
 './TorBrowser/Tor/PluggableTransports/snowflake-client' is 'closed'. Most
 probably the managed proxy stopped running. This might be a bug of the
 managed proxy, a bug of Tor, or a misconfiguration. Please enable logging
 on your managed proxy and check the logs for errors.
 Jan 30 10:45:04.000 [notice] Bootstrapped 5%: Connecting to directory
 server
 Jan 30 10:45:04.000 [warn] We were supposed to connect to bridge
 '0.0.3.0:1' using pluggable transport 'snowflake', but we can't find a
 pluggable transport proxy supporting 'snowflake'. This can happen if you
 haven't provided a ClientTransportPlugin line, or if your pluggable
 transport proxy stopped running.
 Jan 30 10:45:04.000 [warn] Problem bootstrapping. Stuck at 5%: Connecting
 to directory server. (Can't connect to bridge; PT_MISSING; count 1;
 recommendation warn; host 2B280B23E1107BB62ABFC40DDCC8824814F80A72 at
 0.0.3.0:1)
 Jan 30 10:45:04.000 [notice] Closing no-longer-configured Socks listener
 on 127.0.0.1:9150
 Jan 30 10:45:04.000 [notice] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 Jan 30 10:45:04.000 [notice] Closing old Socks listener on 127.0.0.1:9150
 Jan 30 10:45:36.000 [notice] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.
 }}}

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  accepted => needs_review


Comment:

 Please review [https://gitweb.torproject.org/karsten/metrics-
 web.git/commit/?h=task-24294&id=19246a05d8691679fd34838c74d8833b1176059e
 commit 19246a0 in my task-24294 branch].

 In addition to the changes listed in the ticket description I also merged
 `org.torproject.metrics.web.graphs` into its superpackage. The distinction
 there was pretty weak anyway and existed only for historical reasons. If
 we wanted to create a useful subpackage structure for
 `org.torproject.metrics.web`, we'd have to start over anyway. But for now
 it seems okay to just have a single package for all web-related classes.

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

Re: [tor-bugs] #25002 [Metrics/Onionoo]: Make data and results from Onionoo deterministic

[Tor Bug Tracker & Wiki]

#25002: Make data and results from Onionoo deterministic
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Replying to [comment:9 iwakeh]:
 > Replying to [comment:8 karsten]:
 > > Replying to [comment:6 iwakeh]:
 > > > Maybe, also use the valid after timestamp for the value in file
 `out/update` or remove the file?
 > >
 > > That might even be part of #16513. We cannot remove that file, because
 we need it for updating the index in the server part. But we could use
 something else as timestamp than the current system time. Not sure if
 valid-after timestamp is the best choice, because we have two such
 timestamps for relays and for bridges. Maybe we could use the last-
 modified time of `status/summary` here. Untested, just an idea.
 >
 > Last modified time of `status/summary` is not deterministic across
 instances.  What about using the latest time of the two valid after
 timestamps?  This would sort of synchronize Onionoo with 'Tor time'?

 Yes, sounds good!

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

[tor-bugs] #25086 [Metrics/Relay Search]: make clear that bw is about adv. bw.

[Tor Bug Tracker & Wiki]

#25086: make clear that bw is about adv. bw.
--+--
 Reporter:  cypherpunks   |  Owner:  metrics-team
 Type:  defect| Status:  new
 Priority:  Low   |  Milestone:
Component:  Metrics/Relay Search  |Version:
 Severity:  Trivial   |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Aggregated search results clearly state "Advertised Bandwidth":

 https://atlas.torproject.org/#aggregate/version
 https://atlas.torproject.org/#aggregate/as

 Relay level search result pages just say "bandwidth" - which is
 inconsistent
 https://atlas.torproject.org/#toprelays

 Please call it "Advertised Bandwidth" everywhere.

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

Re: [tor-bugs] #25002 [Metrics/Onionoo]: Make data and results from Onionoo deterministic

[Tor Bug Tracker & Wiki]

#25002: Make data and results from Onionoo deterministic
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Replying to [comment:7 karsten]:
 > ...
 > > Please find a suggestion for a patch
 [https://gitweb.torproject.org/user/iwakeh/onionoo.git/commit/?h=task-25002
 here].
 >
 > Commit 0b2e5a2 looks good! Can you rebase to master, add a change log
 entry, and provide a metrics-web patch for updating the
 [https://metrics.torproject.org/onionoo.html#parameters_order
 specification]?

 Sure. Isolated this part as child ticket.

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

[tor-bugs] #25085 [Metrics/Onionoo]: Make order of sorted results deterministic

[Tor Bug Tracker & Wiki]

#25085: Make order of sorted results deterministic
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #25002
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 A non-deterministic element in Onionoo docs is the order of entries. When
 there is a tie in the used order parameter order is arbitrary and will
 differ. A simple solution could be to always sort by fingerprint in case
 of a tie.

 See this
 [https://gitweb.torproject.org/user/iwakeh/onionoo.git/commit/?h=task-25002
 patch].

 Open steps:
 * rebase to master,
 * add a change log entry, and
 * provide a metrics-web patch for updating the ​specification

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

Re: [tor-bugs] #25085 [Metrics/Onionoo]: Make order of sorted results deterministic

[Tor Bug Tracker & Wiki]

#25085: Make order of sorted results deterministic
-+--
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  accepted
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #25002   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

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


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

Re: [tor-bugs] #25002 [Metrics/Onionoo]: Make data and results from Onionoo deterministic

[Tor Bug Tracker & Wiki]

#25002: Make data and results from Onionoo deterministic
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Replying to [comment:8 karsten]:
 > Replying to [comment:6 iwakeh]:
 > > Maybe, also use the valid after timestamp for the value in file
 `out/update` or remove the file?
 >
 > That might even be part of #16513. We cannot remove that file, because
 we need it for updating the index in the server part. But we could use
 something else as timestamp than the current system time. Not sure if
 valid-after timestamp is the best choice, because we have two such
 timestamps for relays and for bridges. Maybe we could use the last-
 modified time of `status/summary` here. Untested, just an idea.

 Last modified time of `status/summary` is not deterministic across
 instances.  What about using the latest time of the two valid after
 timestamps?  This would sort of synchronize Onionoo with 'Tor time'?

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

Re: [tor-bugs] #22983 [Metrics/Library]: Add a Descriptor subinterface and implementation for Tor web server logs

[Tor Bug Tracker & Wiki]

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

Comment (by iwakeh):

 Replying to [comment:70 iwakeh]:
 > Lines like `0.0.0.0 - - [22/Jan/2018:00:00:00 +] "GET
 /collector/archive HTTP/1.1" 301 -` should be valid (cf. comments 50, 51
 on #22428).

 Please review [https://gitweb.torproject.org/user/iwakeh/metrics-
 lib.git/commit/?h=task-22983-5 this commit] on the current task branch for
 adding this feature.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by karsten):

 I'm working on a patch now.

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

Re: [tor-bugs] #25002 [Metrics/Onionoo]: Make data and results from Onionoo deterministic

[Tor Bug Tracker & Wiki]

#25002: Make data and results from Onionoo deterministic
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Replying to [comment:6 iwakeh]:
 > Maybe, also use the valid after timestamp for the value in file
 `out/update` or remove the file?

 That might even be part of #16513. We cannot remove that file, because we
 need it for updating the index in the server part. But we could use
 something else as timestamp than the current system time. Not sure if
 valid-after timestamp is the best choice, because we have two such
 timestamps for relays and for bridges. Maybe we could use the last-
 modified time of `status/summary` here. Untested, just an idea.

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

Re: [tor-bugs] #25002 [Metrics/Onionoo]: Make data and results from Onionoo deterministic

[Tor Bug Tracker & Wiki]

#25002: Make data and results from Onionoo deterministic
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Replying to [comment:5 iwakeh]:
 > Replying to [comment:4 karsten]:
 > > Replying to [comment:2 iwakeh]:
 > > > Another non-deterministic element in Onionoo docs is the order of
 entries.  When there is a tie in the used order parameter order is
 arbitrary and will differ.  A simple solution could be to always sort by
 fingerprint in case of a tie.
 > >
 > > True, that sounds easy enough to do.
 >
 > Please find a suggestion for a patch
 [https://gitweb.torproject.org/user/iwakeh/onionoo.git/commit/?h=task-25002
 here].

 Commit 0b2e5a2 looks good! Can you rebase to master, add a change log
 entry, and provide a metrics-web patch for updating the
 [https://metrics.torproject.org/onionoo.html#parameters_order
 specification]?

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

Re: [tor-bugs] #25082 [Applications/Tor Browser]: Uploads are not cancelled when a New Identity is requested

[Tor Bug Tracker & Wiki]

#25082: Uploads are not cancelled when a New Identity is requested
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-newnym|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Hmm, does it have any security implications?

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

Re: [tor-bugs] #25000 [Applications/Tor Browser]: TorBrowser's modifications to NoScript's mandatory whitelist break some webextensions when permissions are cascaded

[Tor Bug Tracker & Wiki]

#25000: TorBrowser's modifications to NoScript's mandatory whitelist break some
webextensions when permissions are cascaded
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201801  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Resolved #25084 as duplicate.

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

Re: [tor-bugs] #25084 [Applications/Tor Browser]: Suddenly all addons' Options menu got disappeared

[Tor Bug Tracker & Wiki]

#25084: Suddenly all addons' Options menu got disappeared
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Blocker   | Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Not sure what you are doing but this might be a duplicate of #25000.

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

Re: [tor-bugs] #25083 [Applications/Tor Browser]: Can't login to website because of captcha

[Tor Bug Tracker & Wiki]

#25083: Can't login to website because of captcha
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  closed
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Blocker   | Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Not a Tor Browser bug.

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

Re: [tor-bugs] #22000 [Applications/Tor Browser]: update OSX browser sandbox profile for e10s

[Tor Bug Tracker & Wiki]

#22000: update OSX browser sandbox profile for e10s
-+-
 Reporter:  brade|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff52-esr, tbb-security, tbb- |  Actual Points:
  sandboxing, tbb-e10s, TorBrowserTeam201707 |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor4
-+-

Comment (by gk):

 Here is what the Google folks are doing. Might be helpful:

 
https://chromium.googlesource.com/chromium/src.git/+/master/sandbox/mac/seatbelt_sandbox_design.md

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25084 [Applications/Tor Browser]: Suddenly all addons' Options menu got disappeared

[Tor Bug Tracker & Wiki]

#25084: Suddenly all addons' Options menu got disappeared
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Blocker   |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Why did you done this!? Are you enforcing users to stop installing any
 add-on? HELP!!!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25083 [Applications/Tor Browser]: Can't login to website because of captcha

[Tor Bug Tracker & Wiki]

#25083: Can't login to website because of captcha
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Blocker   |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 [*click*] Not a bot

 Instantly got:

 Try again later
 Your computer or network may be sending automated queries. To protect our
 users, we can't process your request right now. For more details visit our
 help page

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

Re: [tor-bugs] #17216 [Applications/Tor Browser]: Make Tor Browser's updater work over Hidden Services

[Tor Bug Tracker & Wiki]

#17216: Make Tor Browser's updater work over Hidden Services
--+--
 Reporter:  isis  |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-hs tbb-security   |  Actual Points:
Parent ID:| Points:  medium
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 #25078 is a duplicate.

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

Re: [tor-bugs] #25078 [Applications/Tor Browser]: Change app.update.url to point to onion service

[Tor Bug Tracker & Wiki]

#25078: Change app.update.url to point to onion service
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Replying to [comment:2 teor]:
 > Replying to [ticket:25078 cypherpunks]:
 > > As of TBB 7.5, app.update.url points to https://aus1.torproject.org .
 Wouldn't it be more sensible for the Tor Project to point automatic
 updates of its software to services it operates ''inside'' of the Tor
 network that it maintains? Metrics could also benefit. The onion service
 of aus1 is listed on onion.torproject.org.
 >
 > Downloads would be slower, and put more load on the network, because the
 torproject onion services are not single onion services. Migration is
 blocked on #21117.

 FWIW: `app.update.url` is responsible to fetch the update meta data which
 is just a plan XML file and pretty tiny compared to the actual update
 which is fetched from Fastly infrastructure. Thus, the extra
 load/additional latency would probably be not that high. That said, this
 is a duplicate of #17216.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by gk):

 Replying to [comment:13 arma]:
 > See #24432 for an example of a situation where this optimistic data
 socks handshake patch surprisingly broke stuff.

 FWIW it's not the first one. Tor Messenger had to back it out, too, see
 comment:3, presumably for the same reason.

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

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

[Tor Bug Tracker & Wiki]

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

 * keywords:   => TorBrowserTeam201801


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25082 [Applications/Tor Browser]: Uploads are not cancelled when a New Identity is requested

[Tor Bug Tracker & Wiki]

#25082: Uploads are not cancelled when a New Identity is requested
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-newnym
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 From #24421:
 {{{
 1. Set High security setting (I was using that one, didn't bother to see
 if it affects other security settings).
 2. Go to the Bezos Washington Post Secure Drop: jcw5q6uyjioupxcc.onion
 (you can verify it here: securedrop.org/directory )
 3. Click on "Submit Documents".
 4. Click on "Use New Codename".
 5. Select some large file (we don't want the upload to finish so we don't
 waste the journalists' time wasting Bezos' money) like a Tor Browser
 tar.gz
 6. Open your Gnome System Monitor and go to "Resources" and watch the
 network graph. You should see the upload at its peek values.
 7. Close the tab, you can see that the upload is still going.
 8. Click on New Identity, again, upload is still going.
 9. Close the Tor Browser, upload halts.

 It works for clearnet websites as well, you can test with
 ​https://catbox.moe/ following essentially the same procedure as the last
 ones above (i.e. 5-9).
 }}}

 This issue is observable with Tor Browser 6.5.2 as well.

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