Re: [tor-bugs] #25137 [Obfuscation/Censorship analysis]: Tor blocked in UAE

[Tor Bug Tracker & Wiki]

#25137: Tor blocked in UAE
-+
 Reporter:  mwolfe   |  Owner:  dcf
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  censorship block ae  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by dcf):

 * status:  new => closed
 * resolution:   => fixed
 * type:  defect => task


Comment:

 This seems resolved, so I'm closing the ticket. mwolfe and cypherpunks,
 thanks for your help. Go ahead and leave further comments or reopen the
 ticket if you have additional information.

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

Re: [tor-bugs] #25137 [Obfuscation/Censorship analysis]: Tor blocked in UAE

[Tor Bug Tracker & Wiki]

#25137: Tor blocked in UAE
-+-
 Reporter:  mwolfe   |  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block ae  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dcf):

 Replying to [comment:11 mwolfe]:
 > On 1 Jan, the TRA ordered Tor blocked. This happened before (several
 years ago, and I have an old ticket on it), then Tor was unblocked, and
 now it's reblocked.

 Do you have a reference for the block order of 1 Jan? I looked at
 https://www.tra.gov.ae/en/services-and-
 activities/regulation/details.aspx#documents but didn't find it.

 > Mostly, torproject.org is blocked, but since I downloaded Tor before it
 was blocked, no problem until they started doing more to block Tor. Now,
 of course, it's a drop down menu item if the regular obfs4 or meek work.
 If they don't, you sent me 3 bridges that are harder to find, so thanks.

 There's also a few other ways to download the software when the
 torproject.org web site is blocked. You can send an email to
 get...@torproject.org. You can also download from GitHub:
 https://github.com/TheTorProject/gettorbrowser.

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

Re: [tor-bugs] #25173 [Core Tor/Tor]: No Control Socket when DisableNetwork and User options are set

[Tor Bug Tracker & Wiki]

#25173: No Control Socket when DisableNetwork and User options are set
--+
 Reporter:  iry   |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 My guess is that we defer opening the unix domain socket here, and then we
 never call retry_all_listeners() again from config.c because our config
 hasn't changed.

 There's a call to retry_all_listeners() in main.c, in this thing called
 retry_listeners_callback(), except it runs
 {{{
   if (!net_is_disabled()) {
 retry_all_listeners(NULL, NULL, 0);
 }}}
 so when net_is_disabled, it just never calls retry_all_listeners again.

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

Re: [tor-bugs] #24806 [Core Tor/Tor]: LTS branch leaks memory continuously under stress/attack, requires back-port of 0.3.2.8-rc fixes to remain viable

[Tor Bug Tracker & Wiki]

#24806: LTS branch leaks memory continuously under stress/attack, requires back-
port of 0.3.2.8-rc fixes to remain viable
--+--
 Reporter:  starlight |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by starlight):

 Replying to [comment:14 arma]:
 > Can you publish the results of your "tracing malloc" work?

 I wrote a quick but reasonable patch that activates and deactivates the
 standard mtrace() facility in response to a pair of RT signals (40-on,
 41-off) or control-channel commands.  Then traced something like 120
 seconds after the relay had warmed up.  mtrace.pl provided alloc/free
 subtraction.  Standard glibc hook functions are terribly inefficient and
 nearly kill it, but strong hints regarding the cause of the problem jumped
 off the page nonetheless and I set aside further refinement.  Was also
 trying to coax LSAN into producing a pretty report, but LSAN is "too
 smart," and builds a graph of references by searching all allocations for
 pointers to other allocations--reliably produced zilch.  No option to tune
 LSAN for stupidity and that exercise was a frustrating waste of time.

 The mtrace() patch can be enhanced with fast hook callbacks that write
 binary structs including full call-arcs, and I was prepared to do that
 (notes in the patch).  A small C/C++ utility to set-subtract frees from
 mallocs and pretty-print the results is required; should summarize by
 call-arc as Valgrind, ASAN, LSAN etc. do (anyone remember Purify?).

 I'm willing to work this into a proper enhancement if of interest.  My
 idea is that it can be an always-available on-demand memory trace one
 could activate and deactivate on a long-running instance, even one with
 months of uptime.

 Am a bit burned-out on hacking Tor at the moment and would prefer to take
 a month or two to finish (more like two).  If this is viewed as near-term
 desirable one of the core devs could certainly complete it and I won't
 feel upstaged (as long I get a little credit).

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

Re: [tor-bugs] #24806 [Core Tor/Tor]: LTS branch leaks memory continuously under stress/attack, requires back-port of 0.3.2.8-rc fixes to remain viable

[Tor Bug Tracker & Wiki]

#24806: LTS branch leaks memory continuously under stress/attack, requires back-
port of 0.3.2.8-rc fixes to remain viable
--+--
 Reporter:  starlight |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by starlight):

 * Attachment "mtrace_1.rpt-sym-clean.txt.gz" added.

 lingering allocations (sanitized)

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

Re: [tor-bugs] #24806 [Core Tor/Tor]: LTS branch leaks memory continuously under stress/attack, requires back-port of 0.3.2.8-rc fixes to remain viable

[Tor Bug Tracker & Wiki]

#24806: LTS branch leaks memory continuously under stress/attack, requires back-
port of 0.3.2.8-rc fixes to remain viable
--+--
 Reporter:  starlight |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by starlight):

 * Attachment "mtrace_1.out-clean.txt.xz" added.

 full trace (sanitized)

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

Re: [tor-bugs] #24806 [Core Tor/Tor]: LTS branch leaks memory continuously under stress/attack, requires back-port of 0.3.2.8-rc fixes to remain viable

[Tor Bug Tracker & Wiki]

#24806: LTS branch leaks memory continuously under stress/attack, requires back-
port of 0.3.2.8-rc fixes to remain viable
--+--
 Reporter:  starlight |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by starlight):

 * Attachment "tor-0.3.2.9-mtrace.patch" added.

 mtrace 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] #25173 [Core Tor/Tor]: No Control Socket when DisableNetwork and User options are set

[Tor Bug Tracker & Wiki]

#25173: No Control Socket when DisableNetwork and User options are set
--+
 Reporter:  iry   |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 {{{
 #ifndef _WIN32
 /* We don't need to be root to create a UNIX socket, so defer until
 after
  * setuid. */
 const or_options_t *options = get_options();
 if (port->is_unix_addr && !geteuid() && (options->User) &&
 strcmp(options->User, "root"))
   continue;
 #endif /* !defined(_WIN32) */
 }}}

 is where we defer opening the control socket listener

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

Re: [tor-bugs] #25173 [Core Tor/Tor]: No Control Socket when DisableNetwork and User options are set

[Tor Bug Tracker & Wiki]

#25173: No Control Socket when DisableNetwork and User options are set
--+
 Reporter:  iry   |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by arma):

 Our first weird hint. Not using the User option, we have
 {{{
 Feb 07 22:06:02.093 [notice] Read configuration file
 "/usr/local/etc/tor/torrc".
 Feb 07 22:06:02.098 [warn] ControlPort is open, but no authentication
 method has been configured.  This means that any program on your computer
 can reconfigure your Tor.  That's bad!  You should upgrade your Tor
 controller as soon as possible.
 Feb 07 22:06:02.098 [notice] Scheduler type KIST has been enabled.
 Feb 07 22:06:02.098 [notice] Opening Socks listener on 127.0.0.1:9050
 Feb 07 22:06:02.098 [notice] Opening Control listener on 127.0.0.1:9051
 Feb 07 22:06:02.098 [notice] Opening Control listener on
 /home/arma/.tor/control
 Feb 07 22:06:02.098 [notice] Opening Control listener on
 /tmp/tor/control.sock
 Feb 07 22:06:02.098 [warn] Your log may contain sensitive information -
 you disabled SafeLogging, and you're logging more than "notice". Don't log
 unless it serves an important reason. Overwrite the log afterwards.
 Feb 07 22:06:02.103 [notice] Parsing GEOIP IPv4 file
 /usr/local/share/tor/geoip.
 Feb 07 22:06:02.220 [notice] Parsing GEOIP IPv6 file
 /usr/local/share/tor/geoip6.
 Feb 07 22:06:02.726 [notice] Bootstrapped 0%: Starting
 }}}

 That is, our controlsocket opens at the same time as the control port.

 But using User, we have
 {{{
 Feb 07 21:25:12.170 [notice] Read configuration file "/tmp/torrc".
 Feb 07 21:25:12.175 [notice] Scheduler type KIST has been enabled.
 Feb 07 21:25:12.175 [notice] Opening Socks listener on 127.0.0.1:9050
 Feb 07 21:25:12.000 [notice] Parsing GEOIP IPv4 file
 /usr/local/share/tor/geoip.
 Feb 07 21:25:12.000 [notice] Parsing GEOIP IPv6 file
 /usr/local/share/tor/geoip6.
 Feb 07 21:25:12.000 [notice] Bootstrapped 0%: Starting
 Feb 07 21:25:12.000 [notice] Starting with guard context "default"
 Feb 07 21:25:12.000 [notice] Bootstrapped 80%: Connecting to the Tor
 network
 Feb 07 21:25:13.000 [notice] Opening Control listener on
 /tmp/tor/control.sock
 Feb 07 21:25:13.000 [notice] Bootstrapped 85%: Finishing handshake with
 first hop
 }}}

 What in our code path is making us open the control socket listener so
 much later when User is set?

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

Re: [tor-bugs] #25173 [Core Tor/Tor]: No Control Socket when DisableNetwork and User options are set

[Tor Bug Tracker & Wiki]

#25173: No Control Socket when DisableNetwork and User options are set
--+
 Reporter:  iry   |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * version:  Tor: 0.3.2.9 => Tor: 0.3.1.9


Comment:

 We use the earliest version that a bug appears in. That makes it easier to
 find the bug.

 Looking forward to seeing logs of what Tor does with the control socket
 file on startup and on HUP. That will give us some clues.

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

Re: [tor-bugs] #25173 [Core Tor/Tor]: No Control Socket when DisableNetwork and User options are set

[Tor Bug Tracker & Wiki]

#25173: No Control Socket when DisableNetwork and User options are set
--+
 Reporter:  iry   |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by yawning):

 Log output if any is helpful as well (and there is a debug log level).

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

Re: [tor-bugs] #25127 [Core Tor/Tor]: Rust implementation of protover_get_supported_protocols() leaks memory

[Tor Bug Tracker & Wiki]

#25127: Rust implementation of protover_get_supported_protocols() leaks memory
--+
 Reporter:  nickm |  Owner:  isis
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  rust, protover, leak  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  SponsorM
--+

Comment (by teor):

 A standard macro that we can use in all our crates would be really
 helpful.

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

Re: [tor-bugs] #25173 [Core Tor/Tor]: No Control Socket when DisableNetwork and User options are set

[Tor Bug Tracker & Wiki]

#25173: No Control Socket when DisableNetwork and User options are set
--+
 Reporter:  iry   |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.9
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by iry):

 * version:  Tor: unspecified => Tor: 0.3.2.9


Comment:

 Thank you, teor!

 > I tested both Tor 0.3.1.9 and 0.3.2.9 on Debian Stretch

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

Re: [tor-bugs] #25140 [Core Tor/Tor]: Parse only .torrc files in torrc.d directory

[Tor Bug Tracker & Wiki]

#25140: Parse only .torrc files in torrc.d directory
--+
 Reporter:  iry   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.1-alpha
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by Jigsaw52):

 * cc: danielpinto52@… (added)


Comment:

 I agree that supporting wildcards in %includes would be a nice feature. I
 remember looking for code for processing wildcards in files in tor and not
 finding any so this might take some effort to develop.

 If someone wants to take on this, the relevant changes are on
 ./src/or/config.c

 In this file, there is a method config_process_include which is called for
 every %include found and receives the string after %include as first
 argument.
 This method then calls config_get_file_list which is responsible for
 returning a list of files to be processed for that %include line. Note
 that config_get_file_list does not care about recursive includes, it just
 returns a list of files in a folder if the included path was a folder or a
 list with a single file if it was a file.

 So, the only existing method that needs changes to support this is
 config_get_file_list.

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

Re: [tor-bugs] #25127 [Core Tor/Tor]: Rust implementation of protover_get_supported_protocols() leaks memory

[Tor Bug Tracker & Wiki]

#25127: Rust implementation of protover_get_supported_protocols() leaks memory
--+
 Reporter:  nickm |  Owner:  isis
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  rust, protover, leak  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  SponsorM
--+
Changes (by isis):

 * status:  assigned => needs_review
 * version:   => Tor: 0.3.2.1-alpha
 * sponsor:   => SponsorM


Comment:

 There's patches in my `bug25127`
 [https://gitweb.torproject.org/user/isis/tor.git/log/?h=bug25127 branch].
 I'm not sure if I like what I came up with though. It might be better to
 make a macro to add the null bytes, similar to the one catalyst linked to,
 but probably without the `as *const ::std::os::raw::c_char` part.
 Opinions?

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

Re: [tor-bugs] #21969 [Core Tor/Tor]: We're missing descriptors for some of our primary entry guards

[Tor Bug Tracker & Wiki]

#21969: We're missing descriptors for some of our primary entry guards
---+---
 Reporter:  asn|  Owner:  asn
 Type:  defect | Status:
   |  needs_information
 Priority:  Immediate  |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Tor   |Version:  Tor:
   |  0.3.0.6
 Severity:  Blocker| Resolution:
 Keywords:  tor-guard, tor-bridge, tor-client  |  Actual Points:
Parent ID: | Points:  1.5
 Reviewer: |Sponsor:  SponsorV
---+---

Comment (by cypherpunks):

 Replying to [comment:65 cypherpunks]:
 > As you can see in comment:58, it is a state of some circuits, but not of
 Tor. And unfortunately, Tor 0.3.2.9 can't get out of it sometimes after
 hibernation, so that web apps can't be resumed (timeout). The log shows
 only a lot of
 > {{{
 > Tor NOTICE: Tried for 120 seconds to get a connection to [scrubbed]:443.
 Giving up. (waiting for circuit)
 > }}}
 > And also it showed
 > {{{
 > Tor NOTICE: Tor has not observed any network activity for the past 121
 seconds. Disabling circuit build timeout recording.
 > Tor NOTICE: Tor now sees network activity. Restoring circuit build
 timeout recording. Network was down for 296 seconds during 19 circuit
 attempts.
 > }}}
 > without any reason (there were no network problems, except it meant Tor
 network).
 I confirm, I have Ricochet running with Tor 0.3.3.1-a and it's unable to
 bootstrap back after hibernation '''even after lefting it there for 6
 hours'''.

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

Re: [tor-bugs] #23633 [Core Tor/Tor]: Why does roflcopter have an empty protocol line in the consensus?

[Tor Bug Tracker & Wiki]

#23633: Why does roflcopter have an empty protocol line in the consensus?
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 An empty pr line is a valid pr line. The relay claims to support nothing.

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

Re: [tor-bugs] #25173 [Core Tor/Tor]: No Control Socket when DisableNetwork and User options are set

[Tor Bug Tracker & Wiki]

#25173: No Control Socket when DisableNetwork and User options are set
--+
 Reporter:  iry   |  Owner:  (none)
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

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


Comment:

 You don't say what tor version you are running. That makes it hard for us
 to work out where the bug is.

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

Re: [tor-bugs] #17945 [Core Tor/Tor]: Stop Tor2Web connecting to (Rendezvous) Single Onion Services

[Tor Bug Tracker & Wiki]

#17945: Stop Tor2Web connecting to (Rendezvous) Single Onion Services
-+-
 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:  tor2web, tor-hs, 029-proposed, 029   |  Actual Points:
  -teor-no, needs-design, needs-proposal-maybe,  |
  single-onion   |
Parent ID:  #24962   | Points:  5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_information => new


Comment:

 It is not possible for Tor2web or single onion services to use a bridge.
 They do not use entry guards. (I don't know what happens when you try.
 Don't expect it to work.)

 We should fix this issue on relays by refusing to rend splice a direct
 client to another direct client. And similar for intros. For rend and
 intro v3, see #22689. For HSDir v3, see #22688.

 Not sure where the v2 tickets got to.

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

Re: [tor-bugs] #19662 [Core Tor/Tor]: On intro failure, Tor2web should build a 3-hop path

[Tor Bug Tracker & Wiki]

#19662: On intro failure, Tor2web should build a 3-hop path
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Low  |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  030-proposed, tor2web, tor-hs,   |  Actual Points:
  single-onion   |
Parent ID:  #17945   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

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


Comment:

 Tor2web should be formally deprecated.

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

Re: [tor-bugs] #20104 [Core Tor/Tor]: Tor2web should connect to HSDirs over a 3-hop path

[Tor Bug Tracker & Wiki]

#20104: Tor2web should connect to HSDirs over a 3-hop path
-+--
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:  tor-hs, tor2web  |  Actual Points:
Parent ID:  #17945   | Points:  1
 Reviewer:   |Sponsor:
-+--
Changes (by teor):

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


Comment:

 Tor2web should be formally deprecated.

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

Re: [tor-bugs] #23250 [Core Tor/Tor]: tor-0.3.0.10: test failure on NetBSD

[Tor Bug Tracker & Wiki]

#23250: tor-0.3.0.10: test failure on NetBSD
-+-
 Reporter:  wiz  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bsd, test, 032-backport, |  Actual Points:
  031-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_information => new


Comment:

 This is probably the same backtrace bug that we see on FreeBSD, and macOS
 gcc x86_64.
 The backtrace is simply not where we expect, or not in the format we
 expect.

 See #18204, where we SKIP the backtrace test on FreeBSD.
 See also #17808, where we thought about doing the same thing for macOS,
 but the backtrace works fine with clang, and with gcc i386.

 To resolve this issue, we can either SKIP on NetBSD, or get compiler and
 arch and a system where we can reproduce.
 Fixing this bug requires a motivated NetBSD developer.

 So I think we should SKIP until that happens,

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

Re: [tor-bugs] #23633 [Core Tor/Tor]: Why does roflcopter have an empty protocol line in the consensus?

[Tor Bug Tracker & Wiki]

#23633: Why does roflcopter have an empty protocol line in the consensus?
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Replying to [comment:6 teor]:
 > Authorities only provide a default implementation if the relay claims to
 be a pre-protover Tor version.
 > If the relay is new enough to have protover, it should provide its own
 line.
 > So blank pr is a correct consensus entry for this relay.

 Hmmm, protover was introduced in tor-0.2.9.4, with that Tor version
 (0.2.9.11), `pr` can't be empty... But I guess, I should have asked if the
 dirauth do such validation that is Tor version + pr line. In other words,
 can I modify my tor to have an empty `pr` line and then it is accepted as
 is with any Tor version I put 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

Re: [tor-bugs] #25171 [Core Tor/Tor]: Clarify 'recognized' field in tor-spec

[Tor Bug Tracker & Wiki]

#25171: Clarify 'recognized' field in tor-spec
---+
 Reporter:  atagar |  Owner:  (none)
 Type:  defect | Status:  needs_revision
 Priority:  Very Low   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Trivial| Resolution:
 Keywords:  tor-spec, doc  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * keywords:   => tor-spec, doc
 * status:  needs_review => needs_revision


Comment:

 As Roger said on IRC: recognised is very likely zero if the cell is
 decrypted and destined for this hop. But there is a `1 in 2^32` chance of
 zero even if the cell is not destined for this hop.

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

Re: [tor-bugs] #23633 [Core Tor/Tor]: Why does roflcopter have an empty protocol line in the consensus?

[Tor Bug Tracker & Wiki]

#23633: Why does roflcopter have an empty protocol line in the consensus?
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by teor):

 Authorities only provide a default implementation if the relay claims to
 be a pre-protover Tor version.
 If the relay is new enough to have protover, it should provide its own
 line.
 So blank pr is a correct consensus entry for this relay.

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

Re: [tor-bugs] #25137 [Obfuscation/Censorship analysis]: Tor blocked in UAE

[Tor Bug Tracker & Wiki]

#25137: Tor blocked in UAE
-+-
 Reporter:  mwolfe   |  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block ae  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mwolfe):

 I am now on my Mac using Snowflake. Works.

 Of course, whatever was blocking obsf4 4 days ago went away about two or
 three hours after I reported it (using a VPN). However, this is just to
 let you know that Snowflake works here, as does obsf4 and meek now. Not at
 all clear what was blocking Tor with meek enabled four days ago. Your DDoS
 theory is probably correct.

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

Re: [tor-bugs] #24805 [Core Tor/Fallback Scripts]: Update fallback whitelist and blacklist

[Tor Bug Tracker & Wiki]

#24805: Update fallback whitelist and blacklist
---+---
 Reporter:  teor   |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:
Parent ID:  #24786 | Points:  2
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 An operator wants this relay '''taken off the whitelist and put on the
 blacklist''':
 0BEA4A88D069753218EAAAD6D22EA87B9A1319D6
 It is being shut down.
 See #25169.

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

Re: [tor-bugs] #25169 [Core Tor/Fallback Scripts]: Fallback removal for 0BEA4A88D069753218EAAAD6D22EA87B9A1319D6

[Tor Bug Tracker & Wiki]

#25169: Fallback removal for 0BEA4A88D069753218EAAAD6D22EA87B9A1319D6
---+
 Reporter:  baelor.tor |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback-change|  Actual Points:
Parent ID:  #24805 | Points:
 Reviewer: |Sponsor:
---+
Changes (by teor):

 * parent:   => #24805


Comment:

 Thanks! We'll rebuild the list in 6-12 months,

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

Re: [tor-bugs] #25140 [Core Tor/Tor]: Parse only .torrc files in torrc.d directory

[Tor Bug Tracker & Wiki]

#25140: Parse only .torrc files in torrc.d directory
--+
 Reporter:  iry   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.1-alpha
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by iry):

 Replying to [comment:7 nickm]:
 > No, I really don't think so. This is much closer to a new feature than
 it is to a bugfix. Moreover, it promises to involve stuff (pattern
 matching, file systems, string handling) that have a way of getting
 unexpected bugs the first time around.

 Thank you so much for your explanation, nickm! Your immediate reply is
 really helpful for the downstream to make decisions on how to deal with
 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] #23147 [Core Tor/Tor]: prop288: Merge privcount-in-tor data collector backend implementation

[Tor Bug Tracker & Wiki]

#23147: prop288: Merge privcount-in-tor data collector backend implementation
---+---
 Reporter:  nickm  |  Owner:  teor
 Type:  enhancement| Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  prop288, prop280, rust, privcount  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:  SponsorQ
---+---
Changes (by teor):

 * owner:  (none) => teor
 * keywords:  prop288, prop280 => prop288, prop280, rust, privcount
 * status:  new => assigned


Comment:

 I think our current plan is that I will end up (re)writing PrivCount in
 Tor in Rust.

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

Re: [tor-bugs] #24509 [Core Tor/Tor]: circuit_can_use_tap() should only allow TAP for v2 onion services

[Tor Bug Tracker & Wiki]

#24509: circuit_can_use_tap() should only allow TAP for v2 onion services
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, security-low,   |  Actual Points:
  easy, intro|
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * status:  needs_information => needs_revision


Comment:

 Replying to [comment:10 dgoulet]:
 > I was working on this and I started to wonder here why isn't the purpose
 + the presence of a TAP onion key in the extend_info_t object not enough
 to rule out v2 HS?

 This check is a defence in depth mechanism.

 > As an example, HSv3 never sets a TAP onion key so it can simply never
 hit true there. Is the goal to have an _explicit_ flag that identifies the
 circuits HS version? Tbh, just to have that, it requires quite a bit of
 gymnastic and added flags for some gain I'm not sure I understand?

 It makes sure that our v3 code never uses TAP.
 And that our v2 code only uses TAP for two specific purposes: client
 intro, and service rend.

 These checks make it easier to get rid of TAP, because we know we're not
 accidentally using it for anything else. And they make sure we can't be
 *tricked* into using it for anything else, if there are bugs in our code.

 > A straight forward way would be to add a flag to the `extend_info_t` so
 the v2 and v3 subsystem can put the right version in there. But how is
 that different from "setting a TAP key" and "not setting a tap key" ?

 If there are bugs in our code, it is different.

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

Re: [tor-bugs] #17270 [Core Tor/Tor]: Evaluate non-C tor implementations for hackability

[Tor Bug Tracker & Wiki]

#17270: Evaluate non-C tor implementations for hackability
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.2.8.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  028-triage, 201511-deferred, |  implemented
  TorCoreTeam201601, 201512-deferred |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
 |  SponsorS
-+-

Comment (by teor):

 Stem now has ORPort support for downloading descriptors:
 https://lists.torproject.org/pipermail/tor-dev/2018-February/012905.html

 This support is based on Endosome:
 https://github.com/teor2345/endosome

 Both are eminently hackable.
 (I used endosome to review tor-spec against the actual C relay
 implementation.)

 This list is kept up to date:
 https://trac.torproject.org/projects/tor/wiki/doc/ListOfTorImplementations

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

Re: [tor-bugs] #24978 [Core Tor/Tor]: Tor doesn't work when built with (unreleased) OpenSSL 1.1.1 built with enable-tls1_3

[Tor Bug Tracker & Wiki]

#24978: Tor doesn't work when built with (unreleased) OpenSSL 1.1.1 built with
enable-tls1_3
-+-
 Reporter:  nickm|  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  029-backport, 031-backport,  |  Actual Points:
  032-backport, openssl, review-group-31 |
Parent ID:   | Points:
 Reviewer:  isis |Sponsor:
-+-
Changes (by isis):

 * reviewer:   => isis


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

Re: [tor-bugs] #25140 [Core Tor/Tor]: Parse only .torrc files in torrc.d directory

[Tor Bug Tracker & Wiki]

#25140: Parse only .torrc files in torrc.d directory
--+
 Reporter:  iry   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.1-alpha
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 No, I really don't think so. This is much closer to a new feature than it
 is to a bugfix. Moreover, it promises to involve stuff (pattern matching,
 file systems, string handling) that have a way of getting unexpected bugs
 the first time around.

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

Re: [tor-bugs] #25140 [Core Tor/Tor]: Parse only .torrc files in torrc.d directory

[Tor Bug Tracker & Wiki]

#25140: Parse only .torrc files in torrc.d directory
--+
 Reporter:  iry   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.1-alpha
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #24509 [Core Tor/Tor]: circuit_can_use_tap() should only allow TAP for v2 onion services

[Tor Bug Tracker & Wiki]

#24509: circuit_can_use_tap() should only allow TAP for v2 onion services
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, security-low,   |  Actual Points:
  easy, intro|
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 I was working on this and I started to wonder here why isn't the purpose +
 the presence of a TAP onion key in the extend_info_t object not enough to
 rule out v2 HS?

 As an example, HSv3 never sets a TAP onion key so it can simply never hit
 true there. Is the goal to have an _explicit_ flag that identifies the
 circuits HS version? Tbh, just to have that, it requires quite a bit of
 gymnastic and added flags for some gain I'm not sure I understand?

 A straight forward way would be to add a flag to the `extend_info_t` so
 the v2 and v3 subsystem can put the right version in there. But how is
 that different from "setting a TAP key" and "not setting a tap key" ?

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

Re: [tor-bugs] #24509 [Core Tor/Tor]: circuit_can_use_tap() should only allow TAP for v2 onion services

[Tor Bug Tracker & Wiki]

#24509: circuit_can_use_tap() should only allow TAP for v2 onion services
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, security-low,   |  Actual Points:
  easy, intro|
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  accepted => needs_information


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

Re: [tor-bugs] #25173 [Core Tor/Tor]: No Control Socket when DisableNetwork and User options are set

[Tor Bug Tracker & Wiki]

#25173: No Control Socket when DisableNetwork and User options are set
--+--
 Reporter:  iry   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by iry):

 I am too afraid to say it is a Tor bug because I may be the one who did
 something wrong. Therefore, could anyone please help me to check 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] #25173 [Core Tor/Tor]: No Control Socket when DisableNetwork and User options are set

[Tor Bug Tracker & Wiki]

#25173: No Control Socket when DisableNetwork and User options are set
--+--
 Reporter:  iry   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by iry):

 For temporary workaround using systemd in Debian, I put these lines in the
 /lib/systemd/system/tor@default.service.d/controlport-workaround.service :

 {{{

 [Service]
 ExecStartPost=/bin/kill -HUP ${MAINPID}
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25173 [Core Tor/Tor]: No Control Socket when DisableNetwork and User options are set

[Tor Bug Tracker & Wiki]

#25173: No Control Socket when DisableNetwork and User options are set
--+--
 Reporter:  iry   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 To successfully reproduce this, we need:

 0. set DisableNetwork to 1
 1. use User option as part of the Tor configuration
 2. run sudo Tor from a different user in a different group

 Here are the specific steps to reproduce it. I tested it on Debian
 Stretch but it should be distribution independent:

 user at host:~$ cat /home/user/my.torrc
 DataDirectory /tmp/tor
 ControlSocket /tmp/tor/control.sock
 ControlSocketsGroupWritable 1
 CookieAuthentication 1
 CookieAuthFileGroupReadable 1
 CookieAuthFile /tmp/tor/control.authcookie
 SocksPort unix:/tmp/tor/socks.sock

 user at host:~$ sudo /usr/bin/install -Z \
 -m 02755 -o debian-tor \
 -g debian-tor -d /tmp/tor

 user at host:~$ ls -ld /tmp/tor/; ls -l /tmp/tor/
 drwxr-s--- 2 debian-tor debian-tor 40 Feb  3 18:19 /tmp/tor/
 total 0

 user at host:~$ sudo /usr/bin/tor \
 -f /home/user/my.torrc \
 --User debian-tor \
 --DisableNetwork 1

 There should be control.sock, but not:

 user at host:~$ ls -ld /tmp/tor/; sudo ls -l /tmp/tor/
 drwx--S--- 2 debian-tor debian-tor 100 Feb  3 20:00 /tmp/tor/
 total 8
 -rw-r- 1 debian-tor debian-tor  32 Feb  3 20:00 control.authcookie
 -rw--- 1 debian-tor debian-tor   0 Feb  3 20:00 lock
 -rw--- 1 debian-tor debian-tor 215 Feb  3 20:00 state

 To let Tor really open the control.sock, we need to reload Tor (yes,
 even though we just start it):

 user at host:~$ ps -A | grep tor
   863 ?00:00:00 xenstore-watch
   927 ?00:00:04 tor-controlport
 11851 pts/000:00:00 tor

 user at host:~$ sudo /bin/kill -HUP 11851

 user at host:~$ ls -ld /tmp/tor/; sudo ls -l /tmp/tor/
 drwx--S--- 2 debian-tor debian-tor 120 Feb  3 20:01 /tmp/tor/
 total 8
 -rw-r- 1 debian-tor debian-tor  32 Feb  3 20:01 control.authcookie
 srw-rw 1 debian-tor debian-tor   0 Feb  3 20:01 control.sock
 -rw--- 1 debian-tor debian-tor   0 Feb  3 20:01 lock
 -rw--- 1 debian-tor debian-tor 215 Feb  3 20:01 state

 I guess the reason Yawning was not able to reproduce it is because User
 option was not set:

 user at host:~$ sudo -u debian-tor \
 /usr/bin/tor -f /home/user/my.torrc \
 --DisableNetwork 1

 [notice] Opening Control listener on /tmp/tor/control.sock

 I was thinking Tor fixing /tmp/tor/ to 2700 may be the reason, but then
 I cannot explain why this will work with /tmp/tor/ set to 2700:

 user at host:~$ sudo /usr/bin/tor \
 -f /home/user/my.torrc \
 --User debian-tor \
 --DisableNetwork 0

 [notice] Opening Control listener on /tmp/tor/control.sock

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

Re: [tor-bugs] #25141 [Core Tor/Tor]: enabling CellStatistics results in gigabytes of incremental memory consumption

[Tor Bug Tracker & Wiki]

#25141: enabling CellStatistics results in gigabytes of incremental memory
consumption
-+-
 Reporter:  starlight|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.9
 Severity:  Major| Resolution:
 Keywords:  031-backport, 029-backport, ddos,|  Actual Points:
  must-fix-before-033-stable |
Parent ID:  #24806   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by robgjansen):

 TL;DR

 These stats are useful for traffic modeling. I think a fine plan is to
 recommend to phase out cell statistics, with the goal of replacing them in
 the long term with more useful privacy-preserving measurements using the
 new PrivCount protocol when its ready, such as bytes-per-stream and
 streams-per-circuit.

 Data point about RAM usage:

 I've had the `CellStatistics` option enabled on my fast relays for a
 couple of years now. I've noticed that RAM usage on any of the relays
 would occasionally increase above 2 GiB (even when I temporarily
 experimented with `MaxMemInQueues 512 MB`), but I never linked it to
 `CellStatistics`. I've now disabled `CellStatistics` because RAM has
 recently become a bit of a problem for other reasons.

 Do we still care about cell statistics?

 Theoretically, cell statistics can help us understand how well our test
 networks model the conditions of the real Tor network, which would be
 useful for test networks that actually try to faithfully model the
 conditions of the real Tor network (like [https://shadow.github.io
 Shadow]). For example, we could run a bunch of clients in the test network
 that are initiating stream transfers according to some understanding of
 client usage, and then we collect the cell stats on the relays in the test
 network and compare them to the stats from the public network. How close
 we are provides a measure of fidelity. I actually did this in the original
 [http://www.robgjansen.com/publications/shadow-ndss2012.pdf Shadow paper].

 However, circuit-level cell information by itself is not the greatest for
 informing how the clients in the test network should generate traffic in
 the first place. For that, we need a combination of stream-level and
 circuit-level information. From a client modeling perspective, I need to
 know how many streams each client should create, how much to download on
 each stream, how many pauses to add and how long to pause, etc. Circuits
 and cells are a second-level effect of the client model.

 The privacy implications are also worth considering (some concerns raised
 [https://lists.torproject.org/pipermail/metrics-
 team/2016-January/57.html here], and moved
 [https://lists.torproject.org/pipermail/tor-dev/2016-February/010398.html
 here]). I think individual relay stats are much more specific that what we
 need; for modeling purposes, we lose very little utility by using
 aggregate network results, but they are much safer.

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

Re: [tor-bugs] #25140 [Core Tor/Tor]: Parse only .torrc files in torrc.d directory

[Tor Bug Tracker & Wiki]

#25140: Parse only .torrc files in torrc.d directory
--+
 Reporter:  iry   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.1-alpha
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by iry):

 It seems still take a while before 0.3.3 becomes stable. But I notice
 that:

 
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases

 > For the most recent supported stable release only, we intend that:
 >Smaller bugs that significantly impact user experience will get
 fixed.

 Is it possible to get the fix into 0.3.2, 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] #25140 [Core Tor/Tor]: Parse only .torrc files in torrc.d directory

[Tor Bug Tracker & Wiki]

#25140: Parse only .torrc files in torrc.d directory
--+
 Reporter:  iry   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.1-alpha
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by iry):

 >What if we created a new syntax, like: %include /etc/torrc.d/*.conf

 My thoughts on this just in case people do not notice it:
 https://lists.torproject.org/pipermail/tor-dev/2018-February/012899.html

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

Re: [tor-bugs] #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_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  s8-errors |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+
Changes (by catalyst):

 * status:  needs_review => needs_revision


Comment:

 I agree with dgoulet.  I also agree with nickm on deferring checking of
 urandom seeding to another ticket.

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

Re: [tor-bugs] #25140 [Core Tor/Tor]: Parse only .torrc files in torrc.d directory

[Tor Bug Tracker & Wiki]

#25140: Parse only .torrc files in torrc.d directory
--+
 Reporter:  iry   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.1-alpha
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by iry):

 > implement %include /etc/torrc.d/*.extension syntax

 I have been thinking about this for a while. I still find supporting a
 very flexible extension name may cause incompatibility between different
 distros and confusion to users and developers.

 How do you like the idea to add another flag named something like
 `StrictParsing` which will let Tor only parse .config files when it is set
 to 1?

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

Re: [tor-bugs] #25140 [Core Tor/Tor]: Parse only .torrc files in torrc.d directory

[Tor Bug Tracker & Wiki]

#25140: Parse only .torrc files in torrc.d directory
--+
 Reporter:  iry   |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.1-alpha
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by iry):

 Current result from the discussion on @tor-dev:
 https://lists.torproject.org/pipermail/tor-dev/2018-February/012902.html

 * %include /etc/torrc.d means parsing all the files in the directory
 * implement %include /etc/torrc.d/*.extension syntax
 * let Tor log each config file it loads
 * warn on potentially unexpected files
 * document *.conf as the recommend usage
 * document how to manually migrate from * to *.conf
 * recommend /etc/torrc.d/*.conf as "a default extension for packagers"

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

Re: [tor-bugs] #23250 [Core Tor/Tor]: tor-0.3.0.10: test failure on NetBSD

[Tor Bug Tracker & Wiki]

#23250: tor-0.3.0.10: test failure on NetBSD
-+-
 Reporter:  wiz  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bsd, test, 032-backport, |  Actual Points:
  031-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * status:  new => needs_information


Comment:

 Something seems to have gone wrong inside the backtrace test. But I think
 there's no real hope of solving this one unless we can reproduce it. Does
 this still happen on master with NetBSD?

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

Re: [tor-bugs] #14006 [Core Tor/Tor]: Hidden service error: "We'd like to launch a circuit to handle a connection, but we already have 32 general-purpose client circuits..."

[Tor Bug Tracker & Wiki]

#14006: Hidden service error: "We'd like to launch a circuit to handle a
connection, but we already have 32 general-purpose client circuits..."
---+---
 Reporter:  asn|  Owner:  (none)
 Type:  defect | Status:
   |  needs_information
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs circuit-management scaling  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by dgoulet):

 * status:  new => needs_information
 * cc: dgoulet (removed)


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

Re: [tor-bugs] #25172 [Internal Services/Tor Sysadmin Team]: static website for support-staging.torproject.org

[Tor Bug Tracker & Wiki]

#25172: static website for support-staging.torproject.org
-+
 Reporter:  hiro |  Owner:  tpa
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

 * status:  new => 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] #24343 [Core Tor/Tor]: Remove dead code and doc regarding the old SocksSocket option

[Tor Bug Tracker & Wiki]

#24343: Remove dead code and doc regarding the old SocksSocket option
---+
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  defect | Status:  needs_review
 Priority:  Low|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-doc, deadcode  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dgoulet):

 * status:  assigned => needs_review


Comment:

 Most of it is code removal except for the configuration option.

 I've moved `SocksSocketsGroupWritable` to become an alias for the new name
 `UnixSocksGroupWritable` because that option only applies to Unix socket
 for the SocksPort.

 Branch: `ticket24343_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

Re: [tor-bugs] #17945 [Core Tor/Tor]: Stop Tor2Web connecting to (Rendezvous) Single Onion Services

[Tor Bug Tracker & Wiki]

#17945: Stop Tor2Web connecting to (Rendezvous) Single Onion Services
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor2web, tor-hs, 029-proposed, 029   |  Actual Points:
  -teor-no, needs-design, needs-proposal-maybe,  |
  single-onion   |
Parent ID:  #24962   | Points:  5
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * status:  new => needs_information


Comment:

 Ticket #24902 adds an option to refuse establish rdv from single hop
 client.

 I think we can extend this to relays that is if the previous and next hop
 in a rendezvous circuit are unauthenticated that is client connection, the
 circuit collapses.

 I'm just wondering here the bridge factor. I guess even if a SOS is
 configured to use a bridge (is it even possible?), it would require a
 client to single hop through a bridge for the RP to deny it. And maybe we
 don't care with such a crazy setup?

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

Re: [tor-bugs] #20104 [Core Tor/Tor]: Tor2web should connect to HSDirs over a 3-hop path

[Tor Bug Tracker & Wiki]

#20104: Tor2web should connect to HSDirs over a 3-hop path
-+---
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, tor2web  |  Actual Points:
Parent ID:  #17945   | Points:  1
 Reviewer:   |Sponsor:
-+---
Changes (by dgoulet):

 * status:  new => needs_information


Comment:

 I'm personally very reluctant to touch the `Tor2web` code because I
 seriously don't want to encourage anyone running this not now not after,
 never.

 And this is also basically touching code that is *never* tested on our
 side nor even packaged by distros. So even shipping Tor2web code in tor
 today is imo border line reckless.

 Regardless of my hate of Tor2web ;), I might prefer much more that HSDir
 defends against that with #24964 so we can avoid a DoS attack.

 At least right now, clients fetching descriptor directly from HSDir are
 putting less load on the network.

 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] #24228 [Core Tor/Tor]: Tor keeps on creating new circuits even when it's idle

[Tor Bug Tracker & Wiki]

#24228: Tor keeps on creating new circuits even when it's idle
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Very High |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:  duplicate
 Keywords:  tor-circuit   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

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


Comment:

 Replying to [comment:17 mikeperry]:
 > The 3X change is done in my patches for #24769, and I also added
 consensus params to let us tweak it live. I think this ticket can be
 dupped to that one.

 Awesome. Closing this one then in favor of #24769. Thanks!

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

[tor-bugs] #25172 [Internal Services/Tor Sysadmin Team]: static website for support-staging.torproject.org

[Tor Bug Tracker & Wiki]

#25172: static website for support-staging.torproject.org
-+-
 Reporter:  hiro |  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:   |
-+-
 This is needed to test the new support portal.

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

Re: [tor-bugs] #23250 [Core Tor/Tor]: tor-0.3.0.10: test failure on NetBSD

[Tor Bug Tracker & Wiki]

#23250: tor-0.3.0.10: test failure on NetBSD
-+-
 Reporter:  wiz  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  bsd, test, 032-backport, |  Actual Points:
  031-backport   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 Anyone has an idea of what's failing exactly here? ...

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

Re: [tor-bugs] #25171 [Core Tor/Tor]: Clarify 'recognized' field in tor-spec

[Tor Bug Tracker & Wiki]

#25171: Clarify 'recognized' field in tor-spec
--+
 Reporter:  atagar|  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Very Low  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #25171 [Core Tor/Tor]: Clarify 'recognized' field in tor-spec

[Tor Bug Tracker & Wiki]

#25171: Clarify 'recognized' field in tor-spec
--+--
 Reporter:  atagar|  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Very Low  |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by atagar):

 * status:  new => 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

[tor-bugs] #25171 [Core Tor/Tor]: Clarify 'recognized' field in tor-spec

[Tor Bug Tracker & Wiki]

#25171: Clarify 'recognized' field in tor-spec
--+
 Reporter:  atagar|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very Low  |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Trivial   |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 Our tor-spec left me pretty mystified what the 'recognized' field actually
 was. It discussed what to do when it was zero, but not what the field
 *was* or what non-zero meant. Thankfully Roger filled me in over tasty,
 tasty pizza.

 Patch available in the 'recognized' branch of my repo...

 https://gitweb.torproject.org/user/atagar/torspec.git/commit/?h=recognized

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

Re: [tor-bugs] #24909 [Core Tor/Tor]: Update dir-spec for new compression options

[Tor Bug Tracker & Wiki]

#24909: Update dir-spec for new compression options
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, doc, tor-dir, review-  |  Actual Points:
  group-31   |
Parent ID:   | Points:  0.5
 Reviewer:  ahf  |Sponsor:
-+-

Comment (by nickm):

 Oh!  Do we mention that HS downloads should be zlib/identity only
 somewhere?  If not, we should.

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

Re: [tor-bugs] #20218 [Core Tor/Tor]: Fix and refactor and redocument routerstatus_has_changed

[Tor Bug Tracker & Wiki]

#20218: Fix and refactor and redocument routerstatus_has_changed
-+-
 Reporter:  nickm|  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:  ipv6, 029-proposed, tor-control, |  Actual Points:  0.5
  easy, spec-conformance, review-group-31|
Parent ID:   | Points:  .1
 Reviewer:  nickm|Sponsor:
-+-
Changes (by nickm):

 * reviewer:   => nickm


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

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

[Tor Bug Tracker & Wiki]

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

 * reviewer:   => nickm


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

Re: [tor-bugs] #24909 [Core Tor/Tor]: Update dir-spec for new compression options

[Tor Bug Tracker & Wiki]

#24909: Update dir-spec for new compression options
-+-
 Reporter:  teor |  Owner:  nickm
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.1.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-spec, doc, tor-dir, review-  |  Actual Points:
  group-31   |
Parent ID:   | Points:  0.5
 Reviewer:  ahf  |Sponsor:
-+-
Changes (by nickm):

 * reviewer:   => ahf


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

Re: [tor-bugs] #25163 [Core Tor/Tor]: rephist: Remove unused counters in or_history_t

[Tor Bug Tracker & Wiki]

#25163: rephist: Remove unused counters in or_history_t
---+---
 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:  implemented
 Keywords:  tor-rephist, code-removal  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

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


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

Re: [tor-bugs] #25163 [Core Tor/Tor]: rephist: Remove unused counters in or_history_t

[Tor Bug Tracker & Wiki]

#25163: rephist: Remove unused counters in or_history_t
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-rephist, code-removal  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by nickm):

 {{{
  8 files changed, 11 insertions(+), 331 deletions(-)
 }}}

 Merged to master!

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

Re: [tor-bugs] #24228 [Core Tor/Tor]: Tor keeps on creating new circuits even when it's idle

[Tor Bug Tracker & Wiki]

#24228: Tor keeps on creating new circuits even when it's idle
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-circuit   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by mikeperry):

 Replying to [comment:16 dgoulet]:
 > Replying to [comment:14 mikeperry]:
 > > That said, 10 minutes *is* 3X faster than we really need. We could
 lower this by a factor of three and still get it done inside of the
 connection idle time for reduced padding clients.
 >
 > Considering #24902 DoS mitigation, I might be in favor of this
 especially if we can get it in the time frame we are comfortable with.
 >
 > @mikeperry, where/what should be changed for this to happen if you are
 still OK?

 The 3X change is done in my patches for #24769, and I also added consensus
 params to let us tweak it live. I think this ticket can be dupped to that
 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] #25137 [Obfuscation/Censorship analysis]: Tor blocked in UAE

[Tor Bug Tracker & Wiki]

#25137: Tor blocked in UAE
-+-
 Reporter:  mwolfe   |  Owner:  dcf
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Obfuscation/Censorship analysis  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  censorship block ae  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by mwolfe):

 The bug tracker sends me an e-mail every time someone adds a comment, but
 I can't reply to the e-mail, I have to log in. I should probably check the
 bug tracker from the Macintosh side. As it is, I know a comment has been
 added only when I check my e-mail on the Windows side.

 My e-mail account is set up to fake a US address, since it requires me to
 give them my mobile number if I log in from a different country. So my
 non-local e-mail (to places like Tor, which is banned here) is running in
 Windows 10 (easier to set Exit {us} in Windows than on the Mac).

 Right now, I'm in Windows 10, but I'll try Snowflake when I'm back on my
 Mac. I've already downloaded 8.01, but I didn't notice Snowflake. I'll
 look later tonight and let you know if it works.

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

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_review
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201802R  |  Actual Points:
Parent ID:  #24689 | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--

Comment (by mcs):

 I almost forgot: for the Moat connection to work reliably, you also need
 to remove the SOCKS optimistic data feature from Tor Browser (#19910).

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

Re: [tor-bugs] #23633 [Core Tor/Tor]: Why does roflcopter have an empty protocol line in the consensus?

[Tor Bug Tracker & Wiki]

#23633: Why does roflcopter have an empty protocol line in the consensus?
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Although, did the consensus was published with an *empty* pr line
 (different from non existent)? If so, I'm not sure that should be? I think
 we put in a default string no?

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

Re: [tor-bugs] #23633 [Core Tor/Tor]: Why does roflcopter have an empty protocol line in the consensus?

[Tor Bug Tracker & Wiki]

#23633: Why does roflcopter have an empty protocol line in the consensus?
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

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


Comment:

 Relay is gone and most likely was running a custom tor or modified version
 or who knows.

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

Re: [tor-bugs] #24228 [Core Tor/Tor]: Tor keeps on creating new circuits even when it's idle

[Tor Bug Tracker & Wiki]

#24228: Tor keeps on creating new circuits even when it's idle
--+
 Reporter:  asn   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Very High |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-circuit   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by dgoulet):

 Replying to [comment:14 mikeperry]:
 > That said, 10 minutes *is* 3X faster than we really need. We could lower
 this by a factor of three and still get it done inside of the connection
 idle time for reduced padding clients.

 Considering #24902 DoS mitigation, I might be in favor of this especially
 if we can get it in the time frame we are comfortable with.

 @mikeperry, where/what should be changed for this to happen if you are
 still 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] #24426 [Core Tor/Tor]: Reliability: Make sure onion services don't publish until they have (nearly) all hsdirs' descriptors

[Tor Bug Tracker & Wiki]

#24426: Reliability: Make sure onion services don't publish until they have
(nearly) all hsdirs' descriptors
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

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


Comment:

 Nothing to do here, we should be ok with #23170.

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

Re: [tor-bugs] #24509 [Core Tor/Tor]: circuit_can_use_tap() should only allow TAP for v2 onion services

[Tor Bug Tracker & Wiki]

#24509: circuit_can_use_tap() should only allow TAP for v2 onion services
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  defect   | Status:
 |  accepted
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs, security-low,   |  Actual Points:
  easy, intro|
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * owner:  (none) => dgoulet
 * reviewer:  dgoulet =>
 * status:  needs_revision => accepted


Comment:

 Taking over after asking irl on IRC.

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

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

[Tor Bug Tracker & Wiki]

#25117: Resolve TROVE-2018-002
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  assigned
 Priority:  High  |  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 dgoulet):

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


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

Re: [tor-bugs] #24449 [Core Tor/Tor]: sched: KIST scheduler should handle limited or failed connection write

[Tor Bug Tracker & Wiki]

#24449: sched: KIST scheduler should handle limited or failed connection write
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:  #23993| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

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


Comment:

 No chance I can get this done in 033... It requires quite a bit of change
 in terms of interface and code flow.

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

Re: [tor-bugs] #25170 [Core Tor/Tor]: explicitly mention email address to contact for rejected relays

[Tor Bug Tracker & Wiki]

#25170: explicitly mention email address to contact for rejected relays
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Minor | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 I'd take a patch for this in 0.3.3 if somebody writes it soon.  I'd
 suggest that the test say "set a valid email address in ContactInfo"
 rather than just "set a ContactInfo"

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

Re: [tor-bugs] #25167 [Metrics/Website]: Metrics website country entry has "??" in "Cura??ao"

[Tor Bug Tracker & Wiki]

#25167: Metrics website country entry has "??" in "Cura??ao"
-+-
 Reporter:  cypherpunks  |  Owner:  karsten
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Trivial  | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by karsten):

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


Comment:

 Fixed. Thanks for the report! Closing.

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

Re: [tor-bugs] #24818 [Core Tor/Tor]: Make the hard-coded authorities into a separate include file with a standard format

[Tor Bug Tracker & Wiki]

#24818: Make the hard-coded authorities into a separate include file with a
standard format
--+
 Reporter:  teor  |  Owner:  teor
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  torspec, tor-dirauth  |  Actual Points:
Parent ID:  #24786| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  needs_review => needs_revision
 * keywords:  torspec, tor-dirauth, review-group-29, review-group-31 =>
 torspec, tor-dirauth


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

Re: [tor-bugs] #24818 [Core Tor/Tor]: Make the hard-coded authorities into a separate include file with a standard format

[Tor Bug Tracker & Wiki]

#24818: Make the hard-coded authorities into a separate include file with a
standard format
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.4.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  torspec, tor-dirauth, review-|  Actual Points:
  group-29, review-group-31  |
Parent ID:  #24786   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by nickm):

 Replying to [comment:14 teor]:
 > Do you want to rephrase any of this existing text?
 >
 >Libraries SHOULD parse and cache the most recent version of these
 lists
 >during their build or release processes. Libraries MUST NOT retrieve
 the
 >lists by default every time they are deployed or executed.

 I'd suggest maybe:

 Library developers SHOULD be sure that they ship the most recent
 version of these lists, and SHOULD check for the freshness of these lists
 as part of their build or release process. Library developers SHOULD NOT
 automatically replace these files without human intervention.

 I think auto-fetching these, even with https, is a dangerous idea.

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

Re: [tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_review
 Priority:  Very High  |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201802R  |  Actual Points:
Parent ID:  #24689 | Points:
 Reviewer: |Sponsor:  Sponsor4
---+--
Changes (by mcs):

 * keywords:  TorBrowserTeam201802 => TorBrowserTeam201802R
 * status:  new => needs_review


Comment:

 Kathy and I are making this code available for review. It has been in a
 nearly finished state for a long time. The patch is here:
 https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug23136-02

 There are still some dependencies that need to be resolved:
 * You will need to compile and use a `meek-client` and `meek-client-
 torbrowser` that includes the fix for #24642. We do not have a new meek
 tag yet so you will need to pull the code from dcf's bug24642 branch.
 * For some reason the deployed BridgeDB does not return any bridges (see
 https://trac.torproject.org/projects/tor/ticket/24432#comment:24). In the
 meantime, I set up a '''very temporary''' BridgeDB test server. Note that
 it is not behind a domain fronting setup, it does not use TLS, it only has
 fake bridges, and since it does not have any vanilla ones you should
 request obfs4 bridges. Here are pref settings for the test server:
  pref("extensions.torlauncher.bridgedb_front", "");
  pref("extensions.torlauncher.bridgedb_reflector",
 "http://pearlcrescent.com:2000;);
  pref("extensions.torlauncher.moat_service",
 "http://pearlcrescent.com/meek/moat;);
  pref("extensions.torlauncher.bridgedb_bridge_type", "obfs4");
 Oh, and our test server uses really easy CAPTCHAs except for one BridgeDB
 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] #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:  dgoulet
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-test, 029-backport,  |  Actual Points:
  031-backport, 032-backport |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Merged to master; marking as backportable.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #25170 [Core Tor/Tor]: explicitly mention email address to contact for rejected relays

[Tor Bug Tracker & Wiki]

#25170: explicitly mention email address to contact for rejected relays
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Minor |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 from the discussion on bad-relays@..

 When we reject relays the operator gets to see something like this in
 their logs:

 {{{
 [warn] http status 400 ("Fingerprint is marked rejected -- please contact
 us?") response from dirserver 'IP:Port'. Please correct.
 }}}

 Lets change this to:

 "Fingerprint is marked rejected, if you think this is a mistake please set
 a ContactInfo and send an email to bad-rel...@lists.torproject.org
 mentioning your fingerprint(s)"

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

Re: [tor-bugs] #25163 [Core Tor/Tor]: rephist: Remove unused counters in or_history_t

[Tor Bug Tracker & Wiki]

#25163: rephist: Remove unused counters in or_history_t
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-rephist, code-removal  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by arma):

 i haven't looked at the patch, but dgoulet filed this "why not get this of
 this stuff" ticket after talking to me on irc, so i am ok with the
 concept.

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

Re: [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:  dgoulet
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.3.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  tor-test, 029-backport,  |  Actual Points:
  031-backport, 032-backport |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by dgoulet):

 * keywords:  tor-test => tor-test, 029-backport, 031-backport, 032-backport


Comment:

 Oh and the 029 branch for backport: `bug25113_029_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

Re: [tor-bugs] #24639 [Core Tor/Tor]: After I updated my relay to Tor 0.3.2.7-rc I got a large amount of Warn errors

[Tor Bug Tracker & Wiki]

#24639: After I updated my relay to Tor 0.3.2.7-rc I got a large amount of Warn
errors
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  duplicate
 Keywords: |  Actual Points:
Parent ID:  #25061 | Points:
 Reviewer: |Sponsor:
---+
Changes (by dgoulet):

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


Comment:

 Executive decision to try to shrink down the 033 tickets, I'm calling this
 a duplicate of #25061 and also pointing out that #24767 might help the
 bootstrap as well if tor does try multiple time to the same unreachable
 relay.

 I'll keep the parent for future ref if needed.

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

Re: [tor-bugs] #23650 [Core Tor/Tor]: Tor source code has many typos

[Tor Bug Tracker & Wiki]

#23650: Tor source code has many typos
---+
 Reporter:  cypherpunks|  Owner:  arma
 Type:  defect | Status:  closed
 Priority:  Very Low   |  Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Trivial| Resolution:  fixed
 Keywords:  easy, review-group-31  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by nickm):

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


Comment:

 Okay, I've merged this, with the following exceptions and tweaks:
* "planetas" in src/test/test_conscache is correct Spanish, to go along
 with "adios" earlier in that line.  I think it's intentional.
* "straight foward" in src/common/crypto.c should be "straightforward"
 (one word).
* Some of the RSA functions had moved to crypto_rsa.c, so I had to
 hand-apply those change and the ones in crypto.c.
* The following files are not maintained by us, so we shouldn't make
 trivial changes to them ourselves:
   * src/ext/curve25519_donna/README
   * src/ext/ed25519/donna/README.md
   * m4/pkg.m4
* I added a changes file in a separate commit.
* I wrapped some wide lines.

 Thanks very much for the 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

[tor-bugs] #25169 [Core Tor/Fallback Scripts]: Fallback removal for 0BEA4A88D069753218EAAAD6D22EA87B9A1319D6

[Tor Bug Tracker & Wiki]

#25169: Fallback removal for 0BEA4A88D069753218EAAAD6D22EA87B9A1319D6
---+-
 Reporter:  baelor.tor |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal |   Keywords:  fallback-change
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+-
 The relay 0BEA4A88D069753218EAAAD6D22EA87B9A1319D6 will go offline in a
 couple of months and should be removed from the fallback directory mirror
 list.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by mcs):

 Replying to [comment:13 ro0ter]:
 > mcs, I can`t make it work since the tor launcher detects my change and
 does not agree... I`d rather not attach a screenshot, not useful, but
 here`s the text:
 > ...

 I forgot that you will be prompted (since you have not previously
 connected). To avoid the prompt, set
 `extensions.torlauncher.prompt_at_startup` to `false` by ensuring that the
 following line in present in your `prefs.js` file:
  user_pref("extensions.torlauncher.prompt_at_startup", false);
 The `prefs.js` file is located in your browser profile. The path is
 `Browser\TorBrowser\Data\Browser\profile.default\prefs.js.

 Replying to [comment:14 ro0ter]:
 > One more question: what about password containing both double quotes and
 pound?
 Our code already knew how to escape double quotes. You can use `\"` to
 include them in your torrc, e.g.,
  HTTPSProxyAuthenticator "mcs:secret\"quote\"#1"

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

Re: [tor-bugs] #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:  dgoulet
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-test  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  accepted => merge_ready


Comment:

 Kind of trivial fix so `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] #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:  dgoulet
 Type:  defect| Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-test  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

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


Comment:

 Quick discussion with nickm on IRC, bumping to 10msec is most likely what
 we want because we need to check for the synchronization between time
 read. Not ideal fix but for now that should do it.

 If we ever encounter a system that will have a 10msec+ gap between the
 function call, we'll adapt at that point.

 Branch: `bug25113_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

Re: [tor-bugs] #25096 [Core Tor/Tor]: Bump up NumNTorsPerTAP to squeeze out v2 onion service traffic?

[Tor Bug Tracker & Wiki]

#25096: Bump up NumNTorsPerTAP to squeeze out v2 onion service traffic?
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 I'm fine with this if you want to do it.  200 is the highest I'd go right
 now; it might be more reasonable to test 150 and see what effect that has.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  ffmancera
 Type:  enhancement   | Status:  assigned
 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 dgoulet):

 * status:  needs_review => assigned
 * owner:  (none) => ffmancera


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  ffmancera
 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  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+
Changes (by dgoulet):

 * 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] #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:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.3.1-alpha
 Severity:  Normal| Resolution:
 Keywords:  tor-test  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

 * status:  new => needs_information
 * keywords:   => tor-test


Comment:

 Wow ok so there is literally a 4msec gap between the `nsecc1` and `msecc1`
 function call on armel.

 {{{
   nsecc1 = monotime_coarse_absolute_nsec();
   [usecc1 = monotime_coarse_absolute_usec();]
   msecc1 = monotime_coarse_absolute_msec();
 }}}

 So this test is doomed to fail on slow system because we get `nsecc1`
 before `msecc1` so shouldn't be `msecc1 >= nsecc1` instead?

 {{{
   tt_u64_op(msecc1, OP_LE, nsecc1 / 100 + 1);
   -> msecc1 <= nsecc1
 }}}

 Actually the whole set of checks between the `1` variables seems a bit
 weird, it assumes the clock gettime calls to be in the same msec range.

 Also, `clock_gettime()` is a vdso in ARM exported since Linux 4.1 so if
 the build machine has an older kernel, the time gaps can be bigger.

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

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

[Tor Bug Tracker & Wiki]

Batch modification to #25074 by dgoulet:


Action: reassign

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

Re: [tor-bugs] #25095 [Core Tor/Tor]: Update dir-spec.txt with recent consensus param additions

[Tor Bug Tracker & Wiki]

#25095: Update dir-spec.txt with recent consensus param additions
---+
 Reporter:  arma   |  Owner:  dgoulet
 Type:  task   | Status:  accepted
 Priority:  Medium |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-spec, tor-dos  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dgoulet):

 * cc: dgoulet (removed)
 * owner:  (none) => dgoulet
 * status:  new => accepted
 * type:  defect => task
 * keywords:  torspec => tor-spec, tor-dos


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

Re: [tor-bugs] #2667 [Core Tor/Tor]: Exits should block reentry into the tor network

[Tor Bug Tracker & Wiki]

#2667: Exits should block reentry into the tor network
-+-
 Reporter:  mikeperry|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:
 Keywords:  needs-proposal, tor-relay,   |  Actual Points:
  SponsorU-deferred  | Points:
Parent ID:   |  medium/large
 Reviewer:   |Sponsor:
-+-

Comment (by dgoulet):

 Nickm's attempt at having an interface to store IP addr with bloom filter:
 `address_set_029`

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

Re: [tor-bugs] #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:  s8-errors |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+

Comment (by dgoulet):

 My two cents.

 NOTICE level should be information the operator needs or is useful to
 know. And I also think it is useful to provide basic status information at
 bootup so if we ever get a report about a misbehaving relay, we can ask
 for those "status" line.

 With this `getrandom()` thing, if Tor stops because it can't use its
 crypto, we ought to put a warning on why even though the users would be
 "omgwtfbbq is that?". At least, at that point, there are possible action
 items that the operator can do including seeking support about that "in
 your face" log line.

 If tor recovers from it, I would argue that it should be at NOTICE so the
 operator can see that it is not critical, that tor did recover but actions
 can still be taken to fix it.

 For instance this, I think it should be at NOTICE for the above reasons.
 This usually happens when someones run a tor not built for their system
 like Stretch Debian tor package on Ubuntu 10.04. Having the notice log
 would allow the operator to try to fix it or simply ignore it. At INFO, I
 believe most of the users will just never notice it.

 {{{
 log_info(LD_CRYPTO, "Can't get entropy from getrandom()."
  " You are running a version of Tor built to support"
  " getrandom(), but the kernel doesn't implement this"
  " function--probably because it is too old?"
  " Trying fallback method instead.");
 }}}

 In a nutshell, +1 on removing the warnings *except* if Tor does stop. And
 then +1 on NOTICE for useful logging for which the operator can notice.

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

Re: [tor-bugs] #20615 [Core Tor/Tor]: Your Guard is failing an extremely large amounts of circuits.

[Tor Bug Tracker & Wiki]

#20615: Your Guard is failing an extremely large amounts of circuits.
--+
 Reporter:  bug_bunny |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.2.8.9
 Severity:  Normal| Resolution:  not a bug
 Keywords:  performance   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by dgoulet):

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


Comment:

 Not much we can do here... This warning is unfortunately something that
 happens and can be often caused by the client seeing it. And this is more
 a thing right now with the ongoing load.

 Closing this because there is really no action items for tor and we are
 working actively on improving the load situation on the network.

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

Re: [tor-bugs] #25163 [Core Tor/Tor]: rephist: Remove unused counters in or_history_t

[Tor Bug Tracker & Wiki]

#25163: rephist: Remove unused counters in or_history_t
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  defect | Status:  merge_ready
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-rephist, code-removal  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by dgoulet):

 * status:  accepted => 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] #25163 [Core Tor/Tor]: rephist: Remove unused counters in or_history_t

[Tor Bug Tracker & Wiki]

#25163: rephist: Remove unused counters in or_history_t
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  defect | Status:  accepted
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-rephist, code-removal  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by dgoulet):

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


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