Re: [tor-bugs] #28334 [Core Tor/Nyx]: Text fields wider than the screeen cropped

[Tor Bug Tracker & Wiki]

#28334: Text fields wider than the screeen cropped
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:
 Keywords:  curses|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by atagar):

 Sorry wagon, I'm unsure what you mean by 'external editor' and, unless I'm
 missing something, readline is mutually exclusive with curses.

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

Re: [tor-bugs] #28334 [Core Tor/Nyx]: Text fields wider than the screeen cropped

[Tor Bug Tracker & Wiki]

#28334: Text fields wider than the screeen cropped
--+--
 Reporter:  wagon |  Owner:  atagar
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Core Tor/Nyx  |Version:  Tor: 0.3.4.9
 Severity:  Normal| Resolution:
 Keywords:  curses|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by wagon):

 Replying to [comment:4 atagar]:
 > That's will be tricky to address
 In such cases you could call some external editor or add readline to Nyx.
 If you do the latter, you could implement
 
[[https://trac.torproject.org/projects/tor/ticket/28300#comment:5|autocompletition]]
 too.

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

Re: [tor-bugs] #13977 [Core Tor/Tor]: Evaluate alternate SSL/TLS libraries: CyaSSL, GnuTLS, ...

[Tor Bug Tracker & Wiki]

#13977: Evaluate alternate SSL/TLS libraries: CyaSSL, GnuTLS, ...
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  unspecified
 Severity:  Normal   | Resolution:
 Keywords:  lorax tor-client portability ssl |  Actual Points:
  openssl|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks3):

 GnuTLS might be helpful for anti-censorship use, despite their
 incompatible licenses.

 I live in China and patched my own Tor with GnuTLS (using their
 `gnutls_record_send_range` to do extra padding), which works smoothly with
 vanilla bridges. Never seen GFW active probing on my bridge.

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

Re: [tor-bugs] #29004 [Core Tor/Tor]: PrivCount proof of concept: implement check counters

[Tor Bug Tracker & Wiki]

#29004: PrivCount proof of concept: implement check counters
-+-
 Reporter:  teor |  Owner:  teor
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  privcount, 040-unreached-20190109,   |  Actual Points:  0.4
  041-proposed-on-roadmap|
Parent ID:  #27908   | Points:  1
 Reviewer:  asn  |Sponsor:
-+-
Changes (by teor):

 * status:  merge_ready => needs_revision


Comment:

 Thanks for the review!

 I talked to nickm about the names, we're going to go for something between
 `pc-ge-rw-bytes` and `privcount-guard-and-exit-read-and-write-byte-count`.

 I will look at the TODOs. Maybe I should have flagged this as a work in
 progress.

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

Re: [tor-bugs] #29056 [Core Tor/Stem]: Implement bandwidth file parser and formater

[Tor Bug Tracker & Wiki]

#29056: Implement bandwidth file parser and formater
---+--
 Reporter:  juga   |  Owner:  juga
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:
Component:  Core Tor/Stem  |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-bwauth |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by teor):

 Replying to [comment:2 atagar]:
 > Thanks juga! Sounds good. Once the bwauth file format

 https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-spec.txt

 > and a method of getting them have been added to the tor spec

 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2652

 > I'd be happy to help write a parser (or merge it if ya have a patch).

 I'd encourage you to wait for the Tor features #21377 (bandwidth file
 URL), and maybe also #26698 (bandwidth-file-digest). There might be last-
 minute code or spec changes.

 For completeness:

 The spec for #26698 (bandwidth-file-digest) is:
 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2140

 bandwidth-file-headers was implemented in #26222, its spec is:
 https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2120

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

Re: [tor-bugs] #28868 [Core Tor/sbws]: best_priority() can starve the worker threads of good relays

[Tor Bug Tracker & Wiki]

#28868: best_priority() can starve the worker threads of good relays
---+---
 Reporter:  teor   |  Owner:  juga
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:  sbws: 1.0.x-final
Component:  Core Tor/sbws  |Version:  sbws: 1.0.2
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #28663 | Points:
 Reviewer: |Sponsor:
---+---

Comment (by teor):

 Replying to [comment:3 juga]:
 > Replying to [ticket:28868 teor]:
 > > `best_priority()` tries to measure unmeasured and failing relays
 first.
 > >
 > > But if `fraction_relays` or `min_relays` always fail, those relays
 will always end up first in the priority queue. (More precisely, those
 relays will end up first in the priority queue, until the results of the
 good relays ~~time out~~ are discarded for being too old.)
 > >
 > > Thinking about starvation is complicated, because of the
 `freshness_reduction_factor` on some errors.
 > >
 > > Here's a very simple algorithm that avoids starving good relays for
 failed relays:
 > > 1. Count the number of times that sbws has attempted to get a result
 from each relay.
 >
 > This is already done when writing the results: ResultError and
 ResultSuccess keep that.

 But some failures do not write a ResultError.

 > > 2. Test the relays with the lowest number of attempts first. (Don't
 check if the attempt succeeded or failed.)
 >
 > This's what i was proposing by commenting the part where it prioritizes
 ResultError measurements.

 I don't understand what you mean here.
 Can you link to the comment, or quote it?

 > >
 > > For this priority rule to work, every time a relay is queued, it must
 get a result. Here's how we can make that happen"
 > > * Modify `result_putter_error()` to store an error result to the
 queue.
 >
 > result_putter already writes ResultError.

 But result_putter_error() is called when there is an exception in
 apply_async(), and it does not write ResultError.

 > Here there're two other bugs, result_putter_error, only happens when:
 > 1. The relay being measured, doesn't have a descriptor (#28870)
 > 2. The operator hits KeyboardInterrupt (#28869)
 >
 > AFAIK, there're no other cases where the error callback is called.

 The code is complicated, so it could throw other exceptions that you
 haven't seen yet. Future code changes could also add more exceptions.

 > > * Make sure timeouts store an error result to the queue.
 > > * Add a unit test and integration test that makes sure every queued
 relay has a result.
 >
 > Testing this is hard, but i'll see.

 Replying to [comment:5 juga]:
 > > Add a unit test and integration test that makes sure every queued
 relay has a result.
 > Maybe this could be done as part of #28566 instead?.
 >
 > #28933 runs the actual scanner. It is not counting that all the relays
 get measured, though in the test network this is the case.
 >
 > Created PR without the tests:
 https://github.com/torproject/sbws/pull/328

 You'll also need to update the documentation:
 https://github.com/torproject/sbws/blob/master/docs/source/specification.rst
 #simple-relay-prioritization

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

Re: [tor-bugs] #28589 [Core Tor/sbws]: Open trac tickets for every open sbws GitHub issue (was: Open trac tickets for every open sbws issue)

[Tor Bug Tracker & Wiki]

#28589: Open trac tickets for every open sbws GitHub issue
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  sbws:
  |  1.1.x-final
Component:  Core Tor/sbws |Version:
 Severity:  Normal| Resolution:
 Keywords:  sbws-1.0-nice-moved-20181128  |  Actual Points:
Parent ID:  #27107| Points:
 Reviewer:|Sponsor:
--+

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by teor):

 Mike, if I don't get to this review on Monday, I'm going to return it to
 you. Because I'm busy with PrivCount now.

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

Re: [tor-bugs] #29077 [Obfuscation/meek]: uTLS for meek-client camouflage

[Tor Bug Tracker & Wiki]

#29077: uTLS for meek-client camouflage
--+-
 Reporter:  dcf   |  Owner:  dcf
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:  moat utls |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by dcf):

 * cc: sf (added)


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

Re: [tor-bugs] #29077 [Obfuscation/meek]: uTLS for meek-client camouflage

[Tor Bug Tracker & Wiki]

#29077: uTLS for meek-client camouflage
--+-
 Reporter:  dcf   |  Owner:  dcf
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal| Resolution:
 Keywords:  moat utls |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-

Comment (by dcf):

 I started trying this out in
  * meek branch [https://gitweb.torproject.org/pluggable-
 transports/meek.git/log/?h=utls=90d82c205c0269b87de5a6956e485225f8a9a2cb
 utls]
  * tor-browser-build branch [https://gitweb.torproject.org/user/dcf/tor-
 browser-build.git/log/?h=meek-client-
 utls=1758a67bc2f366a8af2730d924b80a5c4133eec4 meek-client-utls]

 I built a browser with these changes. It works, but not well. It hangs and
 stalls frequently, and Moat often throws errors. There are two primary
 causes for these problems.

  1. utls's interaction with Go's built-in HTTPS is awkward. In meek-client
 we use an [https://golang.org/pkg/net/http/#Transport http.Transport] to
 enable connection reuse, manage idle timeouts, etc. To hook into utls, I'm
 [https://gitweb.torproject.org/pluggable-
 transports/meek.git/commit/?h=utls=5a98c4447e8d3cb14e53b9ef15d6faa812aed226
 setting the DialTLS callback]--but setting DialTLS has the side effect of
 disabling automatic HTTP/2 support on the client. This wouldn't be a
 problem, except for the fact that with e.g. the `HelloFirefox_63` and
 `HelloChrome_70` fingerprint, utls sends a Client Hello with an ALPN that
 negotiates HTTP/2. The server starts speaking HTTP/2 while the net/http
 client, oblivious to what utls has done, continues speaking HTTP/1.1, and
 you get an error. There are more details on this problem on
 [https://github.com/refraction-networking/utls/issues/16 GitHub ticket
 #16].

 As a workaround for the ALPN mismatch issue, I tried specifying the
 `HelloRandomizedNoALPN` client. Randomized means it picks fingerprint
 features randomly, and NoALPN means it won't negotiate HTTP/2. The loss of
 HTTP/2 is a bummer, but the bigger problem is

  2. The randomized fingerprint is re-randomized for every new TLS
 connection, and occasionally it generates a Client Hello that either (a)
 the server rejects or (b) causes the server to select a feature that the
 client advertised in its fake fingerprint but doesn't actually support.
 When this happens, you get an error in the meek-client log like
 {{{
 error in handling request: tls: server selected unsupported group
 }}}
 At the tor level, you get a stall until tor decides to try the bridge
 again. With Moat, you get an error dialog like "Unable to obtain a bridge
 from BridgeDB. NS_ERROR_NET_INTERRUPT", unless you are lucky that none of
 the TLS connections for the duration of the Moat session had the
 randomization error. The re-randomization of fingerprints normally
 wouldn't a severe problem because of connection reuse, but the combination
 of DialTLS and the lack of HTTP/2 means that connections are reused less
 than normal.

 In summary: the static fingerprints fail completely because of an ALPN
 mismatch; the randomized fingerprints fail sometimes because of server
 feature mismatches.

 There is a partial workaround. Using
 [https://godoc.org/golang.org/x/net/http2#Transport http2.Transport] in
 place of http.Transport seemingly solves all the above problems--with the
 caveat that it doesn't work with servers that don't support HTTP/2.
 [https://github.com/refraction-
 networking/utls/issues/16#issuecomment-453697993 Details here.] So what
 I'm planning to do next is add `utls` and `http2` controls to the PT
 configuration. `utls` would allow you to choose a utls fingerprint (with
 knowledge of the errors described above). `http2` would let meek-client
 assume that the front server always supports HTTP/2, solving the errors
 described above as long as the server actually does support HTTP/2.

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

[tor-bugs] #29077 [Obfuscation/meek]: uTLS for meek-client camouflage

[Tor Bug Tracker & Wiki]

#29077: uTLS for meek-client camouflage
--+---
 Reporter:  dcf   |  Owner:  dcf
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Obfuscation/meek  |Version:
 Severity:  Normal|   Keywords:  moat utls
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 Use [https://github.com/refraction-networking/utls utls]
 ([https://censorbib.nymity.ch/#Frolov2019a paper]) for TLS camouflage
 instead of a headless Firefox helper. The camouflage will not be as robust
 as a headless browser, but the complexity will be lower. It will be
 portable to platforms that don't have a convenient Firefox instance to
 use. It will fix #12774, which is caused by tor starting multiple
 instances of meek-client-torbrowser, which in turn start multiple
 instances of Firefox, which error because they are using the same profile
 directory.

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

Re: [tor-bugs] #28997 [Applications/Tor Browser]: TB 8.0.4 - Tor is not shutting down properly

[Tor Bug Tracker & Wiki]

#28997: TB 8.0.4 - Tor is not shutting down properly
--+---
 Reporter:  jb.1234abcd   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks3):

 > Good news about OwningControllerProcess monitor. It doesn't work for me,
 either. "Monitored process  is still alive" info every 15 (!) seconds
 missed for me too. Is it broken?

 Nope.
 {{{
 reply = this._sendCommand(conn, "TAKEOWNERSHIP", null);
 if (!this.TorCommandSucceeded(reply))
   TorLauncherLogger.log(4, "take ownership failed");
 else
 {
   reply = this._sendCommand(conn, "RESETCONF",
 "__OwningControllerProcess");
   if (!this.TorCommandSucceeded(reply))
 TorLauncherLogger.log(4, "clear owning controller process
 failed");
 }
 }}}

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

Re: [tor-bugs] #28794 [Core Tor/Fallback Scripts]: Run an opt-in process for relay operators to become fallbacks in 2019

[Tor Bug Tracker & Wiki]

#28794: Run an opt-in process for relay operators to become fallbacks in 2019
---+--
 Reporter:  teor   |  Owner:  phoul
 Type:  task   | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Fallback Scripts  |Version:
 Severity:  Normal | Resolution:
 Keywords:  fallback   |  Actual Points:
Parent ID:  #28793 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by toralf):

 Replying to [comment:4 teor]:
 > An operator asked us to remove these whitelist entries:
 > {{{
 > ~/tor/scripts/maint $ grep 5.9.158.75  fallback.whitelist
 > 5.9.158.75:80 orport=443 id=1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA
 ipv6=[2a01:4f8:190:514a::2]:443
 > 5.9.158.75:9030 orport=9001 id=D11D11877769B9E617537B4B46BFB92B443DE33D
 ipv6=[2a01:4f8:190:514a::2]:9001
 > }}}
 (due to new hardware and switching to offline key handling). And BTW I
 prefer to replace them with these
 {{{
 5.9.158.75:80 orport=443 id=63BF46A63F9C21FD315CD061B3EAA3EB05283A0A
 ipv6=[2a01:4f8:190:514a::2]:443
 5.9.158.75:9030 orport=9001 id=509EAB4C5D10C9A9A24B4EA0CE402C047A2D64E6
 ipv6=[2a01:4f8:190:514a::2]:9001
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #29076 [Webpages/Website]: Remove experimental branch from js dropdown in debian install guide

[Tor Bug Tracker & Wiki]

#29076: Remove experimental branch from js dropdown in debian install guide
--+-
 Reporter:  traumschule   |  Owner:  traumschule
 Type:  defect| Status:  assigned
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 The current javascript dropdown menu is a constant maintenance effort that
 will eventually go away through the migration to a new website.

 #27809 has a patch, that with the latest release needs to be updated to
 0.3.5.7.

 Therefor proposing to remove the experimental branch from the
 [https://www.torproject.org/docs/debian-selector.js pull down menu],
 because it requires manually updating the javascript for every version. A
 better approach is to improve {{{docs/en/debian.wml}}} to be updated from
 [https://www.torproject.org/include/versions.wmi include/versions.wmi].

 Renaming the branch to {{{tor-alpha}}} could ease our life in the future.

 Commit
 
[https://github.com/torproject/webwml/pull/54/commits/607e5ac675c2ba887755924bc68c86cc86e2364a
 e3d3adb820e6d8715429cfbe5a71f6e67e7ebbda] makes the development version
 configurable for the non-js version of the page by adding a new variable
 {{{development-branch}}} to {{{versions.wmi}}}:

 {{{
 0.3.5.7
 0.3.5.7
 0.3.5.x
 }}}

 However this is not optimal because it adds another step when updating,
 using a simple regex via
 
[https://web.archive.org/web/20170426133845/http://thewml.org:80/docs/docs/wml_intro.html
 Pass 3] or similar would be preferred.

 Another question is if the guide should reflect if there's no separate
 alpha:
 {{{
 commit 523e14fc1c4eaeadcf6f36decf8dc8dcffca1127
 Author: Nick Mathewson 
 Date:   Mon Jan 7 16:40:53 2019 -0500

 Stable is 0.3.5.7; there is no alpha for the moment.
 }}}

 CC'ing maintainers to check if this is a wise move.

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

Re: [tor-bugs] #26061 [Webpages/Blog]: Add blog posts to contributor pages

[Tor Bug Tracker & Wiki]

#26061: Add blog posts to contributor pages
---+--
 Reporter:  steph  |  Owner:  hiro
 Type:  defect | Status:  reopened
 Priority:  Medium |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal | Resolution:
 Keywords:  ux-team|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by steph):

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


Comment:

 There's another element to this.

 If I click on my name where I've left a comment, such as this one:
 https://blog.torproject.org/comment/279368#comment-279368

 my name opens to this: https://blog.torproject.org/user/105

 Can we connect it to the user profile where authored posts are listed?
 https://blog.torproject.org/users/steph

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

Re: [tor-bugs] #23573 [Core Tor/Tor]: Do we want to close all connections when tor closes?

[Tor Bug Tracker & Wiki]

#23573: Do we want to close all connections when tor closes?
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  0.3.5.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  shutdown, privcount, correctness,|  Actual Points:
  chutney-wants, review-group-24,|
  034-triage-20180328, 034-included20180401, |
  035-roadmap-subtask, 035-triaged-in-20180711   |
Parent ID:  #25510   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * sponsor:  Sponsor19 =>


Comment:

 I don't think this is really sponsor-19.

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

Re: [tor-bugs] #29050 [Core Tor/Torsocks]: Connecting to tor over a socks 5 connection no longer works in 3.5.7

[Tor Bug Tracker & Wiki]

#29050: Connecting to tor over a socks 5 connection no longer works in 3.5.7
---+---
 Reporter:  arj|  Owner:  dgoulet
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Core Tor/Torsocks  |Version:  Tor: 0.3.5.7
 Severity:  Normal | Resolution:
 Keywords:  regression?|  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

 * keywords:   => regression?
 * cc: dgoulet (added)


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

Re: [tor-bugs] #28142 [Core Tor/Tor]: Merge original WTF-PAD branch

[Tor Bug Tracker & Wiki]

#28142: Merge original WTF-PAD branch
-+-
 Reporter:  asn  |  Owner:
 |  mikeperry
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.0.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding|
Parent ID:  #28631   | Points:
 Reviewer:  asn  |Sponsor:
 |  Sponsor2
-+-

Comment (by nickm):

 >For monotime, I think my preference would be some kind of check that
 helps decide which of these time abstractions to use, for optimal accuracy
 and speed.

 I think that might be possible, but it's not going to happen between now
 and the freeze on the 15th.

 Does the current monotime usage happen in the critical path for default
 tor configurations with this patch?  If no, I think we don't have to block
 on a new monotoime approach.  If yes, maybe we can make it conditional on
 wtf-pad being enabled.

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

Re: [tor-bugs] #28493 [Applications/TorBirdy]: Stop forcibly enabling protected headers (aka. Memory Hole) by default

[Tor Bug Tracker & Wiki]

#28493: Stop forcibly enabling protected headers (aka. Memory Hole) by default
---+--
 Reporter:  intrigeri  |  Owner:  sukhbir
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/TorBirdy  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by intrigeri):

 * status:  new => needs_review


Comment:

 I've tested on current Debian sid and I confirm that the Torbirdy code I'm
 referring to here is a no-op: due to the Enigmail pref having been
 renamed, it won't forcibly enable protected headers, and the corresponding
 checkbox in the Torbirdy prefs has no effect. The attached (untested!)
 patch removes this code. Happy to test it before you review it, if you
 agree it's the best course of action. Setting status to "needs review",
 because next step is: the Torbirdy maintainers review my proposal.

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

Re: [tor-bugs] #25417 [Core Tor/Tor]: HSFETCH support for v3 Hidden Services

[Tor Bug Tracker & Wiki]

#25417: HSFETCH support for v3 Hidden Services
-+-
 Reporter:  atagar   |  Owner:  neel
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-control, tor-hs, prop224-extra,  |  Actual Points:
  onionbalance   |
Parent ID:  #28841   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by neel):

 * owner:  (none) => neel
 * 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] #28493 [Applications/TorBirdy]: Stop forcibly enabling protected headers (aka. Memory Hole) by default

[Tor Bug Tracker & Wiki]

#28493: Stop forcibly enabling protected headers (aka. Memory Hole) by default
---+-
 Reporter:  intrigeri  |  Owner:  sukhbir
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Applications/TorBirdy  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by intrigeri):

 * Attachment "0001-Don-t-manage-Enigmail-protected-headers-
 aka.-Memory-.patch" added.


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

Re: [tor-bugs] #28874 [Applications/Tor Browser]: https://browserleaks.com/webgl crashes tab on 64bit Tor Browser for Windows

[Tor Bug Tracker & Wiki]

#28874: https://browserleaks.com/webgl crashes tab on 64bit Tor Browser for 
Windows
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-crash, tbb-rbm,  |  Actual Points:
  TorBrowserTeam201901R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by omg):

 https://trac.torproject.org/projects/tor/ticket/26650#comment:5

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

Re: [tor-bugs] #28997 [Applications/Tor Browser]: TB 8.0.4 - Tor is not shutting down properly

[Tor Bug Tracker & Wiki]

#28997: TB 8.0.4 - Tor is not shutting down properly
--+---
 Reporter:  jb.1234abcd   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks3):

 {{{
 JavaScript error: chrome://torbutton/content/tor-circuit-display.js, line
 436: TypeError: myController is null
 [Parent 11496, Gecko_IOThread] WARNING: pipe error (55): Connection reset
 by peer: file /var/tmp/build/firefox-
 efdff96e8955/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353
 }}}
 Maybe browser just vanished.

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

Re: [tor-bugs] #28997 [Applications/Tor Browser]: TB 8.0.4 - Tor is not shutting down properly

[Tor Bug Tracker & Wiki]

#28997: TB 8.0.4 - Tor is not shutting down properly
--+---
 Reporter:  jb.1234abcd   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks3):

 Maybe (it's complicated, as TB here is Firefox+privacy_patches
 +tor_launcher_add-on) but DROP rules for lo is not so harmless idea by
 itself.

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

Re: [tor-bugs] #28997 [Applications/Tor Browser]: TB 8.0.4 - Tor is not shutting down properly

[Tor Bug Tracker & Wiki]

#28997: TB 8.0.4 - Tor is not shutting down properly
--+---
 Reporter:  jb.1234abcd   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by jb.1234abcd):

 Replying to [comment:29 cypherpunks3]:
 > > or in iptables
 >
 > or kernel update (more likely).
 > some race condition, browser closed socket and vanished, conntrack
 purged state before connection terminated. then anything (non RST) for
 this connection is invalid.
 That would suggest that TB on close/exit is responsible for orderly
 connection closeout, even forceful with e.g. abortive close (tcp RST) to
 avoid CLOSE_WAIT or TIME_WAIT states (see: socket close(3), SO_LINGER
 option with zero timeout).

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

Re: [tor-bugs] #28845 [Core Tor/Tor]: evloop could be better at handling fork() in tests

[Tor Bug Tracker & Wiki]

#28845: evloop could be better at handling fork() in tests
--+
 Reporter:  ahf   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:  #28179| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * sponsor:  Sponsor19-must =>


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

Re: [tor-bugs] #17343 [Core Tor/Tor]: Add torrc option OnionService* alias for HiddenService*

[Tor Bug Tracker & Wiki]

#17343: Add torrc option OnionService* alias for HiddenService*
+--
 Reporter:  dgoulet |  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tor-hs prop224-maybe torrc  |  Actual Points:
Parent ID:  #25918  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by s7r):

 * cc: s7r (added)


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

Re: [tor-bugs] #28997 [Applications/Tor Browser]: TB 8.0.4 - Tor is not shutting down properly

[Tor Bug Tracker & Wiki]

#28997: TB 8.0.4 - Tor is not shutting down properly
--+---
 Reporter:  jb.1234abcd   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks3):

 > or in iptables

 or kernel update (more likely).
 some race condition, browser closed connection and vanished, conntrack
 purged state before connection terminated. then anything (non RST) for
 this connection is invalid.

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

Re: [tor-bugs] #28997 [Applications/Tor Browser]: TB 8.0.4 - Tor is not shutting down properly

[Tor Bug Tracker & Wiki]

#28997: TB 8.0.4 - Tor is not shutting down properly
--+---
 Reporter:  jb.1234abcd   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by jb.1234abcd):

 * Attachment "iptables-invalid-1.log" added.

 TB iptables INVALID log

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

Re: [tor-bugs] #27471 [Core Tor/Tor]: HS intermittently fails: Non-fatal assertion failed in send_introduce1

[Tor Bug Tracker & Wiki]

#27471: HS intermittently fails: Non-fatal assertion failed in send_introduce1
+--
 Reporter:  tgragnato   |  Owner:  dgoulet
 Type:  defect  | Status:
|  merge_ready
 Priority:  Very High   |  Milestone:  Tor:
|  0.3.4.x-final
Component:  Core Tor/Tor|Version:  Tor:
|  0.3.2.1-alpha
 Severity:  Minor   | Resolution:
 Keywords:  tor-hs, 035-backport, 034-backport  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  asn |Sponsor:
+--

Comment (by traumschule):

 This happened once after a clock jump on nightly (#28992).

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

Re: [tor-bugs] #28992 [Core Tor/Tor]: Bug: ../src/feature/hs/hs_client.c:571: send_introduce1: Non-fatal assertion !(ip == NULL) failed.

[Tor Bug Tracker & Wiki]

#28992: Bug: ../src/feature/hs/hs_client.c:571: send_introduce1: Non-fatal
assertion !(ip == NULL) failed.
--+
 Reporter:  traumschule   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:  tor-hs|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by traumschule):

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


Comment:

 This only happened once after a clock jump on a specific nightly version.

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

Re: [tor-bugs] #28997 [Applications/Tor Browser]: TB 8.0.4 - Tor is not shutting down properly

[Tor Bug Tracker & Wiki]

#28997: TB 8.0.4 - Tor is not shutting down properly
--+---
 Reporter:  jb.1234abcd   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by jb.1234abcd):

 Replying to [comment:27 cypherpunks3]:
 > Maybe this
 > {{{
 > 434 22520 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
 > }}}
 > Can you test with ACCEPT all -- lo * before dropping INVALID?
 Congratulations !
 I tested TB run twice for 5 min and all is clean (no process left behind).
 This is strange, as I have run these firewall rules for ages, and also
 have been using TB weekly for a couple of years. Only very recently (prior
 to New Year) this problem popped up.
 This would indicate that my original iptables rules order started blocking
 something INVALID very recently - problem in TB or in iptables (most
 recent upgrade was 2018-11-28 1:1.8.0-1 -> 1:1.8.2-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] #10760 [Applications/Tor Browser]: Integrate TorButton to TorBrowser core to prevent users from disabling them

[Tor Bug Tracker & Wiki]

#10760: Integrate TorButton to TorBrowser core to prevent users from disabling 
them
+--
 Reporter:  Rezonansowy |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  High|  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  TorBrowserTeam201901, AffectsTails  |  Actual Points:
Parent ID:  #24855  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by intrigeri):

 * keywords:  TorBrowserTeam201901 => TorBrowserTeam201901, AffectsTails


Comment:

 FTR, Tails' "Unsafe Browser" is basically Tor Browser, with Torbutton
 disabled and a scary homepage. It would be nice if there were still a
 hidden way for us to disable Torbutton for that browser profile.
 Otherwise, we'll have to ship binaries for another browser, which will
 make our ISO and upgrade delta significantly bigger. In order to plan
 Tails work on this topic, I need to know whether it'll still be possible
 to disable Torbutton somehow, and if not, I would be very grateful to
 learn what's the timeline is here, e.g. whether the plan is to ship this
 change in Tor Browser 8.5. Thanks in advance! Please let me know if you
 need additional info from me to answer my questions :)

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

Re: [tor-bugs] #10760 [Applications/Tor Browser]: Integrate TorButton to TorBrowser core to prevent users from disabling them

[Tor Bug Tracker & Wiki]

#10760: Integrate TorButton to TorBrowser core to prevent users from disabling 
them
--+--
 Reporter:  Rezonansowy   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201901  |  Actual Points:
Parent ID:  #24855| Points:
 Reviewer:|Sponsor:
--+--
Changes (by intrigeri):

 * cc: intrigeri (added)


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

Re: [tor-bugs] #28997 [Applications/Tor Browser]: TB 8.0.4 - Tor is not shutting down properly

[Tor Bug Tracker & Wiki]

#28997: TB 8.0.4 - Tor is not shutting down properly
--+---
 Reporter:  jb.1234abcd   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks3):

 Maybe this
 {{{
 434 22520 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
 }}}
 Can you test with ACCEPT all -- lo * before dropping INVALID?

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

Re: [tor-bugs] #28997 [Applications/Tor Browser]: TB 8.0.4 - Tor is not shutting down properly

[Tor Bug Tracker & Wiki]

#28997: TB 8.0.4 - Tor is not shutting down properly
--+---
 Reporter:  jb.1234abcd   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by jb.1234abcd):

 Replying to [comment:25 cypherpunks3]:
 > @jb.1234abcd, Can you check netfilter rules for lo? Might be some
 another rules affect it?
 # iptables -n -L -v
 Chain INPUT (policy DROP 0 packets, 0 bytes)
  pkts bytes target prot opt in out source
 destination
   434 22520 DROP   all  --  *  *   0.0.0.0/0
 0.0.0.0/0ctstate INVALID
 8746K 5805M ACCEPT all  --  *  *   0.0.0.0/0
 0.0.0.0/0ctstate RELATED,ESTABLISHED
  2963  181K ACCEPT all  --  lo *   0.0.0.0/0
 0.0.0.0/0
 0 0 ACCEPT icmp --  *  *   0.0.0.0/0
 0.0.0.0/0
   132 13874 REJECT udp  --  *  *   0.0.0.0/0
 0.0.0.0/0reject-with icmp-port-unreachable
 160 REJECT tcp  --  *  *   0.0.0.0/0
 0.0.0.0/0reject-with tcp-reset
  4008  128K REJECT all  --  *  *   0.0.0.0/0
 0.0.0.0/0reject-with icmp-proto-unreachable

 Chain FORWARD (policy DROP 0 packets, 0 bytes)
  pkts bytes target prot opt in out source
 destination
 0 0 REJECT all  --  *  *   0.0.0.0/0
 0.0.0.0/0reject-with icmp-admin-prohibited

 Chain OUTPUT (policy ACCEPT 7110K packets, 998M bytes)
  pkts bytes target prot opt in out source
 destination
 #

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

Re: [tor-bugs] #28997 [Applications/Tor Browser]: TB 8.0.4 - Tor is not shutting down properly

[Tor Bug Tracker & Wiki]

#28997: TB 8.0.4 - Tor is not shutting down properly
--+---
 Reporter:  jb.1234abcd   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cypherpunks3):

 Good news about OwningControllerProcess monitor. It doesn't work for me,
 either. "Monitored process  is still alive" info every 15 (!) seconds
 missed for me too. Is it broken?

 @jb.1234abcd, Can you check netfilter rules for lo? Might be some another
 rules affect 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] #29074 [Applications/Tor Browser]: Consider using the Windows 10 UA instead of the Windows 7 UA in the TB UA

[Tor Bug Tracker & Wiki]

#29074: Consider using the Windows 10 UA instead of the Windows 7 UA in the TB 
UA
--+--
 Reporter:  cypherpunks3  |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Thorin):

 this is already upstreamed at
 https://bugzilla.mozilla.org/show_bug.cgi?id=1511434

 meanwhile, until the next ESR, then there is no entropy difference

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