Re: [tor-bugs] #13606 [Metrics/Website]: Make old user number estimates available again

[Tor Bug Tracker & Wiki]

#13606: Make old user number estimates available again
-+---
 Reporter:  dcf  |  Owner:  (none)
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by dcf):

 How does this look?

  *
 https://archive.org/details/tor_metrics_old_user_number_estimates_2008_2013
  *
 https://archive.org/download/tor_metrics_old_user_number_estimates_2008_2013
 /old-user-number-estimates.tar.gz

 If you like, I can add anything to the description, like a disclaimer that
 the files are deprecated and not supported.

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

Re: [tor-bugs] #8185 [Core Tor/Tor]: circuit_package_relay_cell(): Bug: outgoing relay cell has n_chan==NULL. Dropping.

[Tor Bug Tracker & Wiki]

#8185: circuit_package_relay_cell(): Bug: outgoing relay cell has n_chan==NULL.
Dropping.
-+-
 Reporter:  mr-4 |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.9-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay logging needs-analysis |  Actual Points:
  harmless? annoyance|
Parent ID:   | Points:  3
 Reviewer:  isis |Sponsor:
-+-
Changes (by cypherpunks):

 * keywords:  tor-relay logging needs-analysis => tor-relay logging needs-
 analysis harmless? annoyance
 * priority:  Medium => High
 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.3.x-final


Comment:

 For recent duplicate tickets: #19136 #19711 #23105

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

Re: [tor-bugs] #23105 [Core Tor/Tor]: Bug: outgoing relay cell sent from src/or/relay.c:836 has n_chan==NULL.

[Tor Bug Tracker & Wiki]

#23105: Bug: outgoing relay cell sent from src/or/relay.c:836 has n_chan==NULL.
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor:
  |  0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.3.1.5-alpha
 Severity:  Normal| Resolution:  duplicate
 Keywords:  031-backport harmless? annoyance  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by cypherpunks):

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


Comment:

 Duplicate #8185

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

Re: [tor-bugs] #19711 [Core Tor/Tor]: circuit_package_relay_cell(): Bug: outgoing relay cell sent from src/or/relay.c:701 has n_chan==NULL. Dropping. (on Tor 0.2.8.5-rc )

[Tor Bug Tracker & Wiki]

#19711: circuit_package_relay_cell(): Bug: outgoing relay cell sent from
src/or/relay.c:701 has n_chan==NULL. Dropping. (on Tor 0.2.8.5-rc )
+--
 Reporter:  user100500  |  Owner:  (none)
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
|  duplicate
 Keywords:  log annoyance tor-relay tor-client  |  Actual Points:
Parent ID:  | Points:  3
 Reviewer:  |Sponsor:
+--
Changes (by cypherpunks):

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


Comment:

 Duplicate #8185

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23626 [Applications/Tor Browser]: Productionize TB crash submission services

[Tor Bug Tracker & Wiki]

#23626: Productionize TB crash submission services
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #23624
   Points:|   Reviewer:
  Sponsor:|
--+--
 Right now there are two tor instances and two node instances being run in
 tmux screens. We should turn those into init scripts that are run on
 startup.

 Additionally, nodejs is built and installed from source, maybe we want a
 package manager for that.

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

[tor-bugs] #23625 [Applications/Tor Browser]: Test Crash Submission Service

[Tor Bug Tracker & Wiki]

#23625: Test Crash Submission Service
--+--
 Reporter:  tom   |  Owner:  nmago
 Type:  enhancement   | Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #23624
   Points:|   Reviewer:
  Sponsor:|
--+--
 I have set up the crash submission engine at
 http://ucfjmm6hlmz3i7bg.onion/ - let's throw a few test crashes at it!

 The view url is being kept private, when we move to production it will be
 disabled entirely and users will need to scp the reports off the box.

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

Re: [tor-bugs] #22923 [Internal Services/Tor Sysadmin Team]: Create a Virtual Machine for Tor Browser Crash Dumps

[Tor Bug Tracker & Wiki]

#22923: Create a Virtual Machine for Tor Browser Crash Dumps
-+
 Reporter:  tom  |  Owner:  tpa
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:  #23624   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by tom):

 * parent:   => #23624


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23624 [Applications/Tor Browser]: Deploy Crash Reporter for Tor Browser

[Tor Bug Tracker & Wiki]

#23624: Deploy Crash Reporter for Tor Browser
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 This is a meta ticket for getting the crash reporter deployed in Tor
 Browser

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

Re: [tor-bugs] #23105 [Core Tor/Tor]: Bug: outgoing relay cell sent from src/or/relay.c:836 has n_chan==NULL.

[Tor Bug Tracker & Wiki]

#23105: Bug: outgoing relay cell sent from src/or/relay.c:836 has n_chan==NULL.
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor:
  |  0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.3.1.5-alpha
 Severity:  Normal| Resolution:
 Keywords:  031-backport harmless? annoyance  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 Replying to [comment:5 arma]:
 > Same bug as #19711?
 Seems this bug's fossil records go back to 0.2.4.x days ;) see #8185

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

Re: [tor-bugs] #23092 [Core Tor/Tor]: Stop ignoring CircuitIdleTimeout when it's lower than IDLE_TIMEOUT_WHILE_LEARNING (was: CircuitIdleTimeout man entry should document IDLE_TIMEOUT_WHILE_LEARNING)

[Tor Bug Tracker & Wiki]

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

 * keywords:  doc easy => easy
 * status:  needs_revision => needs_review


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

Re: [tor-bugs] #12418 [Applications/Tor Browser]: TBBs with UBSan create lots of errors when running

[Tor Bug Tracker & Wiki]

#12418: TBBs with UBSan create lots of errors when running
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201709  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by arthuredelstein):

 Replying to [comment:19 tom]:
 > Cool! And good work arthur. I signed up to tackle
 https://bugzilla.mozilla.org/show_bug.cgi?id=1402316 which should lay a
 framework for silencing individual errors we don't care about.

 Thanks, Tom. I commented on that ticket.

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

Re: [tor-bugs] #23105 [Core Tor/Tor]: Bug: outgoing relay cell sent from src/or/relay.c:836 has n_chan==NULL.

[Tor Bug Tracker & Wiki]

#23105: Bug: outgoing relay cell sent from src/or/relay.c:836 has n_chan==NULL.
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor:
  |  0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.3.1.5-alpha
 Severity:  Normal| Resolution:
 Keywords:  031-backport harmless? annoyance  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Same bug as #19711?

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

Re: [tor-bugs] #23621 [Core Tor/Tor]: prop224: Missing tons of mds over time with a lurking client

[Tor Bug Tracker & Wiki]

#23621: prop224: Missing tons of mds over time with a lurking client
--+
 Reporter:  asn   |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  prop224   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 The {{{ClientUsageDelay}}} feature here, when set to exactly 1 hour, will
 have interesting side-channel leaks. For example, if you go to a directory
 guard to fetch new microdescs, it knows that there's a good chance you had
 been idle but you just sent something on an existing circuit to your
 primary guard.

 Mike worked hard to remove those side channels in the #17592 fix (see e.g.
 commit d5a151a0).

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

Re: [tor-bugs] #23543 [Core Tor/Tor]: prop224: Disconnects on long-lasting HS connections (possibly because of mds)

[Tor Bug Tracker & Wiki]

#23543: prop224: Disconnects on long-lasting HS connections (possibly because of
mds)
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs prop224 prop224-bugs  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Replying to [comment:10 asn]:
 > Seems like most disconnects happening on the ircd are caused by killing
 of rend circs:
 > {{{
 > circuit_mark_for_close_(): Circuit 4054201541 marked for close at
 src/or/circuitbuild.c:1543 (orig reason: 520, new reason: 0)\
 > }}}

 Whose log is this? Your Tor client still, or is this from the service-
 side?

 If it's the service side, are there more logs? Do they come in clumps, or
 spread out, or what?

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

Re: [tor-bugs] #23543 [Core Tor/Tor]: prop224: Disconnects on long-lasting HS connections (possibly because of mds)

[Tor Bug Tracker & Wiki]

#23543: prop224: Disconnects on long-lasting HS connections (possibly because of
mds)
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs prop224 prop224-bugs  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 It seems the current conclusion for the client-side disconnect is that it
 happened because of a (mis)feature in your irc client?

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

Re: [tor-bugs] #23621 [Core Tor/Tor]: prop224: Missing tons of mds over time with a lurking client

[Tor Bug Tracker & Wiki]

#23621: prop224: Missing tons of mds over time with a lurking client
--+
 Reporter:  asn   |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  prop224   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Replying to [ticket:23621 asn]:
 > After 1-2 days of HS client operation, we will be missing about 2000
 mds. If at that point we need to do another HS operation [...] This can
 result in delays and/or reachability issues.

 This sounds like a bug worth exploring and fixing. It will be a bug --
 even if we do the fix proposed in this ticket -- for an actually idle Tor
 client that then tries to access a v3 onion service as its first action.

 In theory in this situation it should notice that it needs to fetch
 microdescs, and do it, and then let the various circuits proceed. If that
 process is failing somehow, we should find out where and fix 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] #23621 [Core Tor/Tor]: prop224: Missing tons of mds over time with a lurking client

[Tor Bug Tracker & Wiki]

#23621: prop224: Missing tons of mds over time with a lurking client
--+
 Reporter:  asn   |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  prop224   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 I'm not yet convinced that this is a good idea.

 The circuit-building-dormancy thing makes us not fetch descriptors if we
 haven't needed descriptors for a long time. That's a feature.

 I guess the theory here is that if we have an open conn, then we are
 likely to still need descriptors at any moment.

 But the counter to that theory is that if we haven't needed descriptors
 for hours, it could well be more hours until we need them.

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

Re: [tor-bugs] #9498 [Core Tor/Tor]: Allow bridge descriptors to contain no address if they are not being published

[Tor Bug Tracker & Wiki]

#9498: Allow bridge descriptors to contain no address if they are not being
published
-+-
 Reporter:  nwf  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Very High|  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  tor-bridge, need-spec, bridgedb, |  Actual Points:
  needs-proposal censorship  |
Parent ID:   | Points:  large
 Reviewer:   |Sponsor:
-+-
Changes (by catalyst):

 * cc: catalyst (added)


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

[tor-bugs] #23623 [Core Tor/Tor]: hs: Cache current time period number and SRV start time

[Tor Bug Tracker & Wiki]

#23623: hs: Cache current time period number and SRV start time
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-hs, tor-sr
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 For each node in the consensus, we call `node_set_hsdir_index()` which
 gets the time period and srv start time to learn if we are in between TP
 and SRV or not.

 These calls ultimately call `get_voting_schedule()` which allocates memory
 and prints a debug log everytime.

 All of this is actually pretty heavy and they are values we can cache
 because they are all based on the timings of a new consensus (valid_after,
 valid_until, fresh_until).

 It is also called every second by a tor with a hidden service.

 Caching those and updating when we get a new consensus seems a light
 refactoring for a good performance improvement.

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

Re: [tor-bugs] #23562 [Core Tor/Tor]: keep changes files on master release-ready

[Tor Bug Tracker & Wiki]

#23562: keep changes files on master release-ready
---+
 Reporter:  catalyst   |  Owner:  (none)
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  implemented
 Keywords:  ci tor-doc tor-releng  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

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


Comment:

 Going to close this, since its children are closed.

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

Re: [tor-bugs] #21573 [Core Tor/Tor]: Fix tor warnings that chutney is currently ignoring

[Tor Bug Tracker & Wiki]

#21573: Fix tor warnings that chutney is currently ignoring
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  3
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #23563 [Core Tor/Tor]: document changes files release-readiness requirement in doc/HACKING

[Tor Bug Tracker & Wiki]

#23563: document changes files release-readiness requirement in doc/HACKING
+
 Reporter:  catalyst|  Owner:  nickm
 Type:  task| Status:  closed
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tor-doc tor-releng  |  Actual Points:
Parent ID:  #23562  | Points:
 Reviewer:  |Sponsor:
+
Changes (by catalyst):

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


Comment:

 Looks good; thanks!  We can keep an eye on how this works in practice in
 the next few releases and update accordingly.

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

Re: [tor-bugs] #23105 [Core Tor/Tor]: Bug: outgoing relay cell sent from src/or/relay.c:836 has n_chan==NULL.

[Tor Bug Tracker & Wiki]

#23105: Bug: outgoing relay cell sent from src/or/relay.c:836 has n_chan==NULL.
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor:
  |  0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.3.1.5-alpha
 Severity:  Normal| Resolution:
 Keywords:  031-backport harmless? annoyance  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #23318 [Core Tor/Tor]: compute_weighted_bandwidths: do not add 0.5 to final_weight

[Tor Bug Tracker & Wiki]

#23318: compute_weighted_bandwidths: do not add 0.5 to final_weight
+
 Reporter:  cypherpunks |  Owner:  nickm
 Type:  defect  | Status:  accepted
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:  Tor: 0.2.4.3-alpha
 Severity:  Normal  | Resolution:
 Keywords:  path-selection  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  |Sponsor:
+
Changes (by nickm):

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


Comment:

 So, I've done the obvious path as `bug23318_029`.  I suggest trying it in
 0.3.2 for a while before we backport, in case there are any weird
 consequences.

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

Re: [tor-bugs] #23318 [Core Tor/Tor]: compute_weighted_bandwidths: do not add 0.5 to final_weight

[Tor Bug Tracker & Wiki]

#23318: compute_weighted_bandwidths: do not add 0.5 to final_weight
-+-
 Reporter:  cypherpunks  |  Owner:  nickm
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  path-selection 029-backport  |  Actual Points:
  030-backport 031-backport  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  path-selection => path-selection 029-backport 030-backport
 031-backport


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

Re: [tor-bugs] #23318 [Core Tor/Tor]: compute_weighted_bandwidths: do not add 0.5 to final_weight

[Tor Bug Tracker & Wiki]

#23318: compute_weighted_bandwidths: do not add 0.5 to final_weight
-+-
 Reporter:  cypherpunks  |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.3-alpha
 Severity:  Normal   | Resolution:
 Keywords:  path-selection 029-backport  |  Actual Points:
  030-backport 031-backport  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  accepted => needs_review


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

Re: [tor-bugs] #22429 [Applications/Tor Browser]: bridge: Add Lisbeth IPv6 address

[Tor Bug Tracker & Wiki]

#22429: bridge: Add Lisbeth IPv6 address
---+--
 Reporter:  dgoulet|  Owner:  tbb-team
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  tbb-bridges TorBrowserTeam201706R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 Here's a graph showing IPv4 and IPv6 connections to Lisbeth. The Tor
 Browser releases that added Lisbeth's addresses are marked: 6.0.6 for IPv4
 and 7.0 for IPv6. It's just showing the `bridge-ip-versions` line from
 `bridge-extra-info` documents. I don't know what explains the bump in IPv6
 in August 2017.

 [[Image(lisbeth-ip_version.png)]]

 source code: attachment:tor-bridge-ipversion.tar.gz​

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

Re: [tor-bugs] #22429 [Applications/Tor Browser]: bridge: Add Lisbeth IPv6 address

[Tor Bug Tracker & Wiki]

#22429: bridge: Add Lisbeth IPv6 address
---+--
 Reporter:  dgoulet|  Owner:  tbb-team
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  tbb-bridges TorBrowserTeam201706R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by dcf):

 * Attachment "lisbeth-ip_version.png" added.


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

Re: [tor-bugs] #22429 [Applications/Tor Browser]: bridge: Add Lisbeth IPv6 address

[Tor Bug Tracker & Wiki]

#22429: bridge: Add Lisbeth IPv6 address
---+--
 Reporter:  dgoulet|  Owner:  tbb-team
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  tbb-bridges TorBrowserTeam201706R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by dcf):

 * Attachment "tor-bridge-ipversion.tar.gz" added.


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

Re: [tor-bugs] #17569 [Applications/Tor Browser]: Add uBlock Origin to the Tor Browser

[Tor Bug Tracker & Wiki]

#17569: Add uBlock Origin to the Tor Browser
+--
 Reporter:  kernelcorn  |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-usability tbb-security  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by cypherpunks):

 Yet another reason: It's becoming practically impossible to access some
 bloated websites with the Tor Browser in machines with only 1-2Go of RAM,
 and with the switch to FF59 which will have 4 content processes this will
 be even impossible. As has been proven many times, blocking trackers has
 on average significant benefits in terms of RAM usage, especially on
 bloated news sites full of trackers (gorhill, the uBlockOrigin maintainer,
 has some nice examples:
 [https://twitter.com/gorhill/status/849315584907018247 1],
 [https://pbs.twimg.com/media/C8ka6GvUwAA0sxC.jpg 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] #23563 [Core Tor/Tor]: document changes files release-readiness requirement in doc/HACKING

[Tor Bug Tracker & Wiki]

#23563: document changes files release-readiness requirement in doc/HACKING
+
 Reporter:  catalyst|  Owner:  nickm
 Type:  task| Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-doc tor-releng  |  Actual Points:
Parent ID:  #23562  | Points:
 Reviewer:  |Sponsor:
+
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 Further improvements in cbea334d6ba564.

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

Re: [tor-bugs] #17569 [Applications/Tor Browser]: Add uBlock Origin to the Tor Browser

[Tor Bug Tracker & Wiki]

#17569: Add uBlock Origin to the Tor Browser
+--
 Reporter:  kernelcorn  |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-usability tbb-security  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by cypherpunks):

 Another reason which I just thought about: The argument in the Tor Browser
 design documentation assumes that the user in question leaves everything
 in the Tor Browser by default. But there's no guarantee for that, and in
 real life many users make themselves more fingerprintable (e.g. by
 changing the browser's size, ...etc). In such a case, blocking some
 trackers may turn out to be beneficial, if only to prevent some trackers
 from easily fingerprinting some users.

 The other counter-argument that this would damage ad revenue from websites
 ignores that there's only 2 million TB users, and the impact would be
 relatively tiny.

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

Re: [tor-bugs] #22692 [Applications/Tor Browser]: Backport Linux content sandboxing from Firefox 54

[Tor Bug Tracker & Wiki]

#22692: Backport Linux content sandboxing from Firefox 54
-+-
 Reporter:  jld  |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:  fixed
 Keywords:  GeorgKoppen201709,   |  Actual Points:
  TorBrowserTeam201709R, tbb-backport|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 FWIW: the necessary `tor-browser-build` fix landed as well meanwhile:
 commit 85537ff8b5a7294138ed57e44818512aaabb9d57 on `master`.

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

Re: [tor-bugs] #13398 [Applications/Tor Browser]: at startup, browser gleans user FULL NAME (real name, given name) from O/S

[Tor Bug Tracker & Wiki]

#13398: at startup, browser gleans user FULL NAME (real name, given name) from 
O/S
--+--
 Reporter:  zinc  |  Owner:  pospeselr
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201709R |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by pospeselr):

 * keywords:  TorBrowserTeam201708 => TorBrowserTeam201709R


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

Re: [tor-bugs] #12418 [Applications/Tor Browser]: TBBs with UBSan create lots of errors when running

[Tor Bug Tracker & Wiki]

#12418: TBBs with UBSan create lots of errors when running
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-security, TorBrowserTeam201709  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by tom):

 Cool! And good work arthur. I signed up to tackle
 https://bugzilla.mozilla.org/show_bug.cgi?id=1402316 which should lay a
 framework for silencing individual errors we don't care about.

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

Re: [tor-bugs] #13398 [Applications/Tor Browser]: at startup, browser gleans user FULL NAME (real name, given name) from O/S

[Tor Bug Tracker & Wiki]

#13398: at startup, browser gleans user FULL NAME (real name, given name) from 
O/S
--+--
 Reporter:  zinc  |  Owner:  pospeselr
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201708  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by pospeselr):

 * status:  needs_revision => needs_review


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

Re: [tor-bugs] #21883 [Metrics/Analysis]: Perform one-off analysis for number of relays a bwauth decided the median for

[Tor Bug Tracker & Wiki]

#21883: Perform one-off analysis for number of relays a bwauth decided the 
median
for
--+---
 Reporter:  Sebastian |  Owner:  tom
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Metrics/Analysis  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by tom):

 I don't think anything needs to be done, unless Sebastian or Karsten or
 anyone has comments about the graphs (either the look or questions about
 the data.)  Although it's been a while since I generated them so I will
 need to relearn what I did ;)

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

Re: [tor-bugs] #13398 [Applications/Tor Browser]: at startup, browser gleans user FULL NAME (real name, given name) from O/S

[Tor Bug Tracker & Wiki]

#13398: at startup, browser gleans user FULL NAME (real name, given name) from 
O/S
--+
 Reporter:  zinc  |  Owner:  pospeselr
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201708  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by pospeselr):

 Ok, latest patch (13398-pospeselr5.patch) just rips out the offending code
 and returns empty string for all requested properties, assuming ESR59 is
 not defined.  Verified working on linux and windows, building on macOS.
 Version 5 is the same as version 4, except it doesn't 'fix' trailing
 whitespace (new settings config, who dis?).

 I couldn't find any existing firefox version defines, but if any exist I'm
 happy to use them.

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

Re: [tor-bugs] #13398 [Applications/Tor Browser]: at startup, browser gleans user FULL NAME (real name, given name) from O/S

[Tor Bug Tracker & Wiki]

#13398: at startup, browser gleans user FULL NAME (real name, given name) from 
O/S
--+
 Reporter:  zinc  |  Owner:  pospeselr
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201708  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by pospeselr):

 * Attachment "13398-pospeselr5.patch" added.


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

Re: [tor-bugs] #13398 [Applications/Tor Browser]: at startup, browser gleans user FULL NAME (real name, given name) from O/S

[Tor Bug Tracker & Wiki]

#13398: at startup, browser gleans user FULL NAME (real name, given name) from 
O/S
--+
 Reporter:  zinc  |  Owner:  pospeselr
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201708  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by pospeselr):

 * Attachment "13398-pospeselr4.patch" added.


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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #4486, #5830, #6369, #6473, ...

[Tor Bug Tracker & Wiki]

Batch modification to #4486, #5830, #6369, #6473, #10222, #10223, #16520, 
#16659 by nickm:


--
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] #21800 [Core Tor/Tor]: test suite triggers Bug: Result does not fit in tor_timegm but does not fail

[Tor Bug Tracker & Wiki]

#21800: test suite triggers Bug: Result does not fit in tor_timegm but does not
fail
-+-
 Reporter:  weasel   |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.10
 Severity:  Normal   | Resolution:  fixed
 Keywords:  029-backport, 030-backport,  |  Actual Points:
  031-deferred-20170425  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Okay. This bug seems gone as of 230a33679814f3074c0ba43e42dc7b38b5342c10.

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

Re: [tor-bugs] #23539 [Core Tor/Tor]: We've defined "don't use kist" as a negative interval, so don't check for -1

[Tor Bug Tracker & Wiki]

#23539: We've defined "don't use kist" as a negative interval, so don't check 
for
-1
-+
 Reporter:  pastly   |  Owner:  dgoulet
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, easy  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  pastly   |Sponsor:
-+
Changes (by pastly):

 * reviewer:   => pastly


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

Re: [tor-bugs] #23539 [Core Tor/Tor]: We've defined "don't use kist" as a negative interval, so don't check for -1

[Tor Bug Tracker & Wiki]

#23539: We've defined "don't use kist" as a negative interval, so don't check 
for
-1
-+
 Reporter:  pastly   |  Owner:  dgoulet
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, easy  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by dgoulet):

 * status:  needs_information => needs_review


Comment:

 See branch: `bug23539_032_01`

 Making `KISTSchedRunInterval` a `uint32_t` has a lot of ramification so
 this needs careful review. Basically, now if the consensus sets that value
 to 0, it disables KIST. If the user sets it to 0 (default value), it will
 ask the consensus for its opinion.

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

Re: [tor-bugs] #23551 [Core Tor/Tor]: src/common/compress.c:576: tor_compress_process: Non-fatal assertion

[Tor Bug Tracker & Wiki]

#23551: src/common/compress.c:576: tor_compress_process: Non-fatal assertion
--+
 Reporter:  cypherpunks   |  Owner:  ahf
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.5-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ahf):

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


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

Re: [tor-bugs] #23539 [Core Tor/Tor]: We've defined "don't use kist" as a negative interval, so don't check for -1

[Tor Bug Tracker & Wiki]

#23539: We've defined "don't use kist" as a negative interval, so don't check 
for
-1
-+
 Reporter:  pastly   |  Owner:  dgoulet
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, easy  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by dgoulet):

 * parent:  #23538 =>


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

Re: [tor-bugs] #23538 [Core Tor/Tor]: Allow KISTSchedRunInterval to be negative

[Tor Bug Tracker & Wiki]

#23538: Allow KISTSchedRunInterval to be negative
-+
 Reporter:  pastly   |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  tor-sched, easy  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by dgoulet):

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


Comment:

 Ok we are not going down that path anymore. This interval value should
 never be negative, consensus param or not. We'll figure out another option
 to disable KIST if we really want that.

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

Re: [tor-bugs] #23621 [Core Tor/Tor]: prop224: Missing tons of mds over time with a lurking client

[Tor Bug Tracker & Wiki]

#23621: prop224: Missing tons of mds over time with a lurking client
--+
 Reporter:  asn   |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  prop224   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_revision => needs_review


Comment:

 See branch: `bug23621_032_01`

 Notice the change in `rep_hist_client_dormant()` which returns true if
 client last used is unset.

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

Re: [tor-bugs] #22297 [Metrics/Atlas]: Show graphs in "table" format

[Tor Bug Tracker & Wiki]

#22297: Show graphs in "table" format
---+-
 Reporter:  Hello71|  Owner:  irl
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:  wontfix
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by irl):

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


Comment:

 As we're moving to integrate Tor Atlas into the Metrics website, layout
 and styling will be changing. For now, I'm closing this ticket. If this is
 still an issue after the migration then please open a new ticket.

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

Re: [tor-bugs] #23511 [Metrics/Atlas]: Add top 10 relays per country

[Tor Bug Tracker & Wiki]

#23511: Add top 10 relays per country
---+---
 Reporter:  irl|  Owner:  irl
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:  duplicate
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by irl):

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


Comment:

 I believe that #23517 captures a vision for this feature a lot better than
 this ticket does.

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

Re: [tor-bugs] #23517 [Metrics/Atlas]: Add aggregated results table for relays grouped by country and/or AS

[Tor Bug Tracker & Wiki]

#23517: Add aggregated results table for relays grouped by country and/or AS
---+-
 Reporter:  karsten|  Owner:  irl
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by irl):

 I agree that this should be a separate ticket from #23509, I think this
 should encompass #23511 however with the top relays for an aggregation
 listed on the aggregated page. I will close that ticket as a duplicate as
 I think this one captures the vision better.

 I'm concerned that this wouldn't be a new document in Onionoo, for two
 reasons:

 1) It's a lot of logic to add to Atlas where we've always tried to
 minimise the logic and have Atlas serve only as a presentation layer on
 top of Onionoo
 2) It prevents the data being easily reusable by others without their
 reverse engineering of the Atlas source code

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

Re: [tor-bugs] #23092 [Core Tor/Tor]: CircuitIdleTimeout man entry should document IDLE_TIMEOUT_WHILE_LEARNING

[Tor Bug Tracker & Wiki]

#23092: CircuitIdleTimeout man entry should document IDLE_TIMEOUT_WHILE_LEARNING
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.2.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  doc easy  |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:  (none) => teor
 * status:  needs_revision => assigned


Comment:

 setting owner

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

Re: [tor-bugs] #23092 [Core Tor/Tor]: CircuitIdleTimeout man entry should document IDLE_TIMEOUT_WHILE_LEARNING

[Tor Bug Tracker & Wiki]

#23092: CircuitIdleTimeout man entry should document IDLE_TIMEOUT_WHILE_LEARNING
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.2.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  doc easy  |  Actual Points:
Parent ID:| Points:  0.2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  assigned => 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] #23563 [Core Tor/Tor]: document changes files release-readiness requirement in doc/HACKING

[Tor Bug Tracker & Wiki]

#23563: document changes files release-readiness requirement in doc/HACKING
+
 Reporter:  catalyst|  Owner:  nickm
 Type:  task| Status:  needs_revision
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-doc tor-releng  |  Actual Points:
Parent ID:  #23562  | Points:
 Reviewer:  |Sponsor:
+
Changes (by nickm):

 * status:  accepted => 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] #23563 [Core Tor/Tor]: document changes files release-readiness requirement in doc/HACKING

[Tor Bug Tracker & Wiki]

#23563: document changes files release-readiness requirement in doc/HACKING
+
 Reporter:  catalyst|  Owner:  nickm
 Type:  task| Status:  accepted
 Priority:  Medium  |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-doc tor-releng  |  Actual Points:
Parent ID:  #23562  | Points:
 Reviewer:  |Sponsor:
+
Changes (by nickm):

 * owner:  (none) => nickm
 * status:  needs_revision => accepted


Comment:

 setting owner

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

Re: [tor-bugs] #23539 [Core Tor/Tor]: We've defined "don't use kist" as a negative interval, so don't check for -1

[Tor Bug Tracker & Wiki]

#23539: We've defined "don't use kist" as a negative interval, so don't check 
for
-1
-+
 Reporter:  pastly   |  Owner:  dgoulet
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, easy  |  Actual Points:
Parent ID:  #23538   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by pastly):

 Since we are going to keep Interval unsigned, we should probably be
 clamping the Interval here? Hmmm not necessarily. It is clamped from above
 in config.c. So all that we ''might'' want to do is BUG. Up to you.

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

Re: [tor-bugs] #23621 [Core Tor/Tor]: prop224: Missing tons of mds over time with a lurking client

[Tor Bug Tracker & Wiki]

#23621: prop224: Missing tons of mds over time with a lurking client
--+
 Reporter:  asn   |  Owner:  dgoulet
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  prop224   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  assigned => 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] #23621 [Core Tor/Tor]: prop224: Missing tons of mds over time with a lurking client

[Tor Bug Tracker & Wiki]

#23621: prop224: Missing tons of mds over time with a lurking client
--+
 Reporter:  asn   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  prop224   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:  (none) => dgoulet
 * status:  needs_revision => assigned


Comment:

 setting owner

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

Re: [tor-bugs] #23621 [Core Tor/Tor]: prop224: Missing tons of mds over time with a lurking client

[Tor Bug Tracker & Wiki]

#23621: prop224: Missing tons of mds over time with a lurking client
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  prop224   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 I'll take over the patch to add a torrc option to control the client usage
 delay.

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

Re: [tor-bugs] #23552 [Core Tor/Tor]: We don't need to log our scheduler type so often

[Tor Bug Tracker & Wiki]

#23552: We don't need to log our scheduler type so often
--+
 Reporter:  pastly|  Owner:  pastly
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Merged; removed the now-unused chosen_scheduler_type local variable to fix
 a warning.

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

Re: [tor-bugs] #21800 [Core Tor/Tor]: test suite triggers Bug: Result does not fit in tor_timegm but does not fail

[Tor Bug Tracker & Wiki]

#21800: test suite triggers Bug: Result does not fit in tor_timegm but does not
fail
-+-
 Reporter:  weasel   |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.10
 Severity:  Normal   | Resolution:
 Keywords:  029-backport, 030-backport,  |  Actual Points:
  031-deferred-20170425  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Okay, it's  passing again, but I still see a couple `Result does not fit
 in tor_timegm` warnings. Going to wait for more CI builders to finish,
 then analyze.

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

Re: [tor-bugs] #23621 [Core Tor/Tor]: prop224: Missing tons of mds over time with a lurking client

[Tor Bug Tracker & Wiki]

#23621: prop224: Missing tons of mds over time with a lurking client
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  prop224   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * cc: mikeperry, arma (added)


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

Re: [tor-bugs] #23621 [Core Tor/Tor]: prop224: Missing tons of mds over time with a lurking client

[Tor Bug Tracker & Wiki]

#23621: prop224: Missing tons of mds over time with a lurking client
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  prop224   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  new => needs_review


Comment:

 Have a look at bug23621_032 -- does it make sense to you as a fix for
 this?

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

Re: [tor-bugs] #23552 [Core Tor/Tor]: We don't need to log our scheduler type so often

[Tor Bug Tracker & Wiki]

#23552: We don't need to log our scheduler type so often
--+
 Reporter:  pastly|  Owner:  pastly
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 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] #21800 [Core Tor/Tor]: test suite triggers Bug: Result does not fit in tor_timegm but does not fail

[Tor Bug Tracker & Wiki]

#21800: test suite triggers Bug: Result does not fit in tor_timegm but does not
fail
-+-
 Reporter:  weasel   |  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.9.10
 Severity:  Normal   | Resolution:
 Keywords:  029-backport, 030-backport,  |  Actual Points:
  031-deferred-20170425  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 We ran into a bug that I tried to fix with
 512c57cff97c0533bbb56e6c41a1e3dca5fd9064 . Let's see if the CI tests
 become happier.

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

Re: [tor-bugs] #23621 [Core Tor/Tor]: prop224: Missing tons of mds over time with a lurking client

[Tor Bug Tracker & Wiki]

#23621: prop224: Missing tons of mds over time with a lurking client
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  prop224   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Description changed by dgoulet:

Old description:

> As roger described in comment:1:ticket:23543 tor will slowly expire its
> cached mds. Tor will start fetching again mds when it sees some client
> activity.
>
> In the case of a prop224 HS client with a single rend circ open (e.g. to
> an ircd, or downloading something) Tor will consider itself inactive and
> will not fetch any mds during that time.
>
> After 1-2 days of HS client operation, we will be missing about 2000 mds.
> If at that point we need to do another HS operation we will either stall
> if we are missing too many mds:
> {{{
> hs_client_refetch_hsdesc(): Can't fetch descriptor for service
> MUvEXhuYFWdElDqoHOeXPqi8TcKfLxeDKkYUejwLgt0 because we dont have enough
> descriptors. Stalling connection.
> }}}
> or will try to fetch a descriptor with some missing mds. This can result
> in delays and/or reachability issues.
>
> That's not a problem for v2, since all the info for v2 are in the
> consensus and it does not need any mds to connect to HSes.
>
> Perhaps it's good for us to periodically keep fetching mds if we have
> long-lasting active rend circs. (Sorta related to #23543 but not
> exactly).

New description:

 As roger described in comment:1:ticket:23543 tor will slowly expire its
 cached mds. Tor will start fetching again mds when it sees some client
 activity.

 In the case of a prop224 HS client with a single rend circ open (e.g. to
 an ircd, or downloading something) Tor will consider itself inactive and
 will not fetch any mds during that time.

 After 1-2 days of HS client operation, we will be missing about 2000 mds.
 If at that point we need to do another HS operation we will either stall
 if we are missing too many mds:
 {{{
 hs_client_refetch_hsdesc(): Can't fetch descriptor for service
 MUvEXhuYFWdElDqoHOeXPqi8TcKfLxeDKkYUejwLgt0 because we dont have enough
 descriptors. Stalling connection.
 }}}
 or will try to fetch a descriptor with some missing mds. This can result
 in delays and/or reachability issues.

 That's not a problem for v2, since all the info for v2 are in the
 consensus and it does not need any mds to connect to HSes.

 Perhaps it's good for us to periodically keep fetching mds if we have
 long-lasting active rend circs. (Sorta related to #23543 but not exactly).

--

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

Re: [tor-bugs] #23610 [Core Tor/Tor]: handle_establish_intro() can mark circuits for close twice

[Tor Bug Tracker & Wiki]

#23610: handle_establish_intro() can mark circuits for close twice
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.0.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  prop224, tor-hs, tor-bug-warning,|  Actual Points:
  030-backport, 031-backport |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 backported

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

Re: [tor-bugs] #23551 [Core Tor/Tor]: src/common/compress.c:576: tor_compress_process: Non-fatal assertion

[Tor Bug Tracker & Wiki]

#23551: src/common/compress.c:576: tor_compress_process: Non-fatal assertion
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.5-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 I think that the reason it's making no progress is because out_len_orig
 was 0 -- there was no space in the output buffer when it started.

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

Re: [tor-bugs] #22084 [Applications/Tor Browser]: Neuter NetworkInformation API on Tor Browser Mobile

[Tor Bug Tracker & Wiki]

#22084: Neuter NetworkInformation API on Tor Browser Mobile
---+--
 Reporter:  gk |  Owner:  igt0
 Type:  task   | Status:  accepted
 Priority:  High   |  Milestone:
Component:  Applications/Tor Browser   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tbb-mobile tbb-fingerprinting  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by igt0):

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


Comment:

 I am working on it.

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

Re: [tor-bugs] #23551 [Core Tor/Tor]: src/common/compress.c:576: tor_compress_process: Non-fatal assertion

[Tor Bug Tracker & Wiki]

#23551: src/common/compress.c:576: tor_compress_process: Non-fatal assertion
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.5-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 It wouldn't surprise me if we have a zstd version incompatibility here. Or
 maybe truncated input data?

 Truncated input data would definitely explain why zstd can't make any
 progress, but isn't returning an error code. In that case, it's our fault
 for not giving zstd enough data to work with. (And not failing the loop
 quietly?)

 Because if it were corrupt data, it really should return an error:
 http://facebook.github.io/zstd/zstd_manual.html#Chapter9

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

Re: [tor-bugs] #22805 [Core Tor/Tor]: Remove or_circuit_t.is_first_hop, because it's not accurate any more

[Tor Bug Tracker & Wiki]

#22805: Remove or_circuit_t.is_first_hop, because it's not accurate any more
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt, security-review, |  implemented
  review-group-23|  Actual Points:  .3
Parent ID:   | Points:  1
 Reviewer:  asn  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 merged; made new ticket as #23622.  Thanks!

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

Re: [tor-bugs] #23552 [Core Tor/Tor]: We don't need to log our scheduler type so often

[Tor Bug Tracker & Wiki]

#23552: We don't need to log our scheduler type so often
--+
 Reporter:  pastly|  Owner:  pastly
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by pastly):

 * status:  needs_revision => merge_ready


Comment:

 Made `SCHEDULER_NONE` == -1. It doesn't look like `old_scheduler_type`
 needs to be an int.

 `bug23552_032_03` on https://github.com/pastly/public-tor.git

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23622 [Core Tor/Tor]: Maybe use "has authenticated" rather than "has authenticated as a known relay" to set client flag

[Tor Bug Tracker & Wiki]

#23622: Maybe use "has authenticated" rather than "has authenticated as a known
relay" to set client flag
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 In #22805, teor proposes that we should use the following rule for setting
 our "is this a client flag" on a channel:

 >If a connecting peer has a zero identity digest, it's a client/bridge, if
 it doesn't, it's a relay. (A listening peer is always a relay.
 Interestingly, bridges look like relays to clients, but look like clients
 to public 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] #23618 [Core Tor/Tor]: "Bug: tor_compress_process: Non-fatal assertion"

[Tor Bug Tracker & Wiki]

#23618: "Bug: tor_compress_process: Non-fatal assertion"
--+
 Reporter:  torvlnt33r|  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Old description:

> Getting many such messages since upgrading to Tor 0.3.2.1-alpha, on a
> client connected to a bridge running 0.3.2.1-alpha too:
>
> Sep 21 21:00:16.000 [warn] tor_bug_occurred_(): Bug:
> ../src/common/compress.c:576: tor_compress_process: Non-fatal assertion
> !((rv == TOR_COMPRESS_OK) && *in_len == in_len_orig && *out_len ==
> out_len_orig) failed. (on Tor 0.3.2.1-alpha )
> Sep 21 21:00:16.000 [warn] Bug: Non-fatal assertion !((rv ==
> TOR_COMPRESS_OK) && *in_len == in_len_orig && *out_len == out_len_orig)
> failed in tor_compress_process at ../src/common/compress.c:576. Stack
> trace: (on Tor 0.3.2.1-alpha )
> Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(log_backtrace+0x43)
> [0x557e14f28ba3] (on Tor 0.3.2.1-alpha )
> Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xb9)
> [0x557e14f43cd9] (on Tor 0.3.2.1-alpha )
> Sep 21 21:00:16.000 [warn] Bug:
> /usr/bin/tor(tor_compress_process+0x14b) [0x557e14f4d50b] (on Tor
> 0.3.2.1-alpha )
> Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(+0x1a7745)
> [0x557e14f4d745] (on Tor 0.3.2.1-alpha )
> Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(tor_uncompress+0x31)
> [0x557e14f4dc01] (on Tor 0.3.2.1-alpha )
> Sep 21 21:00:16.000 [warn] Bug:
> /usr/bin/tor(connection_dir_reached_eof+0x1211) [0x557e14ed9301] (on Tor
> 0.3.2.1-alpha )
> Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(+0x10b259)
> [0x557e14eb1259] (on Tor 0.3.2.1-alpha )
> Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(+0x51f0e)
> [0x557e14df7f0e] (on Tor 0.3.2.1-alpha )
> Sep 21 21:00:16.000 [warn] Bug: /usr/lib/x86_64-linux-
> gnu/libevent-2.1.so.6(+0x229ba) [0x7f9a861109ba] (on Tor 0.3.2.1-alpha )
> Sep 21 21:00:16.000 [warn] Bug: /usr/lib/x86_64-linux-
> gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f9a86111537] (on Tor
> 0.3.2.1-alpha )
> Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x28d)
> [0x557e14df8e5d] (on Tor 0.3.2.1-alpha )
> Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(tor_main+0xe1d)
> [0x557e14dfbc6d] (on Tor 0.3.2.1-alpha )
> Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(main+0x19)
> [0x557e14df4699] (on Tor 0.3.2.1-alpha )
> Sep 21 21:00:16.000 [warn] Bug: /lib/x86_64-linux-
> gnu/libc.so.6(__libc_start_main+0xf1) [0x7f9a849032e1] (on Tor
> 0.3.2.1-alpha )
> Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(_start+0x2a)
> [0x557e14df46ea] (on Tor 0.3.2.1-alpha )
> Sep 21 21:00:16.000 [warn] More info on the bug: method == Zstandard
> compressed, finish == 0,  *in_len == in_len_orig == 2878, *out_len ==
> out_len_orig == 0

New description:

 Getting many such messages since upgrading to Tor 0.3.2.1-alpha, on a
 client connected to a bridge running 0.3.2.1-alpha too:
 {{{
 Sep 21 21:00:16.000 [warn] tor_bug_occurred_(): Bug:
 ../src/common/compress.c:576: tor_compress_process: Non-fatal assertion
 !((rv == TOR_COMPRESS_OK) && *in_len == in_len_orig && *out_len ==
 out_len_orig) failed. (on Tor 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] Bug: Non-fatal assertion !((rv ==
 TOR_COMPRESS_OK) && *in_len == in_len_orig && *out_len == out_len_orig)
 failed in tor_compress_process at ../src/common/compress.c:576. Stack
 trace: (on Tor 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(log_backtrace+0x43)
 [0x557e14f28ba3] (on Tor 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xb9)
 [0x557e14f43cd9] (on Tor 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] Bug:
 /usr/bin/tor(tor_compress_process+0x14b) [0x557e14f4d50b] (on Tor
 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(+0x1a7745)
 [0x557e14f4d745] (on Tor 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(tor_uncompress+0x31)
 [0x557e14f4dc01] (on Tor 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] Bug:
 /usr/bin/tor(connection_dir_reached_eof+0x1211) [0x557e14ed9301] (on Tor
 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(+0x10b259)
 [0x557e14eb1259] (on Tor 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(+0x51f0e)
 [0x557e14df7f0e] (on Tor 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] Bug: /usr/lib/x86_64-linux-
 gnu/libevent-2.1.so.6(+0x229ba) [0x7f9a861109ba] (on Tor 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] Bug: /usr/lib/x86_64-linux-
 gnu/libevent-2.1.so.6(event_base_loop+0x5a7) 

Re: [tor-bugs] #23374 [Core Tor/Tor]: Circuit dirtiness is inconsistant with MaxCircuitDirtiness

[Tor Bug Tracker & Wiki]

#23374: Circuit dirtiness is inconsistant with MaxCircuitDirtiness
--+
 Reporter:  Jaym  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 No problem.  I'll see about changing the manpage.  Please remember to look
 for warnings, though! :)

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

[tor-bugs] #23621 [Core Tor/Tor]: prop224: Missing tons of mds over time with a lurking client

[Tor Bug Tracker & Wiki]

#23621: prop224: Missing tons of mds over time with a lurking client
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal|   Keywords:  prop224
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 As roger described in comment:1:ticket:23543 tor will slowly expire its
 cached mds. Tor will start fetching again mds when it sees some client
 activity.

 In the case of a prop224 HS client with a single rend circ open (e.g. to
 an ircd, or downloading something) Tor will consider itself inactive and
 will not fetch any mds during that time.

 After 1-2 days of HS client operation, we will be missing about 2000 mds.
 If at that point we need to do another HS operation we will either stall
 if we are missing too many mds:
 {{{
 hs_client_refetch_hsdesc(): Can't fetch descriptor for service
 MUvEXhuYFWdElDqoHOeXPqi8TcKfLxeDKkYUejwLgt0 because we dont have enough
 descriptors. Stalling connection.
 }}}
 or will try to fetch a descriptor with some missing mds. This can result
 in delays and/or reachability issues.

 That's not a problem for v2, since all the info for v2 are in the
 consensus and it does not need any mds to connect to HSes.

 Perhaps it's good for us to periodically keep fetching mds if we have
 long-lasting active rend circs. (Sorta related to #23543 but not exactly).

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

Re: [tor-bugs] #23551 [Core Tor/Tor]: src/common/compress.c:576: tor_compress_process: Non-fatal assertion

[Tor Bug Tracker & Wiki]

#23551: src/common/compress.c:576: tor_compress_process: Non-fatal assertion
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.5-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 I suggest we split that BUG() expression into its separate components to
 aid in diagnosing future issues.

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

Re: [tor-bugs] #23620 [Core Tor/Tor]: Tor lies about "Optimistically trying directory fetches again"

[Tor Bug Tracker & Wiki]

#23620: Tor lies about "Optimistically trying directory fetches again"
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.10
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * version:  Tor: 0.3.0.11 => Tor: 0.3.0.10


Comment:

 I'm using Tor Browser 7.0.5 on macOS 10.12 with the packaged version of
 tor 0.3.0.10.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23620 [Core Tor/Tor]: Tor lies about "Optimistically trying directory fetches again"

[Tor Bug Tracker & Wiki]

#23620: Tor lies about "Optimistically trying directory fetches again"
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.0.11
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:  1 |   Reviewer:
  Sponsor:|
--+
 My tor hasn't sent anything to the network for 15 minutes, but it keeps
 telling me `Application request when we haven't used client functionality
 lately. Optimistically trying directory fetches again.`

 My laptop was asleep, and when I woke it up, Tor tried to connect to the
 network a few times, and then ended up in this state.

 {{{
 21/9/17, 12:35:33.100 [NOTICE] Average packaged cell fullness: 67.067%.
 TLS write overhead: 4%
 21/9/17, 12:46:37.900 [NOTICE] Tor has successfully opened a circuit.
 Looks like client functionality is working.
 21/9/17, 12:46:37.900 [NOTICE] Tor has successfully opened a circuit.
 Looks like client functionality is working.
 22/9/17, 11:42:02.700 [NOTICE] Your system clock just jumped 65128 seconds
 forward; assuming established circuits no longer work.
 22/9/17, 11:42:02.700 [NOTICE] Heartbeat: Tor's uptime is 4 days 16:01
 hours, with 0 circuits open. I've sent 11.27 MB and received 124.39 MB.
 22/9/17, 11:42:02.700 [NOTICE] Average packaged cell fullness: 67.151%.
 TLS write overhead: 4%
 22/9/17, 11:52:39.800 [NOTICE] Application request when we haven't used
 client functionality lately. Optimistically trying directory fetches
 again.
 22/9/17, 11:54:39.000 [NOTICE] Tried for 120 seconds to get a connection
 to [scrubbed]:443. Giving up. (waiting for circuit)
 22/9/17, 12:05:05.400 [NOTICE] Application request when we haven't used
 client functionality lately. Optimistically trying directory fetches
 again.
 (repeats many times)
 }}}

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

Re: [tor-bugs] #23601 [Applications/Tor Browser]: cert transparency checker & pinpatrol addons, by elevenpaths

[Tor Bug Tracker & Wiki]

#23601: cert transparency checker & pinpatrol addons, by elevenpaths
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  enhancement   | 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):

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


Comment:

 Do you get any error messages related to those extensions? For example in
 the error console (Ctrl + Shift + J)? Do the extensions work in a clean
 Firefox 52 ESR (you can find ESR versions to test on
 https://www.mozilla.org/en-US/firefox/organizations/all/)

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

Re: [tor-bugs] #23543 [Core Tor/Tor]: prop224: Disconnects on long-lasting HS connections (possibly because of mds)

[Tor Bug Tracker & Wiki]

#23543: prop224: Disconnects on long-lasting HS connections (possibly because of
mds)
-+-
 Reporter:  asn  |  Owner:  asn
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs prop224 prop224-bugs  |  Actual Points:
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Seems like most disconnects happening on the ircd are caused by killing of
 rend circs:
 {{{
 circuit_mark_for_close_(): Circuit 4054201541 marked for close at
 src/or/circuitbuild.c:1543 (orig reason: 520, new reason: 0)}}}


 where `orig reason: 520` means that the circ died because of
 `END_CIRC_REASON_CHANNEL_CLOSED`...

 Is it normal for this to occur so frequently??? It occurs for me about
 once a day, and it also occurs to more people.

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

Re: [tor-bugs] #23619 [Applications/Tor Browser]: Add makefile rule for creating incremental mars for unsigned builds

[Tor Bug Tracker & Wiki]

#23619: Add makefile rule for creating incremental mars for unsigned builds
--+-
 Reporter:  boklm |  Owner:  boklm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:  #17381| Points:
 Reviewer:|Sponsor:
--+-
Changes (by boklm):

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


Comment:

 Hmm, it seems I was wrong, and the `incrementals-release` and
 `incrementals-alpha` makefile rules already generate incrementals for the
 unsigned builds.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23619 [Applications/Tor Browser]: Add makefile rule for creating incremental mars for unsigned builds

[Tor Bug Tracker & Wiki]

#23619: Add makefile rule for creating incremental mars for unsigned builds
--+--
 Reporter:  boklm |  Owner:  boklm
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-rbm
Actual Points:|  Parent ID:  #17381
   Points:|   Reviewer:
  Sponsor:|
--+--
 In `tor-browser-build.git` I tried to separate directories for signed and
 unsigned builds. The unsigned builds are located in the `alpha/unsigned`
 build. The incrementals, update_responses and dmg2mar makefile rules are
 using the `alpha/signed` directory. I think later we can also add some
 other directories for some of the signing steps (like the code signed OSX
 tar.gz that need to be converted to dmg).

 However, we are currently missing a makefile rule to generate the
 incremental mars for an unsigned build. Maybe this rule should also skip
 the OSX incrementals as they need to be generated again after code
 signing.

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

Re: [tor-bugs] #23374 [Core Tor/Tor]: Circuit dirtiness is inconsistant with MaxCircuitDirtiness

[Tor Bug Tracker & Wiki]

#23374: Circuit dirtiness is inconsistant with MaxCircuitDirtiness
--+
 Reporter:  Jaym  |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Low   |  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by Jaym):

 Replying to [comment:3 nickm]:
 >
 > 3) Have you patched Tor to allow "MaxCircuitDirtiness 1" ?  By default,
 it should be saying:
 >
 > {{{
 > Sep 21 16:52:54.348 [warn] MaxCircuitDirtiness option is too short;
 raising to 10 seconds.
 > }}}

 Urk. I am stupid. I did not see this. Maybe it is worth indicating the
 minimum value authorized in the man page?

 Thanks for your 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

Re: [tor-bugs] #23618 [Core Tor/Tor]: "Bug: tor_compress_process: Non-fatal assertion"

[Tor Bug Tracker & Wiki]

#23618: "Bug: tor_compress_process: Non-fatal assertion"
--+
 Reporter:  torvlnt33r|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by torvlnt33r):

 (exactly every minute)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23618 [Core Tor/Tor]: "Bug: tor_compress_process: Non-fatal assertion"

[Tor Bug Tracker & Wiki]

#23618: "Bug: tor_compress_process: Non-fatal assertion"
--+
 Reporter:  torvlnt33r|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Getting many such messages since upgrading to Tor 0.3.2.1-alpha, on a
 client connected to a bridge running 0.3.2.1-alpha too:

 Sep 21 21:00:16.000 [warn] tor_bug_occurred_(): Bug:
 ../src/common/compress.c:576: tor_compress_process: Non-fatal assertion
 !((rv == TOR_COMPRESS_OK) && *in_len == in_len_orig && *out_len ==
 out_len_orig) failed. (on Tor 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] Bug: Non-fatal assertion !((rv ==
 TOR_COMPRESS_OK) && *in_len == in_len_orig && *out_len == out_len_orig)
 failed in tor_compress_process at ../src/common/compress.c:576. Stack
 trace: (on Tor 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(log_backtrace+0x43)
 [0x557e14f28ba3] (on Tor 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xb9)
 [0x557e14f43cd9] (on Tor 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] Bug:
 /usr/bin/tor(tor_compress_process+0x14b) [0x557e14f4d50b] (on Tor
 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(+0x1a7745)
 [0x557e14f4d745] (on Tor 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(tor_uncompress+0x31)
 [0x557e14f4dc01] (on Tor 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] Bug:
 /usr/bin/tor(connection_dir_reached_eof+0x1211) [0x557e14ed9301] (on Tor
 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(+0x10b259)
 [0x557e14eb1259] (on Tor 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(+0x51f0e)
 [0x557e14df7f0e] (on Tor 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] Bug: /usr/lib/x86_64-linux-
 gnu/libevent-2.1.so.6(+0x229ba) [0x7f9a861109ba] (on Tor 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] Bug: /usr/lib/x86_64-linux-
 gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f9a86111537] (on Tor
 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x28d)
 [0x557e14df8e5d] (on Tor 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(tor_main+0xe1d)
 [0x557e14dfbc6d] (on Tor 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(main+0x19)
 [0x557e14df4699] (on Tor 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] Bug: /lib/x86_64-linux-
 gnu/libc.so.6(__libc_start_main+0xf1) [0x7f9a849032e1] (on Tor
 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(_start+0x2a)
 [0x557e14df46ea] (on Tor 0.3.2.1-alpha )
 Sep 21 21:00:16.000 [warn] More info on the bug: method == Zstandard
 compressed, finish == 0,  *in_len == in_len_orig == 2878, *out_len ==
 out_len_orig == 0

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

Re: [tor-bugs] #23614 [Internal Services/Tor Sysadmin Team]: Switch tp.org Onion Services to "v3"

[Tor Bug Tracker & Wiki]

#23614: Switch tp.org Onion Services to "v3"
-+-
 Reporter:  cypherpunks  |  Owner:  tpa
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  invalid
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by weasel):

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


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

Re: [tor-bugs] #22651 [Applications/Tor Browser]: Remove redirects for torbrowser-launcher

[Tor Bug Tracker & Wiki]

#22651: Remove redirects for torbrowser-launcher
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  TorBrowserTeam201709  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by boklm):

 It looks like the torbrowser-launcher package has now been updated in
 debian:
 http://metadata.ftp-master.debian.org/changelogs/contrib/t/torbrowser-
 launcher/torbrowser-launcher_0.2.8-1~bpo9+1_changelog

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #23617 [Internal Services/Service - trac]: Connectivity issues with trac.torproject.org

[Tor Bug Tracker & Wiki]

#23617: Connectivity issues with trac.torproject.org
--+-
 Reporter:  hellais   |  Owner:  qbi
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 This may be related to
 https://trac.torproject.org/projects/tor/ticket/23325.

 Since today I have started having connectivity issues with
 trac.torproject.org from Vodafone Italia.

 {{{
 % dig A trac.torproject.org

 ; <<>> DiG 9.8.3-P1 <<>> A trac.torproject.org
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19433
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

 ;; QUESTION SECTION:
 ;trac.torproject.org.   IN  A

 ;; ANSWER SECTION:
 trac.torproject.org.767 IN  CNAME   troodi.torproject.org.
 troodi.torproject.org.  767 IN  A   138.201.212.227

 ;; Query time: 37 msec
 ;; SERVER: 8.8.8.8#53(8.8.8.8)
 ;; WHEN: Fri Sep 22 10:12:52 2017
 ;; MSG SIZE  rcvd: 74

 % telnet 138.201.212.227 80
 Trying 138.201.212.227...
 telnet: connect to address 138.201.212.227: Operation timed out
 telnet: Unable to connect to remote host

 % telnet 138.201.212.227 443
 Trying 138.201.212.227...
 telnet: connect to address 138.201.212.227: Operation timed out
 telnet: Unable to connect to remote host

 % curl --connect-timeout 10 https://trac.torproject.org
 curl: (28) Connection timed out after 10004 milliseconds


 % sudo mtr -b -w 138.201.212.227
 Start: 2017-09-22T10:17:20+0200
 HOST: sony-vaio.local Loss%   Snt   Last
 Avg  Best  Wrst StDev

 [... SNIP ]

   3.|-- net-2-39-247-1.cust.vodafonedsl.it (2.39.247.1)  0.0%109.5
 9.9   9.1  11.2   0.6
   4.|-- 83.224.40.1340.0%109.6
 10.5   9.6  11.9   0.6
   5.|-- 83.224.40.1330.0%10   10.4
 10.5   9.9  11.6   0.5
   6.|-- voda-it-gw1.cw.net (195.89.99.134)   0.0%10   10.1
 9.9   9.4  10.4   0.3
   7.|-- ae6-xcr1.mlb.cw.net (195.2.28.225)   0.0%10   29.5
 40.6  28.1 143.8  36.3
   8.|-- ae51-xcr1.fix.cw.net (195.2.2.158)   0.0%10   28.9
 31.3  27.6  50.4   7.3
   9.|-- ae1-xcr1.fri.cw.net (195.2.9.237)0.0%10   27.3
 30.4  27.3  52.0   7.6
  10.|-- ??? 100.0100.0
 0.0   0.0   0.0   0.0
 }}}

 It seems like there is 100% packet loss after the 195.2.9.237 hop.

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

Re: [tor-bugs] #23615 [Applications/Tor Browser]: Redirect update requests of users in old Tor Browser versions (6.0.x)

[Tor Bug Tracker & Wiki]

#23615: Redirect update requests of users in old Tor Browser versions (6.0.x)
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by boklm):

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


Comment:

 Replying to [comment:9 arma]:
 > Replying to [ticket:23615 gk]:
 > > I think we should try to get those users updated by having some
 redirects, say, for the next 6 months.
 >
 > If it's doable, I think we should try to support them for the long term.

 This is done now. https://dist.torproject.org/torbrowser/update_3/release/
 is redirected to https://aus1.torproject.org/torbrowser/update_2/release/.

 (then update_2 is redirected update_3 for Linux and OSX users which should
 get the latest version, while Windows users are getting version 6.5.2
 which uses the new update URL, and also check for SSE2 support)

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

Re: [tor-bugs] #23615 [Applications/Tor Browser]: Redirect update requests of users in old Tor Browser versions (6.0.x)

[Tor Bug Tracker & Wiki]

#23615: Redirect update requests of users in old Tor Browser versions (6.0.x)
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * status:  needs_information => assigned


Comment:

 Replying to [comment:9 arma]:
 > Replying to [ticket:23615 gk]:
 > > I think we should try to get those users updated by having some
 redirects, say, for the next 6 months.
 >
 > If it's doable, I think we should try to support them for the long term.
 >
 > The failure mode is really bad: you get no update suggestion, and you
 are told that your Tor Browser is up-to-date.
 >
 > Especially since some people use Tor Browser as a backup "when the
 censorship happens", we should expect that reasonable people have a
 version of Tor Browser from some years ago.

 I agree, let's move ahead with this ticket.

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

Re: [tor-bugs] #23615 [Applications/Tor Browser]: Redirect update requests of users in old Tor Browser versions (6.0.x)

[Tor Bug Tracker & Wiki]

#23615: Redirect update requests of users in old Tor Browser versions (6.0.x)
--+---
 Reporter:  gk|  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 arma):

 Replying to [ticket:23615 gk]:
 > I think we should try to get those users updated by having some
 redirects, say, for the next 6 months.

 If it's doable, I think we should try to support them for the long term.

 The failure mode is really bad: you get no update suggestion, and you are
 told that your Tor Browser is up-to-date.

 Especially since some people use Tor Browser as a backup "when the
 censorship happens", we should expect that reasonable people have a
 version of Tor Browser from some years ago.

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

Re: [tor-bugs] #23615 [Applications/Tor Browser]: Redirect update requests of users in old Tor Browser versions (6.0.x)

[Tor Bug Tracker & Wiki]

#23615: Redirect update requests of users in old Tor Browser versions (6.0.x)
--+---
 Reporter:  gk|  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 arma):

 So far today (I think that means several hours), we have
 {{{
 $ grep update_2 dist.torproject.org-access.log|wc -l
 875
 }}}

 {{{
 $ grep update_2 dist.torproject.org-access.log|grep "gcc3/x"|wc -l
 31
 }}}

 {{{
 $ grep update_2 dist.torproject.org-access.log|grep "Linux"|wc -l
 48
 $ grep update_2 dist.torproject.org-access.log|grep "WIN"|wc -l
 773
 }}}

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

Re: [tor-bugs] #23615 [Applications/Tor Browser]: Redirect update requests of users in old Tor Browser versions (6.0.x)

[Tor Bug Tracker & Wiki]

#23615: Redirect update requests of users in old Tor Browser versions (6.0.x)
--+---
 Reporter:  gk|  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 boklm):

 All of the requests from this sample look like Tor Browser users.

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

Re: [tor-bugs] #23615 [Applications/Tor Browser]: Redirect update requests of users in old Tor Browser versions (6.0.x)

[Tor Bug Tracker & Wiki]

#23615: Redirect update requests of users in old Tor Browser versions (6.0.x)
--+---
 Reporter:  gk|  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 arma):

 Here is a random sample from the past few minutes:
 {{{
 0.0.0.1 - - [22/Sep/2017:00:00:00 +] "GET
 /torbrowser/update_2/release/WINNT_x86-gcc3/5.0.4/ru HTTP/1.1" 404 319 "-"
 "-" -
 0.0.0.1 - - [22/Sep/2017:00:00:00 +] "GET
 /torbrowser/update_2/release/Linux_x86_64-gcc3/4.5.3/en-US HTTP/1.1" 404
 325 "-" "-" -
 0.0.0.1 - - [22/Sep/2017:00:00:00 +] "GET
 /torbrowser/update_2/release/WINNT_x86-gcc3-x86/6.0.4/en-US HTTP/1.1" 404
 326 "-" "-" -
 0.0.0.1 - - [22/Sep/2017:00:00:00 +] "GET
 /torbrowser/update_2/release/WINNT_x86-gcc3/5.0.2/en-US HTTP/1.1" 404 322
 "-" "-" -
 0.0.0.1 - - [22/Sep/2017:00:00:00 +] "GET
 /torbrowser/update_2/release/WINNT_x86-gcc3/5.0.4/ru HTTP/1.1" 404 319 "-"
 "-" -
 0.0.0.1 - - [22/Sep/2017:00:00:00 +] "GET
 /torbrowser/update_2/release/WINNT_x86-gcc3/5.0.4/ru HTTP/1.1" 404 319 "-"
 "-" -
 0.0.0.1 - - [22/Sep/2017:00:00:00 +] "GET
 /torbrowser/update_2/release/Darwin_x86_64-gcc3/6.0.5/en-US HTTP/1.1" 404
 326 "-" "-" -
 0.0.0.1 - - [22/Sep/2017:00:00:00 +] "GET
 /torbrowser/update_2/release/WINNT_x86-gcc3/5.0.7/ru HTTP/1.1" 404 319 "-"
 "-" -
 }}}

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

Re: [tor-bugs] #23615 [Applications/Tor Browser]: Redirect update requests of users in old Tor Browser versions (6.0.x)

[Tor Bug Tracker & Wiki]

#23615: Redirect update requests of users in old Tor Browser versions (6.0.x)
--+---
 Reporter:  gk|  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 boklm):

 I think it affects both users of the old version of torbrowser-launcher,
 and users of old versions of Tor Browser. Although I don't know which part
 of the 10 - 15 requests we see per minute are Tor Browser. The torbrowser-
 launcher requests should have an URL ending with
 `release/Linux_x86_64-gcc3/x/en-US`, while the Tor Browser ones should
 have a version number instead of the `x`.

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

Re: [tor-bugs] #23615 [Applications/Tor Browser]: Redirect update requests of users in old Tor Browser versions (6.0.x)

[Tor Bug Tracker & Wiki]

#23615: Redirect update requests of users in old Tor Browser versions (6.0.x)
--+---
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information


Comment:

 We deliberately removed that one for torbrowser-launcher as they did not
 fix their stuff even after repeatedly asking and giving deadlines. I am
 not willing to support that longer, so we might want to figure out whether
 actual Tor Browsers are affected and how many.

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

Re: [tor-bugs] #23615 [Applications/Tor Browser]: Redirect update requests of users in old Tor Browser versions (6.0.x)

[Tor Bug Tracker & Wiki]

#23615: Redirect update requests of users in old Tor Browser versions (6.0.x)
--+--
 Reporter:  gk|  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 gk):

 Replying to [comment:2 boklm]:
 > Ok. I can restore the redirect from #22651.

 Wait? That's the same as for torbrowser-launcher? So, maybe those things
 that doing the requests are no  Tor Browsers then?

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

Re: [tor-bugs] #23616 [Internal Services/Service - trac]: Move Metrics/Censorship analysis component to Obfuscation/Censorship analysis

[Tor Bug Tracker & Wiki]

#23616: Move Metrics/Censorship analysis component to Obfuscation/Censorship
analysis
--+
 Reporter:  karsten   |  Owner:  qbi
 Type:  task  | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by karsten):

 * cc: dcf (added)
 * status:  new => closed
 * resolution:   => fixed


Comment:

 Done. I also changed the default component owner to dcf, which made more
 sense than leaving it at metrics-team. Closing.

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

[tor-bugs] #23616 [Internal Services/Service - trac]: Move Metrics/Censorship analysis component to Obfuscation/Censorship analysis

[Tor Bug Tracker & Wiki]

#23616: Move Metrics/Censorship analysis component to Obfuscation/Censorship
analysis
--+-
 Reporter:  karsten   |  Owner:  qbi
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 dcf and I discussed moving the Metrics/Censorship analysis component to
 Obfuscation/Censorship analysis, which seems like a better fit. I'll make
 this change in a moment. The purpose of this ticket is to document this
 change.

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