Re: [tor-bugs] #23840 [Applications/Tor Browser]: Cloudflare and Google Captcha failed 100%

[Tor Bug Tracker & Wiki]

#23840: Cloudflare and Google Captcha failed 100%
--+--
 Reporter:  cypherpunks   |  Owner:  hiro
 Type:  defect| Status:  reopened
 Priority:  Immediate |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Critical  | Resolution:
 Keywords:|  Actual Points:
Parent ID:  #24351| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

 * component:  Community/Tor Support => Applications/Tor Browser


Comment:

 A lot of cries and no constructive action again.
 Recaptcha fails when
 {{{
 09:00:15.693 NetworkError: Failed to load worker script at
 https://www.gstatic.com/recaptcha/api2/r20171115120512/recaptcha__en.js
 (nsresult = 0x805e0006) 1 webworker.js:1
 }}}
 from
 `https://www.google.com/recaptcha/api2/webworker.js?hl=en&v=r20171115120512`

 If you are testing with https://news.ycombinator.com/item?id=11022315, you
 can also hit
 {{{
 Firefox can’t find the file at
 https://news.ycombinator.com/item?id=11022315.
 }}}
 or
 {{{

 Web server is returning an unknown error

 There is an unknown connection issue between Cloudflare and the origin web
 server. As a result, the web page can not be displayed.

 Ray ID: 3c23166f2b7f2d8f
 Your IP address: 192.36.27.6
 Error reference number: 520
 Cloudflare Location: Berlin
 }}}
 Therefore, server should have a reliable connection to test recaptcha, for
 example,
 https://www.etsy.com/join?ref=hdr&from_page=https%3A%2F%2Fwww.etsy.com%2F

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

Re: [tor-bugs] #22530 [Webpages/Blog]: Tor Browser 7.0 can't post on https://blog.torproject.org unless security slider is lowered

[Tor Bug Tracker & Wiki]

#22530: Tor Browser 7.0 can't post on https://blog.torproject.org unless 
security
slider is lowered
---+--
 Reporter:  cypherpunks|  Owner:  hiro
 Type:  defect | Status:  accepted
 Priority:  High   |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 I don't need js enabled to post at blog.torproject.org. I see a blog
 comment of mine from one month ago.
 My most significant prefs change from TBB default is allowing history (I
 reset this in Firefox prefs GUI).
 Other prefs I change seem even less related to js - disable trim urls,
 wrap lines in view source, minimum font size, and a few others like those.
 I also set noscript options strictly.
 I change those after setting security slider to highest.


 The only "strange" behavior I experience by the new blog is that after I
 have posted a comment (as reply or a new comment), tor blog won't show the
 "reply" link on comments. But this happens in only the same TBB tab.
 Loading the blog page in a new tab fixes that "strange" defect.

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

Re: [tor-bugs] #22530 [Webpages/Blog]: Tor Browser 7.0 can't post on https://blog.torproject.org unless security slider is lowered

[Tor Bug Tracker & Wiki]

#22530: Tor Browser 7.0 can't post on https://blog.torproject.org unless 
security
slider is lowered
---+--
 Reporter:  cypherpunks|  Owner:  hiro
 Type:  defect | Status:  accepted
 Priority:  High   |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Major  | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 To avoid confusion:
 I posted only comment 7 and this addendum comment on this ticket.

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

[tor-bugs] #24400 [Core Tor/Tor]: Seccomp filter incorrectly tries to act on strings, allowing sandbox bypass

[Tor Bug Tracker & Wiki]

#24400: Seccomp filter incorrectly tries to act on strings, allowing sandbox 
bypass
--+
 Reporter:  Sebastian |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  sandbox
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 I am filing this on behalf of cypherpunks who cannot use our trac because
 of its javascript requirements for posting some stuff.

 Currently, the Tor seccomp sandbox attempts to whitelist internal strings.
 This is a bug, because seccomp is incapable of whitelisting memory
 contents, only register contents (i.e. the pointer itself). That is, when
 you call `open(path, mode)`, the first argument is actually an address,
 such as `0x368a227dec3`. When you attempt to use the seccomp filter to
 whitelist this, you are not whitelisting the string, only the pointer to
 the string. The only reason it works is because compilers deduplicate
 identical strings, allowing two strings that are the same (e.g. the string
 given to seccomp for whitelisting, and the string being given to a
 syscall) point to the same location in `.rodata`.

 **A demonstration showing deduplication:**

 {{{
 cat $ hello.c
 #include 

 void main(int argc, char *argv[])
 {
 char *s1 = "Hello, world!";
 char *s2 = "Hello, world!";
 char *s3 = argv[1];

 printf("%p\t%s\n%p\t%s\n%p\t%s\n", s1, s1, s2, s2, s3, s3);
 }

 $ gcc hello.c

 $ ./a.out "Hello, world!"
 0x64a4b457b4Hello, world!
 0x64a4b457b4Hello, world!
 0x3eb7d22b37d   Hello, world!

 $ readelf -x .rodata a.out

 Hex dump of section '.rodata':
   0x07b0 01000200 48656c6c 6f2c2077 6f726c64 Hello, world
   0x07c0 21002570 0925730a 25700925 730a2570 !.%p.%s.%p.%s.%p
   0x07d0 0925730a 00 .%s..

 }}}

 Despite the strings being identical in all cases, only the first two,
 which were defined internally, point to the same data. Only when the
 string is accessed at runtime does the value change. This means that
 hardcoding a string with a seccomp sandbox may seem to work, but provides
 no protection, as all an attacker would have to do is write their own
 strings to those addresses (changing the permissions of `.rodata` first if
 it is stored there).

 **A demonstration which shows how a whitelisted string can be bypassed:**

 {{{
 $ cat seccomp.c
 #include 
 #include 
 #include 
 #include 

 void main(void)
 {
 char *s = malloc(14);

 memcpy(s, "Hello, world!\n", 14);

 scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_TRAP);
 seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(exit_group), 0);
 seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(write), 1,
 SCMP_A1(SCMP_CMP_EQ, (scmp_datum_t)s));
 seccomp_load(ctx);

 write(1, s, 14);
 memcpy(s, "Hallo, world!\n", 14);
 write(1, s, 14);
 }

 $ gcc seccomp.c -lseccomp

 $ ./a.out
 Hello, world!
 Hallo, world!
 }}}

 See "Why does seccomp-filter is not enough?" [sic] from
 https://lwn.net/Articles/698226/, which explains why an LSM (currently in
 development) is required to provide seccomp with the ability to filter
 paths and other memory-resident values:

 >A seccomp filter can access to raw syscall arguments which means that it
 is not
 >possible to filter according to pointed data as a file path. As
 demonstrated
 >the first version of this patch series, filtering at the syscall level is
 >complicated (e.g. need to take care of race conditions). This is mainly
 because
 >the access control checkpoints of the kernel are not at this high-level
 but
 >more underneath, at LSM hooks level. The LSM hooks are designed to handle
 this
 >kind of checks. This series use this approach to leverage the ability of
 >unprivileged users to limit themselves.

 It may seem like it would be enough to ensure the buffers are read-only
 and disallow `mprotect()` accessing that address. Unfortunately, other
 syscalls like `brk()` can bypass this. In the end, it's extremely
 difficult to ensure that a memory region cannot be written to by malicious
 code without disabling virtually all memory-related syscalls.

 The entirety of `src/common/sandbox.c:sandbox_intern_string` is poorly
 thought out and relies on incorrect and dangerous assumptions. This
 results in 6 syscalls so far which devs believe to be filtered but which
 in fact can be bypassed:
 * chown  - pathname argument
 * chmod  - pathname argument
 * open   - pathname argument
 * openat - pathname argument
 * rename - oldpath and newpath arguments
 * stat64 - pathname argument

 The solution is to use the syscalls before enabling the sandbox, or
 whitelisting them (excluding arguments in memory) and eventually
 blacklisting the

Re: [tor-bugs] #24315 [Core Tor/Tor]: sandbox incompatible with glibc 2.26 (openat() not handled for all our files)

[Tor Bug Tracker & Wiki]

#24315: sandbox incompatible with glibc 2.26 (openat() not handled for all our
files)
--+
 Reporter:  dgoulet   |  Owner:  nickm
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.3.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
--+

Comment (by Sebastian):

 cypherpunks notes that #24400 applies here, 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] #23840 [Community/Tor Support]: Cloudflare and Google Captcha failed 100%

[Tor Bug Tracker & Wiki]

#23840: Cloudflare and Google Captcha failed 100%
---+--
 Reporter:  cypherpunks|  Owner:  hiro
 Type:  defect | Status:  reopened
 Priority:  Immediate  |  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Critical   | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #24351 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cypherpunks):

 * component:  Applications/Tor Browser => Community/Tor Support


Comment:

 Replying to [comment:29 cypherpunks]:
 > A lot of cries and no constructive action again.
 That's because the problem stems from Google, and there's nothing TB-team
 can do other than speak up.

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

Re: [tor-bugs] #23518 [Metrics/Atlas]: Turn Atlas into page on Tor Metrics

[Tor Bug Tracker & Wiki]

#23518: Turn Atlas into page on Tor Metrics
---+--
 Reporter:  karsten|  Owner:  irl
 Type:  enhancement| Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-2017   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by irl):

 The SVG tooltips used in the graphs are broken with bootstrap 3.3.7 but
 work with 3.3.5. The fix appears to be to replace the getPosition function
 from 3.3.5 in 3.3.7 and we should ensure we do this. For now, Relay Search
 is hosting its own bootstrap js.

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

Re: [tor-bugs] #24394 [Core Tor/Tor]: add ipv6 dirauth address

[Tor Bug Tracker & Wiki]

#24394: add ipv6 dirauth address
--+
 Reporter:  stefani   |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * milestone:   => Tor: 0.3.2.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] #24395 [Metrics/Atlas]: Make exit_address IPs RelaySearch URLs

[Tor Bug Tracker & Wiki]

#24395: Make exit_address IPs RelaySearch URLs
---+--
 Reporter:  cypherpunks|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by irl):

 Is there a use case for this?

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

Re: [tor-bugs] #24395 [Metrics/Atlas]: Make exit_address IPs RelaySearch URLs

[Tor Bug Tracker & Wiki]

#24395: Make exit_address IPs RelaySearch URLs
---+--
 Reporter:  cypherpunks|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 Yes this ticket is based on discussions on bad-relays@

 for example the following 4 badexits:
 https://lists.riseup.net/www/arc/ornetradar/2017-11/msg00116.html

 Currently you have to copy and paste the exit_address IP manually to the
 search box if you are currently on the details page to confirm that this
 is in fact a rerouting exit, with the feature implemented this would be a
 single click for every IP listed in the exit_addresses field.

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

Re: [tor-bugs] #24395 [Metrics/Atlas]: Make exit_address IPs RelaySearch URLs

[Tor Bug Tracker & Wiki]

#24395: Make exit_address IPs RelaySearch URLs
---+--
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by irl):

 * owner:  metrics-team => irl
 * status:  new => accepted


Comment:

 Ok, I suspected it may be 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

[tor-bugs] #24401 [Core Tor/Nyx]: Nyx crashed when scrolling down on the Tor Configuration File page

[Tor Bug Tracker & Wiki]

#24401: Nyx crashed when scrolling down on the Tor Configuration File page
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Core Tor/Nyx   |Version:
 Severity:  Major  |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 Nyx crashed when scrolling down on the Tor Configuration File page. Here
 is the traceback.

 {{{
 File "/usr/local/bin/nyx", line 11, in 

     sys.exit(main())

   File "/usr/local/lib/python3.5/dist-packages/nyx/__init__.py", line 176,
 in main

     nyx.starter.main()

   File "/usr/local/lib/python3.5/dist-packages/stem/util/conf.py", line
 289, in wrapped

     return func(*args, config = config, **kwargs)

   File "/usr/local/lib/python3.5/dist-packages/nyx/starter.py", line 118,
 in main

     nyx.curses.start(nyx.draw_loop, acs_support =
 config.get('acs_support', True), transparent_background = True, cursor =
 False)

   File "/usr/local/lib/python3.5/dist-packages/nyx/curses.py", line 217,
 in start

     curses.wrapper(_wrapper)

   File "/usr/lib/python3.5/curses/__init__.py", line 94, in wrapper

     return func(stdscr, *args, **kwds)

   File "/usr/local/lib/python3.5/dist-packages/nyx/curses.py", line 215,
 in _wrapper

     function()

   File "/usr/local/lib/python3.5/dist-packages/nyx/__init__.py", line 243,
 in draw_loop

     keybinding.handle(key)

   File "/usr/local/lib/python3.5/dist-packages/nyx/panel/__init__.py",
 line 82, in handle

     self._action(key)

   File "/usr/local/lib/python3.5/dist-packages/nyx/panel/config.py", line
 232, in _scroll

     self.redraw()

   File "/usr/local/lib/python3.5/dist-packages/nyx/panel/__init__.py",
 line 175, in redraw

     self._last_draw_size = nyx.curses.draw(self._draw, top = self._top,
 height = self.get_height(), draw_if_resized = draw_dimension)

   File "/usr/local/lib/python3.5/dist-packages/nyx/curses.py", line 746,
 in draw

     func(_Subwindow(subwindow_width, subwindow_height, curses_subwindow))

   File "/usr/local/lib/python3.5/dist-packages/nyx/panel/config.py", line
 315, in _draw

     _draw_line(subwindow, scroll_offset, DETAILS_HEIGHT + i, entry, entry
 == selected, value_width, description_width)

   File "/usr/local/lib/python3.5/dist-packages/nyx/panel/config.py", line
 335, in _draw_line

     attr = [CONFIG['attr.config.category_color'].get(entry.category,
 WHITE)]

   File "/usr/local/lib/python3.5/dist-packages/nyx/panel/config.py", line
 136, in category

     return getattr(manual(self.name), 'category')

 AttributeError: 'NoneType' object has no attribute 'category'
 }}}

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

Re: [tor-bugs] #24395 [Metrics/Atlas]: Make exit_address IPs RelaySearch URLs

[Tor Bug Tracker & Wiki]

#24395: Make exit_address IPs RelaySearch URLs
---+
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by irl):

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


Comment:

 Fixed in eeb3484 and deployed.

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

Re: [tor-bugs] #23782 [Metrics/Atlas]: Expose all possible query features in an "Advanced Search" HTML form

[Tor Bug Tracker & Wiki]

#23782: Expose all possible query features in an "Advanced Search" HTML form
---+--
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  accepted
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID:  #23518 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by irl):

 When we have advanced queries, we should update exit_address links to
 search for exact matches instead of the inline search parameters.

 https://lists.torproject.org/pipermail/metrics-
 team/2017-November/000566.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] #6682 [Metrics/Compass]: Merge Atlas and Compass into a single tool

[Tor Bug Tracker & Wiki]

#6682: Merge Atlas and Compass into a single tool
-+--
 Reporter:  cypherpunks  |  Owner:  metrics-team
 Type:  enhancement  | Status:  closed
 Priority:  Low  |  Milestone:
Component:  Metrics/Compass  |Version:
 Severity:  Normal   | Resolution:  duplicate
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

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


Comment:

 This is a duplicate of #23517.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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: #6639, #6677, #6713, #7640, ...

[Tor Bug Tracker & Wiki]

Batch modification to #6639, #6677, #6713, #7640, #7744, #7834, #8054, #8461, 
#8498, #9350, #10001, #10859, #11434, #17738, #6450, #6619, #6703, #7568, 
#7879, #6648, #9993 by irl:


Action: resolve

Comment:
The metrics team has put a goal of shutting down Compass in its roadmap and 
merging functionality with Relay Search (previously known as Atlas). This 
ticket is specific to Compass and as development on Compass has ceased, I am 
marking this ticket as wontfix.

See #23517 for information on the planned work to integrate Compass 
functionality into Relay Search.

--
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

[tor-bugs] [Tor Bug Tracker & Wiki] Batch modify: #6728, #6818

[Tor Bug Tracker & Wiki]

Batch modification to #6728, #6818 by irl:


Action: resolve

Comment:
The metrics team has put a goal of shutting down Compass in its roadmap and 
merging functionality with Relay Search (previously known as Atlas). This 
ticket is specific to Compass and as development on Compass has ceased, I am 
marking this ticket as wontfix. 


See #23517 for information on the planned work to integrate Compass 
functionality into Relay Search.

--
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] #6730 [Metrics/Compass]: Display newly added or recently disappeared relays or bridges

[Tor Bug Tracker & Wiki]

#6730: Display newly added or recently disappeared relays or bridges
-+--
 Reporter:  mo   |  Owner:  metrics-team
 Type:  enhancement  | Status:  closed
 Priority:  Low  |  Milestone:
Component:  Metrics/Compass  |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

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


Comment:

 This functionality is present in Relay Search.

 For newly appeared relays:
 https://atlas.torproject.org/#search/first_seen_days:-1

 For recently disappeared relays:
 https://atlas.torproject.org/#search/running:false%20last_seen_days:1-2

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

Re: [tor-bugs] #10306 [Metrics/Compass]: Show relays by nickname substring

[Tor Bug Tracker & Wiki]

#10306: Show relays by nickname substring
-+--
 Reporter:  arma |  Owner:  metrics-team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Metrics/Compass  |Version:
 Severity:  Normal   | Resolution:  wontfix
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by irl):

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


Comment:

 The metrics team has put a goal of shutting down Compass in its roadmap
 and merging functionality with Relay Search (previously known as Atlas).
 This ticket is specific to Compass and as development on Compass has
 ceased, I am marking this ticket as wontfix.

 See #23517 for information on the planned work to integrate Compass
 functionality into Relay Search.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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: #6662, #6675, #6946, #6947, #6855

[Tor Bug Tracker & Wiki]

Batch modification to #6662, #6675, #6946, #6947, #6855 by irl:
component to Metrics/Atlas

Action: leave

Comment:
In #23517 it is planned to merge Compass functionality with Relay Search 
(formerly known as Atlas). These tickets may be relevant to that work and so 
these are being reassigned to the Metrics/Atlas component.

--
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] #23517 [Metrics/Atlas]: Add aggregated results table for relays grouped by country and/or AS

[Tor Bug Tracker & Wiki]

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

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


Comment:

 Fixed in 5463eb8 in Relay Search.

 I would still like to move the actual aggregation to Onionoo, but for now
 this works and doesn't seem to have terrible performance. The aggregations
 load faster than the single relays do so this isn't a massive concern.

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

Re: [tor-bugs] #23509 [Metrics/Atlas]: Implement family-level pages showing aggregated graphs

[Tor Bug Tracker & Wiki]

#23509: Implement family-level pages showing aggregated graphs
---+-
 Reporter:  cypherpunks|  Owner:  irl
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords:  metrics-2018   |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-

Comment (by irl):

 I have a plan for this that involves a new #/aggregate/details/(onionoo
 lookup) route using an aggregatesCollection with an aType of "all" to give
 a single row.

 There needs to be a switch in aggregatesCollection to allow collecting
 more fields than normal (while not doing this on the search page) and then
 an aggregate details template to show the information.

 For the graphs it may be possible to stack them as on the nos-oignons.net
 but I'd rather not be doing a lot of aggregating large documents in the
 JavaScript. Maybe at a limit it will just refuse to attempt to plot.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24402 [Metrics/Atlas]: Make numbers in Guard and Exit column clickable (aggregated view)

[Tor Bug Tracker & Wiki]

#24402: Make numbers in Guard and Exit column clickable (aggregated view)
---+--
 Reporter:  cypherpunks|  Owner:  metrics-team
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 Make numbers in Guard and Exit column clickable to show the respective
 relays.

 this adds flag:exit or flag:guard to the search term

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

Re: [tor-bugs] #24338 [Core Tor/Tor]: DirAuths that have IPv6 addresses don't include them in their vote on themself

[Tor Bug Tracker & Wiki]

#24338: DirAuths that have IPv6 addresses don't include them in their vote on
themself
-+-
 Reporter:  tom  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  needs-mandatory-IPv6, tor-dirauth,   |  Actual Points:
  easy, intro|
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:  #20916 =>
 * milestone:  Tor: very long term => Tor: 0.3.3.x-final


Comment:

 Hang on, we will need authorities to unconditionally advertise their own
 IPv6 address.

 When we implement relay IPv6 reachability checks, relays in a new network
 will need IPv6 addresses to bootstrap off.

 > If an authority votes for its own IPv6 address, and it's the only one to
 do this, then its IPv6 address will always be in the consensus, even if
 it's actually unreachable. (A single IPv6-voting authority can determine
 an IPv6 address by voting for it.)

 This is ok, because if we have a majority of authorities on IPv6 (that
 doesn't include that authority), that authority won't be marked Running,
 and its operator will notice.

 Also, we should do reachability checks on authority IPv6 addresses, but
 just warn if they fail. This is what we do for authority IPv4 addresses.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24403 [Core Tor/Tor]: Propose and implement IPv6 ORPort reachability checks on relays

[Tor Bug Tracker & Wiki]

#24403: Propose and implement IPv6 ORPort reachability checks on relays
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  ipv6, tor-relay
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:  SponsorV-can  |
--+
 This is the top-level task for relay IPv6 ORPort reachability checks.

 See:
 
https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/IPv6Features#ReachabilityChecks

 Check the child tickets for details.

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

Re: [tor-bugs] #24338 [Core Tor/Tor]: DirAuths that have IPv6 addresses don't include them in their vote on themself

[Tor Bug Tracker & Wiki]

#24338: DirAuths that have IPv6 addresses don't include them in their vote on
themself
--+
 Reporter:  tom   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-dirauth, easy, intro  |  Actual Points:
Parent ID:  #24403| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * keywords:  needs-mandatory-IPv6, tor-dirauth, easy, intro => tor-dirauth,
 easy, intro
 * parent:   => #24403


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

Re: [tor-bugs] #24404 [Core Tor/Tor]: Propose a relay protover that allows IPv6 extends

[Tor Bug Tracker & Wiki]

#24404: Propose a relay protover that allows IPv6 extends
-+-
 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:  needs-proposal, ipv6, tor-relay  |  Actual Points:
Parent ID:  #24403   | Points:  1
 Reviewer:   |Sponsor:  SponsorV-
 |  can
-+-
Changes (by teor):

 * parent:   => #24403


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24404 [Core Tor/Tor]: Propose a relay protover that allows IPv6 extends

[Tor Bug Tracker & Wiki]

#24404: Propose a relay protover that allows IPv6 extends
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core |Version:
  Tor/Tor|
 Severity:  Normal   |   Keywords:  needs-proposal, ipv6, tor-relay
Actual Points:   |  Parent ID:
   Points:  1|   Reviewer:
  Sponsor:  SponsorV-|
  can|
-+-
 Write a proposal for a relay protover, in which relays with IPv6 ORPorts
 start attempting to connect to IPv6 ORPorts in response to EXTEND2 cells
 containing IPv6 addresses. (Relays always prefer existing canonical
 connections, which may be over IPv4.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24405 [Core Tor/Tor]: Implement relay IPv6 extends with proposed protover

[Tor Bug Tracker & Wiki]

#24405: Implement relay IPv6 extends with proposed protover
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core |Version:
  Tor/Tor|
 Severity:  Normal   |   Keywords:  needs-proposal, ipv6, tor-relay
Actual Points:   |  Parent ID:  #24403
   Points:  1|   Reviewer:
  Sponsor:  SponsorV-|
  can|
-+-
 Make relays with IPv6 ORPorts start attempting to connect to IPv6 ORPorts
 in response to EXTEND2 cells containing IPv6 addresses. (Relays always
 prefer existing canonical connections, which may be over IPv4.)

 Make these relays declare the protover from #24404.

 Make them implement the IPv4/IPv6 Extend behviour from #24404.

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

Re: [tor-bugs] #24404 [Core Tor/Tor]: Propose a relay protover that allows IPv6 extends

[Tor Bug Tracker & Wiki]

#24404: Propose a relay protover that allows IPv6 extends
-+-
 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:  needs-proposal, ipv6, tor-relay  |  Actual Points:
Parent ID:  #24403   | Points:  1
 Reviewer:   |Sponsor:  SponsorV-
 |  can
-+-

Comment (by teor):

 We also need to decide what relays should do when:
   * An EXTEND request is received with an IPv4 and an IPv6 address (relays
 should only use IPv6 in step 2), and
   * The relay receiving the extend request supports the new protover:
 * Always use IPv4? (then we'll need another protover for client IPv6
 extends)
 * Choose between IPv4 and IPv6 at random?
 * Attempt to switch between IPv4 and IPv6?
 * Do something even better?

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

Re: [tor-bugs] #6939 [Core Tor/Tor]: Missing IPv6 ORPort reachability check

[Tor Bug Tracker & Wiki]

#6939: Missing IPv6 ORPort reachability check
-+-
 Reporter:  shamrock |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.4.2-alpha
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, tor-relay, ipv6-relay self-|  Actual Points:
  test   |
Parent ID:  #24403   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:  #4565 => #24403


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

Re: [tor-bugs] #24403 [Core Tor/Tor]: Propose and implement IPv6 ORPort reachability checks on relays

[Tor Bug Tracker & Wiki]

#24403: Propose and implement IPv6 ORPort reachability checks on relays
-+
 Reporter:  teor |  Owner:  (none)
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, tor-relay  |  Actual Points:
Parent ID:  #4565| Points:
 Reviewer:   |Sponsor:  SponsorV-can
-+
Changes (by teor):

 * parent:   => #4565


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

Re: [tor-bugs] #4565 [Core Tor/Tor]: Enable relays to talk to other relays via IPv6

[Tor Bug Tracker & Wiki]

#4565: Enable relays to talk to other relays via IPv6
-+-
 Reporter:  karsten  |  Owner:  ln5
 Type:  project  | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6 tor-relay needs-design  |  Actual Points:
Parent ID:  #5788| Points:  5
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 Replying to [comment:10 arma]:
 > The roadmap in #4556 basically says "this relay-to-relay use of ipv6
 will happen naturally over time".
 >
 > Meaning, there isn't any discussion of whether it's a good idea to
 switch to ipv6 if both relays support it, or leave those tls connections
 on ipv4 since we still mandate all relays be able to speak ipv4.
 >
 > So: is there some advantage to moving relay communications to ipv6?
 Maybe the routing is different and better? (I could imagine the routing
 being different and worse, in the case of folks who have the more
 centralized hurricane electric ipv6 connections.)

 We'll try to answer this as part of #24403.
 But I think the answer will be: "just use either at random".

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

Re: [tor-bugs] #24393 [Core Tor/Tor]: Clients should check IPv4 and IPv6 subnets when choosing circuit paths

[Tor Bug Tracker & Wiki]

#24393: Clients should check IPv4 and IPv6 subnets when choosing circuit paths
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, intro, tor-dirauth security|  Actual Points:
  sybil  |
Parent ID:  #24403   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:  #7193 => #24403


Comment:

 #7193 also depends on 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] #15518 [Core Tor/Tor]: Tor considers routers in the same IPv6 /16 to be "in the same subnet"

[Tor Bug Tracker & Wiki]

#15518: Tor considers routers in the same IPv6 /16 to be "in the same subnet"
-+-
 Reporter:  isis |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, path, path-bias, tor-client|  Actual Points:
  easy   |
Parent ID:  #24393   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by teor):

 * parent:  #7193 => #24393


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

Re: [tor-bugs] #7193 [Core Tor/Tor]: Tor's sybil protection doesn't consider IPv6

[Tor Bug Tracker & Wiki]

#7193: Tor's sybil protection doesn't consider IPv6
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ipv6, intro, tor-dirauth security|  Actual Points:
  sybil  |
Parent ID:   | Points:  small
 Reviewer:   |Sponsor:
-+-

Comment (by teor):

 We need to do #24393 before we do 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] #13112 [Core Tor/Tor]: Some things are probably broken when we advertise multiple ORPorts and only some are reachable

[Tor Bug Tracker & Wiki]

#13112: Some things are probably broken when we advertise multiple ORPorts and 
only
some are reachable
-+-
 Reporter:  andrea   |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-relay reachability self-testing  |  Actual Points:
  needs-design ipv6 tor-bridge   |
Parent ID:  #24403   | Points:  1
 Reviewer:   |Sponsor:
 |  SponsorV-can
-+-
Changes (by teor):

 * version:  Tor: unspecified =>
 * points:   => 1
 * sponsor:   => SponsorV-can
 * parent:   => #24403
 * milestone:  Tor: unspecified => 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] #17782 [Core Tor/Tor]: Relays may publish descriptors with incorrect IP address

[Tor Bug Tracker & Wiki]

#17782: Relays may publish descriptors with incorrect IP address
---+---
 Reporter:  fk |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  0.3.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Major  | Resolution:
 Keywords:  intro tor-relay address-detection  |  Actual Points:
Parent ID:  #24403 | Points:  1
 Reviewer: |Sponsor:  SponsorV-
   |  can
---+---
Changes (by teor):

 * sponsor:   => SponsorV-can
 * points:  medium => 1
 * version:  Tor: unspecified =>
 * parent:   => #24403
 * milestone:  Tor: unspecified => Tor: 0.3.3.x-final


Comment:

 This will likely be fixed by #13112 or in other children of #24403.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24406 [Core Tor/Tor]: Implement IPv6 ORPort reachability fallback

[Tor Bug Tracker & Wiki]

#24406: Implement IPv6 ORPort reachability fallback
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:  ipv6, tor-relay
Actual Points:|  Parent ID:  #24403
   Points:  1 |   Reviewer:
  Sponsor:  SponsorV-can  |
--+
 Implement the IPv6 ORPort reachability fallback from #24404.

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

Re: [tor-bugs] #24404 [Core Tor/Tor]: Propose a relay protover that allows IPv6 extends

[Tor Bug Tracker & Wiki]

#24404: Propose a relay protover that allows IPv6 extends
-+-
 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:  needs-proposal, ipv6, tor-relay  |  Actual Points:
Parent ID:  #24403   | Points:  1
 Reviewer:   |Sponsor:  SponsorV-
 |  can
-+-

Comment (by teor):

 We also need to decide which fallback to use if we don't confirm ourselves
 reachable within 20 minutes (this can happen because relays will use
 existing canonical connections rather than making a new one):
   * use an IPv6 exit to connect to our ORPort (this doesn't authenticate
 that the remote port actually belongs to us)
   * use a magic value for the identity (all zeroes?) when connecting to
 our ORPort, to force a new connection (DoS risk, doesn't authenticate, but
 does check addresses in the NETINFO cell)
   * close an old/unused connection, and then extend a preemptive circuit
 to ourselves over IPv6
   * put flags in the extend cell that say "must IPv6"?
   * some smarter mechanism?

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

Re: [tor-bugs] #24404 [Core Tor/Tor]: Propose a relay protover that allows IPv6 extends

[Tor Bug Tracker & Wiki]

#24404: Propose a relay protover that allows IPv6 extends
-+-
 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:  needs-proposal, ipv6, tor-relay  |  Actual Points:
Parent ID:  #24403   | Points:  1
 Reviewer:   |Sponsor:  SponsorV-
 |  can
-+-

Comment (by Sebastian):

 Extend the notion of canonical to have a canonical v4 and a canonical v6
 connection. Only in the event of a reachability check with a "must v4" or
 "must v6" flag create a new connection of the other connection type. Treat
 this second connection as canonical for the purpose of deciding whether to
 close it etc, but not for actual traffic. Does that alleviate the DoS risk
 you're worried about? If not, why not?

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

Re: [tor-bugs] #24400 [Core Tor/Tor]: Seccomp filter incorrectly tries to act on strings, allowing sandbox bypass

[Tor Bug Tracker & Wiki]

#24400: Seccomp filter incorrectly tries to act on strings, allowing sandbox 
bypass
--+
 Reporter:  Sebastian |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  sandbox   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 I think `cat $ hello.c` should probably be `$ cat hello.c` instead.

 Tested the demonstration files and they work. There is also a danger of
 thread concurrency bugs when trying to read memory in a filter context as
 well.

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

Re: [tor-bugs] #23783 [Core Tor/Tor]: Can't build Tor 0.3.2.2-alpha with mingw32 on Windows 7

[Tor Bug Tracker & Wiki]

#23783: Can't build Tor 0.3.2.2-alpha with mingw32 on Windows 7
-+-
 Reporter:  Bizarre™ |  Owner:  (none)
 Type:  defect   | Status:  closed
 Priority:  High |  Milestone:  Tor:
 |  0.3.2.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.3.2.2-alpha
 Severity:  Normal   | Resolution:  fixed
 Keywords:  0.3.2.2-alpha-blogpost-bugreport,|  Actual Points:
  windows, mingw |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by Bizarre™):

 Update:

 Hi, guys. I just want to let you know that I was able to build Tor
 0.3.2.5-alpha. Thank you very much and keep up the good work :D

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

Re: [tor-bugs] #24404 [Core Tor/Tor]: Propose a relay protover that allows IPv6 extends

[Tor Bug Tracker & Wiki]

#24404: Propose a relay protover that allows IPv6 extends
-+-
 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:  needs-proposal, ipv6, tor-relay  |  Actual Points:
Parent ID:  #24403   | Points:  1
 Reviewer:   |Sponsor:  SponsorV-
 |  can
-+-

Comment (by teor):

 Replying to [comment:4 Sebastian]:
 > Extend the notion of canonical to have a canonical v4 and a canonical v6
 connection. Only in the event of a reachability check with a "must v4" or
 "must v6" flag create a new connection of the other connection type. Treat
 this second connection as canonical for the purpose of deciding whether to
 close it etc, but not for actual traffic. Does that alleviate the DoS risk
 you're worried about? If not, why not?

 It mitigate it, but does not eliminate it, because it still doubles the
 number of open connections per relay (in a worst-case scenario where all
 relays have IPv6). However, a scheme like this would also substantially
 reduce the need for a fallback mechanism for reachability checking. To
 eliminate it, we could make a must-flagged EXTEND cell trigger a NETINFO
 cell along an existing connection.

 Here's a much nicer alternative fallback that avoids adding must flags:
 * relays with the latest protover respond to NETINFO cells on existing
 connections by sending a NETINFO cell, at most every N minutes per
 connection (N < 20 minutes, the current reachability warning threshold)

 Then the fallback becomes:
 * if there are no relays with the right protover or all relays with the
 right protover have an existing connection to this relay, try these steps
 in order
   1. Elicit a NETINFO cell by sending a relay with the right protover a
 NETINFO cell, where this relay is the server side of the TLS connection
   2. Elicit a NETINFO cell by sending a relay with the right protover a
 NETINFO cell, where this relay is the client side of the TLS connection
   3. Open a connection to a relay to elicit a NETINFO cell

 I think this is conceptually much simpler, uses the same mechanisms we
 would use anyway, and minimises the number of changes required.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24407 [Core Tor/Tor]: No warning when IPv6 port is not reachable

[Tor Bug Tracker & Wiki]

#24407: No warning when IPv6 port is not reachable
--+--
 Reporter:  MikeEU|  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.8
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 Case:
 Running relay on IPv4. All checks ok, running good.
 Stop relay, add ORPort for IPv6.
 Restart. Checks look ok, circuits are built up.
 After a while, no new users are added, but circuits disappear and relay is
 reported as off line in atlas. This lasted for over a day.

 Reason: IPv6 port was blocked by firewall. This was not reported in the
 error logs (but was tested, hence the relay being reported offline).
 Unblock IPv6 port places the relay 'online' again, and all works well.

 Request: report on IPv6 port not reachable. This would have saved quite
 some time and searching.
 Question/discussion: should a relay go offline when IPv4 works, but only
 IPv6 has problems? And what happens if IPv4 is taken off completely?

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

Re: [tor-bugs] #24407 [Core Tor/Tor]: No warning when IPv6 port is not reachable

[Tor Bug Tracker & Wiki]

#24407: No warning when IPv6 port is not reachable
--+--
 Reporter:  MikeEU|  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.8
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by Sebastian):

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


Comment:

 See #24403 for the "do ipv6 reachability checks on relays" feature. I'm
 going to close this as a duplicate in favor of that other ticket. While we
 don't have that I argue that marking your relay non-running is the best
 possible course of action because it alerted you to the problem and
 allowed you to fix it, so today we have one more relay on IPv6 than we
 would've had otherwise.

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

Re: [tor-bugs] #24407 [Core Tor/Tor]: No warning when IPv6 port is not reachable

[Tor Bug Tracker & Wiki]

#24407: No warning when IPv6 port is not reachable
--+--
 Reporter:  MikeEU|  Owner:  (none)
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.8
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Sebastian):

 Oh, to answer your last question, every relay must have ipv4 currently.
 This is unlikely to change in the near future.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24408 [- Select a component]: New Identity fails to clear unprotected cookies

[Tor Bug Tracker & Wiki]

#24408: New Identity fails to clear unprotected cookies
--+---
 Reporter:  theresa   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:  cookies, new identity
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+---
 Encountered the following:

 1. If 'Always use private browsing mode' has been disabled in preferences;
 2. And some cookies for '''domain A''' were marked as ''protected'' in
 Cookie Protections dialog;
 3. After clicking ''New Identity''
 4. Unprotected cookies for unrelated ''domain B'' are not deleted.

 Expected behavior: all cookies except the ones marked as ''protected''
 (i.e. for '''domain A''') should have been deleted.

 Using TBB 7.0.10.

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

[tor-bugs] #24409 [Core Tor/Nyx]: nyx crashed when trying to write to the torrc

[Tor Bug Tracker & Wiki]

#24409: nyx crashed when trying to write to the torrc
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  atagar
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Nyx   |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 nyx crashed when trying to write to the torrc. Here are the crash logs

 [WARN] Couldn't rename configuration file "/etc/tor/torrc" to
 "/etc/tor/torrc.orig.1": Read-only file system

 {{{
 Traceback (most recent call last):

   File "/usr/local/bin/nyx", line 11, in 

     sys.exit(main())

   File "/usr/local/lib/python3.5/dist-packages/nyx/__init__.py", line 176,
 in main

     nyx.starter.main()

   File "/usr/local/lib/python3.5/dist-packages/stem/util/conf.py", line
 289, in wrapped

     return func(*args, config = config, **kwargs)

   File "/usr/local/lib/python3.5/dist-packages/nyx/starter.py", line 118,
 in main

     nyx.curses.start(nyx.draw_loop, acs_support =
 config.get('acs_support', True), transparent_background = True, cursor =
 False)

   File "/usr/local/lib/python3.5/dist-packages/nyx/curses.py", line 217,
 in start

     curses.wrapper(_wrapper)

   File "/usr/lib/python3.5/curses/__init__.py", line 94, in wrapper

     return func(stdscr, *args, **kwds)

   File "/usr/local/lib/python3.5/dist-packages/nyx/curses.py", line 215,
 in _wrapper

     function()

   File "/usr/local/lib/python3.5/dist-packages/nyx/__init__.py", line 243,
 in draw_loop

     keybinding.handle(key)

   File "/usr/local/lib/python3.5/dist-packages/nyx/panel/__init__.py",
 line 84, in handle

     self._action()

   File "/usr/local/lib/python3.5/dist-packages/nyx/panel/config.py", line
 219, in _show_write_dialog

     controller.save_conf()

   File "/usr/local/lib/python3.5/dist-packages/stem/control.py", line
 3220, in save_conf

     raise stem.OperationFailed(response.code, response.message)

 stem.OperationFailed: Unable to write configuration to disk.
 }}}

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

Re: [tor-bugs] #24404 [Core Tor/Tor]: Propose a relay protover that allows IPv6 extends

[Tor Bug Tracker & Wiki]

#24404: Propose a relay protover that allows IPv6 extends
-+-
 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:  needs-proposal, ipv6, tor-relay  |  Actual Points:
Parent ID:  #24403   | Points:  1
 Reviewer:   |Sponsor:  SponsorV-
 |  can
-+-

Comment (by teor):

 Replying to [comment:5 teor]:
 > relays with the latest protover respond to NETINFO cells on existing
 connections by sending a NETINFO cell, at most every N minutes per
 connection (N < 20 minutes, the current reachability warning threshold)
 >
 > Then the fallback becomes:
 > * if there are no relays with the right protover or all relays with the
 right protover have an existing connection to this relay, try these steps
 in order
 >   1. Elicit a NETINFO cell by sending a relay with the right protover a
 NETINFO cell, where this relay is the server side of an existing TLS
 connection over the desired IP version

 These won't work, they don't get a NETINFO for the ORPort address:

 >   2. ~~Elicit a NETINFO cell by sending a relay with the right protover
 a NETINFO cell, where this relay is the client side of an existing TLS
 connection over the desired IP version~~
 >   3. ~~Open a connection to a relay to elicit a NETINFO cell over the
 desired IP version~~

 Instead, we should:
 2. expire 10% of our oldest connections, and optionally 10% of our least-
 used connections (don't do this on authorities)
 3. Retry step 1
 4. If we keep on failing, we are not getting any inbound connections, so
 we're an anomaly: a busy relay that can only make outbound connections.
 (This situation fixes itself: if we give up and drop out of the consensus,
 we're no longer a busy relay, and our reachability checks should work.)

 There will need to be limits so that we publish immediately if a minimum
 number of relays supporting the protover aren't in the consensus.
 And we should make sure we expire a minimum number of connections.

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

Re: [tor-bugs] #24408 [Applications/Tor Browser]: New Identity fails to clear unprotected cookies

[Tor Bug Tracker & Wiki]

#24408: New Identity fails to clear unprotected cookies
--+--
 Reporter:  theresa   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  cookies, new identity |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by arma):

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


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

Re: [tor-bugs] #24408 [Applications/Tor Browser]: New Identity fails to clear unprotected cookies when private browsing mode is disabled (was: New Identity fails to clear unprotected cookies)

[Tor Bug Tracker & Wiki]

#24408: New Identity fails to clear unprotected cookies when private browsing 
mode
is disabled
--+--
 Reporter:  theresa   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  cookies, new identity |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

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