Re: [tor-bugs] #27921 [Core Tor/Tor]: apparent DOS / impairment-of-service against FallbackDirs using DIR requests, please evaluate for possible mitigation

[Tor Bug Tracker & Wiki]

#27921: apparent DOS / impairment-of-service against FallbackDirs using DIR
requests, please evaluate for possible mitigation
--+
 Reporter:  starlight |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-dos   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:14 starlight]:
 > what version of the daemon pulls _uncompressed_ full descriptors over
 the OR port?

 Either a very old tor, or stem, or some other custom code.

 > in what scenario would a dozen rotating tor-daemons-bots request so many
 descriptors it burns 3+ mbytes/sec from multiple fallback directories?

 Some kind of internal failure or bug. There are few rate-limits in the tor
 client code, there should be more.

 > IMO this is intentional in the way the circuit-extend attack was
 intentional: cause trouble, harass the network

 Quite possibly. But tor has also had "fast zombie" bugs in the past, so we
 should consider that possibility as well.

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

Re: [tor-bugs] #28313 [Applications/Tor Browser]: Trouble Connecting to Tor browser

[Tor Bug Tracker & Wiki]

#28313: Trouble Connecting to Tor browser
--+---
 Reporter:  coolnoob  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Duping this over to #28333.

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

Re: [tor-bugs] #27921 [Core Tor/Tor]: apparent DOS / impairment-of-service against FallbackDirs using DIR requests, please evaluate for possible mitigation

[Tor Bug Tracker & Wiki]

#27921: apparent DOS / impairment-of-service against FallbackDirs using DIR
requests, please evaluate for possible mitigation
--+
 Reporter:  starlight |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-dos   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by starlight):

 what version of the daemon pulls _uncompressed_ full descriptors over the
 OR port?

 in what scenario would a dozen rotating tor-daemons-bots request so many
 descriptors it burns 3+ mbytes/sec from multiple fallback directories?

 IMO this is intentional in the way the circuit-extend attack was
 intentional: cause trouble, harass the network

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

Re: [tor-bugs] #28333 [Applications/Tor Browser]: Trouble Connecting to Tor browser

[Tor Bug Tracker & Wiki]

#28333: Trouble Connecting to Tor browser
--+--
 Reporter:  Executor  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Have you tried using bridges? That might help in case someone censoring
 your Internet connection is involved. At any rate, this is our bug tracker
 tracking development efforts. We have some support channels in case your
 problem should persist:
 https://www.torproject.org/about/contact.html.en#support. Good luck.

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

Re: [tor-bugs] #26376 [Core Tor/Tor]: add cross compiling docs

[Tor Bug Tracker & Wiki]

#26376: add cross compiling docs
--+
 Reporter:  Hello71   |  Owner:  Hello71
 Type:  enhancement   | Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:  Sponsor8-can
--+

Comment (by teor):

 This ticket is about cross-compiling, #13694 is about native builds (using
 mingw).

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

Re: [tor-bugs] #13694 [Core Tor/Tor]: Ship with native build instructions for windows

[Tor Bug Tracker & Wiki]

#13694: Ship with native build instructions for windows
---+---
 Reporter:  nickm  |  Owner:  gk
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  win32, build, lorax tor-build-doc  |  Actual Points:
Parent ID:  #26376 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by teor):

 * parent:   => #26376


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

Re: [tor-bugs] #28350 [Internal Services]: Request for a Tor Circuit site which appears to be in the USA

[Tor Bug Tracker & Wiki]

#28350: Request for a Tor Circuit site which appears to be in the USA
---+-
 Reporter:  CrisBCT|  Owner:  < apparent IP address >
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Internal Services  |Version:
 Severity:  Normal | Resolution:  not a bug
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by gk):

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


Comment:

 That's already possible, see the `ExitNodes` section in the man page.

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

Re: [tor-bugs] #26376 [Core Tor/Tor]: add cross compiling docs

[Tor Bug Tracker & Wiki]

#26376: add cross compiling docs
--+
 Reporter:  Hello71   |  Owner:  Hello71
 Type:  enhancement   | Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:  Sponsor8-can
--+

Comment (by gk):

 What's the relationship of this ticket to #13694?

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

Re: [tor-bugs] #23918 [Applications/Tor Browser]: tor button and tor browser home page says "not connected to network"

[Tor Bug Tracker & Wiki]

#23918: tor button and tor browser home page says "not connected to network"
--+---
 Reporter:  tortracfree   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-torbutton |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by gk):

 Replying to [comment:16 tortracfree]:
 > still the same problem happening, this is not solved...

 Where do you have your Tor Browser installed? And, does it work for you if
 you install a new bundle to a different location?

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

Re: [tor-bugs] #27921 [Core Tor/Tor]: apparent DOS / impairment-of-service against FallbackDirs using DIR requests, please evaluate for possible mitigation

[Tor Bug Tracker & Wiki]

#27921: apparent DOS / impairment-of-service against FallbackDirs using DIR
requests, please evaluate for possible mitigation
--+
 Reporter:  starlight |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-dos   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Hmm, it is also possible that the botnet simply upgraded its tor version.

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

Re: [tor-bugs] #27921 [Core Tor/Tor]: apparent DOS / impairment-of-service against FallbackDirs using DIR requests, please evaluate for possible mitigation

[Tor Bug Tracker & Wiki]

#27921: apparent DOS / impairment-of-service against FallbackDirs using DIR
requests, please evaluate for possible mitigation
--+
 Reporter:  starlight |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-dos   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by starlight):

 Replying to [comment:11 teor]:
 > > perhaps they are simply causing trouble the way the circuit extend
 idiots were (same idiots, likely as not).  Requests all originate from
 direct attached clients, a pool of rotating IPs in South America an SE
 Asia--botnet if you ask me.
 >
 > Are they all in the same AS? Or a small set of ASes?
 > Are the ASes ISPs or VPS providers?

 Early this year the IPs were mostly in residential dynamic IP ranges in
 countries notorious for running ancient WinXP and/or pirated other Windows
 systems, also notorious for botnets due to the ease with which such
 systems are infected and kept in that state.  No particular ASs, just
 general regions with a residential profile.  Some IPs on the CBL, some
 not.  Smells like botnet-for hire.  A few dozen IPs per week in constant
 rotation.

 Certainly the same MO now, only difference is the upgrade from DIR to DIR-
 over-OR request path.  I ran the info logging scriptlet from earlier and
 observed the request pattern was identical, inspiring me to disable the
 target code path.

 > > . . .the connections serving the requests generally have back-pressure
 and standing send-Q bytes

 Possibly this is the point.  Maybe it biases KIST somehow and facilitates
 a subtle traffic analysis attack of some kind.

 > We already limit connections and circuits per IP address. Maybe we
 should limit directory requests as well.

 What I was thinking when opening 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] #26698 [Core Tor/Tor]: Authorities should put a hash of the bandwidth file in their votes

[Tor Bug Tracker & Wiki]

#26698: Authorities should put a hash of the bandwidth file in their votes
+--
 Reporter:  teor|  Owner:  (none)
 Type:  enhancement | Status:  needs_review
 Priority:  Low |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-crypto tor-dirauth  |  Actual Points:
Parent ID:  #27047  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 We typically use hexadecimal or base64 to encode raw bytes in directory
 documents.

 base64 is shorter, but it doesn't work in file names.

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

Re: [tor-bugs] #26698 [Core Tor/Tor]: Authorities should put a hash of the bandwidth file in their votes

[Tor Bug Tracker & Wiki]

#26698: Authorities should put a hash of the bandwidth file in their votes
+--
 Reporter:  teor|  Owner:  (none)
 Type:  enhancement | Status:  needs_review
 Priority:  Low |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-crypto tor-dirauth  |  Actual Points:
Parent ID:  #27047  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 Replying to [comment:8 juga]:
 > Replying to [comment:7 teor]:
 > > If collector is going to use hexadecimal for the bandwidth file hash,
 we should use hexadecimal in the votes. I asked karsten here:
 > > https://trac.torproject.org/projects/tor/ticket/21378#comment:17
 >
 > i asked in IRC why we would encode the hash of a file in base 64 in a
 vote and i was told that we don't use raw bytes anymore.

 Directory documents never contain raw bytes.

 > Searching for "base64" in dir-spec.txt, gives several results, though i
 couldn't find a paragraph that would confirm that.

 Directory documents only contain printing ASCII characters:
 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n193

 Although we allow some other text encodings in the contact and platform
 lines.

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

Re: [tor-bugs] #26843 [Applications/Tor Browser]: TBA: Investigate how Mozilla Fennec provides localization

[Tor Bug Tracker & Wiki]

#26843: TBA: Investigate how Mozilla Fennec provides localization
-+-
 Reporter:  sysrqb   |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-mobile, TorBrowserTeam201811,|  Actual Points:
  TBA-a2, GeorgKoppen201811  |
Parent ID:  #26782   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  tbb-mobile => tbb-mobile, TorBrowserTeam201811, TBA-a2,
 GeorgKoppen201811


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

Re: [tor-bugs] #27921 [Core Tor/Tor]: apparent DOS / impairment-of-service against FallbackDirs using DIR requests, please evaluate for possible mitigation

[Tor Bug Tracker & Wiki]

#27921: apparent DOS / impairment-of-service against FallbackDirs using DIR
requests, please evaluate for possible mitigation
--+
 Reporter:  starlight |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-dos   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [comment:10 starlight]:
 > Replying to [comment:9 teor]:
 > . . .
 > > I wonder if this is a bug in Tor. If it is, it seems to affect relays
 (or old clients). Are the addresses making these requests in the consensus
 as relays?
 >
 > Seems to me it's some actor with a dubious agenda.  They pull
 uncompressed full descriptors at a ridiculous rate from several stable
 relays, mine included.  Perhaps they are trying to detect changes with
 little or no delay

 But descriptors only change once an hour on directory mirrors, because
 mirrors don't fetch new descriptors until they get a new consensus. So
 this probably isn't helping them at all.

 > perhaps they are simply causing trouble the way the circuit extend
 idiots were (same idiots, likely as not).  Requests all originate from
 direct attached clients, a pool of rotating IPs in South America an SE
 Asia--botnet if you ask me.

 Are they all in the same AS? Or a small set of ASes?
 Are the ASes ISPs or VPS providers?

 > I have lists of IPs from the iptables blocker that was working early
 this year if you are interested.  Today I observed the connections serving
 the requests generally have back-pressure and standing send-Q bytes, the
 IPs appear similar to when the requests arrived via DIR port.

 We already limit connections and circuits per IP address. Maybe we should
 limit directory requests as well.

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

Re: [tor-bugs] #26698 [Core Tor/Tor]: Authorities should put a hash of the bandwidth file in their votes

[Tor Bug Tracker & Wiki]

#26698: Authorities should put a hash of the bandwidth file in their votes
+--
 Reporter:  teor|  Owner:  (none)
 Type:  enhancement | Status:  needs_review
 Priority:  Low |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-crypto tor-dirauth  |  Actual Points:
Parent ID:  #27047  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by juga):

 Replying to [comment:7 teor]:
 > If collector is going to use hexadecimal for the bandwidth file hash, we
 should use hexadecimal in the votes. I asked karsten here:
 > https://trac.torproject.org/projects/tor/ticket/21378#comment:17

 i asked in IRC why we would encode the hash of a file in base 64 in a vote
 and i was told that we don't use raw bytes anymore.
 Searching for "base64" in dir-spec.txt, gives several results, though i
 couldn't find a paragraph that would confirm 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] #27921 [Core Tor/Tor]: apparent DOS / impairment-of-service against FallbackDirs using DIR requests, please evaluate for possible mitigation

[Tor Bug Tracker & Wiki]

#27921: apparent DOS / impairment-of-service against FallbackDirs using DIR
requests, please evaluate for possible mitigation
--+
 Reporter:  starlight |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-dos   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by starlight):

 Replying to [comment:9 teor]:
 . . .
 > I wonder if this is a bug in Tor. If it is, it seems to affect relays
 (or old clients). Are the addresses making these requests in the consensus
 as relays?

 Seems to me it's some actor with a dubious agenda.  They pull uncompressed
 full descriptors at a ridiculous rate from several stable relays, mine
 included.  Perhaps they are trying to detect changes with little or no
 delay, perhaps they are simply causing trouble the way the circuit extend
 idiots were (same idiots, likely as not).  Requests all originate from
 direct attached clients, a pool of rotating IPs in South America an SE
 Asia--botnet if you ask me.

 I have lists of IPs from the iptables blocker that was working early this
 year if you are interested.  Today I observed the connections serving the
 requests generally have back-pressure and standing send-Q bytes, the IPs
 appear similar to when the requests arrived via DIR port.

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

Re: [tor-bugs] #28328 [Metrics/Website]: inlcude "total consensus" in vote totals graph

[Tor Bug Tracker & Wiki]

#28328: inlcude "total consensus" in vote totals graph
-+--
 Reporter:  starlight|  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by starlight):

 Replying to [comment:6 teor]:
 > I'm not sure I understand the problem, or its likely cause. I am cc'ing
 Mike, because he has more experience with bandwidth weighting.
 >
 > I'm going to ask some questions to work out what is happening. I find
 big blocks of text confusing, so it would help me if you'd answer after
 each question.
 >
 > Replying to [ticket:28328 starlight]:
 > > Totals of consensus weighs shift erratically due to some aspect of
 vote median behavior in the consensus.  E.g. (Exit,Exit+Guard) moved 12.5%
 in 12 hours on 09-Jul-18 12:00 to 23:59 UTC while votes steady.
 >
 > The consensus is created deterministically from the votes. If the votes
 are identical, the consensus will be identical. In particular, the
 consensus weights are the low-median of the votes for each relay: they
 can't change unless the votes change.
 >
 > What is changing in the votes to change the consensus weights?

 The problem I see is that, in aggregate, the median votes values selected
 by the consensus will, in a short span, shift around such that the _total_
 consensus value moves significantly.  This would not matter if individual
 votes were updated as quickly as these shifts in totals, but in practice
 individual relays are often not updated for sometimes two and even three
 days.  Individual relays see their consensus selection probability change
 by 5% or even 10% (because the denominator changes) while the absolute
 median for the relay (numerator) does not move at all.

 In a word:  anachronism

 >
 > Are some authorities not voting?

 Voting continues, but not consistently across the entire set of relays.
 SBWS likely does not suffer from this behavior.

 > Are the Bandwidth= figures in the votes actually different?

 Per the above, some change some do not.

 An easy way to think about this is cases where one of the bwauths drops
 out for a few hours or a day or two.  The consensus total will experience
 a huge jump in one hour but many relay median votes do not move at all.
 This is the extreme case but it happens all the time without a bwauth
 withdraw or join event.

 > Or, are you talking about overall relay selection probability, which
 depends on the total consensus weight?

 This is all about the totals moving and shifting votes that are not
 refreshing as quickly.  Each relay class operates independently as a
 practical matter, and exits have the worst time if it.

 > Do other relays start Running or stop Running?

 Relays are generally stable.  It seems to me that occasionally a big
 operator will take down or start up a block of a dozen or so high-
 bandwidth nodes and this can trigger a shift, but it's not the principal
 cause.  The "rc" columns and percentages in the CSV can be used to look
 for these.

 > Do some relays start or stop being Guard or Exit?

 Possibly, but again these events are not a big problem as AFAICT.

 > > Twenty percent in 56 hours with votes shifting.  The behavior results
 in significant adjustment to the selection probability of relays with
 unchanged consensus weights.
 >
 > The goal of the bandwidth weighting system is to provide a set of
 weights that give clients equal performance, regardless of the particular
 relays they choose.
 >
 > Maybe the load on the relay changes erratically, so its selection
 probability should also change?

 Again, in this situation I'm focused on consensus totals.  Something about
 the way Torflow votes from different authorities interact results in the
 medians shifting wholesale while the individual votes sets appear mostly
 stable.  I did not try to analyze the exact nature of it, figuring it
 would be worth the trouble only if the new system experiences this.

 > Maybe other available relays change their performance, so this relay
 should get used more (or less)?
 >
 > Do these erratic changes affect client performance?

 Clients use selection probability, so yes for sure.  If a node's
 probability changes because the denominator moved, the number is still
 different.

 > Would clients perform better or worse without these erratic changes?

 I believe this contributes to misrating, especially for faster relays
 where the offset ratios are high, +1 and above (i.e 2x the average) and
 could be a factor in relays overloading and seizing up as often happens.
 I notice this when using SSH frequently--a good session will abruptly
 become terrible 

Re: [tor-bugs] #27921 [Core Tor/Tor]: apparent DOS / impairment-of-service against FallbackDirs using DIR requests, please evaluate for possible mitigation

[Tor Bug Tracker & Wiki]

#27921: apparent DOS / impairment-of-service against FallbackDirs using DIR
requests, please evaluate for possible mitigation
--+
 Reporter:  starlight |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-dos   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Replying to [ticket:27921 starlight]:
 > The attacker enhanced their botware to request via OR port and the
 problem is back.  In the previous 24-hour stats window DIR requests
 increased output load on the relay by 17%.  In the current cycle the
 increase is 12%.

 This is interesting. Tor clients on 0.2.8 and later only use the ORPort.
 And relays on 0.2.9(?) or later will fall back to the ORPort when the
 DirPort doesn't work.

 Replying to [comment:8 starlight]:
 > modified the daemon to reject /tor/server/d/ requests with a 404;
 crushed the cockroach
 >
 > /tor/micro/d/ left alone, quite a few .z requests for these
 presumably from booting relays and clients
 >
 > any objection?  any valid purpose for which this request type is
 critical?

 Since 0.2.3.25, clients use microdescs by default. Since 0.3.0.6, relays
 use microdescriptors by default for building circuits, but most relays are
 directory caches, so they still download full descriptors.

 So this is either a relay, or a client with UseMicrodescriptors 0 set. (Or
 similar options.)

 I wonder if this is a bug in Tor. If it is, it seems to affect relays (or
 old clients). Are the addresses making these requests in the consensus as
 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

[tor-bugs] #28354 [Metrics/Website]: Does the total consensus weight graph belong in the traffic section?

[Tor Bug Tracker & Wiki]

#28354: Does the total consensus weight graph belong in the traffic section?
-+--
 Reporter:  teor |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #28328
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 It seems like consensus weight is more like traffic than servers:
 https://metrics.torproject.org/totalcw.html

 But it is totally 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

[tor-bugs] #28353 [Metrics/Website]: Use Guard & Exit, Guard only, Exit only, and Middle only on all bandwidth by flag graphs

[Tor Bug Tracker & Wiki]

#28353: Use Guard & Exit, Guard only, Exit only, and Middle only on all 
bandwidth
by flag graphs
-+--
 Reporter:  teor |  Owner:  metrics-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #28328
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 Should we use Guard & Exit, Guard only, Exit only, and Middle only on:
 * https://metrics.torproject.org/bandwidth-flags.html and
 * https://metrics.torproject.org/bwhist-flags.html
 * the new graph from #28328

 I think it would be helpful to be consistent, but it's also not a big
 deal.

 If we make the bandwidth-flags and bwhist-flags graphs use the same flags,
 should we merge the two graphs?
 * https://metrics.torproject.org/bandwidth-flags.html and
 * https://metrics.torproject.org/bwhist-flags.html

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

[tor-bugs] #28352 [Metrics/Website]: Add "total consensus weight in consensus" to "Total consensus weight across bandwidth authorities"

[Tor Bug Tracker & Wiki]

#28352: Add "total consensus weight in consensus" to "Total consensus weight 
across
bandwidth authorities"
-+--
 Reporter:  teor |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #28328
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 The "Total consensus weight across bandwidth authorities" graph at
 https://metrics.torproject.org/totalcw.html lists the total consensus
 weight in the vote of every bandwidth authority.

 But it would be really useful to see if shifts in the votes also cause a
 shift in the consensus.

 Please add a "consensus" line to the graph.

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

Re: [tor-bugs] #28328 [Metrics/Website]: inlcude "total consensus" in vote totals graph

[Tor Bug Tracker & Wiki]

#28328: inlcude "total consensus" in vote totals graph
-+--
 Reporter:  starlight|  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by teor):

 I'm not sure I understand the problem, or its likely cause. I am cc'ing
 Mike, because he has more experience with bandwidth weighting.

 I'm going to ask some questions to work out what is happening. I find big
 blocks of text confusing, so it would help me if you'd answer after each
 question.

 Replying to [ticket:28328 starlight]:
 > Totals of consensus weighs shift erratically due to some aspect of vote
 median behavior in the consensus.  E.g. (Exit,Exit+Guard) moved 12.5% in
 12 hours on 09-Jul-18 12:00 to 23:59 UTC while votes steady.

 The consensus is created deterministically from the votes. If the votes
 are identical, the consensus will be identical. In particular, the
 consensus weights are the low-median of the votes for each relay: they
 can't change unless the votes change.

 What is changing in the votes to change the consensus weights?

 Are some authorities not voting?
 Are the Bandwidth= figures in the votes actually different?

 Or, are you talking about overall relay selection probability, which
 depends on the total consensus weight?

 Do other relays start Running or stop Running?
 Do some relays start or stop being Guard or Exit?

 > Twenty percent in 56 hours with votes shifting.  The behavior results in
 significant adjustment to the selection probability of relays with
 unchanged consensus weights.

 The goal of the bandwidth weighting system is to provide a set of weights
 that give clients equal performance, regardless of the particular relays
 they choose.

 Maybe the load on the relay changes erratically, so its selection
 probability should also change?
 Maybe other available relays change their performance, so this relay
 should get used more (or less)?

 Do these erratic changes affect client performance?
 Would clients perform better or worse without these erratic changes?

 > Please add to
 >
 > https://metrics.torproject.org/totalcw.html

 I think a separate graph would be better: having 6 authorities * 5
 categories = 30 lines on a graph will be unmanageable.

 Replying to [comment:5 starlight]:
 > I thought more about weighting the values (as in Relay Search), but it
 makes no difference for the purpose which is to see if the totals of
 medians continue jumping about with SBWS as presently happens with
 Torflow.  Simply graphing the total consensus for each selection class,
 Exit, Guard, Middle is sufficient.

 I agree we should monitor the behaviour of each class of relays.

 > (Exit,Exit+Guard) is the total of Exit-Only and Exit+Guard flagged
 relays as this is the set used for choosing exits

 No, this is the set that is *currently* used for choosing exits. If tor
 gets more exits in future, then Exit+Guard may be used as Guard.

 So we shouldn't hard-code the assumption that Exit+Guard is only used as
 an Exit.

 Instead, I suggest that we match the sets in
 https://metrics.torproject.org/bwhist-flags.html

 Guard & Exit
 Guard only
 Exit only
 Middle only

 I noticed some other things while reviewing this ticket, I'll create child
 tickets for 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] #26698 [Core Tor/Tor]: Authorities should put a hash of the bandwidth file in their votes

[Tor Bug Tracker & Wiki]

#26698: Authorities should put a hash of the bandwidth file in their votes
+--
 Reporter:  teor|  Owner:  (none)
 Type:  enhancement | Status:  needs_review
 Priority:  Low |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-crypto tor-dirauth  |  Actual Points:
Parent ID:  #27047  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 If collector is going to use hexadecimal for the bandwidth file hash, we
 should use hexadecimal in the votes. I asked karsten here:
 https://trac.torproject.org/projects/tor/ticket/21378#comment:17

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

Re: [tor-bugs] #21378 [Metrics/CollecTor]: Archive bwauth bandwidth files

[Tor Bug Tracker & Wiki]

#21378: Archive bwauth bandwidth files
+--
 Reporter:  tom |  Owner:  metrics-team
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Metrics/CollecTor   |Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-bwauth tor-dirauth  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by teor):

 Replying to [comment:16 karsten]:
 > Replying just to the parts where I wouldn't reply "okay, cool!":
 >
 > Replying to [comment:15 teor]:
 > > Replying to [comment:14 karsten]:
 > > > In the future, we can switch to fetching only those files that are
 referenced from votes, unless for some reason we want to have non-
 referenced files, too.
 > >
 > > How are bandwidth files referenced from votes?
 > >
 > > I don't think we will implement "bandwidth-file-url" from
 https://trac.torproject.org/projects/tor/ticket/21378?replyto=14#comment:6
 > >
 > > Tor 0.3.5? and later add bandwidth file headers to each vote, and we
 may add a bandwidth file hash in future. Once all authorities upgrade, you
 can fetch the bandwidth file if the vote contains headers.
 >
 > I guess I was thinking of 0.3.5 then. I'm not aware of any other plans.

 The ticket for putting the bandwidth file hash in the votes is #26698.

 Will you use a hexadecimal hash when you archive the bandwidth files?
 If so, maybe we should switch to a hexadecimal hash in the vote.
 (I said base64 when I did the initial design, but consistency is more
 important than saving a few bytes.)

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

Re: [tor-bugs] #27921 [Core Tor/Tor]: apparent DOS / impairment-of-service against FallbackDirs using DIR requests, please evaluate for possible mitigation

[Tor Bug Tracker & Wiki]

#27921: apparent DOS / impairment-of-service against FallbackDirs using DIR
requests, please evaluate for possible mitigation
--+
 Reporter:  starlight |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-dos   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by starlight):

 * Attachment "reasonable_dir_request_traffic.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] #27921 [Core Tor/Tor]: apparent DOS / impairment-of-service against FallbackDirs using DIR requests, please evaluate for possible mitigation

[Tor Bug Tracker & Wiki]

#27921: apparent DOS / impairment-of-service against FallbackDirs using DIR
requests, please evaluate for possible mitigation
--+
 Reporter:  starlight |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-dos   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by starlight):

 modified the daemon to reject /tor/server/d/ requests with a 404;
 crushed the cockroach

 /tor/micro/d/ left alone, quite a few .z requests for these
 presumably from booting relays and clients

 any objection?  any valid purpose for this request type is critical?

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

Re: [tor-bugs] #28328 [Metrics/Website]: inlcude "total consensus" in vote totals graph

[Tor Bug Tracker & Wiki]

#28328: inlcude "total consensus" in vote totals graph
-+--
 Reporter:  starlight|  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by starlight):

 * Attachment "cnsns_gdrlypct_alltot.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] #28328 [Metrics/Website]: inlcude "total consensus" in vote totals graph

[Tor Bug Tracker & Wiki]

#28328: inlcude "total consensus" in vote totals graph
-+--
 Reporter:  starlight|  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by starlight):

 * Attachment "cnsns_gdrlywgt_alltot.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] #28328 [Metrics/Website]: inlcude "total consensus" in vote totals graph

[Tor Bug Tracker & Wiki]

#28328: inlcude "total consensus" in vote totals graph
-+--
 Reporter:  starlight|  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by starlight):

 * Attachment "cnsns_exit_alltot.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] #28328 [Metrics/Website]: inlcude "total consensus" in vote totals graph

[Tor Bug Tracker & Wiki]

#28328: inlcude "total consensus" in vote totals graph
-+--
 Reporter:  starlight|  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by starlight):

 * Attachment "bw_stat_dbw_201807-11_graph.csv" 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] #28328 [Metrics/Website]: inlcude "total consensus" in vote totals graph

[Tor Bug Tracker & Wiki]

#28328: inlcude "total consensus" in vote totals graph
-+--
 Reporter:  starlight|  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by starlight):

 ok, attachments follow

 I thought more about weighting the values (as in Relay Search), but it
 makes no difference for the purpose which is to see if the totals of
 medians continue jumping about with SBWS as presently happens with
 Torflow.  Simply graphing the total consensus for each selection class,
 Exit, Guard, Middle is sufficient.

 (Exit,Exit+Guard) is the total of Exit-Only and Exit+Guard flagged relays
 as this is the set used for choosing exits

 (Guard,notExit) is the set used when selecting guards

 (Guard,unflagged) is the set for selecting middle relays, is the only one
 where current consensus weight values make a difference

 In a perfect solution each selection category would be constructed from
 the full set of relevant weights, but since most weights presently are
 either 1 or 0 it was not worth the trouble for the scripts I wrote.
 Perhaps Relay Search (formerly Atlas) logic can be reused here.

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

Re: [tor-bugs] #28326 [Applications/Tor Browser]: Tor Browser for PPC64LE

[Tor Bug Tracker & Wiki]

#28326: Tor Browser for PPC64LE
--+--
 Reporter:  power9|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by tpearson-raptor):

 Replying to [comment:10 ppc64le]:
 > Replying to [comment:3 gk]:
 > > Replying to [comment:2 teor]:
 > > > Tor doesn't support PPC, because its MUL instruction is not
 constant-time.
 > > > It's really hard to write secure crypto without a constant-time MUL.
 > > >
 
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/SupportedPlatforms
 > >
 > > Good to know. FWIW: there are Debian packages for that platform,
 though.
 >
 > {{{
 >  Debian 9 regrettably removes support for the following architecture:
 >
 > PowerPC (powerpc)
 >
 > The following are the officially supported architectures for Debian 9:
 >
 > 64-bit little-endian PowerPC (ppc64el)
 > }}}
 > Replying to [comment:4 power9]:
 > > That's mean we never see Tor Browser on PPC?
 > Yes.

 As I mmentioned above, we do have constant time multiplication on ppc64le,
 plus ppc64le is a Debian supported architecture.  Can we get Tor for
 ppc64le even if old 32-bit ppc is 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] #28326 [Applications/Tor Browser]: Tor Browser for PPC64LE

[Tor Bug Tracker & Wiki]

#28326: Tor Browser for PPC64LE
--+--
 Reporter:  power9|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by ppc64le):

 Replying to [comment:3 gk]:
 > Replying to [comment:2 teor]:
 > > Tor doesn't support PPC, because its MUL instruction is not constant-
 time.
 > > It's really hard to write secure crypto without a constant-time MUL.
 > >
 
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/SupportedPlatforms
 >
 > Good to know. FWIW: there are Debian packages for that platform, though.

 {{{
  Debian 9 regrettably removes support for the following architecture:

 PowerPC (powerpc)

 The following are the officially supported architectures for Debian 9:

 64-bit little-endian PowerPC (ppc64el)
 }}}
 Replying to [comment:4 power9]:
 > That's mean we never see Tor Browser on PPC?
 Yes.

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

Re: [tor-bugs] #28144 [Applications/Tor Browser]: Update projects/tor-browser for Android

[Tor Bug Tracker & Wiki]

#28144: Update projects/tor-browser for Android
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201811, TBA-a2   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sisbell):

 * 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] #28144 [Applications/Tor Browser]: Update projects/tor-browser for Android

[Tor Bug Tracker & Wiki]

#28144: Update projects/tor-browser for Android
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201811, TBA-a2   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sisbell):

 * status:  needs_information => needs_revision


Comment:

 Changes (android-1106)

  * Added var/desktop field. Used to disable the projects that android
 doesn't need (if there is better way open to suggestions)
  * Created build.android file
  * Build unzips apk and copies xpi files into resources and then rezips
 apk

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

Re: [tor-bugs] #27699 [Applications]: Release teams: please verify the website lists the correct key

[Tor Bug Tracker & Wiki]

#27699: Release teams: please verify the website lists the correct key
--+
 Reporter:  traumschule   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #22637| Points:
 Reviewer:|Sponsor:
--+
Changes (by traumschule):

 * cc: boklm (removed)
 * cc: atagar, arma (added)


Comment:

 Shall we replace the short key ids?
 - Roger Dingledine (0x28988BF5 and 0x19F78451)
 - Damian Johnson (0x9ABBEEC6)

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

Re: [tor-bugs] #28306 [Internal Services/Tor Sysadmin Team]: Please add signing keys to db.torproject.org

[Tor Bug Tracker & Wiki]

#28306: Please add signing keys to db.torproject.org
-+-
 Reporter:  traumschule  |  Owner:  tpa
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  not a
 |  bug
 Keywords:   |  Actual Points:
Parent ID:  #22637   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by traumschule):

 * parent:   => #22637


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

Re: [tor-bugs] #23918 [Applications/Tor Browser]: tor button and tor browser home page says "not connected to network"

[Tor Bug Tracker & Wiki]

#23918: tor button and tor browser home page says "not connected to network"
--+---
 Reporter:  tortracfree   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-torbutton |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by tortracfree):

 still the same problem happening, this is not solved...

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

Re: [tor-bugs] #28096 [Core Tor/Tor]: Windows 8.1 and 10 relays claim to be Windows 8

[Tor Bug Tracker & Wiki]

#28096: Windows 8.1 and 10 relays claim to be Windows 8
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.2.34
 Severity:  Normal   | Resolution:
 Keywords:  windows, fast-fix, 029-backport, |  Actual Points:  0.2
  033-backport, 034-backport, 035-backport   |
Parent ID:   | Points:  0.2
 Reviewer:  asn  |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:12 asn]:
 > LGTM but what to do about the `TODO: only print this in the main process
 on Windows,`?

 nickm will help some time this week.

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

Re: [tor-bugs] #26376 [Core Tor/Tor]: add cross compiling docs

[Tor Bug Tracker & Wiki]

#26376: add cross compiling docs
--+
 Reporter:  Hello71   |  Owner:  Hello71
 Type:  enhancement   | Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  teor  |Sponsor:  Sponsor8-can
--+
Changes (by teor):

 * status:  needs_revision => needs_information
 * milestone:  Tor: 0.3.5.x-final => Tor: 0.3.6.x-final


Comment:

 We discussed this documentation in the network team meeting.

 We want to document the following use cases:
 * cross-compiling Tor (Tor Browser, Tor Devs using Wine)
 * compiling Tor using mingw (Appveyor, Tor Devs using Native Windows)

 We want to spend some more time reviewing this document, and trying out
 the process, before deciding if we want to merge it as-is, or make some
 more changes.

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

Re: [tor-bugs] #28229 [Core Tor/Tor]: Possible race condition opening SOCKS Port in test_rebind.py

[Tor Bug Tracker & Wiki]

#28229: Possible race condition opening SOCKS Port in test_rebind.py
--+
 Reporter:  teor  |  Owner:  rl1987
 Type:  defect| Status:  merge_ready
 Priority:  High  |  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-ci|  Actual Points:
Parent ID:| Points:
 Reviewer:  catalyst  |Sponsor:
--+
Changes (by catalyst):

 * status:  needs_review => merge_ready


Comment:

 Replying to [comment:2 rl1987]:
 > Patch for diagnostics: https://github.com/torproject/tor/pull/473
 >
 > This should help with digging up the root cause of the failure, if it
 happens again.
 Thanks for the patch! I left a minor comment on the pull request, which
 you may address if you like (timestamp redundancy).

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

Re: [tor-bugs] #26540 [Applications/Tor Browser]: Enabling pdfjs disableRange option prevents pdfs from loading

[Tor Bug Tracker & Wiki]

#26540: Enabling pdfjs disableRange option prevents pdfs from loading
-+-
 Reporter:  pospeselr|  Owner:  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201811R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by pospeselr):

 Better patch following suggestions from Arthur, now using the secret
 chrome-only SetOriginAttributes function:

 https://gitweb.torproject.org/user/richard/tor-
 browser.git/commit/?h=bug_26540_v4

 The origin attributes are set immediately after channel creation, FPI
 regarding cookies is now enforced correctly, and pdfjs's range-based
 requests now go out on the correct channel (the channel for the hosted
 pdf's domain if entered directly in the title bar, and the first party
 domain's when embedded via an iframe or embed node).

 Verified on jsbin.com with the following html:

 {{{
 
 
 
   http://cadwe.free.fr/cadr/DD4/Player%27s%20Handbook.pdf;>
 
 
 }}}

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

Re: [tor-bugs] #27921 [Core Tor/Tor]: apparent DOS / impairment-of-service against FallbackDirs using DIR requests, please evaluate for possible mitigation

[Tor Bug Tracker & Wiki]

#27921: apparent DOS / impairment-of-service against FallbackDirs using DIR
requests, please evaluate for possible mitigation
--+
 Reporter:  starlight |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-dos   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by starlight):

 next above will not work because several other configuration elements
 implicitly activate caching of full descriptors

 does any reason exist why I should not modify the daemon to reject
 individual descriptor queries?  seems to me relays pull "all"; I know that
 my scripts do

 either that or I will have the daemon log requesting IPs and feed them to
 scripts written to block the botnet when it came in via plaintext DIR port

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

Re: [tor-bugs] #28326 [Applications/Tor Browser]: Tor Browser for PPC64LE

[Tor Bug Tracker & Wiki]

#28326: Tor Browser for PPC64LE
--+--
 Reporter:  power9|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-rbm   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by tpearson-raptor):

 https://bearssl.org/ctmul.html has been updated, we officially have
 constant time multiplication listed!

 Are there any other blockers to getting this support going?

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

Re: [tor-bugs] #28303 [Core Tor/Tor]: Include sys/time.h in timers.c and time_fmt.c to fix OpenBSD build

[Tor Bug Tracker & Wiki]

#28303: Include sys/time.h in timers.c and time_fmt.c to fix OpenBSD build
--+
 Reporter:  kjak  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  openbsd   |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+

Comment (by kjak):

 Awesome.  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] #27490 [Core Tor/Tor]: When ClientPreferIPv6ORPort is set to auto, and a relay is being chosen for a directory or orport connection, prefer IPv4 or IPv6 at random

[Tor Bug Tracker & Wiki]

#27490: When ClientPreferIPv6ORPort is set to auto, and a relay is being chosen 
for
a directory or orport connection, prefer IPv4 or IPv6 at random
--+
 Reporter:  neel  |  Owner:  neel
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ipv6  |  Actual Points:
Parent ID:  #17835| Points:
 Reviewer:  teor  |Sponsor:
--+

Comment (by teor):

 Here's what we discussed at the meeting:

 Pathbias isn't affected, because it only triggers after two hops.

 Guard selection may be affected, but:
 * IPv4-only clients will try 1-2 guards, and fail 0-1 times before
 connecting on average (all guards have IPv4)
 * IPv6-only clients will try 1-5 guards, and fail 0-5 times before
 connecting on average (20% of guard weight has IPv6 -
 https://metrics.torproject.org/advbw-ipv6.html )
 We think this is acceptable, and if it causes bugs in the guard code,
 let's fix the guard 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] #27921 [Core Tor/Tor]: apparent DOS / impairment-of-service against FallbackDirs using DIR requests, please evaluate for possible mitigation

[Tor Bug Tracker & Wiki]

#27921: apparent DOS / impairment-of-service against FallbackDirs using DIR
requests, please evaluate for possible mitigation
--+
 Reporter:  starlight |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-dos   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by starlight):

 the abuser is issuing huge quantities of /tor/server/d/ requests

 setting

 DownloadExtraInfo 1
 UseMicrodescriptors 1

 and leaving it unless DOS mitigation for this problem becomes available

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28351 [Core Tor/Chutney]: Test clock skewed clients using chutney

[Tor Bug Tracker & Wiki]

#28351: Test clock skewed clients using chutney
-+-
 Reporter:  teor |  Owner:  teor
 Type:   | Status:  assigned
  enhancement|
 Priority:  Medium   |  Milestone:
Component:  Core |Version:
  Tor/Chutney|   Keywords:  bootstrap, clock-skew, tor-guard,
 Severity:  Normal   |  usability, ux, s8-errors, 035-roadmap-subtask,
 |  s8-bootstrap
Actual Points:   |  Parent ID:  #23605
   Points:   |   Reviewer:
  Sponsor:   |
  Sponsor8-can   |
-+-
 To test #23605, we could run chutney with the clients clock skewed using
 chutney.

 Alternately, we could launch the clients from a chutney network on a
 separate, skewed machine; or launch the clients and onion services on the
 public network (but we'd need exits?).

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

Re: [tor-bugs] #27100 [Core Tor/Tor]: report connection to PT SOCKS proxy separately from OR connection

[Tor Bug Tracker & Wiki]

#27100: report connection to PT SOCKS proxy separately from OR connection
-+-
 Reporter:  catalyst |  Owner:  ahf
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-roadmap-subtask, 035-triaged-|  Actual Points:
  in-20180711, socks, pt, s8-bootstrap   |
Parent ID:  #28018   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by ahf):

 * owner:  catalyst => ahf


Comment:

 This is slightly related to some of the stuff I'm already working on for
 S8. Taking over this one.

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

Re: [tor-bugs] #28203 [Core Tor/Chutney]: Make chutney log the bootstrap progress for each node

[Tor Bug Tracker & Wiki]

#28203: Make chutney log the bootstrap progress for each node
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Chutney |Version:
 Severity:  Normal   | Resolution:
 Keywords:  test, chutney, consistency,  |  Actual Points:
  jenkins, integration-testing, continuous-  |
  integration|
Parent ID:  #28018   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-
Changes (by teor):

 * owner:  (none) => teor
 * status:  new => assigned
 * sponsor:   => Sponsor8-can
 * parent:  #20647 => #28018


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

Re: [tor-bugs] #23605 [Core Tor/Tor]: expired consensus causes guard selection to stall at BOOTSTRAP PROGRESS=80

[Tor Bug Tracker & Wiki]

#23605: expired consensus causes guard selection to stall at BOOTSTRAP 
PROGRESS=80
-+-
 Reporter:  catalyst |  Owner:  teor
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bootstrap, clock-skew, tor-guard,|  Actual Points:
  usability, ux, s8-errors, 035-roadmap- |
  subtask, 035-triaged-in-20180711,  |
  s8-bootstrap   |
Parent ID:  #28018   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8
-+-
Changes (by teor):

 * owner:  catalyst => teor


Comment:

 I am doing most of the subtickets, so I guess this is mine

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

Re: [tor-bugs] #27225 [Core Tor/Tor]: Perform fewer allocations in summarize_protocol_flags()

[Tor Bug Tracker & Wiki]

#27225: Perform fewer allocations in summarize_protocol_flags()
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-roadmap-master, 035-triaged- |  Actual Points:
  in-20180711|
Parent ID:  #26630   | Points:
 Reviewer:  mikeperry|Sponsor:
 |  Sponsor8
-+-
Changes (by mikeperry):

 * status:  needs_review => merge_ready


Comment:

 Yeah I suppose we can deal with the ordering issue if/when different
 implementations/modularization actually becomes an issue.

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

Re: [tor-bugs] #28137 [Metrics/Statistics]: Modify "Total consensus weights across bandwidth authorities" graph to only include relays that end up in the consensus

[Tor Bug Tracker & Wiki]

#28137: Modify "Total consensus weights across bandwidth authorities" graph to 
only
include relays that end up in the consensus
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by karsten):

 Okay, I might have an idea how we can implement this with reasonable
 effort:
  - We import fingerprints into a table and assign numeric identifiers that
 we use in other tables.
  - We import all fingerprints in a consensus together with the votes
 referenced from the consensus.
  - We import all fingerprints in a vote together with a way to refer to
 the consensus coming out of it.
  - When aggregating, we join votes with the consensus they refer to.
  - After aggregating, we delete all votes that we aggregated in the
 previous step and we delete all consensuses ''if'' we aggregated all votes
 referenced from consensuses.

 This approach effectively moves the aggregation step to the database. It
 was more convenient to just do it after parsing, but it's doable in the
 database as well.

 This approach also ensures that tables don't grow forever. I would expect
 that there are just a few votes and consensuses missing from the archives,
 so we'd carry just those fingerprints in the database forever.

 However, this is not a trivial change to the existing "totalcw" module.
 It's basically a rewrite.

 Are there any other changes we might want to make in the near future? For
 example, does #28328 maybe add something here?

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

Re: [tor-bugs] #27921 [Core Tor/Tor]: apparent DOS / impairment-of-service against FallbackDirs using DIR requests, please evaluate for possible mitigation

[Tor Bug Tracker & Wiki]

#27921: apparent DOS / impairment-of-service against FallbackDirs using DIR
requests, please evaluate for possible mitigation
--+
 Reporter:  starlight |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-dos   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by starlight):

 does anyone have any idea what this nonsense is about?  50% of 6MB/sec DIR
 request traffic?

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

Re: [tor-bugs] #27921 [Core Tor/Tor]: apparent DOS / impairment-of-service against FallbackDirs using DIR requests, please evaluate for possible mitigation

[Tor Bug Tracker & Wiki]

#27921: apparent DOS / impairment-of-service against FallbackDirs using DIR
requests, please evaluate for possible mitigation
--+
 Reporter:  starlight |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-dos   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by starlight):

 * Attachment "extreme_dir_request_traffic8.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] #28328 [Metrics/Website]: inlcude "total consensus" in vote totals graph

[Tor Bug Tracker & Wiki]

#28328: inlcude "total consensus" in vote totals graph
-+--
 Reporter:  starlight|  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * cc: teor (added)


Comment:

 I'm afraid I cannot open that file. A CSV file might work better, as would
 a PNG or PDF.

 Can you also elaborate what separate weighted lines you'd want to see in
 the graph? For example, I don't really understand your (Exit,Exit+Guard)
 notation. Which relays does this include? And does it weight the measured
 bandwidth by anything depending on flag combination?

 I'm also copying teor on this ticket, in case they have a better intuition
 what modifications you have in mind for the graph they suggested in
 #25459.

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

Re: [tor-bugs] #28205 [Obfuscation/Snowflake]: linking against other libwebrtc binaries errors out on missing symbols

[Tor Bug Tracker & Wiki]

#28205: linking against other libwebrtc binaries errors out on missing symbols
---+---
 Reporter:  eighthave  |  Owner:  eighthave
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords:  android|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by eighthave):

 looks like that did the trick for the GNU/Linux build:
 https://gitlab.com/eighthave/go-webrtc/-/jobs/117246103

 Wish me luck on the Android stuff!

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

Re: [tor-bugs] #27841 [Core Tor/Tor]: Close intro circuit after introduction has been completed

[Tor Bug Tracker & Wiki]

#27841: Close intro circuit after introduction has been completed
-+-
 Reporter:  asn  |  Owner:  neel
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs dos 033-backport, |  Actual Points:
  034-backport   |
Parent ID:   | Points:
 Reviewer:  dgoulet  |Sponsor:
-+-

Comment (by neel):

 A PR based on `maint-3.3` which includes your suggestions is here:
 https://github.com/torproject/tor/pull/487

 If you want it based on `master`, tell me and I can base the patch off
 that instead.

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

Re: [tor-bugs] #28205 [Obfuscation/Snowflake]: linking against other libwebrtc binaries errors out on missing symbols

[Tor Bug Tracker & Wiki]

#28205: linking against other libwebrtc binaries errors out on missing symbols
---+---
 Reporter:  eighthave  |  Owner:  eighthave
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords:  android|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by eighthave):

 I'm first just trying to get a native build repeatable here, e.g. a
 Debian/amd64 binary building on Debian/amd64.  That's where its failing.
 Once I get that working, then I'll move on to gomobile.

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

Re: [tor-bugs] #28193 [Core Tor/Tor]: Compile-time assertion

[Tor Bug Tracker & Wiki]

#28193: Compile-time assertion
--+
 Reporter:  riastradh |  Owner:  (none)
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+

Comment (by nickm):

 Made a github PR as https://github.com/torproject/tor/pull/486 to make
 sure that CI likes 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] #28077 [Core Tor/Tor]: remove unsafe block from cstr! macro

[Tor Bug Tracker & Wiki]

#28077: remove unsafe block from cstr! macro
--+
 Reporter:  cyberpunks|  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:  ahf   |Sponsor:
--+

Comment (by nickm):

 merged the pr to master.

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

Re: [tor-bugs] #28077 [Core Tor/Tor]: remove unsafe block from cstr! macro

[Tor Bug Tracker & Wiki]

#28077: remove unsafe block from cstr! macro
--+
 Reporter:  cyberpunks|  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.4.1-alpha
 Severity:  Normal| Resolution:  fixed
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:
 Reviewer:  ahf   |Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #28350 [Internal Services]: Request for a Tor Circuit site which appears to be in the USA

[Tor Bug Tracker & Wiki]

#28350: Request for a Tor Circuit site which appears to be in the USA
---+-
 Reporter:  CrisBCT|  Owner:  < apparent IP address >
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Internal Services  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by CrisBCT):

 * Attachment "TOR Access Denied 2018:11:06.png" added.

 Screenshot showing Access Denied

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

Re: [tor-bugs] #26698 [Core Tor/Tor]: Authorities should put a hash of the bandwidth file in their votes

[Tor Bug Tracker & Wiki]

#26698: Authorities should put a hash of the bandwidth file in their votes
+--
 Reporter:  teor|  Owner:  (none)
 Type:  enhancement | Status:  needs_review
 Priority:  Low |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-crypto tor-dirauth  |  Actual Points:
Parent ID:  #27047  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by juga):

 Replying to [comment:4 teor]:
 > Replying to [comment:3 juga]:
 > > i wonder if we should add the hash to the bandwidth file name in
 `sbws`, similar to what is done with descriptors. Though then we would
 need to allow giving a directory or a file (to be compatible with older
 versions) in V3BandwidthsFile, and then adding (or resusing?) code to find
 the latest file parsing the date in it.
 >
 > We could add this feature if we want, but I think it would make the tor
 code much more complicated.

 i agree

 > If you want to add it, let's open a separate ticket.
 >
 > This ticket is about verifying the bandwidth file that was used in a
 vote.

 not doing it so far cause the reason above

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

Re: [tor-bugs] #27367 [Core Tor/Tor]: Authorities should reject non-UTF-8 in relay descriptors

[Tor Bug Tracker & Wiki]

#27367: Authorities should reject non-UTF-8 in relay descriptors
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  rust-wants, prop285, |  implemented
  034-triage-20180328, 034-removed-20180328  |  Actual Points:
Parent ID:  #24033   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 LGTM; merged. There's a travis failure, but it looks intermittent and
 unrelated.

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

Re: [tor-bugs] #26698 [Core Tor/Tor]: Authorities should put a hash of the bandwidth file in their votes

[Tor Bug Tracker & Wiki]

#26698: Authorities should put a hash of the bandwidth file in their votes
+--
 Reporter:  teor|  Owner:  (none)
 Type:  enhancement | Status:  needs_review
 Priority:  Low |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-crypto tor-dirauth  |  Actual Points:
Parent ID:  #27047  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by juga):

 * status:  new => needs_review


Comment:

 https://github.com/torproject/tor/pull/485

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28350 [Internal Services]: Request for a Tor Circuit site which appears to be in the USA

[Tor Bug Tracker & Wiki]

#28350: Request for a Tor Circuit site which appears to be in the USA
-+-
 Reporter:  CrisBCT  |  Owner:  < apparent IP address >
 Type:  enhancement  | Status:  assigned
 Priority:  Medium   |  Component:  Internal Services
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
 Here in Europe I frequently find that a US site won't allow me to visit
 because I'm not in the USA. eg. www.cnbc.com/video/2018/08/16/jay-leno-
 chats-with-teslas-chief-designer-about-the-2020-tesla-roadster.html
 reports "Access Denied".

 And I do know that "New Tor Circuit for this Site" will give another
 apparent location, but not necessarily a US location.

 To resolve this problem TOR needs an enhancement to be able to request an
 apparent IP address for the Tor Circuit site which is in the USA...

 Please add this to the requested enhancements list, as

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

Re: [tor-bugs] #26973 [Core Tor/Tor]: Privcount blinding and encryption: add rustfmt CI check

[Tor Bug Tracker & Wiki]

#26973: Privcount blinding and encryption: add rustfmt CI check
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  privcount, 035-roadmap-master, 035   |  implemented
  -triaged-in-20180711, rust |  Actual Points:
Parent ID:  #25669   | Points:
 Reviewer:  nickm|Sponsor:
 |  SponsorV
-+-
Changes (by nickm):

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


Comment:

 Okay -- merged!

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

Re: [tor-bugs] #26632 [Core Tor/Tor]: Updated version of the WTF-pad proposal

[Tor Bug Tracker & Wiki]

#26632: Updated version of the WTF-pad proposal
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  project  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.6.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  035-roadmap-master, 035-triaged- |  implemented
  in-20180711|  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor2
-+-
Changes (by nickm):

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


Comment:

 merged to torspec!

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

Re: [tor-bugs] #28113 [Core Tor/Tor]: notify systemd if shutdown will be longer than 30 seconds

[Tor Bug Tracker & Wiki]

#28113: notify systemd if shutdown will be longer than 30 seconds
-+-
 Reporter:  Hello71  |  Owner:  Hello71
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.6.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-systemd, 029-backport-maybe, |  Actual Points:
  033-backport-maybe, 034-backport-maybe, 035|
  -backport-maybe|
Parent ID:   | Points:
 Reviewer:  teor |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Merging to 0.3.5, marking for possible backport.

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

Re: [tor-bugs] #28298 [Core Tor/Tor]: Tor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative DataDirectory

[Tor Bug Tracker & Wiki]

#28298: Tor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative
DataDirectory
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression 033-backport  |  Actual Points:
  034-backport   |
Parent ID:   | Points:
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Merged to maint-0.3.5; marking for backport.

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

Re: [tor-bugs] #28303 [Core Tor/Tor]: Include sys/time.h in timers.c and time_fmt.c to fix OpenBSD build

[Tor Bug Tracker & Wiki]

#28303: Include sys/time.h in timers.c and time_fmt.c to fix OpenBSD build
--+
 Reporter:  kjak  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  openbsd   |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by nickm):

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


Comment:

 Cherry-picked to maint-0.3.5 and merged forward. Thank you!

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

Re: [tor-bugs] #28303 [Core Tor/Tor]: Include sys/time.h in timers.c and time_fmt.c to fix OpenBSD build

[Tor Bug Tracker & Wiki]

#28303: Include sys/time.h in timers.c and time_fmt.c to fix OpenBSD build
--+
 Reporter:  kjak  |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  openbsd   |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+

Comment (by nickm):

 Looks like it's new in 0.3.5.

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

Re: [tor-bugs] #28205 [Obfuscation/Snowflake]: linking against other libwebrtc binaries errors out on missing symbols

[Tor Bug Tracker & Wiki]

#28205: linking against other libwebrtc binaries errors out on missing symbols
---+---
 Reporter:  eighthave  |  Owner:  eighthave
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords:  android|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by dcf):

 Replying to [comment:11 eighthave]:
 > And confirmed your suspicion:

 I expected to see arm64 here, not amd64?

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

Re: [tor-bugs] #28205 [Obfuscation/Snowflake]: linking against other libwebrtc binaries errors out on missing symbols

[Tor Bug Tracker & Wiki]

#28205: linking against other libwebrtc binaries errors out on missing symbols
---+---
 Reporter:  eighthave  |  Owner:  eighthave
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords:  android|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by dcf):

 Replying to [comment:10 eighthave]:
 > So I think this is starting to make sense to me.  The Android .pc file
 that I wrote already includes `-D_GLIBCXX_USE_CXX11_ABI=0`, so I
 guess I should change that to 1 also?  Does this still need to also be set
 in `CGO_CXXFLAGS`?  Should this be building with gcc?  I think gomobile
 defaults to clang.

 If you put `-D_GLIBCXX_USE_CXX_ABI=1` in `CGO_CXXFLAGS`, it will override
 the setting in the .pc file (with a harmless warning about redefinition).

 It's better to leave `-D_GLIBCXX_USE_CXX11_ABI=0` in the .pc file for now,
 because we're currently keeping the pre-built library at that ABI version.
 In the Tor Browser build, though, we're overriding it to `1`.
 Cf. https://github.com/keroserene/go-
 webrtc/commit/a1272c08ab1d5ca154c6794ddc5f73d2e576fe1b.

 I think it should work with either GCC or Clang. I think currently in the
 Tor Browser build, we're using GCC for linux and Clang for mac, at least
 if I'm interpreting [https://gitweb.torproject.org/builders/tor-browser-
 
build.git/tree/projects/webrtc/build?id=2b270ede9341f8ce496e811f7af9077e3eed9049#n81
 this] and [https://gitweb.torproject.org/builders/tor-browser-
 
build.git/tree/projects/webrtc/build?id=2b270ede9341f8ce496e811f7af9077e3eed9049#n118
 this] correctly.

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

Re: [tor-bugs] #28205 [Obfuscation/Snowflake]: linking against other libwebrtc binaries errors out on missing symbols

[Tor Bug Tracker & Wiki]

#28205: linking against other libwebrtc binaries errors out on missing symbols
---+---
 Reporter:  eighthave  |  Owner:  eighthave
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords:  android|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by eighthave):

 And confirmed your suspicion:
 {{{
 $ nm --demangle libwebrtc-linux-amd64-magic.a| grep CreateIceCandidate
  U
 webrtc::CreateIceCandidate(std::__cxx11::basic_string, std::allocator > const&, int,
 std::__cxx11::basic_string,
 std::allocator > const&, webrtc::SdpParseError*)
  T
 webrtc::CreateIceCandidate(std::__cxx11::basic_string, std::allocator > const&, int,
 std::__cxx11::basic_string,
 std::allocator > const&, webrtc::SdpParseError*)
 }}}

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

Re: [tor-bugs] #28205 [Obfuscation/Snowflake]: linking against other libwebrtc binaries errors out on missing symbols

[Tor Bug Tracker & Wiki]

#28205: linking against other libwebrtc binaries errors out on missing symbols
---+---
 Reporter:  eighthave  |  Owner:  eighthave
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Major  | Resolution:
 Keywords:  android|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by eighthave):

 Kind of ironic that I'm working on this, since I know neither Go nor C++.
 But I do know C, autotools, and even pkg-config a little bit.

 So I think this is starting to make sense to me.  The Android .pc file
 that I wrote already includes `  -D_GLIBCXX_USE_CXX11_ABI=0`, so I guess I
 should change that to 1 also?  Does this still need to also be set in
 `CGO_CXXFLAGS`?  Should this be building with gcc?  I think gomobile
 defaults to clang.

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

Re: [tor-bugs] #25890 [Core Tor/Nyx]: add instructions for running nyx safely to the FAQ

[Tor Bug Tracker & Wiki]

#25890: add instructions for running nyx safely to the FAQ
--+---
 Reporter:  arma  |  Owner:  atagar
 Type:  enhancement   | Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by wagon):

 > Disable cookie authentication in `torrc` (we don't need it), but enable
 password authentication in `torrc`. If you curious about the reasons, read
 my explanation in another comment.
 UPDATE: In principle, it may be better to use SafeCookie as I explained
 [[https://trac.torproject.org/projects/tor/ticket/28295#comment:7|here]].
 If Nyx has to have access to `torrc` file and Tor logs (to display their
 content), user used to run Nyx should be added to `debian-tor` group. If
 restricted functionality (only `ControlPort` is accessible) is sufficient,
 Nyx can be launched from user who is not member of `debian-tor` group.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #28349 [Metrics/Website]: Make "We're Hiring" more visible on Tor Metrics website

[Tor Bug Tracker & Wiki]

#28349: Make "We're Hiring" more visible on Tor Metrics website
-+--
 Reporter:  karsten  |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 I added a link to our metrics job person yesterday, but we should make it
 more visible.

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

Re: [tor-bugs] #27321 [Core Tor/Nyx]: incorrect bw calculation during initial startup

[Tor Bug Tracker & Wiki]

#27321: incorrect bw calculation during initial startup
--+---
 Reporter:  a_p   |  Owner:  atagar
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by wagon):

 > If all those datapoints are from before Nyx started then they came from
 the output of a `GETINFO bw-event-cache` command to `tor`.
 OK, good.

 Sometimes these jumps are not so high (I don't know what their existence
 depend on), sometimes they absent completely. I think it is a minor thing
 anyway, but if somebody will have its own observations in future I am
 ready to listen 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] #28332 [Core Tor/Nyx]: Nyx configurashion editor reproducibly crashes if custom ordering is set

[Tor Bug Tracker & Wiki]

#28332: Nyx configurashion editor reproducibly crashes if custom ordering is set
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:  duplicate
 Keywords:  config|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by atagar):

 > Then it cannot find Stem

 Gotcha. Personally I just clone a copy of stem into nyx's directory or add
 a symlink for wherever it's located. Here's what I usually do...

 {{{
 % git clone https://git.torproject.org/nyx.git
 % git clone https://git.torproject.org/stem.git

 % cd nyx
 % ln -s ../stem/stem stem
 }}}

 > I am not hurry with this. Please, sign it when you will have time.

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 As of 11/6/18 the master branches of Stem and Nyx reference the following
 commits...

 * Stem (git clone https://git.torproject.org/stem.git)

   atagar@morrigan:~/Desktop/stem$ git rev-parse origin/master
   c15c8a5af1f7a9a85a092b932f380b4823ebe86d

 * Nyx (git clone https://git.torproject.org/nyx.git)

   atagar@morrigan:~/Desktop/nyx$ git rev-parse origin/master
   d3dd23cec8cab7eea4969d0c462a2e1abfa5b19d

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQEcBAEBAgAGBQJb4eKPAAoJEIiEBMGH8waQ3lEH/iwkvkKS3MyOTm84Bz9HFQzW
 ZxEjQlKKgD4tW98Ig+B988AB95F712AT1cvAfedMMbPeJL7BhFnXvxJ47eLIig8O
 kit32erXhYEBbBRLLGPCdpNLzqdpSAZhkwS9azugUlGfSFRVUMqRNgZPMVnp9ABe
 3U2EZNtA0UyiDPa62OKx7JXLNmdh6Kgq2vkICcIhVfY+h7FZIrM9wH0+ZLtchQgB
 5Bj8YRh84ck5UXe5DiUJjxpo3a8Ivfk51/F9He14GnwufcFNC03IB9kbvW+2PeOb
 cFkhSY/4LlOeEwzJ5YgKJPteorLetIt2Lti0DFGrV2T9xzCK2LPd+vC8/namPso=
 =tXQm
 -END PGP SIGNATURE-

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

Re: [tor-bugs] #28332 [Core Tor/Nyx]: Nyx configurashion editor reproducibly crashes if custom ordering is set

[Tor Bug Tracker & Wiki]

#28332: Nyx configurashion editor reproducibly crashes if custom ordering is set
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:  duplicate
 Keywords:  config|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by wagon):

 > it wouldn't exploit root since `nyx` does not need to be installed to
 `/usr`
 Then it cannot find Stem:
 {{{
 $ pip3 list | grep stem
 stem (1.7.0-dev)
 $ ./run_nyx --help
 Traceback (most recent call last):
   File "./run_nyx", line 7, in 
 import nyx
   File "[/path/to]/nyx/nyx/__init__.py", line 54, in 
 import stem
 ImportError: No module named stem
 }}}

 > If a meanie snagged my trac password, exploited the Tor git repository
 (to circumvent the https), and MITM your connection you're completely
 right - someone could do something nasty. But this is both requires the
 exploitation of multiple core Tor systems (in which case honestly your
 system is the least of our worries)
 There is good security practice: sign your code. It is much simpler than
 thinking about possible ways of exploitation.

 > if you're still worried I can pgp sign this message later.
 I am not hurry with this. Please, sign it when you will have time.

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

Re: [tor-bugs] #28144 [Applications/Tor Browser]: Update projects/tor-browser for Android

[Tor Bug Tracker & Wiki]

#28144: Update projects/tor-browser for Android
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201811, TBA-a2   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sysrqb):

 Replying to [comment:9 sisbell]:
 > Replying to [comment:7 boklm]:
 > > Replying to [comment:5 gk]:
 > >
 > > >
 > > > For b) we usually have the bundling step (i.e. the tor-browser
 project). If that's not going to work (Is that the case? If so, why?) for
 Android (which would mean reopening the .apk we got in the firefox step
 and putting the extensions into place after building them if needed) we
 need to find a way doing that in the firefox build step and could do just
 the renaming in the tor-browser step.
 > > >
 > >
 > > However doing that in the firefox build means we need to rebuild
 firefox to update the extensions, so if that's possible, doing it in the
 `tor-browser` step would be better.
 > >
 > > It looks like .apk files are zip files, so I'm wondering if extracting
 them and adding the extensions in the right directory before rezipping the
 .apk file would work, or if there is something more needed.
 > To add assets, we can just use 'aapt add' command from the android SDK.
 We also need to make sure we resign the apk as part of a tor-browser step.
 We would do this with 'apksigner'.

 The app won't be signed within tor-browser-build, so that isn't a problem.
 We only must produce a valid unsigned-unaligned apk as the result.

 I agree adding the extensions in the tor-browser project (like we do for
 desktop) makes the most sense. We'll need to investigate what Mozilla do
 when a distribution is defined and replicate that in `build` - I haven't
 looked closely enough at this, so I don't know what is needed.

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

Re: [tor-bugs] #28300 [Core Tor/Stem]: Scrolling support for tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28300: Scrolling support for tor-prompt is needed
---+--
 Reporter:  wagon  |  Owner:  atagar
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:  Tor: 0.3.4.8
 Severity:  Normal | Resolution:  wontfix
 Keywords:  tor-prompt |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by atagar):

 > In tor-prompt double Tab key suggests possible completions for commands,
 but this doesn't work in Nyx interpreter. Can it be added to Nyx too? It
 is very convenient feature.

 Thanks wagon, glad you like it! Sadly autocompletion is a feature of
 readline so I can't add it to Nyx (similar to how I can't port scrolling
 to readline). In this case it's technically possible, but it would be
 quite a bit of work.

 > Should these commands be removed from interpreter's /help GETINFO
 listing?

 Thanks! I'll look into it. The GETINFO command list comes from tor itself
 so I'll see if it includes anything saying what commands are deprecated.
 If not then this might require a tor change.

 > [err] sandbox_getaddrinfo(): Bug: (Sandbox) failed to get address
 [hostname redacted]! (on Tor 0.3.4.9 )

 Please file a ticket with the 'Core Tor / Tor' component for this one. It
 sounds like simply calling 'GETINFO address' causes its sandboxing code to
 issue a bug warning. This is either uncovering a bug on their side or this
 log message should be downgraded (ie, not err runlevel or say it's a tor
 bug).

 > There are many commands with * at the end. Does it always mean that some
 value must be substituted instead of *?

 Yup. For more information on all the commands see
 https://gitweb.torproject.org/torspec.git/tree/control-spec.txt

 > In Nyx connections window the value published is printed as information
 about selected relay. What ControlPort command Nyx uses to get its value?

 Nyx gets the published attribute from the consensus ('GETINFO
 ns/id/' or 'GETINFO ns/name/').

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

Re: [tor-bugs] #17393 [Webpages/Website]: Make the various javascript on Tor sites be LibreJS-compatible?

[Tor Bug Tracker & Wiki]

#17393: Make the various javascript on Tor sites be LibreJS-compatible?
+--
 Reporter:  arma|  Owner:  traumschule
 Type:  enhancement | Status:  needs_review
 Priority:  Low |  Milestone:  WebsiteV3
Component:  Webpages/Website|Version:
 Severity:  Minor   | Resolution:
 Keywords:  defer-new-website, website-bug  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by traumschule):

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


Comment:

 Retested the functionality of LibreJS 7.18:

 Replying to comment:9:
 > LibreJS 7.16 recognizes the link to a [https://www.gnu.org/licenses
 /javascript-labels.html JavaScript Web Labels table]. It can be placed
 anywhere in the site, but not in comments
 > The result is that all JavaScript on the page is qualified
 > It seems that the content of the linked page does not change the result
 as it was tested with an empty page and with a table listing the scripts
 by name.
 This has been fixed with 7.18. Now it also correctly parses the table and
 recognizes when scripts are missing.

 > A license definition only at the head of the loaded script as described
 in [https://www.gnu.org/software/librejs/free-your-javascript.html 3.2.4
 Stylized comment] however is not recognized

 Also fixed.

 > Based on this i propose to place the link to the Web labels table in the
 footer to appear on all pages of our site.

 Seconding myself.

 I suggest we are done here.

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

Re: [tor-bugs] #17393 [Webpages/Website]: Make the various javascript on Tor sites be LibreJS-compatible?

[Tor Bug Tracker & Wiki]

#17393: Make the various javascript on Tor sites be LibreJS-compatible?
+--
 Reporter:  arma|  Owner:  traumschule
 Type:  enhancement | Status:
|  needs_revision
 Priority:  Low |  Milestone:  WebsiteV3
Component:  Webpages/Website|Version:
 Severity:  Minor   | Resolution:
 Keywords:  defer-new-website, website-bug  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  hiro|Sponsor:
+--
Changes (by traumschule):

 * Attachment "librejs7.18.png" removed.

 Retested the functionality of LibreJS 7.18: * Left: The license of
 {{{debian-os-selector.js}}} on the
 [https://github.com/torproject/webwml/pull/45 librejs branch] is
 recognized because of the js table  * Right: Default red LibreJS symbol on
 tpo's onion service  Replying to comment:9: > LibreJS 7.16 recognizes the
 link to a [https://www.gnu.org/licenses/javascript-labels.html JavaScript
 Web Labels table]. It can be placed anywhere in the site, but not in
 comments > The result is that all JavaScript on the page is qualified > It
 seems that the content of the linked page does not change the result as it
 was tested with an empty page and with a table listing the scripts by
 name. This has been fixed with 7.18. Now it also correctly parses the
 table and recognizes when scripts are missing.   > A license definition
 only at the head of the loaded script as described in
 [https://www.gnu.org/software/librejs/free-your-javascript.html 3.2.4
 Stylized comment] however is not recognized Also fixed.   > Based on this
 i propose to place the link to the Web labels table in the footer to
 appear on all pages of our site. Seconding myself.

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

Re: [tor-bugs] #17393 [Webpages/Website]: Make the various javascript on Tor sites be LibreJS-compatible?

[Tor Bug Tracker & Wiki]

#17393: Make the various javascript on Tor sites be LibreJS-compatible?
+--
 Reporter:  arma|  Owner:  traumschule
 Type:  enhancement | Status:
|  needs_revision
 Priority:  Low |  Milestone:  WebsiteV3
Component:  Webpages/Website|Version:
 Severity:  Minor   | Resolution:
 Keywords:  defer-new-website, website-bug  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  hiro|Sponsor:
+--
Changes (by traumschule):

 * Attachment "librejs7.18.2.png" added.

 Right: Default red LibreJS symbol on tpo's onion service  Left: The
 license of {{{debian-os-selector.js}}} is recognized because of the
 Javascibt Web Labels Table on the [librejs
 branch](https://github.com/torproject/webwml/pull/45)

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

Re: [tor-bugs] #17393 [Webpages/Website]: Make the various javascript on Tor sites be LibreJS-compatible?

[Tor Bug Tracker & Wiki]

#17393: Make the various javascript on Tor sites be LibreJS-compatible?
+--
 Reporter:  arma|  Owner:  traumschule
 Type:  enhancement | Status:
|  needs_revision
 Priority:  Low |  Milestone:  WebsiteV3
Component:  Webpages/Website|Version:
 Severity:  Minor   | Resolution:
 Keywords:  defer-new-website, website-bug  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  hiro|Sponsor:
+--
Changes (by traumschule):

 * Attachment "librejs7.18.png" added.

 Retested the functionality of LibreJS 7.18: * Left: The license of
 {{{debian-os-selector.js}}} on the
 [https://github.com/torproject/webwml/pull/45 librejs branch] is
 recognized because of the js table  * Right: Default red LibreJS symbol on
 tpo's onion service  Replying to comment:9: > LibreJS 7.16 recognizes the
 link to a [https://www.gnu.org/licenses/javascript-labels.html JavaScript
 Web Labels table]. It can be placed anywhere in the site, but not in
 comments > The result is that all JavaScript on the page is qualified > It
 seems that the content of the linked page does not change the result as it
 was tested with an empty page and with a table listing the scripts by
 name. This has been fixed with 7.18. Now it also correctly parses the
 table and recognizes when scripts are missing.   > A license definition
 only at the head of the loaded script as described in
 [https://www.gnu.org/software/librejs/free-your-javascript.html 3.2.4
 Stylized comment] however is not recognized Also fixed.   > Based on this
 i propose to place the link to the Web labels table in the footer to
 appear on all pages of our site. Seconding myself.

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

Re: [tor-bugs] #28298 [Core Tor/Tor]: Tor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative DataDirectory

[Tor Bug Tracker & Wiki]

#28298: Tor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative
DataDirectory
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression 033-backport  |  Actual Points:
  034-backport   |
Parent ID:   | Points:
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by ahf):

 * status:  needs_review => merge_ready


Comment:

 Patch looks good. Both the PR for the maint-0.3.3 and master branches
 seems to make Travis happy.

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

Re: [tor-bugs] #28300 [Core Tor/Stem]: Scrolling support for tor-prompt is needed

[Tor Bug Tracker & Wiki]

#28300: Scrolling support for tor-prompt is needed
---+--
 Reporter:  wagon  |  Owner:  atagar
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:  Tor: 0.3.4.8
 Severity:  Normal | Resolution:  wontfix
 Keywords:  tor-prompt |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by wagon):

 There is another question related to `tor-prompt` vs Nyx control
 interpreter. In `tor-prompt` double Tab key suggests possible completions
 for commands, but this doesn't work in Nyx interpreter. Can it be added to
 Nyx too? It is very convenient feature.

 Then, as concerns commands themselves, Nyx lists some outdated variants.
 For example, when I use `GETINFO status/version/num-concurring` and
 `GETINFO status/version/num-versioning` Tor writes to its log file:

 {{{
 [warn] status/version/num-concurring is deprecated; it no longer gives
 useful information
 [warn] status/version/num-versioning is deprecated; it no longer gives
 useful information
 }}}

 Should these commands be removed from interpreter's `/help GETINFO`
 listing?

 If `Sandbox 1` is set in `torrc`, during each start  Nyx does something
 inappropriate to Tor forcing it to complain in log:

 {{{
 [err] sandbox_getaddrinfo(): Bug: (Sandbox) failed to get address
 [hostname redacted]! (on Tor 0.3.4.9 )
 }}}

 Is it OK? Should it be fixed?


 There are many commands with `*` at the end. Does it always mean that some
 value must be substituted instead of `*`? For example, I didn't find any
 valid substitution for `GETINFO config/*` (`config/defaults` and
 `config/names` are separate and documented commands).

 In Nyx connections window the value `published` is printed as information
 about selected relay. What `ControlPort` command Nyx uses to get its
 value? `/var/lib/tor/cached-microdescs` file?

 Inverse situation is with Tor `version`: it is shown in `/var/lib/tor
 /cached-microdesc-consensus` but Nyx does not show it in information about
 relays (connections window). Can relay's Tor version be learned from
 `ControlPort` too?

 Yes, I could add [[https://nyx.torproject.org/#missing_relay_details|extra
 options]] to get more information accessible through Nyx and
 `ControlPort`, but my question is mainly about default Tor configuration.

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

Re: [tor-bugs] #28144 [Applications/Tor Browser]: Update projects/tor-browser for Android

[Tor Bug Tracker & Wiki]

#28144: Update projects/tor-browser for Android
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_information
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, |  Actual Points:
  TorBrowserTeam201811, TBA-a2   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 Replying to [comment:7 boklm]:


 > Replying to [comment:5 gk]:
 >
 > >
 > > For b) we usually have the bundling step (i.e. the tor-browser
 project). If that's not going to work (Is that the case? If so, why?) for
 Android (which would mean reopening the .apk we got in the firefox step
 and putting the extensions into place after building them if needed) we
 need to find a way doing that in the firefox build step and could do just
 the renaming in the tor-browser step.
 > >
 >
 > However doing that in the firefox build means we need to rebuild firefox
 to update the extensions, so if that's possible, doing it in the `tor-
 browser` step would be better.
 >
 > It looks like .apk files are zip files, so I'm wondering if extracting
 them and adding the extensions in the right directory before rezipping the
 .apk file would work, or if there is something more needed.
 >> To add assets, we can just use 'aapt add' command from the android SDK.
 We also need to make sure we resign the apk as part of a tor-browser step.
 We would do this with 'apksigner'.

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

Re: [tor-bugs] #27836 [Internal Services/Service - trac]: RSS feed https authentication

[Tor Bug Tracker & Wiki]

#27836: RSS feed https authentication
--+-
 Reporter:  atagar|  Owner:  qbi
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Internal Services/Service - trac  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by atagar):

 Ah! Thanks traumschule. I could log in if this was my own script, but
 since this is r2e it's gonna require me to adjust their codebase a bit.

 Can we drop the login requirement on a per-page basis? The rss feed is
 read-only and as such there's no risk of spam. It sounds like this is
 simply collateral damage from spam elsewhere causing a site-wide
 restriction.

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

Re: [tor-bugs] #28298 [Core Tor/Tor]: Tor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative DataDirectory

[Tor Bug Tracker & Wiki]

#28298: Tor 0.3.3.1-alpha resumes allowing RunAsDaemon=1 with relative
DataDirectory
-+-
 Reporter:  arma |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  regression 033-backport  |  Actual Points:
  034-backport   |
Parent ID:   | Points:
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by nickm):

 * keywords:  regression => regression 033-backport 034-backport
 * milestone:   => Tor: 0.3.5.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] #28184 [Core Tor/Tor]: Reload is additive with regards to new v3 HS client authorizations but it won't subtract deleted ones

[Tor Bug Tracker & Wiki]

#28184: Reload is additive with regards to new v3 HS client authorizations but 
it
won't subtract deleted ones
--+
 Reporter:  jchevali  |  Owner:  haxxpop
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.5.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.2-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:  asn   |Sponsor:
--+
Changes (by nickm):

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


Comment:

 (This will need a changes file. I assume it's for 0.3.5, since that's
 where client auth comes from?)

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

Re: [tor-bugs] #27443 [Applications/Tor Browser]: Update Firefox RBM config and build for Android

[Tor Bug Tracker & Wiki]

#27443: Update Firefox RBM config and build for Android
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, TBA-a2, |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by sisbell):

 * 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] #27443 [Applications/Tor Browser]: Update Firefox RBM config and build for Android

[Tor Bug Tracker & Wiki]

#27443: Update Firefox RBM config and build for Android
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, tbb-mobile, TBA-a2, |  Actual Points:
  TorBrowserTeam201811   |
Parent ID:  #26693   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by sisbell):

 Changes (android-1106)

 * Fixed how-to-create-gradle-dependencies-list.txt as specified in
 https://trac.torproject.org/projects/tor/ticket/27443#comment:38

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

Re: [tor-bugs] #28348 [Core Tor/Tor]: Setting DisableNetwork won't disable NEED_NET events

[Tor Bug Tracker & Wiki]

#28348: Setting DisableNetwork won't disable NEED_NET events
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  034-backport  |  Actual Points:
Parent ID:| Points:  0
 Reviewer:  dgoulet   |Sponsor:  Sponsor8
--+
Changes (by nickm):

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


Comment:

 Merged to 0.3.5; marking for 0.3.4 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] #28344 [Core Tor/Tor]: Should we log \r\n on Windows?

[Tor Bug Tracker & Wiki]

#28344: Should we log \r\n on Windows?
+--
 Reporter:  teor|  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:  Tor:
|  0.3.6.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  036-roadmap-proposed, fast-fix  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by nickm):

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


Comment:

 I think the "binary v text" flag here might also be what we want?  And we
 might want different rules for stream-logs and file-logs?

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

Re: [tor-bugs] #28193 [Core Tor/Tor]: Compile-time assertion

[Tor Bug Tracker & Wiki]

#28193: Compile-time assertion
--+
 Reporter:  riastradh |  Owner:  (none)
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.6.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  nickm |Sponsor:
--+
Changes (by nickm):

 * status:  needs_revision => merge_ready
 * milestone:  Tor: unspecified => Tor: 0.3.6.x-final


Comment:

 okay, sounds good to me! I'll merge it later this week -- probably today.

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