Re: [tor-bugs] #25123 [- Select a component]: Snowflake not work

[Tor Bug Tracker & Wiki]

#25123: Snowflake not work
--+---
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks):

 I do not know English.Use google translate.
 Problem.My tor browser alpha-version can not establish a connection with
 snowflake.My OS Zorin 32 bit https://zorinos.com/

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

Re: [tor-bugs] #25013 [Applications/Tor Browser]: Move TorButton code to the tor browser repository

[Tor Bug Tracker & Wiki]

#25013: Move TorButton code to the tor browser repository
--+--
 Reporter:  igt0  |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201802R |  Actual Points:
Parent ID:  #24855| Points:
 Reviewer:  gk, sysrqb, mcs,  |Sponsor:
--+--
Changes (by gk):

 * keywords:  TorBrowserTeam201802 => TorBrowserTeam201802R
 * 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] #25123 [- Select a component]: Snowflake not work

[Tor Bug Tracker & Wiki]

#25123: Snowflake not work
--+---
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  High  |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by Dbryrtfbcbhgf):

 * status:  new => needs_information


Comment:

 Please provide a more detailed description of your problem.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25123 [- Select a component]: Snowflake not work

[Tor Bug Tracker & Wiki]

#25123: Snowflake not work
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+


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

Re: [tor-bugs] #25087 [Obfuscation/Snowflake]: Snowflake broken if no libatomic on host (e.g. Lubuntu 17 64 bits)

[Tor Bug Tracker & Wiki]

#25087: Snowflake broken if no libatomic on host (e.g. Lubuntu 17 64 bits)
---+---
 Reporter:  cypherpunks|  Owner:  tbb-team
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by yawning):

 Replying to [comment:11 arma]:
 > Speaking of atomic, there's an intriguingly related ChangeLog entry to
 Tor itself in 0.3.3.1-alpha:
 > {{{
 > - Use stdatomic.h where available, rather than mutexes, to implement
 >   atomic_counter_t. Closes ticket 23953.
 > }}}
 > But on first glance it looks like that's headers, not the library. But,
 does that mean that if Tor Browser builds Tor on a system with libatomic
 headers, then Tor Browser's Tor will expect a libatomic it can use?

 "Depends".  libatomic is what GCC will fall back to if does not have
 native code generation capability for an atomic operation on a given
 target.  If Tor Browser is targeting something where GCC ends up doing
 that, then yes, Tor Browser's Tor will also expect a working libatomic.

 > as we wait maybe everybody will get libatomic.

 In an ideal world, GCC will support the relevant code generation for all
 the targets that the bundle is shipped for, and no one will need
 libatomic.

 After thinking about this for a bit, I'm of the opinion that as long as
 the GCC used to build Tor Browser generates code that links to it, Tor
 Browser should bundle it, much like how libstdc++ is bundled.

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

Re: [tor-bugs] #24931 [Applications/rbm]: Build log grows with build_log_append set to 0

[Tor Bug Tracker & Wiki]

#24931: Build log grows with build_log_append set to 0
---+
 Reporter:  gk |  Owner:  boklm
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/rbm   |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  TorBrowserTeam201801R  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by gk):

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


Comment:

 Thanks, merged to `master` (commit
 7494edc6d2556c511c213823a6549410ba75f73b).

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

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

[Tor Bug Tracker & Wiki]

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

 * keywords:  TorBrowserTeam201801 => TorBrowserTeam201802


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

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

[Tor Bug Tracker & Wiki]

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

 * status:  new => needs_information


Comment:

 ma1 could make an exception for about:addons. Allowing [System+Principal]
 is too wide and this could allow NSA to attack tbb.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by cypherpunks):

 So you guys just rip off [system] from original NoScript, or Noscript ma1
 is lying?

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

Re: [tor-bugs] #25111 [Applications/Tor Browser]: Don't compile Yasm on our own anymore for Windows Tor Browser

[Tor Bug Tracker & Wiki]

#25111: Don't compile Yasm on our own anymore for Windows Tor Browser
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201801R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by gk):

 Looks good, thanks. Merged to `master` (commit
 57f544ca8590b00b609b62132aeb2ae7abfa7779).

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

Re: [tor-bugs] #25111 [Applications/Tor Browser]: Don't compile Yasm on our own anymore for Windows Tor Browser

[Tor Bug Tracker & Wiki]

#25111: Don't compile Yasm on our own anymore for Windows Tor Browser
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  tbb-rbm, TorBrowserTeam201801R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * status:  needs_review => 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] #25087 [Obfuscation/Snowflake]: Snowflake broken if no libatomic on host (e.g. Lubuntu 17 64 bits)

[Tor Bug Tracker & Wiki]

#25087: Snowflake broken if no libatomic on host (e.g. Lubuntu 17 64 bits)
---+---
 Reporter:  cypherpunks|  Owner:  tbb-team
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by arma):

 Speaking of atomic, there's an intriguingly related ChangeLog entry to Tor
 itself in 0.3.3.1-alpha:
 {{{
 - Use stdatomic.h where available, rather than mutexes, to implement
   atomic_counter_t. Closes ticket 23953.
 }}}
 But on first glance it looks like that's headers, not the library. But,
 does that mean that if Tor Browser builds Tor on a system with libatomic
 headers, then Tor Browser's Tor will expect a libatomic it can use?

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

Re: [tor-bugs] #25087 [Obfuscation/Snowflake]: Snowflake broken if no libatomic on host (e.g. Lubuntu 17 64 bits)

[Tor Bug Tracker & Wiki]

#25087: Snowflake broken if no libatomic on host (e.g. Lubuntu 17 64 bits)
---+---
 Reporter:  cypherpunks|  Owner:  tbb-team
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by arma):

 It sounds like we should either bundle libatomic, which bumps up the
 bundle size for everyone, or do some sort of "is there libatomic? if not
 tell the user" test on startup.

 I'd be tempted to suggest the latter at least to start, since it should be
 easier, and as we wait maybe everybody will get libatomic, and while
 snowflake is still in alpha it should let us get a sense of how many
 people have this 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] #25087 [Obfuscation/Snowflake]: Snowflake broken if no libatomic on host (e.g. Lubuntu 17 64 bits) (was: Snowflake doesn't work on a fresh clean install of Lubuntu 17 64 bits and a fres

[Tor Bug Tracker & Wiki]

#25087: Snowflake broken if no libatomic on host (e.g. Lubuntu 17 64 bits)
---+---
 Reporter:  cypherpunks|  Owner:  tbb-team
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by arma):

 Retitled the ticket based on new info

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

Re: [tor-bugs] #22794 [Applications/Tor Browser]: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.

[Tor Bug Tracker & Wiki]

#22794: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.
-+-
 Reporter:  yawning  |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, tbb-sandboxing,|  Actual Points:
  TorBrowserTeam201802R  |
Parent ID:  #20775   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 macOS legacy sandbox support has:
 {{{
  #include 
 ...
  kSBXProfileNoInternet  TCP/IP networking is prohibited.
 DEPRECATED.

  kSBXProfileNoNetwork   All sockets-based networking is
 pro-
 hibited.  DEPRECATED.
 }}}

 sandbox-exec is also legacy, but it works from the command line:
 https://paolozaino.wordpress.com/2015/10/20/maximum-security-and-privacy-
 using-mac-os-sandbox-and-tor-browser-bundle/

 Unfortunately, the replacement API doesn't seem to distinguish between
 TCP/IP and unix sockets. We'd need to do some testing.
 {{{
 com.apple.security.network.client

 Network socket for connecting to other machines

 com.apple.security.network.server

 Network socket for listening for incoming connections initiated by other
 machines
 }}}
 
https://developer.apple.com/library/content/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/EnablingAppSandbox.html#//apple_ref/doc/uid/TP40011195-CH4-SW9

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

Re: [tor-bugs] #22794 [Applications/Tor Browser]: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.

[Tor Bug Tracker & Wiki]

#22794: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.
-+-
 Reporter:  yawning  |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, tbb-sandboxing,|  Actual Points:
  TorBrowserTeam201802R  |
Parent ID:  #20775   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by yawning):

 Oh hey, I was right.

 Regarding the patch:
  * I'm not sure if checking that the URI scheme is file is the correct
 long term fix (eg: #20337), but that bridge can be burnt when someone gets
 there.
  * Should this apply to OSX as well?  I do not know how OSX's process
 sandboxing stuff works, or what options it has for limiting what a process
 can do.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by yawning):

 Replying to [comment:7 cypherpunks]:
 > OK; did what yawning suggested and this is the output,
 >
 > {{{
 > ./snowflake-client: error while loading shared libraries:
 libatomic.so.1: cannot open shared object file: No such file or directory
 > }}}
 >
 > This is the last time I can have access to this system so please forgive
 me if I can't provide further debugging.

 Hmm, that's part of gcc's runtime.  I wonder how reasonable it is to
 expect people to have a copy of that.

 https://packages.ubuntu.com/artful/libatomic1 for Ubuntu and derivatives.

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

Re: [tor-bugs] #22794 [Applications/Tor Browser]: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.

[Tor Bug Tracker & Wiki]

#22794: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.
-+-
 Reporter:  yawning  |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, tbb-sandboxing,|  Actual Points:
  TorBrowserTeam201802R  |
Parent ID:  #20775   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pospeselr):

 * keywords:  tbb-security, tbb-sandboxing, TorBrowserTeam201801 => tbb-
 security, tbb-sandboxing, TorBrowserTeam201802R
 * status:  assigned => needs_review


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

Re: [tor-bugs] #22794 [Applications/Tor Browser]: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.

[Tor Bug Tracker & Wiki]

#22794: Don't open AF_INET/AF_INET6 sockets when AF_LOCAL is configured.
-+-
 Reporter:  yawning  |  Owner:
 |  pospeselr
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-security, tbb-sandboxing,|  Actual Points:
  TorBrowserTeam201801   |
Parent ID:  #20775   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by pospeselr):

 * Attachment "0001-Bug-22794-Don-t-open-AF_INET-AF_INET6-sockets-
 when-A.patch" added.


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

Re: [tor-bugs] #25013 [Applications/Tor Browser]: Move TorButton code to the tor browser repository

[Tor Bug Tracker & Wiki]

#25013: Move TorButton code to the tor browser repository
--+
 Reporter:  igt0  |  Owner:  tbb-team
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201802  |  Actual Points:
Parent ID:  #24855| Points:
 Reviewer:  gk, sysrqb, mcs,  |Sponsor:
--+

Comment (by igt0):

 Update commit messages:

 Tor Browser Build:
   ** Bug 25013: Remove torbutton from the tor browser build **
   https://github.com/igortoliveira/tor-browser-
 build/commit/9fd151714fe5d992d9cce12e3bb59259eea154d2

 Tor Browser:
   ** Bug 25013: Move Tor Button source code to the browser/extensions
 directory **
   https://github.com/igortoliveira/tor-
 browser/commit/910da3b9edb7068a1084443e75653487997bd978

   ** Bug 25013: Integrate Tor Button in the browser build system **
   https://github.com/igortoliveira/tor-
 browser/commit/e931e6ae94c5a884b6f2c8ccb96568952bcd

   **  Bug 25013: Use anonymous function to keep the torbutton.js and
 preferences.js scope limited to the parent function **
   https://github.com/igortoliveira/tor-
 browser/commit/16c360da0b7edc0218fdeac7e5300f83e9bbc0a6

   **  Bug 25013: Initialize startup.homepage in the startup-observer
 component **
   https://github.com/igortoliveira/tor-
 browser/commit/a28341162bf034299f4b060098e62cf515716e37

 Replying to [comment:10 gk]:
 > Oh, and please for the browser patches a "Bug 25013:" in front 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] #25121 [Core Tor/DirAuth]: dir auths should not recommend EOL releases 0.3.0.13, 0.3.0.14

[Tor Bug Tracker & Wiki]

#25121: dir auths should not recommend EOL releases 0.3.0.13, 0.3.0.14
--+-
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by cypherpunks):

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


Comment:

 that was fast, 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] #25087 [Obfuscation/Snowflake]: Snowflake doesn't work on a fresh clean install of Lubuntu 17 64 bits and a fresh clean install of TB 8.0a1

[Tor Bug Tracker & Wiki]

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

Comment (by cypherpunks):

 OK; did what yawning suggested and this is the output,

 {{{
 ./snowflake-client: error while loading shared libraries: libatomic.so.1:
 cannot open shared object file: No such file or directory
 }}}

 This is the last time I can have access to this system so please forgive
 me if I can't provide further debugging.

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

Re: [tor-bugs] #24700 [Core Tor/Tor]: sched: With KIST, a channel can be added more than once in the pending list

[Tor Bug Tracker & Wiki]

#24700: sched: With KIST, a channel can be added more than once in the pending 
list
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.2.1-alpha
 Severity:  Normal | Resolution:  fixed
 Keywords:  tor-sched, kist, 032-backport  |  Actual Points:
Parent ID:  #23993 | Points:
 Reviewer:  nickm  |Sponsor:
---+---
Changes (by nickm):

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


Comment:

 I've merged those to maint-0.3.2 and master.  Let's test it hard!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25122 [Core Tor/Tor]: geoip: Hook the client geoip cache into the OOM handler

[Tor Bug Tracker & Wiki]

#25122: geoip: Hook the client geoip cache into the OOM handler
--+-
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-relay, tor-oom, tor-dos
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 The geoip cache can possibly grow quite a bit so it would be wise to make
 our OOM aware of it.

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

Re: [tor-bugs] #24700 [Core Tor/Tor]: sched: With KIST, a channel can be added more than once in the pending list

[Tor Bug Tracker & Wiki]

#24700: sched: With KIST, a channel can be added more than once in the pending 
list
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.2.1-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-sched, kist, 032-backport  |  Actual Points:
Parent ID:  #23993 | Points:
 Reviewer:  nickm  |Sponsor:
---+---
Changes (by dgoulet):

 * status:  needs_revision => needs_review


Comment:

 Ok, the 032 branch has the fixes with extra checks from Nickm and also
 added checks on my part.

 The 033 branch is the 032 branch merged into master + one commit for unit
 tests.

 Branches: `bug24700_032_01` and `bug24700_033_01`

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

[tor-bugs] #25121 [Core Tor/DirAuth]: dir auths should not recommend EOL releases 0.3.0.13, 0.3.0.14

[Tor Bug Tracker & Wiki]

#25121: dir auths should not recommend EOL releases 0.3.0.13, 0.3.0.14
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/DirAuth  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Lets remove 0.3.0.13, 0.3.0.14 from
 https://consensus-health.torproject.org/#recommendedversions
 they reached eol:
 
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases

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

Re: [tor-bugs] #25013 [Applications/Tor Browser]: Move TorButton code to the tor browser repository

[Tor Bug Tracker & Wiki]

#25013: Move TorButton code to the tor browser repository
--+
 Reporter:  igt0  |  Owner:  tbb-team
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201802  |  Actual Points:
Parent ID:  #24855| Points:
 Reviewer:  gk, sysrqb, mcs,  |Sponsor:
--+

Comment (by gk):

 Replying to [comment:9 gk]:
 > Okay, I just compiled bundles with all the patches.
 >
 > One thing for the `tor-browser-build` one: Could you add the bug number
 in front of your commit message like "Bug 25013:"?
 >
 > For the browser patches:
 >
 > 1) I don't see the Torbutton icon on the toolbar button.
 > 2) The arrow warning me that my version out-of-date is not visible
 either.

 Those two might actually not be your fault. It turns out that the `patch`
 does not like the `git` binary diffs are seems to ignore the images in the
 Linux case and breaks the Windows builds. Let me try to test your patches
 differently tomorrow.

 > That's on a 64bit Linux box.

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

Re: [tor-bugs] #24984 [Applications/TorBirdy]: Torbirdy changes SMTP security setting from STARTTLS to SSL/TLS

[Tor Bug Tracker & Wiki]

#24984: Torbirdy changes SMTP security setting from STARTTLS to SSL/TLS
---+-
 Reporter:  markr  |  Owner:  sukhbir
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/TorBirdy  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by sukhbir):

 Yes, that's expected behaviour because on re-enabling TorBirdy, it sets
 secure defaults for all existing mail servers in case they have been
 configured incorrectly. While I agree that we can be "smart" about it, for
 now it just upgrades all settings to the secure defaults, which in this
 case is SSL/TLS. Does your server not support SSL/TLS? Using that is
 probably the easiest (and perhaps the only for now) solution to this
 problem.

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

Re: [tor-bugs] #25120 [Core Tor/Tor]: getrandom() syscall failure warning should be a notice and worded better

[Tor Bug Tracker & Wiki]

#25120: getrandom() syscall failure warning should be a notice and worded better
--+
 Reporter:  catalyst  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ahf):

 * status:  new => needs_review


Comment:

 Wording and log-level patches in
 https://oniongit.eu/ahf/tor/merge_requests/5

 These patches do not have the mechanism needed to check if `/dev/urandom`
 is safe.

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

Re: [tor-bugs] #25070 [Core Tor/Tor]: protover_get_supported_protocols() should include Link=5 as of 0.3.1.1-alpha

[Tor Bug Tracker & Wiki]

#25070: protover_get_supported_protocols() should include Link=5 as of
0.3.1.1-alpha
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  protover, rust, 031-backport,|  Actual Points:  0.3
  032-backport   |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 lgtm; Merged those to master and maint-0.3.1 respectively.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25120 [Core Tor/Tor]: getrandom() syscall failure warning should be a notice and worded better

[Tor Bug Tracker & Wiki]

#25120: getrandom() syscall failure warning should be a notice and worded better
--+
 Reporter:  catalyst  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 The logging improvement for error handling of the `getrandom()` syscall in
 #24500 could be further improved:

 * The log level should possibly be NOTICE rather than WARN.
 * The log message should mention that tor will fall back to alternative
 sources of randomness.
 * Maybe we want to mention header/kernel version mismatches as a specific
 common reason for this issue.

 Yes, some of the fallbacks are somewhat dangerous, like `/dev/urandom`
 might not be seeded yet. etc,.

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

Re: [tor-bugs] #23814 [Core Tor/Tor]: Remove non-exponential backoff directory download implementation

[Tor Bug Tracker & Wiki]

#23814: Remove non-exponential backoff directory download implementation
-+
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-31  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+

Comment (by teor):

 Is this going in 0.3.4?
 If it's not urgent, I'd like to review it. I should have time around the
 middle of next 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] #23814 [Core Tor/Tor]: Remove non-exponential backoff directory download implementation

[Tor Bug Tracker & Wiki]

#23814: Remove non-exponential backoff directory download implementation
-+
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:  merge_ready
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  review-group-31  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  asn  |Sponsor:
-+
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 Changes look good to me.

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

Re: [tor-bugs] #24658 [Core Tor/Tor]: Split/refactor crypto.h into smaller separate modules

[Tor Bug Tracker & Wiki]

#24658: Split/refactor crypto.h into smaller separate modules
--+
 Reporter:  isis  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-crypto, refactor  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+
Changes (by nickm):

 * keywords:  tor-crypto, refactor, review-group-29, review-group-31 => tor-
 crypto, refactor
 * status:  needs_review => new


Comment:

 squashed and merged; 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] #25105 [Core Tor/Tor]: Look at PRT_HSREND, not PRT_HSDIR, for supports_v3_rendezvous_point

[Tor Bug Tracker & Wiki]

#25105: Look at PRT_HSREND, not PRT_HSDIR, for supports_v3_rendezvous_point
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #24658 [Core Tor/Tor]: Split/refactor crypto.h into smaller separate modules

[Tor Bug Tracker & Wiki]

#24658: Split/refactor crypto.h into smaller separate modules
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-crypto, refactor, review-|  Actual Points:
  group-29, review-group-31  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-

Comment (by ffmancera):

 Seems fine to me, I agree the second approach looks better than the first
 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] #18918 [Core Tor/Tor]: Clarify directory and ORPort checking functions

[Tor Bug Tracker & Wiki]

#18918: Clarify directory and ORPort checking functions
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.8.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  easy, doc, code, refactor,   |  Actual Points:
  technical-debt, tor-relay, review-group-31 |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Only one thing I'm seeing here: the log message in
 `router_should_be_directory_server()` will sometimes refer to
 "DirDirectory Service support".

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

Re: [tor-bugs] #25013 [Applications/Tor Browser]: Move TorButton code to the tor browser repository

[Tor Bug Tracker & Wiki]

#25013: Move TorButton code to the tor browser repository
--+
 Reporter:  igt0  |  Owner:  tbb-team
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201802  |  Actual Points:
Parent ID:  #24855| Points:
 Reviewer:  gk, sysrqb, mcs,  |Sponsor:
--+

Comment (by gk):

 Oh, and please for the browser patches a "Bug 25013:" in front 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] #25013 [Applications/Tor Browser]: Move TorButton code to the tor browser repository

[Tor Bug Tracker & Wiki]

#25013: Move TorButton code to the tor browser repository
--+
 Reporter:  igt0  |  Owner:  tbb-team
 Type:  defect| Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201802  |  Actual Points:
Parent ID:  #24855| Points:
 Reviewer:  gk, sysrqb, mcs,  |Sponsor:
--+
Changes (by gk):

 * status:  needs_review => needs_revision
 * keywords:  TorBrowserTeam201801R => TorBrowserTeam201802


Comment:

 Okay, I just compiled bundles with all the patches.

 One thing for the `tor-browser-build` one: Could you add the bug number in
 front of your commit message like "Bug 25013:"?

 For the browser patches:

 1) I don't see the Torbutton icon on the toolbar button.
 2) The arrow warning me that my version out-of-date is not visible either.

 That's on a 64bit Linux box.

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

Re: [tor-bugs] #24658 [Core Tor/Tor]: Split/refactor crypto.h into smaller separate modules

[Tor Bug Tracker & Wiki]

#24658: Split/refactor crypto.h into smaller separate modules
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-crypto, refactor, review-|  Actual Points:
  group-29, review-group-31  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor8-can
-+-

Comment (by nickm):

 hm.  I like all of this except for the part that makes the contents of
 crypto_pk_t public.  Generally it's better to keep structure contents like
 this opaque whenever we can.

 Two options here would be: moving the crypto_pk_digest functions into
 crypto_rsa, or making them use crypto_pk_asn1_encode() instead.  I tried
 the latter approach in a squash commit I made on top of `bug24658-rsa` in
 my public branch of the same name.  Does it look ok to you?

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

Re: [tor-bugs] #25035 [Metrics/Ideas]: Create a mailing list for metrics-specific Nagios alerts

[Tor Bug Tracker & Wiki]

#25035: Create a mailing list for metrics-specific Nagios alerts
---+--
 Reporter:  karsten|  Owner:  karsten
 Type:  enhancement| Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Metrics/Ideas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 There, I just created #25119 to get this list created. Once we have it,
 I'll configure it and make sure that future notifications go there.

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

[tor-bugs] #25119 [Internal Services/Tor Sysadmin Team]: Please create new mailing list metrics-alerts@

[Tor Bug Tracker & Wiki]

#25119: Please create new mailing list metrics-alerts@
-+-
 Reporter:  karsten  |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Please create the following new mailing list:

  - List name: metrics-alerts@
  - Email addresses of list maintainers: karsten@tp.o, iwakeh@tp.o
  - Description: Notification list for Tor Metrics service-related alerts

 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] #24700 [Core Tor/Tor]: sched: With KIST, a channel can be added more than once in the pending list

[Tor Bug Tracker & Wiki]

#24700: sched: With KIST, a channel can be added more than once in the pending 
list
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  defect | Status:
   |  needs_revision
 Priority:  High   |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.2.1-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-sched, kist, 032-backport  |  Actual Points:
Parent ID:  #23993 | Points:
 Reviewer:  nickm  |Sponsor:
---+---
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 I'm taking this one. I'll pull nickm's changes and unit tests that we
 don't add twice the same channel in the pqueue.

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

Re: [tor-bugs] #24975 [Core Tor/Tor]: sched: scheduler_notify_networkstatus_changed() calls select_scheduler() without the new consensus

[Tor Bug Tracker & Wiki]

#24975: sched: scheduler_notify_networkstatus_changed() calls select_scheduler()
without the new consensus
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  032-backport, tor-sched  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  armadev  |Sponsor:
-+
Changes (by dgoulet):

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


Comment:

 Replying to [comment:9 nickm]:
 > I've merged to 0.3.2 and forward (on the theory that having only one
 version of this to maintain will make us happier).  I put the
 dos_consensus_has_changed() call in notify_before but please let's change
 it as appropriate?
 >
 > Leaving this open till somebody confirms the dos_consensus_has_changed()
 issue.

 Yes I do confirm that it is properly placed. Using the new consensus it
 was needs to be done so good!

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

Re: [tor-bugs] #24469 [Core Tor/Tor]: Cannibalizing a circuit should check that first hop is in our guard state

[Tor Bug Tracker & Wiki]

#24469: Cannibalizing a circuit should check that first hop is in our guard 
state
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-circuit   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Replying to [comment:4 nickm]:
 > lgtm; merging.  Maybe open a new ticket about improving cannibalization
 tests?

 Yes! Done #25118

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25118 [Core Tor/Tor]: We need circuit launch and cannibalization unit tests

[Tor Bug Tracker & Wiki]

#25118: We need circuit launch and cannibalization unit tests
--+---
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-circuit, tor-test
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 In particular, these functions `circuit_launch_by_extend_info()` and
 `circuit_find_to_cannibalize()` really needs unit tests!

 They do so much and they are so core that we need to assess what they are
 doing is ok. See #24469 for an example of what it should have done.

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

Re: [tor-bugs] #24700 [Core Tor/Tor]: sched: With KIST, a channel can be added more than once in the pending list

[Tor Bug Tracker & Wiki]

#24700: sched: With KIST, a channel can be added more than once in the pending 
list
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.2.1-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-sched, kist, 032-backport  |  Actual Points:
Parent ID:  #23993 | Points:
 Reviewer:  nickm  |Sponsor:
---+---

Comment (by nickm):

 I've made an updated version of your branch as `bug24700_032_01` in my
 public repository.

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

Re: [tor-bugs] #25097 [Core Tor/Tor]: Remove commented functions in crypto module

[Tor Bug Tracker & Wiki]

#25097: Remove commented functions in crypto module
--+
 Reporter:  ffmancera |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:  implemented
 Keywords:  easy, intro   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 merged to master; 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] #25097 [Core Tor/Tor]: Remove commented functions in crypto module

[Tor Bug Tracker & Wiki]

#25097: Remove commented functions in crypto module
--+
 Reporter:  ffmancera |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:  easy, intro   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by ffmancera):

 * status:  new => needs_review


Comment:

 Done, check my github [https://github.com/ffmancera/tor-1/tree/bug25097
 branch bug25097.]

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

Re: [tor-bugs] #24700 [Core Tor/Tor]: sched: With KIST, a channel can be added more than once in the pending list

[Tor Bug Tracker & Wiki]

#24700: sched: With KIST, a channel can be added more than once in the pending 
list
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.2.1-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-sched, kist, 032-backport  |  Actual Points:
Parent ID:  #23993 | Points:
 Reviewer:  nickm  |Sponsor:
---+---

Comment (by nickm):

 fwiw, my patch is wrong: it should say != not ==.

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

[tor-bugs] #25117 [Core Tor/Tor]: Resolve TROVE-2018-002

[Tor Bug Tracker & Wiki]

#25117: Resolve TROVE-2018-002
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+


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

[tor-bugs] #25116 [Core Tor/Tor]: hs: circuit_log_ancient_one_hop_circuits() should probably not log single onion service rendezvous circuit

[Tor Bug Tracker & Wiki]

#25116: hs: circuit_log_ancient_one_hop_circuits() should probably not log 
single
onion service rendezvous circuit
--+
 Reporter:  dgoulet   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  tor-hs, sos, easy
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Assume an email server where clients often keep a connection open and
 regularly exchange traffic on them.

 Making that email server an .onion, RP circuits will stay open for a while
 and more than 1800 seconds which is the cutoff of
 `circuit_log_ancient_one_hop_circuits()` to log single hop circuits.

 I think we want to ignore to log anything service related in there. Some
 v3 services have started seeing that heartbeat more and more in the last
 days.

 Related: #8387

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

Re: [tor-bugs] #25100 [Metrics/CollecTor]: Make CollecTor's webstats module use less RAM and wall time (was: Make CollecTor's webstats module use less RAM and CPU time)

[Tor Bug Tracker & Wiki]

#25100: Make CollecTor's webstats module use less RAM and wall time
---+
 Reporter:  karsten|  Owner:  iwakeh
 Type:  enhancement| Status:  needs_revision
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

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

Re: [tor-bugs] #25035 [Metrics/Ideas]: Create a mailing list for metrics-specific Nagios alerts

[Tor Bug Tracker & Wiki]

#25035: Create a mailing list for metrics-specific Nagios alerts
---+--
 Reporter:  karsten|  Owner:  karsten
 Type:  enhancement| Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Metrics/Ideas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by karsten):

 We briefly discussed this at today's meeting, and we agree on having such
 a list under the suggested 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] #24700 [Core Tor/Tor]: sched: With KIST, a channel can be added more than once in the pending list

[Tor Bug Tracker & Wiki]

#24700: sched: With KIST, a channel can be added more than once in the pending 
list
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.2.1-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-sched, kist, 032-backport  |  Actual Points:
Parent ID:  #23993 | Points:
 Reviewer:  nickm  |Sponsor:
---+---

Comment (by nickm):

 dgoulet:

 1) Can you tell me something about how this was tested? How do we know it
 will work?

 2) When we merge to 0.3.3, should we remove the
 scheduler_set_channel_state() call instead?

 2) Do you think we should redundantly keep track of the "is_inserted"
 property in the sched_heap_idx field? (See my branch `24700_heap_idx_033`
 for an idea of what I mean.)

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

Re: [tor-bugs] #24700 [Core Tor/Tor]: sched: With KIST, a channel can be added more than once in the pending list

[Tor Bug Tracker & Wiki]

#24700: sched: With KIST, a channel can be added more than once in the pending 
list
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.2.1-alpha
 Severity:  Normal | Resolution:
 Keywords:  tor-sched, kist, 032-backport  |  Actual Points:
Parent ID:  #23993 | Points:
 Reviewer:  nickm  |Sponsor:
---+---
Changes (by nickm):

 * priority:  Medium => High
 * reviewer:   => nickm


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

Re: [tor-bugs] #18090 [Applications/Tor Browser]: Torcrazybutton eats all memory and crashes Tor Browser

[Tor Bug Tracker & Wiki]

#18090: Torcrazybutton eats all memory and crashes Tor Browser
-+-
 Reporter:  bugzilla |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Major| Resolution:
 Keywords:  tbb-crash, tbb-performance-leaking,  |  Actual Points:
  tbb-oom, tbb-torbutton |
Parent ID:  #18047   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 Replying to [comment:16 bugzilla]:
 > "unbound recursion" (?), and FF will continue to do something by
 overloading memory throughput, but very slowly growing in size (hours
 before OOM).
 or CPU and memory now, in the `firefox.exe+0x14c0` thread of a child
 process with stack, full of
 
`xul.dll!ZN7mozilla6scache10PathifyURIEP6nsIURIR19nsACString_internal+0x60xx`
 calls (more than hundred of them in depth).

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

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

[Tor Bug Tracker & Wiki]

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

 * keywords:
 ddos, tor-relay, review-group-30, 029-backport, 031-backport,
 032-backport, review-group-31
 =>
 ddos, tor-relay, review-group-30, 029-backport, 031-backport,
 032-backport, review-group-31, SponsorV


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

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

[Tor Bug Tracker & Wiki]

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

Comment (by valentecaio):

 Yes. Actually, I ran a "make test-full" and it seems that everything is
 ok.

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

Re: [tor-bugs] #25071 [Core Tor/Tor]: Add a test-rust make target to the Makefile

[Tor Bug Tracker & Wiki]

#25071: Add a test-rust make target to the Makefile
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  rust  |  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 I think using `dirname "$0"` here would get the sourcedir, not the
 builddir.

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

Re: [tor-bugs] #25108 [Core Tor/Tor]: hs: nodelist_recompute_all_hsdir_indices() is not used

[Tor Bug Tracker & Wiki]

#25108: hs: nodelist_recompute_all_hsdir_indices() is not used
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  tor-hs, easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Done in c2757c3774c4f1

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

Re: [tor-bugs] #25115 [Core Tor/Tor]: Chutney test-network and test-network-all fail on master branch

[Tor Bug Tracker & Wiki]

#25115: Chutney test-network and test-network-all fail on master branch
--+
 Reporter:  ffmancera |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Okay -- it appears that I misunderstood how the seccomp2 filter rules
 interact.  It appears that `SCMP_ACT_ERRNO()` always takes precedence over
 `SCMP_ACT_ALLOW()` -- I had thought instead that earlier rules would
 override later ones.

 The solution here is to revert 9a06282546418b2e9d21559d4853bcf124b953f4.
 Done in ea8e9f17f52877cc795f1792acb81d7fdaff6baf.  Reopened #16106.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by nickm):

 Okay, that didn't work; it caused #25115.  Reverted in 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] #16106 [Core Tor/Tor]: Sandbox causes crash when creating a hidden service through the control port

[Tor Bug Tracker & Wiki]

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

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


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

Re: [tor-bugs] #25115 [Core Tor/Tor]: Chutney test-network and test-network-all fail on master branch

[Tor Bug Tracker & Wiki]

#25115: Chutney test-network and test-network-all fail on master branch
--+
 Reporter:  ffmancera |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Indeed, it's looking like my patch for #16106 broke the sandbox 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] #24469 [Core Tor/Tor]: Cannibalizing a circuit should check that first hop is in our guard state

[Tor Bug Tracker & Wiki]

#24469: Cannibalizing a circuit should check that first hop is in our guard 
state
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-circuit   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 lgtm; merging.  Maybe open a new ticket about improving cannibalization
 tests?

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

Re: [tor-bugs] #24469 [Core Tor/Tor]: Cannibalizing a circuit should check that first hop is in our guard state

[Tor Bug Tracker & Wiki]

#24469: Cannibalizing a circuit should check that first hop is in our guard 
state
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-circuit   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => 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] #24975 [Core Tor/Tor]: sched: scheduler_notify_networkstatus_changed() calls select_scheduler() without the new consensus

[Tor Bug Tracker & Wiki]

#24975: sched: scheduler_notify_networkstatus_changed() calls select_scheduler()
without the new consensus
-+
 Reporter:  dgoulet  |  Owner:  dgoulet
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  032-backport, tor-sched  |  Actual Points:
Parent ID:   | Points:
 Reviewer:  armadev  |Sponsor:
-+

Comment (by nickm):

 I've merged to 0.3.2 and forward (on the theory that having only one
 version of this to maintain will make us happier).  I put the
 dos_consensus_has_changed() call in notify_before but please let's change
 it as appropriate?

 Leaving this open till somebody confirms the dos_consensus_has_changed()
 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

[tor-bugs] #25115 [Core Tor/Tor]: Chutney test-network and test-network-all fail on master branch

[Tor Bug Tracker & Wiki]

#25115: Chutney test-network and test-network-all fail on master branch
--+
 Reporter:  ffmancera |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 `make test-network` and `make test-network-all` are failing in my system
 with a clean version of master branch. It is failing since I pulled the
 commit
 
[https://gitweb.torproject.org/tor.git/commit/?id=8b0b850efa0f77b627f31e9907acc6d29482f362
 8b0b850efa0], here is the log of basic-min test.

 {{{
 Using Python 2.7.14
 test003c is running with PID 21530
 1/4 nodes are running
 FAIL basic-min (exit status: 3)
 }}}
 I am getting this error with all network tests. If you need more
 information let me know.

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

Re: [tor-bugs] #25111 [Applications/Tor Browser]: Don't compile Yasm on our own anymore for Windows Tor Browser

[Tor Bug Tracker & Wiki]

#25111: Don't compile Yasm on our own anymore for Windows Tor Browser
+--
 Reporter:  gk  |  Owner:  tbb-team
 Type:  defect  | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201801R  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by boklm):

 * status:  new => needs_review
 * keywords:  tbb-rbm => tbb-rbm, TorBrowserTeam201801R


Comment:

 There is a patch for review in branch `bug_25111` from my repo:
 https://gitweb.torproject.org/user/boklm/tor-browser-
 build.git/commit/?h=bug_25111=57f544ca8590b00b609b62132aeb2ae7abfa7779

 I successfully ran `make testbuild-windows-i686 testbuild-windows-x86_64`
 with this patch.

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

Re: [tor-bugs] #22813 [Applications/Tor Browser]: Multiprocess Firefox hangs! (on Windows)

[Tor Bug Tracker & Wiki]

#22813: Multiprocess Firefox hangs! (on Windows)
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-crash, tbb-e10s   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * keywords:  tbb-crash => tbb-crash, tbb-e10s


Comment:

 FWIW here is the stack trace, when it happens with the child process:
 {{{
 0, ntdll.dll!RtlAcquireSRWLockExclusive+0x2a (No unwind info)
 1, ntdll.dll!RtlReleasePrivilege+0x11d (No unwind info)
 2, ntdll.dll!RtlGetGroupSecurityDescriptor+0x30c (No unwind info)
 3, ntdll.dll!RtlGetGroupSecurityDescriptor+0x211 (No unwind info)
 4, ntdll.dll!KiUserExceptionDispatcher+0xf (No unwind info)
 ...
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25114 [Internal Services/Tor Sysadmin Team]: Please add hiro as a git maintainer

[Tor Bug Tracker & Wiki]

#25114: Please add hiro as a git maintainer
-+-
 Reporter:  Sebastian|  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 Hiro has agreed helping out with git maintenance. I added her to the
 gitolite-admin repo already, but we should also have her added to the
 gitolite and gitweb groups. 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] #25100 [Metrics/CollecTor]: Make CollecTor's webstats module use less RAM and CPU time

[Tor Bug Tracker & Wiki]

#25100: Make CollecTor's webstats module use less RAM and CPU time
---+
 Reporter:  karsten|  Owner:  iwakeh
 Type:  enhancement| Status:  needs_revision
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by karsten):

 Uhh, sounds like we'd be relying on the database to implicitly do magic
 for us, whereas we could explicitly do magic ourselves. I think I'd want
 to see both solutions if we really want to go the internal database route
 without normalized schema. In my (possibly naive) understanding, the
 improved data structure is a 20-line patch.

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

Re: [tor-bugs] #24266 [Internal Services/Service - git]: GC problem with my /nickm/tor.git repository

[Tor Bug Tracker & Wiki]

#24266: GC problem with my /nickm/tor.git repository
-+-
 Reporter:  nickm|  Owner:  tor-gitadm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:  user
 |  disappeared
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by Sebastian):

 * status:  new => closed
 * resolution:   => user disappeared


Comment:

 Please reopen if this continues to be 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] #25080 [Internal Services/Service - git]: Grant website commit access to colin

[Tor Bug Tracker & Wiki]

#25080: Grant website commit access to colin
-+
 Reporter:  phoul|  Owner:  tor-gitadm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by Sebastian):

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


Comment:

 [x]

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

Re: [tor-bugs] #24925 [Internal Services/Service - git]: Please create a tor-browser user repo for igt0

[Tor Bug Tracker & Wiki]

#24925: Please create a tor-browser user repo for igt0
-+
 Reporter:  igt0 |  Owner:  tor-gitadm
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by Sebastian):

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


Comment:

 [x]

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

[tor-bugs] #25113 [Core Tor/Tor]: monotonic_time unit test fail, 0.3.3.1-alpha debian armel

[Tor Bug Tracker & Wiki]

#25113: monotonic_time unit test fail, 0.3.3.1-alpha debian armel
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.1-alpha
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 {{{
  util/monotonic_time:
FAIL ../src/test/test_util.c:5843: assert(msecc1 OP_LE nsecc1 /
 100 + 1): 41399 vs 41395
[monotonic_time FAILED]
 
 
https://buildd.debian.org/status/fetch.php?pkg=tor=armel=0.3.3.1-alpha-1=1517099318=0
 }}}

 Looks like the armel build failed:
 https://buildd.debian.org/status/package.php?p=tor=experimental

 The comment in the unit tests right above that is
 {{{
   /* We need to be a little careful here since we don't know the system
 load.
 }}}
 which makes me suspicious. :)

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

Re: [tor-bugs] #25112 [Applications/Tor Browser]: Tor Browser 7.5 is not working on Windows Vista 64bit

[Tor Bug Tracker & Wiki]

#25112: Tor Browser 7.5 is not working on Windows Vista 64bit
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff60-esr-will-have|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 FWIW: Windows Vista is EOL for almost a year now. Might still be worth
 trying to understand what the issue is and fixing it if it is easy.

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

[tor-bugs] #25112 [Applications/Tor Browser]: Tor Browser 7.5 is not working on Windows Vista 64bit

[Tor Bug Tracker & Wiki]

#25112: Tor Browser 7.5 is not working on Windows Vista 64bit
--+
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  ff60-esr-will-have
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 We have some users on the blog complaining about Tor Browser 7.5 being
 broken on Windows Vista 64bit. See, for
 instance:https://blog.torproject.org/comment/273815#comment-273815

 The error ("TypeError: frameLoader.tabParent is null") might indicate that
 our enabled sandboxing is breaking things 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] #25100 [Metrics/CollecTor]: Make CollecTor's webstats module use less RAM and CPU time

[Tor Bug Tracker & Wiki]

#25100: Make CollecTor's webstats module use less RAM and CPU time
---+
 Reporter:  karsten|  Owner:  iwakeh
 Type:  enhancement| Status:  needs_revision
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by iwakeh):

 Be aware that the compression achieved using the in-memory db will not be
 based on normalization and/or a complex db schema, but rather on an
 efficient underlying, transparent storage mechanism for strings and
 repeated values.  It won't need the review time the deployment of a real
 persistent db would require.

 The "manual compression" also increases review and later maintenance time
 (I know that from reviewing older Metrics' code bases).

 There would be still some one-time overhead investigating which in-memory
 solution offers the wanted features and to get it running.

 I'll take a look at both the "manual compression" and in-memory db in
 parallel; either one is done very quickly or a show-stopper comes up for
 the other approach.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25111 [Applications/Tor Browser]: Don't compile Yasm on our own anymore for Windows Tor Browser

[Tor Bug Tracker & Wiki]

#25111: Don't compile Yasm on our own anymore for Windows Tor Browser
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-rbm
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 With the switch to Debian we can now rely on Yasm as shipped by the
 distribution. It is sufficiently recent enough to not break Firefox
 compilation.

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

Re: [tor-bugs] #16513 [Metrics/Onionoo]: Make writing of the out/ directory from the status/ directory deterministic

[Tor Bug Tracker & Wiki]

#16513: Make writing of the out/ directory from the status/ directory 
deterministic
-+---
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  enhancement  | Status:  merge_ready
 Priority:  Very High|  Milestone:  Onionoo-2.0.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+---

Comment (by karsten):

 Thanks for checking!

 Those three commits (87177e9, 638d895, and 6308c89) look good.

 Let's discuss deployment at today's meeting.

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

Re: [tor-bugs] #25103 [Metrics/Library]: Improve webstats performance

[Tor Bug Tracker & Wiki]

#25103: Improve webstats performance
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  merge_ready
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #25100   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  needs_review => merge_ready


Comment:

 Fixup commit 0a44786 looks good!

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

Re: [tor-bugs] #25103 [Metrics/Library]: Improve webstats performance

[Tor Bug Tracker & Wiki]

#25103: Improve webstats performance
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Library  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #25100   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:4 karsten]:
 > Commit 841e667 should print `0` as `0`, not as `-`. Basically, it should
 be `this.size >= 0` in two places. Can you prepare a fixup commit for
 that?

 Good catch!  Please review [https://gitweb.torproject.org/user/iwakeh
 /metrics-lib.git/commit/?h=next another commit] fixing 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] #16513 [Metrics/Onionoo]: Make writing of the out/ directory from the status/ directory deterministic

[Tor Bug Tracker & Wiki]

#16513: Make writing of the out/ directory from the status/ directory 
deterministic
-+---
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  enhancement  | Status:  merge_ready
 Priority:  Very High|  Milestone:  Onionoo-2.0.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+---
Changes (by iwakeh):

 * status:  accepted => merge_ready


Comment:

 The made changes look ok, although the new graph history compiler code is
 still not making much use the java.time classes.  But, changing it raises
 some questions about the calculations and would take too long for this
 ticket.  Thus, making a note later on the java8 ticket for Onionoo.

 The changes here and the upcoming changes in 25002 will make Onionooo
 distances independent of their local state as far as possible.

 The change here leads to identical 'out' directories when run with the
 same 'status' directory contents.  I have a few
 [https://gitweb.torproject.org/user/iwakeh/onionoo.git/log/?h=task-16513-2
 minor unrelated commits].

 Comparing the 'out' dir resulting from Onionoo-4.4-1.8.0 with the
 resulting 'out' from the new 5.0-1.9.0  can only be done manually.  So
 far, I think those differences are due to the changes here and thus
 intended, but that's hard to verify.  Maybe, make a copy of 'out' and
 'status' before deployment to have a rollback option in the unlikely case
 there are unwanted differences?

 In total: merge ready.

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

Re: [tor-bugs] #25100 [Metrics/CollecTor]: Make CollecTor's webstats module use less RAM and CPU time

[Tor Bug Tracker & Wiki]

#25100: Make CollecTor's webstats module use less RAM and CPU time
---+
 Reporter:  karsten|  Owner:  iwakeh
 Type:  enhancement| Status:  needs_revision
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by karsten):

 I think that an in-memory database is the second-best solution. The
 "manual compression" sounds more promising to me, because it leverages a
 specific redundancy of web server logs. Of course, we could further
 normalize the data and store request line parts in separate tables. But
 I'd say that the effort to make code changes and get them reviewed is
 several times as high as using the suggested data structure, whereas we'd
 already achieve 2/3 or 3/4 of possible improvements just from that without
 using a database.

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

Re: [tor-bugs] #25100 [Metrics/CollecTor]: Make CollecTor's webstats module use less RAM and CPU time

[Tor Bug Tracker & Wiki]

#25100: Make CollecTor's webstats module use less RAM and CPU time
---+
 Reporter:  karsten|  Owner:  iwakeh
 Type:  enhancement| Status:  needs_revision
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by iwakeh):

 Replying to [comment:8 karsten]:
 > Replying to [comment:7 iwakeh]:
 > > True, so far we didn't trade memory for time, but got some
 improvements that could be picked easily even winning some time here.
 > > Keeping counts of different sanitized lines in memory could also help
 and might be only a small change; I'm looking into this next.
 >
 > Aha! That sounds very promising, too. Maybe even leave out the date part
 from sanitized lines and keep a bag of dates containing sanitized lines.
 Something like `Map` (yes, I know that there's no
 `Bag` type in Java; time to add Apache Commons Collections?). And later
 when we write sanitized logs, we simply put in the date.

 Depending on the target scenarios it might be also very fruitful and a
 reusable approach for other CollecTor modules, not no implement
 'compression' (which the above is) by hand, but rather use some in-memory
 database that compresses the highly redundant data at hand.  Reasoning:
 the above mentioned 8867 logs from weschniakowsky and meronense combined
 are just 60M when xz compressed and roughly 20G (plus/minus x) deflated.
 If the in-memory db achieves a compression about ten times less efficient
 than xz, still only 600M were needed.  Plus we'd get some sql (like) query
 support in addition.

 If it works, we'd have a useful approach to recycle widely in metrics'
 code base.

 Thoughts?

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

Re: [tor-bugs] #24654 [Applications/Tor Browser]: Tor Browser 7.5a9 timed out waiting for circuit

[Tor Bug Tracker & Wiki]

#24654: Tor Browser 7.5a9 timed out waiting for circuit
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #21969| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * status:  needs_information => new
 * parent:   => #21969


Comment:

 Looks like a consequence of #21969. That explains "there was no circuit
 related to this username/password combination" and "timed out waiting for
 circuit". The questions are:
 1. Why does tor report its timeout as timeout of duckduckgo.com?
 2. Would Torbutton switch circuits otherwise?
 BTW, it still happens with tor 0.3.2.9.

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

Re: [tor-bugs] #25100 [Metrics/CollecTor]: Make CollecTor's webstats module use less RAM and CPU time

[Tor Bug Tracker & Wiki]

#25100: Make CollecTor's webstats module use less RAM and CPU time
---+
 Reporter:  karsten|  Owner:  iwakeh
 Type:  enhancement| Status:  needs_revision
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by karsten):

 Replying to [comment:7 iwakeh]:
 > True, so far we didn't trade memory for time, but got some improvements
 that could be picked easily even winning some time here.
 > Keeping counts of different sanitized lines in memory could also help
 and might be only a small change; I'm looking into this next.

 Aha! That sounds very promising, too. Maybe even leave out the date part
 from sanitized lines and keep a bag of dates containing sanitized lines.
 Something like `Map` (yes, I know that there's no
 `Bag` type in Java; time to add Apache Commons Collections?). And later
 when we write sanitized logs, we simply put in the date.

 > But first, we should make sure that the performance tuning focuses on
 the usual scenario (not the rare bulk import) before starting bigger
 changes.
 >
 > 1. The usual import amount will logs of a few days, not the yearly logs,
 right?
 > 2. Major bulk imports like the initial one should work, but also appear
 very rarely.  Correct?
 >
 > Do you have some reasonable figures as example for each?

 Agreed that bulk imports are rare. Still, they may happen. Maybe the
 suggestion above resolves this relatively easily.

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

Re: [tor-bugs] #16513 [Metrics/Onionoo]: Make writing of the out/ directory from the status/ directory deterministic

[Tor Bug Tracker & Wiki]

#16513: Make writing of the out/ directory from the status/ directory 
deterministic
-+---
 Reporter:  karsten  |  Owner:  iwakeh
 Type:  enhancement  | Status:  accepted
 Priority:  Very High|  Milestone:  Onionoo-2.0.0
Component:  Metrics/Onionoo  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  metrics-2018 |  Actual Points:
Parent ID:   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+---
Changes (by karsten):

 * priority:  High => Very High


Comment:

 Raising priority of this ticket even more, because it's currently blocking
 #24729 which confuses a lot of relay operators and leads to repeated
 questions.

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

Re: [tor-bugs] #24729 [Metrics/Onionoo]: Find reason for 'null' values in Onionoo document

[Tor Bug Tracker & Wiki]

#24729: Find reason for 'null' values in Onionoo document
-+--
 Reporter:  Dbryrtfbcbhgf|  Owner:  karsten
 Type:  defect   | Status:  needs_review
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #24155   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+--

Comment (by karsten):

 Replying to [comment:12 iwakeh]:
 > The suggestion in comment:4 seems ok, technically all data for shorter
 graphs can be taken from there.

 Agreed.

 > Can the clients using the data provide all useful/needed graphs with
 this change and deal with possibly omitted data?

 As of now, clients cannot handle this yet. But I think that's #24831, so
 at least Relay Search will be handle to handle this at some point.

 However, I thought more about omitting data. Maybe we should not do that.
 Here's a new idea:

  - We add a 6 month history object with a data resolution of 1 day. (Same
 as above.)
  - We drop the shorter graphs from clients documents with a data
 resolution of 1 day. (Same as above.)
  - If we compile a graph from a history '''only''' containing entries with
 a data resolution that is too low for the graph (e.g., data is provided
 for 24 hours, but the graph shows data for 12 hours), we skip that graph.
 (Same as we do right now, same as above.)
  - If we compile a graph from a history '''also''' containing entries with
 a data resolution that is too low along with entries with the high-enough
 data resolution (e.g., data is provided for 4 hour intervals, then for 24
 hour intervals, then again for 4 hour intervals), we include that graph
 and interpolate data as necessary. (This suggestion is new. The earlier
 suggestion was to drop this graph.)

 Here's why I think that this suggestion is better:
  - Even if we add a 6 month graph today, the data in current status files
 for 3 to 6 months ago is already compressed to a resolution of 2 days.
 We'd basically have to wait 3 months for 6 month graphs to first appear,
 or we'd have to re-import data. Ewww.
  - I'm worried that there are edge cases where we're compressing data in
 status files a tiny bit too early. The effect might be that we're not
 providing any graphs at all.

 Here's a possible issue that I see with this suggestion:
  - Whenever a relay changes its reporting interval, graphs will suddenly
 be a lot less volatile, which might confuse relay operators wondering what
 happened. But I think the explanation that their relay is now reporting
 data on a lower resolution should be obvious enough to quickly answer
 those questions.

 I did not implement this, because I'd still want us to resolve #16513
 first. Raising priority on that even more, so that we can finally resolve
 this one.

 How does this plan sound?

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

Re: [tor-bugs] #25100 [Metrics/CollecTor]: Make CollecTor's webstats module use less RAM and CPU time

[Tor Bug Tracker & Wiki]

#25100: Make CollecTor's webstats module use less RAM and CPU time
---+
 Reporter:  karsten|  Owner:  iwakeh
 Type:  enhancement| Status:  needs_revision
 Priority:  High   |  Milestone:
Component:  Metrics/CollecTor  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by iwakeh):

 True, so far we didn't trade memory for time, but got some improvements
 that could be picked easily even winning some time here.
 Keeping counts of different sanitized lines in memory could also help and
 might be only a small change; I'm looking into this next.

 But first, we should make sure that the performance tuning focuses on the
 usual scenario before starting the bigger changes.

 1. The usual import amount will logs of a few days, not the yearly logs,
 right?
 2. Major bulk imports like the initial one should work, but also appear
 very rarely.  Correct?

 Do you have some reasonable figures as example for each?

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