Re: [tor-bugs] #24531 [Core Tor/Tor]: sched: Add function to change scheduler state and always use it

[Tor Bug Tracker & Wiki]

#24531: sched: Add function to change scheduler state and always use it
-+
 Reporter:  pastly   |  Owner:  (none)
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, easy  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by aruna1234):

 * Attachment "0002-Bug-24531-Function-to-change-channel-scheduler-
 state.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] #24531 [Core Tor/Tor]: sched: Add function to change scheduler state and always use it

[Tor Bug Tracker & Wiki]

#24531: sched: Add function to change scheduler state and always use it
-+
 Reporter:  pastly   |  Owner:  (none)
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, easy  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by aruna1234):

 Please igoner the above patch.
 The following is the correct one.

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

Re: [tor-bugs] #24531 [Core Tor/Tor]: sched: Add function to change scheduler state and always use it

[Tor Bug Tracker & Wiki]

#24531: sched: Add function to change scheduler state and always use it
-+
 Reporter:  pastly   |  Owner:  (none)
 Type:  defect   | Status:  needs_revision
 Priority:  Medium   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-sched, easy  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by aruna1234):

 * Attachment "0003-Bug-24531-Function-to-change-the-channel-
 scheduler-s.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] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

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

Comment (by mcs):

 Replying to [comment:23 isabela]:
 > > In the meantime, please let us know if you would like us to make some
 screenshots. I know it is difficult to visualize the interface based on a
 textual description.
 >
 > If is not too much trouble I would like that. But if its, don't worry we
 can play with it once is in alpha.

 We will post some screenshots in the next few days, probably on Monday.

 > Question! If all goes well this implementation will be on a alpha
 release around Dec 15?

 Unfortunately, I think we will be too late to make it into that release.
 Even if we can get the client side done, we do not have a server to which
 we can talk. Currently Kathy and I are testing with our own copy of
 BridgeDB that is deployed on a test server that is not on the public net.

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

Re: [tor-bugs] #24567 [Core Tor]: Hypothesis: Some exit nodes are tampering/blocking DNS request

[Tor Bug Tracker & Wiki]

#24567: Hypothesis: Some exit nodes are tampering/blocking DNS request
-+--
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  task | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Core Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  exitmap  |  Actual Points:
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
-+--
Changes (by teor):

 * status:  new => assigned
 * severity:  Major => Normal
 * cc: phw (added)
 * component:  Core Tor/Torflow => Core Tor
 * priority:  High => Medium
 * keywords:   => exitmap
 * points:   => 3
 * owner:  tom => (none)


Old description:

> Recently, DNSPort is way unstable. I think some exit nodes are returning
> wrong IP address(pointed to some hosting provider) or blocking DNS
> request.
>
> Can anyone experiment on this automatically?
>
> https://www.privateinternetaccess.com/

New description:

 Recently, DNSPort is way unstable. I think some exit nodes are returning
 wrong IP address(pointed to some hosting provider) or blocking DNS
 request.

 Can anyone experiment on this automatically?

 privateinternetaccess.com

 Edit: potential link spam disabled

--

Comment:

 This is a task for exitmap, which doesn't have a component on this bug
 tracker.
 Try here:
 https://github.com/NullHypothesis/exitmap

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

Re: [tor-bugs] #24568 [Core Tor/Tor]: I get a warn error every time I build tor from source

[Tor Bug Tracker & Wiki]

#24568: I get a warn error every time I build tor from source
---+---
 Reporter:  Dbryrtfbcbhgf  |  Owner:  (none)
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:  duplicate
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by nickm):

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


Comment:

 Thanks for reporting this!  I think it is a duplicate of #24480.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24568 [Core Tor/Tor]: I get a warn error every time I build tor from source

[Tor Bug Tracker & Wiki]

#24568: I get a warn error every time I build tor from source
---+
 Reporter:  Dbryrtfbcbhgf  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Core Tor/Tor   |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+
 I get a warn error every time I build tor from source. I'm running macOS
 and using Xcode 9.2

 {{{
 Tor 0.3.2.6
 }}}
 {{{
 '''src/or/rendservice.c:1910:29: warning: comparison of integers of
 different signs: 'ssize_t' (aka 'long') and 'size_t' (aka 'unsigned long')
 [-Wsign-compare]'''

     parsed_req->ciphertext, MIN(parsed_req->ciphertext_len, keylen),

 '''                            ^   ~~  ~~'''

 
'''/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/sys/param.h:215:23:
 note: '''expanded from macro 'MIN'

 #define MIN(a,b) (((a)<(b))?(a):(b))
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  Blocker| Resolution:
 Keywords: |  Actual Points:
Parent ID:  #24351 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 https://support.google.com/recaptcha/answer/6081888?hl=en


 We're sorry, but your computer or network may be sending automated
 queries. To protect our users, we can't process your request right now.

 equals:

 We're sorry, but we can't track you if you continue to use Tor network.
 To protect our good information-domestic sheep and cows, aka "users",
 we refuse to serve anonymous users. Take off you clothes now or walk away.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: 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:  Blocker| Resolution:
 Keywords: |  Actual Points:
Parent ID:  #24351 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cypherpunks):

 I still can't login!!
 This will result in noob tor broser given up and move to normal, censored,
 monitored network.

 Tor devs please respond, over!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24567 [Core Tor/Torflow]: Hypothesis: Some exit nodes are tampering/blocking DNS request

[Tor Bug Tracker & Wiki]

#24567: Hypothesis: Some exit nodes are tampering/blocking DNS request
--+-
 Reporter:  cypherpunks   |  Owner:  tom
 Type:  task  | Status:  new
 Priority:  High  |  Milestone:
Component:  Core Tor/Torflow  |Version:
 Severity:  Major |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+-
 Recently, DNSPort is way unstable. I think some exit nodes are returning
 wrong IP address(pointed to some hosting provider) or blocking DNS
 request.

 Can anyone experiment on this automatically?

 https://www.privateinternetaccess.com/

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

Re: [tor-bugs] #23100 [Core Tor/Tor]: Circuit Build Timeout needs to count hidden service circuits

[Tor Bug Tracker & Wiki]

#23100: Circuit Build Timeout needs to count hidden service circuits
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:  Tor:
 |  0.2.7
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tor-hs, path-bias, guard-discovery-  |  Actual Points:
  prop247-controller, needs-proposal, mike-can,  |
  prop247, tor-guard, review-group-25, review-   |
  group-26, review-group-27  |
Parent ID:  #9001| Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Mike made a `bug23114_squashed2`; I merged it, plus
 241b676638285e63bd6e4ca5225444a4b16207be to handle the fallout from
 #23347.

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

Re: [tor-bugs] #23114 [Core Tor/Tor]: Circuit Build Timeout should apply at circuit completion

[Tor Bug Tracker & Wiki]

#23114: Circuit Build Timeout should apply at circuit completion
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery-prop247-controller,  |  implemented
  review-group-25, review-group-26, review-  |  Actual Points:
  group-27   |
Parent ID:  #23100   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by nickm):

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


Comment:

 Mike made a `bug23114_squashed2`; I merged it, plus
 241b676638285e63bd6e4ca5225444a4b16207be to handle the fallout from
 #23347.

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

Re: [tor-bugs] #19984 [Core Tor/Tor]: Use a better set of comparison/evaluation functions for deciding which connections to kill when OOS

[Tor Bug Tracker & Wiki]

#19984: Use a better set of comparison/evaluation functions for deciding which
connections to kill when OOS
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  dos, sockets  |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:  SponsorV-can
--+
Changes (by Hello71):

 * priority:  Low => High


Comment:

 directory connections are poorly impacted by this metric, but:

 1. if the connection is legitimate, there will be data flowing down it
 soon after fetching directory information anyways. works better with the
 new ORPort-only architecture, but for legacy clients I guess we could just
 sum together the bandwidth used by an IP address and use that somehow

 2. AIUI directory connections are only absolutely necessary during the
 very first startup. at any later time, if a directory connection cannot be
 made or is suddenly terminated, cached data can be temporarily used until
 a connection can be re-established. therefore, prematurely terminating
 directory connections is not a huge problem, and is much better than
 rejecting new connections which may require relay service.

 raising priority as discussed on IRC.

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

Re: [tor-bugs] #23761 [Metrics/Website]: Add IPv6 relay graphs to metrics site

[Tor Bug Tracker & Wiki]

#23761: Add IPv6 relay graphs to metrics site
--+
 Reporter:  teor  |  Owner:  metrics-team
 Type:  enhancement   | Status:  needs_revision
 Priority:  Medium|  Milestone:
Component:  Metrics/Website   |Version:
 Severity:  Normal| Resolution:
 Keywords:  core-tor-wants, ipv6  |  Actual Points:  0.5
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Based on the discussion on the metrics list, can we go with the column
 name "reachable", and edit the text:
 {{{
 reachable: Whether enough directory authorities have confirmed
 reachability of an IPv6 OR address announced by a relay, by
 including an "a" line in the consensus
 }}}

 I'd say "the same IPv6 address", but it reads badly, and this version
 captures the essence of what's happening.
 This version is also future-proof, if we ever have relays announce more
 than one address, or ever have authorities check more than one address.

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

Re: [tor-bugs] #24497 [Webpages/Website]: Improve documentation for tor relay operators

[Tor Bug Tracker & Wiki]

#24497: Improve documentation for tor relay operators
--+
 Reporter:  arthuredelstein   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by alison):

 > > I plan to work on migrating more of this today.
 >
 > I'm waiting for you to finish migrating content, once you are done I'll
 start working on that wiki page.

 I migrated everything from our original post. Some things to note:

 * My original plan to move away from all externally linked content has not
 happened. Lots of the links have images and additional links, so I
 couldn't easily create new trac pages. So maybe we should do that part
 more gradually.
 * I have not migrated the iptables rules because there is a conversation
 happening on the pad about them.
 * I noted some of the places that I plan to add to over the weekend, but
 others should feel free to edit away!

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

Re: [tor-bugs] #23114 [Core Tor/Tor]: Circuit Build Timeout should apply at circuit completion

[Tor Bug Tracker & Wiki]

#23114: Circuit Build Timeout should apply at circuit completion
-+-
 Reporter:  mikeperry|  Owner:
 |  mikeperry
 Type:  enhancement  | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.3.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  guard-discovery-prop247-controller,  |  Actual Points:
  review-group-25, review-group-26, review-  |
  group-27   |
Parent ID:  #23100   | Points:
 Reviewer:  asn  |Sponsor:
-+-
Changes (by nickm):

 * status:  needs_review => merge_ready


Comment:

 looks good to me with the changes on gitlab.

 Mike, do you have time to squash this?  I tried to do it myself, and got
 so many conflicts that I'm fairly sure I'm doing it wrong.

 (if you git rebase -i --autosquash
 3c31d99b023f341829ccc94d2e270f38cfbf893a, or use the git-resquash script
 in the githax repository, it'll be a pure squash with no rebasing)

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

Re: [tor-bugs] #24427 [Core Tor/Tor]: Consider using other mach_*_time() functions for monotonic time on OSX

[Tor Bug Tracker & Wiki]

#24427: Consider using other mach_*_time() functions for monotonic time on OSX
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:  ahf   |Sponsor:  Sponsor8-can
--+
Changes (by ahf):

 * reviewer:   => ahf


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

Re: [tor-bugs] #19984 [Core Tor/Tor]: Use a better set of comparison/evaluation functions for deciding which connections to kill when OOS

[Tor Bug Tracker & Wiki]

#19984: Use a better set of comparison/evaluation functions for deciding which
connections to kill when OOS
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  defect| Status:  accepted
 Priority:  Low   |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  dos, sockets  |  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:  SponsorV-can
--+

Comment (by Hello71):

 normally, one would use IP reputation to deal with spamming attacks.
 however, for obvious reasons, I can see why that might be frowned upon in
 these circles.

 therefore, some other unfalsifiable proof of work is required. one could
 implement a custom proof-of-work protocol, but it seems more useful to me
 to measure the bandwidth used. this incurs negligible overhead for
 legitimate users, but has the added benefit that attackers are forced to
 encrypt their data in order to increase their bandwidth usage.
 additionally, if attackers have vastly more bandwidth than you, they can
 simply mount a traditional DoS attack anyways.

 tl;dr just sort connections by recently used valid data traffic.

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

Re: [tor-bugs] #24497 [Webpages/Website]: Improve documentation for tor relay operators

[Tor Bug Tracker & Wiki]

#24497: Improve documentation for tor relay operators
--+
 Reporter:  arthuredelstein   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by steph):

 * cc: steph@… (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] #24566 [Applications/Tor Browser]: When I open TorBrowser 7.0.11 the popup goes completely white

[Tor Bug Tracker & Wiki]

#24566: When I open TorBrowser 7.0.11 the popup goes completely white
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by Dbryrtfbcbhgf):

 * Attachment "bug.mov" added.

 Video showing the bug

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24566 [Applications/Tor Browser]: When I open TorBrowser 7.0.11 the popup goes completely white

[Tor Bug Tracker & Wiki]

#24566: When I open TorBrowser 7.0.11 the popup goes completely white
--+--
 Reporter:  Dbryrtfbcbhgf |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major |   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 When I open !TorBrowser 7.0.11 the popup goes completely white, I captured
 a debug log when the bug was occurring.

 {{{
 Dec 08 12:50:28.000 [notice] Tor 0.3.1.9 (git-727d3f1b5e6eeda7) opening
 log file.

 Dec 08 12:50:28.895 [notice] Tor 0.3.1.9 (git-727d3f1b5e6eeda7) running on
 Darwin with Libevent 2.0.22-stable, OpenSSL 1.0.2k, Zlib 1.2.11, Liblzma
 N/A, and Libzstd N/A.

 Dec 08 12:50:28.896 [notice] Tor can't help you if you use it wrong! Learn
 how to be safe at https://www.torproject.org/download/download#warning

 Dec 08 12:50:28.896 [notice] Read configuration file
 "/Users/"user"/Desktop/tor/TorBrowser.app/Contents/Resources/TorBrowser/Tor
 /torrc-defaults".

 Dec 08 12:50:28.896 [notice] Read configuration file
 "/Users/"user"/Desktop/tor/TorBrowser-Data/Tor/torrc".

 Dec 08 12:50:28.899 [notice] Opening Control listener on 127.0.0.1:9151

 Dec 08 12:50:28.900 [notice] DisableNetwork is set. Tor will not make or
 accept non-control network connections. Shutting down all existing
 connections.

 Dec 08 12:50:28.000 [warn] Your log may contain sensitive information -
 you're logging more than "notice". Don't log unless it serves an important
 reason. Overwrite the log afterwards.

 Dec 08 12:50:28.000 [info] options_act_reversible: Recomputed OOS
 thresholds: ConnLimit 1000, ConnLimit_ 10176, ConnLimit_high_thresh 10112,
 ConnLimit_low_thresh 7632

 Dec 08 12:50:28.000 [debug] tor_disable_debugger_attach: Attemping to
 disable debugger attachment to Tor for unprivileged users.

 Dec 08 12:50:28.000 [debug] tor_disable_debugger_attach: Debugger
 attachment disabled for unprivileged users.

 Dec 08 12:50:28.000 [info] tor_lockfile_lock: Locking
 "/Users/"user"/Desktop/tor/TorBrowser-Data/Tor/lock"

 Dec 08 12:50:28.000 [debug] parse_dir_authority_line: Trusted 100
 dirserver at 128.31.0.39:9131 (9695)

 Dec 08 12:50:28.000 [debug] parse_dir_authority_line: Trusted 100
 dirserver at 86.59.21.38:80 (847B)

 Dec 08 12:50:28.000 [debug] parse_dir_authority_line: Trusted 100
 dirserver at 194.109.206.212:80 (7EA6)

 Dec 08 12:50:28.000 [debug] parse_dir_authority_line: Trusted 16 dirserver
 at 37.218.247.217:80 (1D8F)

 Dec 08 12:50:28.000 [debug] parse_dir_authority_line: Trusted 100
 dirserver at 131.188.40.189:80 (F204)

 Dec 08 12:50:28.000 [debug] parse_dir_authority_line: Trusted 100
 dirserver at 193.23.244.244:80 (7BE6)

 Dec 08 12:50:28.000 [debug] parse_dir_authority_line: Trusted 100
 dirserver at 171.25.193.9:443 (BD6A)

 Dec 08 12:50:28.000 [debug] parse_dir_authority_line: Trusted 100
 dirserver at 154.35.175.225:80 (CF6D)

 Dec 08 12:50:28.000 [debug] parse_dir_authority_line: Trusted 100
 dirserver at 199.58.81.140:80 (74A9)

 Dec 08 12:50:28.000 [debug] parse_dir_authority_line: Trusted 100
 dirserver at 204.13.164.118:80 (24E2)

 Dec 08 12:50:28.000 [debug] file_status: stat()ing
 /Users/"user"/Desktop/tor/TorBrowser-Data/Tor/state

 Dec 08 12:50:28.000 [info] or_state_load: Loaded state from
 "/Users/"user"/Desktop/tor/TorBrowser-Data/Tor/state"

 Dec 08 12:50:28.000 [info] circuit_build_times_parse_state: Adding 0
 timeouts.

 Dec 08 12:50:28.000 [info] circuit_build_times_parse_state: Loaded 0/0
 values from 0 lines in circuit time histogram

 Dec 08 12:50:28.000 [info] read_file_to_str: Could not open
 "/Users/"user"/Desktop/tor/TorBrowser-Data/Tor/router-stability": No such
 file or directory

 Dec 08 12:50:28.000 [debug] tor_rename: Renaming /Users/"user"/Desktop/tor
 /TorBrowser-Data/Tor/control_auth_cookie.tmp to /Users/"user"/Desktop/tor
 /TorBrowser-Data/Tor/control_auth_cookie

 Dec 08 12:50:28.000 [info] init_cookie_authentication: Generated auth
 cookie file in '"/Users/"user"/Desktop/tor/TorBrowser-
 Data/Tor/control_auth_cookie"'.

 Dec 08 12:50:28.000 [info] cell_ewma_set_scale_factor: Disabled cell_ewma
 algorithm because of value in Default value

 Dec 08 12:50:28.000 [notice] Parsing GEOIP IPv4 file
 
/Users/"user"/Desktop/tor/TorBrowser.app/Contents/Resources/TorBrowser/Tor/geoip.

 Dec 08 12:50:29.000 [notice] Parsing GEOIP IPv6 file
 
/Users/"user"/Desktop/tor/TorBrowser.app/Contents/Resources/TorBrowser/Tor/geoip6.

 Dec 08 12:50:29.000 [info] add_predicted_port: New port prediction added.
 Will continue predictive circ building for 2159 more seconds.

 Dec 08 12:50:29.000 [info] crypto_global_init: NOT using OpenSSL en

Re: [tor-bugs] #24564 [- Select a component]: confirmation/information on tor failure with weird crashes due to "OpenSSL version from headers does not match"

[Tor Bug Tracker & Wiki]

#24564: confirmation/information on tor failure with weird crashes due to 
"OpenSSL
version from headers does not match"
--+
 Reporter:  miroR |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Hm.  Those don't look like the kind of crashes I'd expect to see from a
 mismatched openssl version.  If that were going to cause a bug, it would
 probably crash in something more related to header layout.

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

Re: [tor-bugs] #24337 [Core Tor/Tor]: Every _free() function should be a macro that sets the corresponding pointer to NULL.

[Tor Bug Tracker & Wiki]

#24337: Every _free() function should be a macro that sets the corresponding
pointer to NULL.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
  |  implemented
 Keywords:  review-group-26, review-group-27  |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
  |  Sponsor8-can
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #24337 [Core Tor/Tor]: Every _free() function should be a macro that sets the corresponding pointer to NULL.

[Tor Bug Tracker & Wiki]

#24337: Every _free() function should be a macro that sets the corresponding
pointer to NULL.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:
  |  merge_ready
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  review-group-26, review-group-27  |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
  |  Sponsor8-can
--+

Comment (by nickm):

 I don't think that macro example would work -- putting FREE_AND_NULL in an
 inline function would make it have no effect on the varfiable the functio
 is called on -- only __obj would get set to NULL.

 What you'd need here is some way do say
 {{{
 #define DECL_FREE(name, typename) \
   void name##_(typename *__obj);  \
   #define name(obj) FREE_AND_NULL(typename, name##_, (obj))
 }}}
 but you can't do that in C.

 Squashed and merged.  Some conflicts resolved in "5ee0cccd49e57fad8c81".

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

Re: [tor-bugs] #23709 [Core Tor/Tor]: channel: `outgoing_queue` and `incoming_queue` are always empty

[Tor Bug Tracker & Wiki]

#23709: channel: `outgoing_queue` and `incoming_queue` are always empty
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  closed
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  tor-sched |  Actual Points:
Parent ID:  #23993| Points:
 Reviewer:  nickm |Sponsor:  SponsorV
--+
Changes (by nickm):

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


Comment:

 Okay, I think this is looking fairly good.  Time to merge!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24565 [- Select a component]: User queries and issues

[Tor Bug Tracker & Wiki]

#24565: User queries and issues
--+
 Reporter:  Pari  |  Owner:  (none)
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 This ticket contains user queries and issues, observed and collected from
 various channels, updated regularly.

 
 == Installation queries: ==
 
 == Errors / Bugs: ==
 '''General:'''

 ||  '''Error message ''' ||  '''Error Description''' ||
 || 500 Internal Server Error  || On certain sites, using TOR, users get
 this message.   ||
 || -- || Users running test tor network settings report that it says
 "connecting" for hours.  ||
 || captcha saying too much automated query || Users are sometimes blocked
 by websites  ||
 || -- || Tor Browser 7.0.10 : No Script is on the right of the screen ||



 === [[BR]]Linux users: ===
 || ''' Error message ''' || ''' Error Description''' ||
 ||  502 Bad Gateway [[BR]] nginx/1.10.3  ||  While browsing to a new site,
 the page shows error instead.   ||

 ===
 Windows users: ===


 Windows users seem to be facing the maximum number of issues.

 || '''Version''' || ''' Error message ''' || ''' Error Description''' ||
 || Win 8, 64 bit ||  -- || Browser is crashing on window to choose the
 download location after pressing Save file. On the event logs, crashes are
 related to ntdll.dll and mozglue.dll ||
 || Win 10, 64 bit || Message of insufficient permissions.  || Tor Browser
 7.5a8 will not run on Win10 x 64 after the last "Fall update".  ||
 || Win 10, 64 bit || Tor Browser does not have permission to access the
 profile. Please adjust your file system permissions and try again. || When
 users start the program, they receive this error message ||
 || Win 10 || -- || After turning off Trusteer, Windows 10 Firewall, and
 Defender Virus protection, Tor will still not launch. ||
 || Win 8 || Establishing a tor circuit failed (connection refused -
 185.129.62.62:9001) || users trying to run tor for the first time after
 downloading on Win 8 are facing this error. ||

 === [[BR]]Mac users: ===
 || '''Version''' || ''' Error message ''' || ''' Error Description''' ||
 || Win 8, 64 bit ||  -- || Browser is crashing on window to choose the
 download location after pressing Save file. On the event logs, crashes are
 related to ntdll.dll and mozglue.dll ||

 
 == Video streaming: ==
  * Many users report issues with certain video streaming sites. The video
 player box opens, but videos don't stream.
  * Users face issues with enabling Flash player.
  * Users face problems with accessing country restricted videos on
 youtube. When users use the !ExitNodes and set the country, the browser
 and other sites like DNS leak test can see the new ip, but youtube still
 says the video is not available.



 
 == Privacy related doubts/issues: ==
  * Some users report trust issues with Tor following Mozilla and updating
 to Firefox 57.
  * Some users wonder if there is any way to set the identity to non random
 to avoid getting blocked from certain places.
  * A lot of users have concerns about Google knowing that they are using
 Tor, and that Google captchas may give away their IPs.



 
 == User demands and suggestions: ==
  * Tor Browser update to the Firefox 57 Quantum baseline
  * Tor Browser for iPhones.
  * level 3 content sandboxing in FF 57 patched to work with Linux 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] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

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

Comment (by isabela):

 Replying to [comment:22 mcs]:

 > Unfortunately, Kathy and I did not know that you were planning to do
 more design work. We have already proceeded down a different
 implementation path (using the overlay approach, as we discussed). Since
 we are already well past our engineering deadline for this task, I don't
 think it makes sense to switch right now to the inline flow that you have
 designed. Also, our implementation includes most of what you suggested.

 I know this project is running late. We understand it and is ok to go with
 the flow you implemented. I think we will do better with timing on new
 projects, we are actually doing it with the roadmap coordinations which is
 giving time for design work etc.


  Here is some info about our flow:
 > * When the user clicks the "Request another bridge" radio button, a
 CAPTCHA prompt is shown. This prompt is overlaid on top of the other
 content that is in the settings panel.
 > * If the user cancels without completing the CAPTCHA, the prompt is
 closed and a "Request a Bridge…" button is displayed beneath the "Request
 another bridge" radio button.
 > * If someone who is interacting with the CAPTCHA prompt enters an
 incorrect response, we keep the same CAPTCHA but display the following in
 red below the CAPTCHA image: "The solution is not correct. Please try
 again."
 > * After the CAPTCHA is solved and a bridge is obtained, the overlay
 disappears and the bridge info is displayed beneath the "Request another
 bridge" radio button. We also change the button label to "Get a  New
 Bridge…"
 >
 > This is very similar to what you proposed, so I think we are actually in
 agreement on most points. Hopefully we will have a test version available
 soon, although we have a BridgeDB dependency and we are not 100% finished
 with the Tor Launcher code either.
 >

 Yes, is very similar indeed. Our only concern  is with the pop-out because
 its not always a nice experience and takes the person out of that wizard
 window (not as bad as we had before where the user would have to go, open
 their email client, type the email etc).

 But I think we can totally work on testing it later on, and see how our
 users goes about it and if it needs any improvement. We will always be
 iterating with our work and we can look into that on a new iteration
 later, after we have the feature out and working.

 > In the meantime, please let us know if you would like us to make some
 screenshots. I know it is difficult to visualize the interface based on a
 textual description.

 If is not too much trouble I would like that. But if its, don't worry we
 can play with it once is in alpha.

 Question! If all goes well this implementation will be on a alpha release
 around Dec 15?

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

Re: [tor-bugs] #23459 [Core Tor/Tor]: prop224: Specialize interface of hs_circuitmap_get_rend_circ_client_side()

[Tor Bug Tracker & Wiki]

#23459: prop224: Specialize interface of 
hs_circuitmap_get_rend_circ_client_side()
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, prop224-extra,  |  Actual Points:
  refactoring, easy, 032-unreached   |
Parent ID:   | Points:  0.4
 Reviewer:   |Sponsor:
-+-

Comment (by ffmancera):

 I did a rebase so there is only one commit. Thanks for your review :)

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

Re: [tor-bugs] #23459 [Core Tor/Tor]: prop224: Specialize interface of hs_circuitmap_get_rend_circ_client_side()

[Tor Bug Tracker & Wiki]

#23459: prop224: Specialize interface of 
hs_circuitmap_get_rend_circ_client_side()
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  prop224, prop224-extra,  |  Actual Points:
  refactoring, easy, 032-unreached   |
Parent ID:   | Points:  0.4
 Reviewer:   |Sponsor:
-+-

Comment (by asn):

 Great! Two more nitpicks:

 - `make check-spaces` complains about a wide line (more than 80 columns)
 in `hs_client.c:943`. Split that into two lines as follows:
 {{{
   rend_circ =
 hs_circuitmap_get_established_rend_circ_client_side(rendezvous_cookie);
 }}}

 - Add a period to the end of your changes file as follows: `Closes ticket
 23459.`

 Do the above changes on a small fixup commit, push it and I'll mark the
 ticket as `merge_ready`.

 Thanks! :-)

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

Re: [tor-bugs] #23709 [Core Tor/Tor]: channel: `outgoing_queue` and `incoming_queue` are always empty

[Tor Bug Tracker & Wiki]

#23709: channel: `outgoing_queue` and `incoming_queue` are always empty
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_review
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:  #23993| Points:
 Reviewer:  nickm |Sponsor:  SponsorV
--+
Changes (by dgoulet):

 * status:  needs_revision => needs_review


Comment:

 Done. Fixup commit from your review and extra commit for the changes file
 are in the branch.

 Once merged, I'll monitor this closely especially for memleak overtime. So
 far so good on my public relay, running without a problem for more than 2
 weeks 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] #24337 [Core Tor/Tor]: Every _free() function should be a macro that sets the corresponding pointer to NULL.

[Tor Bug Tracker & Wiki]

#24337: Every _free() function should be a macro that sets the corresponding
pointer to NULL.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:
  |  merge_ready
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  review-group-26, review-group-27  |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
  |  Sponsor8-can
--+
Changes (by dgoulet):

 * status:  needs_review => merge_ready


Comment:

 Ok I guess we are good to go. Compiles and `make check` passes. However,
 it is based on a head commit for which `test-network-all` is broken so I
 can't really test that part.

 Last thing, let us make a note at the next weekly meeting to "announce" to
 everyone that this is a thing now because creating free() functions just
 became a bit more complex than just `tor_free()` :).

 Extra idea for helping us but doesn't block this branch getting merged:
 What about we add an helper macro to declare/implement free functions
 which would use a standard naming convention (and we could have one that
 takes a `free_fn` for special cases:

 {{{
 #define DECL_FREE(name, typename) \
   void name##_(typename *__obj);  \
   static inline void  \
   name(typename *__obj) { \
 FREE_AND_NULL(typename, name##_, (__obj)); \
   }
 }}}

 As an example with hs_service_free():

 {{{
 + DECL_FREE(hs_service_free, hs_service_t)
 - void hs_service_free_(hs_service_t *service);
 - #define hs_service_free(s) FREE_AND_NULL(hs_service_t, hs_service_free_,
 (s))
 }}}

 It makes the `hs_service_free()` inline, then declares the
 `hs_service_free_()` which needs to be implemented in a .c file for which
 we could use `IMPL_FREE(hs_service_free, hs_service_t)` kind of macro for
 the signature.

 The thing I like about this is that it completely hides the fact that a
 second symbol with a trailing underscore exists and thus forces us to
 always use and consider `hs_service_free` instead of `hs_service_free_`.
 We could go one step further and use something like `void __name##` which
 would make the symbol not even in the "namespace" (or prefix it in its own
 namespace like "tor_free__*").

 Anyway, we don't have to change the whole patch again but I think it would
 1) help and simplify the code base especially helping developers creating
 free function by using the DECL/IMPL macros and 2) hide the "private but
 not really private" real free function so we never make the mistake of
 using it directly.

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

Re: [tor-bugs] #24218 [Metrics/Statistics]: Implement new metrics-web module for IPv6 relay statistics

[Tor Bug Tracker & Wiki]

#24218: Implement new metrics-web module for IPv6 relay statistics
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+--

Comment (by karsten):

 Replying to [comment:11 iwakeh]:
 > A quick glance tells me there is one
 [https://gitweb.torproject.org/karsten/metrics-web.git/tree/modules
 /servers-ipv6/src/main/resources/init-servers-
 ipv6.sql?h=tasks-24218-23761&id=ba969fe47c2c40949f3c51b6f9e80c9a633a52cc#n97
 'date' column left] in the view, which needs to be renamed.

 Huh, yes. Fixed now in [https://gitweb.torproject.org/karsten/metrics-
 web.git/commit/?h=tasks-24218-23761&id=3c6b01bcfa27537cafb28a3e31469b932ecb6b39
 commit 3c6b01b] (where I also updated the pgTAP tests which I forget
 earlier).

 > I used `psql (PostgreSQL) 9.5.10` (ubuntu), will check with 9.6 later (a
 quick update of my postgres failed :-/
 > Would be nice to have the 'on conflict'.

 It also works fine in my Debian squeeze VM. I'll for now assume it's a
 problem with your PostgreSQL version.

 > Regarding the structure I am wondering about more indexes, but these
 could be added later.

 True, we could add indexes later. Though I didn't spot any obviously
 missing indexes in my tests so far. The largest amount of data I imported
 was 2 years, but I didn't test continuous updates after that. I guess
 we'll learn.

 > Tests for the sql are missing to verify he results.  Just from reading
 it seems fine, but just reading.

 I think that what we have as tests is at least a start. To be honest, I'm
 not entirely happy with the JUnit/pgTAP mix here. But I hope that we'll
 improve that over time as we write more modules following this schema.

 Green light for archive import?

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

Re: [tor-bugs] #23709 [Core Tor/Tor]: channel: `outgoing_queue` and `incoming_queue` are always empty

[Tor Bug Tracker & Wiki]

#23709: channel: `outgoing_queue` and `incoming_queue` are always empty
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  needs_revision
 Priority:  High  |  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-sched |  Actual Points:
Parent ID:  #23993| Points:
 Reviewer:  nickm |Sponsor:  SponsorV
--+
Changes (by nickm):

 * status:  needs_review => needs_revision


Comment:

 Looks good, but now I think there's an incorrect comment hiding there.
 (See note on oniongit.)

 Also, this branch needs a changes file.

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

Re: [tor-bugs] #23761 [Metrics/Website]: Add IPv6 relay graphs to metrics site

[Tor Bug Tracker & Wiki]

#23761: Add IPv6 relay graphs to metrics site
--+--
 Reporter:  teor  |  Owner:  metrics-team
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Metrics/Website   |Version:
 Severity:  Normal| Resolution:
 Keywords:  core-tor-wants, ipv6  |  Actual Points:  0.5
Parent ID:| Points:  1
 Reviewer:|Sponsor:
--+--
Changes (by karsten):

 * status:  needs_revision => needs_review


Comment:

 Replying to [comment:18 teor]:
 > [...]

 All good suggestions! The last one was a bit hard for me to apply, so
 please take another quick look at the
 [https://gitweb.torproject.org/karsten/metrics-
 web.git/commit/?h=tasks-24218-23761&id=04396cdae4a063fe7705e88bdb430281234a180c
 revised text]. Thanks!

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

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_information => new


Comment:

 Replying to [comment:21 antonela]:
 > We have been reviewing this flow a little bit more.
 > Here is the user flow approach we end up with:
 > ...
 > Let us know what do you think!

 Unfortunately, Kathy and I did not know that you were planning to do more
 design work. We have already proceeded down a different implementation
 path (using the overlay approach, as we discussed). Since we are already
 well past our engineering deadline for this task, I don't think it makes
 sense to switch right now to the inline flow that you have designed. Also,
 our implementation includes most of what you suggested. Here is some info
 about our flow:
 * When the user clicks the "Request another bridge" radio button, a
 CAPTCHA prompt is shown. This prompt is overlaid on top of the other
 content that is in the settings panel.
 * If the user cancels without completing the CAPTCHA, the prompt is closed
 and a "Request a Bridge…" button is displayed beneath the "Request another
 bridge" radio button.
 * If someone who is interacting with the CAPTCHA prompt enters an
 incorrect response, we keep the same CAPTCHA but display the following in
 red below the CAPTCHA image: "The solution is not correct. Please try
 again."
 * After the CAPTCHA is solved and a bridge is obtained, the overlay
 disappears and the bridge info is displayed beneath the "Request another
 bridge" radio button. We also change the button label to "Get a  New
 Bridge…"

 This is very similar to what you proposed, so I think we are actually in
 agreement on most points. Hopefully we will have a test version available
 soon, although we have a BridgeDB dependency and we are not 100% finished
 with the Tor Launcher code either.

 In the meantime, please let us know if you would like us to make some
 screenshots. I know it is difficult to visualize the interface based on a
 textual description.

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

Re: [tor-bugs] #24218 [Metrics/Statistics]: Implement new metrics-web module for IPv6 relay statistics

[Tor Bug Tracker & Wiki]

#24218: Implement new metrics-web module for IPv6 relay statistics
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+--

Comment (by iwakeh):

 A quick glance tells me there is one
 [https://gitweb.torproject.org/karsten/metrics-web.git/tree/modules
 /servers-ipv6/src/main/resources/init-servers-
 ipv6.sql?h=tasks-24218-23761&id=ba969fe47c2c40949f3c51b6f9e80c9a633a52cc#n97
 'date' column left] in the view, which needs to be renamed.

 I used `psql (PostgreSQL) 9.5.10` (ubuntu), will check with 9.6 later (a
 quick update of my postgres failed :-/
 Would be nice to have the 'on conflict'.
 Regarding the structure I am wondering about more indexes, but these could
 be added later.  Tests for the sql are missing to verify he results.  Just
 from reading it seems fine, but just reading.

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

Re: [tor-bugs] #24337 [Core Tor/Tor]: Every _free() function should be a macro that sets the corresponding pointer to NULL.

[Tor Bug Tracker & Wiki]

#24337: Every _free() function should be a macro that sets the corresponding
pointer to NULL.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:
  |  needs_review
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  review-group-26, review-group-27  |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
  |  Sponsor8-can
--+
Changes (by nickm):

 * status:  needs_revision => needs_review


Comment:

 Okay; I've made the requested changes. :)

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

Re: [tor-bugs] #21952 [Webpages]: .Onion everywhere?: increasing the use of onion services through automatic redirects and aliasing

[Tor Bug Tracker & Wiki]

#21952: .Onion everywhere?: increasing the use of onion services through 
automatic
redirects and aliasing
--+--
 Reporter:  linda |  Owner:  linda
 Type:  project   | Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Webpages  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by asn):

 Posted new backend proposal here: https://lists.torproject.org/pipermail
 /tor-dev/2017-December/012660.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] #24218 [Metrics/Statistics]: Implement new metrics-web module for IPv6 relay statistics

[Tor Bug Tracker & Wiki]

#24218: Implement new metrics-web module for IPv6 relay statistics
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+--

Comment (by karsten):

 (Thanks!)

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

Re: [tor-bugs] #24218 [Metrics/Statistics]: Implement new metrics-web module for IPv6 relay statistics

[Tor Bug Tracker & Wiki]

#24218: Implement new metrics-web module for IPv6 relay statistics
+--
 Reporter:  karsten |  Owner:  metrics-team
 Type:  enhancement | Status:  needs_review
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+--
Changes (by karsten):

 * status:  needs_revision => needs_review


Comment:

 All good suggestions above! Please do another review of
 [https://gitweb.torproject.org/karsten/metrics-
 web.git/commit/?h=tasks-24218-23761&id=ba969fe47c2c40949f3c51b6f9e80c9a633a52cc
 squash commit ba969fe in my tasks-24218-23761 branch].

 Regarding the error with `ON CONFLICT`, can you check which PostgreSQL
 version you have? That's a relatively new feature that I think was added
 in 9.5, but I checked that Debian stretch has 9.6, so it ''should'' be
 available. (I tried only locally with the PostgreSQL I got from brew.) If
 it is ''not'' available, I'll have to rewrite things quite a bit.

 Regarding the module renaming, I'm fine with `ipv6servers`. How about I
 rename things after you're done with your review? Otherwise that's
 basically going to rewrite all commits.

 Regarding your Java-related questions: Classes are not yet public, because
 they were internal classes at the beginning, but they should be made
 public now. The reason for prefixing classes with `Parsed` was to avoid
 confusions with metrics-lib classes.

 Waiting for another review of the database parts before starting the bulk
 import. And to be clear, renaming things is okay even after finishing the
 import. But changing types or even table structures would be much harder.
 If you have any doubts about the database schema aggregating things
 correctly, please be sure to bring them up here!

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

Re: [tor-bugs] #23247 [Applications/Tor Browser]: Communicating security expectations for .onion: what to say about different padlock states for .onion services

[Tor Bug Tracker & Wiki]

#23247: Communicating security expectations for .onion: what to say about 
different
padlock states for .onion services
--+--
 Reporter:  isabela   |  Owner:  tbb-team
 Type:  project   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by asn):

 Replying to [comment:20 tom]:
 > From the meeting today:
 >
 >
 > I believe this table represents current thinking.
 >

 Hello tjr, I posted some thoughts on the various options on the pad. Check
 them out and please enrich them with your thoughts! :)

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

Re: [tor-bugs] #24337 [Core Tor/Tor]: Every _free() function should be a macro that sets the corresponding pointer to NULL.

[Tor Bug Tracker & Wiki]

#24337: Every _free() function should be a macro that sets the corresponding
pointer to NULL.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:
  |  needs_revision
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  review-group-26, review-group-27  |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
  |  Sponsor8-can
--+

Comment (by nickm):

 I did the line-splitting by hand.  I'm not super excited to go through and
 reindent all the lines -- though I'd run a script to do it, if we can have
 one that isn't super-disruptive.

 I'd like to apply this to static free function as well, but that will take
 a little longer. Shall I give it a try?

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

Re: [tor-bugs] #24427 [Core Tor/Tor]: Consider using other mach_*_time() functions for monotonic time on OSX

[Tor Bug Tracker & Wiki]

#24427: Consider using other mach_*_time() functions for monotonic time on OSX
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor8-can
--+
Changes (by nickm):

 * status:  accepted => needs_review


Comment:

 See branch `feature24427` in my public repository.  It just uses
 mach_approximate_time() for coarse monotonic time, to save a few cycles
 when we can.

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

Re: [tor-bugs] #24497 [Webpages/Website]: Improve documentation for tor relay operators

[Tor Bug Tracker & Wiki]

#24497: Improve documentation for tor relay operators
--+
 Reporter:  arthuredelstein   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 > That said, depending on how wide we want to expand it, we should find
 people who are happy to be "in-charge" of keeping their preferred OS
 instructions up to date. While there are a lot of people who could install
 Gentoo / Arch / etc.. and write up instructions, if these are not systems
 people run day-to-day, they may not be aware when things change and the
 instructions no longer work.

 I'm happy to be "in-charge" of keeping things maintained for all OSes that
 I have to keep an eye for ansible-relayor already. I discovered there is
 one more OS that has apparently a well maintained tor package that is not
 on the list, I might add that.

 I also started to work on a OS table that shows what things (related to
 tor) are available or not.


 Replying to [comment:29 alison]:
 > Edit: another idea is that we should have a table of contents, like the
 support wiki
 https://trac.torproject.org/projects/tor/wiki/org/teams/CommunityTeam/Support

 Yes, a ToC is a IMO a must-have (when this content reaches a proper
 website).


 > I plan to work on migrating more of this today.

 I'm waiting for you to finish migrating content, once you are done I'll
 start working on that wiki page.

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

Re: [tor-bugs] #24337 [Core Tor/Tor]: Every _free() function should be a macro that sets the corresponding pointer to NULL.

[Tor Bug Tracker & Wiki]

#24337: Every _free() function should be a macro that sets the corresponding
pointer to NULL.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:
  |  needs_revision
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  review-group-26, review-group-27  |  Actual Points:
Parent ID:| Points:
 Reviewer:  dgoulet   |Sponsor:
  |  Sponsor8-can
--+
Changes (by dgoulet):

 * reviewer:   => dgoulet


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

Re: [tor-bugs] #10573 [Applications/Tor Browser]: `nsILocalFile` should be replaced with `nsIFile` in our extensions

[Tor Bug Tracker & Wiki]

#10573: `nsILocalFile` should be replaced with `nsIFile` in our extensions
+--
 Reporter:  cypherpunks |  Owner:  tbb-team
 Type:  defect  | Status:
|  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Minor   | Resolution:
 Keywords:  tbb-easy, TorBrowserTeam201712  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by aruna1234):

 * Attachment "0001-Bug-10573-Replace-deprecated-nsILocalFile-with-
 nsIFi.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] #24337 [Core Tor/Tor]: Every _free() function should be a macro that sets the corresponding pointer to NULL.

[Tor Bug Tracker & Wiki]

#24337: Every _free() function should be a macro that sets the corresponding
pointer to NULL.
--+
 Reporter:  nickm |  Owner:  nickm
 Type:  enhancement   | Status:
  |  needs_revision
 Priority:  Medium|  Milestone:  Tor:
  |  0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  review-group-26, review-group-27  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
  |  Sponsor8-can
--+
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 I like it! Although, did you do that by hand or with a script? I'm asking
 because I see some indentation issue when it goes to 3 lines which should
 be not that complicated to fix with a script?

 {{{
 +#define service_intro_point_free(ip)\
 +  FREE_AND_NULL(hs_service_intro_point_t, \
 +  service_intro_point_free_, (ip))
 }}}

 Ideally, we would like to have them lined up:

 {{{
 +#define service_intro_point_free(ip)  \
 +  FREE_AND_NULL(hs_service_intro_point_t, \
 +service_intro_point_free_, (ip))
 }}}

 Also, if we could have a note in our CodingStandards.md about this
 template, it would be grand!

 Finally, correct me if I'm wrong, but this also *only* applies to non-
 static (public) free functions so if we merge this, we'll still have a
 series of static functions that don't do this "free and null" dance. Can
 we think of something to fix that? I mean, seems that we can only enforce
 this template to our public functions but nothing within a C code file
 unless we make all those symbols public and I'm not too keen about that
 :S.

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

Re: [tor-bugs] #24556 [Core Tor/Tor]: Non-fatal assertion !((*diff)->entry == NULL) failed in cdm_diff_ht_purge at ../src/or/consdiffmgr.c:329. Stack trace

[Tor Bug Tracker & Wiki]

#24556: Non-fatal assertion !((*diff)->entry == NULL) failed in 
cdm_diff_ht_purge
at ../src/or/consdiffmgr.c:329. Stack trace
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.1.9
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Yup, it's the same issue.  We'll probably backport the fix into the next
 0.3.1.x release, assuming it doesn't cause trouble in 0.3.2.x.

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

Re: [tor-bugs] #24559 [Core Tor/Tor]: Move a comment to relay_send_end_cell_from_edge()

[Tor Bug Tracker & Wiki]

#24559: Move a comment to relay_send_end_cell_from_edge()
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:  comment-only  |  Actual Points:  0.1
Parent ID:| Points:  0.1
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 merged!

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

Re: [tor-bugs] #24564 [- Select a component]: confirmation/information on tor failure with weird crashes due to "OpenSSL version from headers does not match"

[Tor Bug Tracker & Wiki]

#24564: confirmation/information on tor failure with weird crashes due to 
"OpenSSL
version from headers does not match"
--+
 Reporter:  miroR |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by miroR):

 Replying to [ticket:24564 miroR]:
 > As I reported here:
 [...]
 > https://github.com/minipli/linux-
 unofficial_grsec/issues/20#issuecomment-350208705
 [...]
 > but it's also about crashes I've had earlier/later, same issues page,
 but numbers # 13, # 17, # 18, # 19, and # 21,
 It's issue numbers from:
 https://github.com/minipli/linux-unofficial_grsec/issues
 ( sorry for links redirecting wrong automatically )

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

Re: [tor-bugs] #24563 [Metrics/Atlas]: Relay Search map has severe area distortions

[Tor Bug Tracker & Wiki]

#24563: Relay Search map has severe area distortions
---+--
 Reporter:  teor   |  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Old description:

> I'm concerned that the Relay Search map represents countries and
> continents poorly.
>
> It uses the d3.geo.mercator() projection, which is not recommended for
> comparison maps like ours:
> {{{
> The spherical Mercator projection...introduces severe area distortion at
> world scale and thus is not recommended for choropleths.
> }}}
> https://en.wikipedia.org/wiki/Choropleth_map
>
> One obvious issue is that India and the EU are about the same size, but
> the EU looks larger. Similarly, Greenland is smaller than India, but
> looks much larger. Here's a list of countries in order of area:
> https://en.wikipedia.org/wiki/List_of_countries_by_area
>
> I suggest we use an equal-area projection instead. It's much better
> suited to the kinds of comparisons that we're doing.
>
> None of the built-in projections are rectangular equal-area:
> https://github.com/d3/d3-geo#projections
>
> Extra projections are available here:
> https://github.com/d3/d3-geo-projection
>
> This is the only rectangular equal-area projection without significant
> distortion:
> https://en.wikipedia.org/wiki/Cylindrical_equal-area_projection
> https://github.com/d3/d3-geo-projection#geoCylindricalEqualArea
>
> Here's the line in js/views/aggregate/map.js we'll need to change, as
> well as adding the d3-geo-projection import:
> {{{
> var projection = d3.geo.mercator()
> }}}

New description:

 I'm concerned that the Relay Search map represents countries and
 continents poorly.

 It uses the d3.geo.mercator() projection, which is not recommended for
 comparison maps like ours:

The spherical Mercator projection...introduces severe area distortion
 at world scale and thus is not recommended for choropleths.

 References:
 * https://github.com/d3/d3-3.x-api-reference/blob/master/Geo-
 Projections.md#mercator
 * https://en.wikipedia.org/wiki/Choropleth_map

 One obvious issue is that India and the EU are about the same size, but
 the EU looks larger. Similarly, Greenland is smaller than India, but looks
 much larger. Here's a list of countries in order of area:
 https://en.wikipedia.org/wiki/List_of_countries_by_area

 I suggest we use an equal-area projection instead. It's much better suited
 to the kinds of comparisons that we're doing.

 None of the built-in projections are rectangular equal-area:
 https://github.com/d3/d3-geo#projections

 Extra projections are available here:
 https://github.com/d3/d3-geo-projection

 This is the only rectangular equal-area projection without significant
 distortion:
 https://en.wikipedia.org/wiki/Cylindrical_equal-area_projection
 https://github.com/d3/d3-geo-projection#geoCylindricalEqualArea

 Here's the line in js/views/aggregate/map.js we'll need to change, as well
 as adding the d3-geo-projection import:
 {{{
 var projection = d3.geo.mercator()
 }}}

--

Comment (by teor):

 Tidy up the reference and the quote

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24564 [- Select a component]: confirmation/information on tor failure with weird crashes due to "OpenSSL version from headers does not match"

[Tor Bug Tracker & Wiki]

#24564: confirmation/information on tor failure with weird crashes due to 
"OpenSSL
version from headers does not match"
--+
 Reporter:  miroR |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 As I reported here:
 kernel tried to execute NX-protected page - exploit attempt?
 https://github.com/minipli/linux-
 unofficial_grsec/issues/20#issuecomment-350208705
 (find the OpenSSL no-match headers tor log lines near bottom)
 but it's also about crashes I've had earlier/later, same issues page, but
 numbers #13, #17, #18, #19, and #21,
 all my crashes vanished once I disabled tor.
 Can you pls look up those crashes and confirm if the reason is as I
 suspect (from same log, just earlier, that line repeated for weeks :) ...
 ouch!):

 Dec 07 04:25:47.000 [notice] Tor 0.2.9.12 (git-2b1e823d7bc05a37) opening
 new log file.
 Dec 07 04:25:47.859 [warn] OpenSSL version from headers does not match the
 version we're running with. If you get weird crashes, that might be why.
 (Compiled with 1010006f: OpenSSL 1.1.0f  25 May 2017; running with
 1010007f: OpenSSL 1.1.0g  2 Nov 2017).
 Dec 07 04:25:47.885 [notice] Tor 0.2.9.12 (git-2b1e823d7bc05a37) running
 on Linux with Libevent 2.0.21-stable, OpenSSL 1.1.0g and Zlib 1.2.8.

 I know this is about package maintainance, but if I got the right cause
 here, can you pls. direct us where to look for explanation, more
 information how this come about. Thank you!

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

[tor-bugs] #24563 [Metrics/Atlas]: Relay Search map has severe area distortions

[Tor Bug Tracker & Wiki]

#24563: Relay Search map has severe area distortions
---+--
 Reporter:  teor   |  Owner:  metrics-team
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:
Component:  Metrics/Atlas  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 I'm concerned that the Relay Search map represents countries and
 continents poorly.

 It uses the d3.geo.mercator() projection, which is not recommended for
 comparison maps like ours:
 {{{
 The spherical Mercator projection...introduces severe area distortion at
 world scale and thus is not recommended for choropleths.
 }}}
 https://en.wikipedia.org/wiki/Choropleth_map

 One obvious issue is that India and the EU are about the same size, but
 the EU looks larger. Similarly, Greenland is smaller than India, but looks
 much larger. Here's a list of countries in order of area:
 https://en.wikipedia.org/wiki/List_of_countries_by_area

 I suggest we use an equal-area projection instead. It's much better suited
 to the kinds of comparisons that we're doing.

 None of the built-in projections are rectangular equal-area:
 https://github.com/d3/d3-geo#projections

 Extra projections are available here:
 https://github.com/d3/d3-geo-projection

 This is the only rectangular equal-area projection without significant
 distortion:
 https://en.wikipedia.org/wiki/Cylindrical_equal-area_projection
 https://github.com/d3/d3-geo-projection#geoCylindricalEqualArea

 Here's the line in js/views/aggregate/map.js we'll need to change, as well
 as adding the d3-geo-projection import:
 {{{
 var projection = d3.geo.mercator()
 }}}

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

Re: [tor-bugs] #24175 [Metrics/Website]: Use an embedded Jetty in metrics-web and use metrics-base as build environment.

[Tor Bug Tracker & Wiki]

#24175: Use an embedded Jetty in metrics-web and use metrics-base as build
environment.
-+--
 Reporter:  iwakeh   |  Owner:  iwakeh
 Type:  enhancement  | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Metrics/Website  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by iwakeh):

 * status:  accepted => needs_review


Comment:

 First of all thanks for the data, it helped a lot!

 Please review the thirty something commits on
 [https://gitweb.torproject.org/user/iwakeh/metrics-
 web.git/log/?h=task-24175-stepbystep this patch branch].  I didn't change
 anything, only ironed out tiny things.  The commits are for ease of review
 and partially examples for refactoring the modules, not so much suited for
 cherry picking.

 I created a ticket for removing the dependency on server locale.

 Most of comment:2 applies.  The open topic is solved with having data, but
 this is not part of this restructuring ticket.  This reproducibility issue
 concerns the two oldest dbs: userstats and tordir.  The R issue (mentioned
 in comment:2) in the clients module doesn't show up when a sufficient
 amount of data is available.

 What is not really reproducible from scratch is the tordir database (the
 oldest db here).  This issue has nothing to do with restructuring as it
 concerns the initial db setup.  The refresh_all call in the legacy module
 fails at call refresh_network_size.  After adding more data and running
 the other refresh functions by hand: refresh_all suddenly works.   This
 should be investigated in its own ticket in addition to the
 inconsistencies of the main db and the db setup, i.e. there are still
 functions in the data dump that are not in the sql scripts, for example:
 refresh_oldest_week.

 After ant war and jar: steps for setting up metrics-web: `ant run-web-
 prepare` prepares everything, `ant run-rserver` starts the R daemon, and
 `java -DLOGBASE=logs -jar generated/dist/metrics-web-1.0.0-dev.war` starts
 jetty.

 Two  more tickets needed: one each for making the setup of userstats and
 tordir db reproducible from scratch.

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

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

[Tor Bug Tracker & Wiki]

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

Comment (by antonela):

 We have been reviewing this flow a little bit more.
 Here is the user flow approach we end up with:

 [Direct user flow - '''asking for a bridge for the first time''']

 I am a user I select 'Request a bridge' and the screen expands showing me
 the captcha.
 I type the letters from the captcha and I click on [Get Bridge] button.
 The IP address and signature of the bridge I got is displayed above the
 captcha.
 The captcha is refreshed and a new set of words shows up and the button
 next the captcha has changed and says '[Get a New Bridge]'
 I click [Connect]

 [User flow where the user '''tries to get another bridge''']

 I am a user I select 'Request a bridge' and the screen expands showing me
 the captcha.
 I type the letters from the captcha and I click on [Get Bridge] button.
 The IP address and signature of the bridge I got is displayed above the
 captcha.
 The captcha is refreshed and a new set of words shows up and the button
 next the captcha has changed and says '[Get a New Bridge]'
 I don't like the bridge I have, I type the new words and I click '[Get a
 New Bridge]' button
 A new IP address and signature is shown above the captcha replacing the
 old one.
 I click [Connect]

 [User flow where the user '''fails to solve the captcha while trying to
 get the first bridge''']

 I am a user I select 'Request a bridge' and the screen expands showing me
 the captcha.
 I type the letters from the captcha and I click on [Get Bridge] button.
 The letters I typed was wrong, above the captcha I see an error message.
 The captcha is refreshed and a new set of words shows up and the button
 next the captcha stays as '[Get a Bridge]'
 I click [Connect]

 [User flow where the user '''fails to solve the captcha while trying to
 get another bridge''']

 I am a user I select 'Request a bridge' and the screen expands showing me
 the captcha.
 I type the letters from the captcha and I click on [Get Bridge] button.
 The IP address and signature of the bridge I got is displayed above the
 captcha.
 The captcha is refreshed and a new set of words shows up and the button
 next the captcha has changed and says '[Get a New Bridge]'
 The letters I typed was wrong, above the captcha I see an error message.
 The captcha is refreshed and a new set of words shows up and the button
 next the captcha stays'[Get a New Bridge]'
 I click [Connect]

 Mockups attached ->
 https://trac.torproject.org/projects/tor/attachment/ticket/23136/23136-4.png

 Let us know what do you think!

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

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

[Tor Bug Tracker & Wiki]

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

 * Attachment "23136-4.png" added.


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

Re: [tor-bugs] #24130 [Webpages/Website]: Design/layout for support.tpo based on wireframe

[Tor Bug Tracker & Wiki]

#24130: Design/layout for support.tpo based on wireframe
--+--
 Reporter:  isabela   |  Owner:  antonela
 Type:  task  | Status:  assigned
 Priority:  Medium|  Milestone:  website redesign
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team,  |  Actual Points:
Parent ID:  #24129| Points:
 Reviewer:|Sponsor:
--+--

Comment (by antonela):

 New Iteration based on this week comments.

 ​https://marvelapp.com/4471ig9/screen/35210130

 We are close! Thanks!

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

Re: [tor-bugs] #24562 [Metrics]: Define SQL coding guidelines for Metrics' products

[Tor Bug Tracker & Wiki]

#24562: Define SQL coding guidelines for Metrics' products
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by irl):

 If there is to be a reimplementation of Onionoo using a relational
 database backend, this would be particularly useful for that.

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

Re: [tor-bugs] #24562 [Metrics]: Define SQL coding guidelines for Metrics' products (was: Define SQL coding guidelines for Merrics' products)

[Tor Bug Tracker & Wiki]

#24562: Define SQL coding guidelines for Metrics' products
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by iwakeh):

 Corrected typo (maybe, I wrote Merrics earlier b/c of the season ;-)

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

Re: [tor-bugs] #24218 [Metrics/Statistics]: Implement new metrics-web module for IPv6 relay statistics

[Tor Bug Tracker & Wiki]

#24218: Implement new metrics-web module for IPv6 relay statistics
+
 Reporter:  karsten |  Owner:  metrics-team
 Type:  enhancement | Status:  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Metrics/Statistics  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  iwakeh  |Sponsor:
+
Changes (by iwakeh):

 * status:  needs_review => needs_revision


Comment:

 Starting with the SQL as this is most important.
 I'll add a ticket later (unless I find an existing one) for (finally)
 writing up sql coding guide lines and adapting all existing scripts.
 From reading intensely through the older sql scripts (for the tech report)
 I know that the naming in init-servers-ipv6.sql is consistent with the old
 naming, but there are parts that are really hard to read and often only
 understandable when reading the Java code in addition.

 Here some topics that should go into the guide doc (b/c of the upcoming
 guide doc, I'm trying to be verbose):
 * Use names (not numbers) for group-by and order-by, which is fine in this
 script.
 * types and function names etc. shouldn't be used as column or field
 identifiers, for example `count`, `date`, `timestamp`, and `server` (the
 enum type defined in the script).  For the server enum I'd suggest using
 `server_enum`, so the column (e.g. in table statuses) can be defined as
 `server server_enum NOT NULL,`, which makes immediately clear, what that
 column will contain.  Below I add comments to the various table
 definitions.
 * Names should be self-explanatory as much as reasonably possible.  Some
 names only make sense after reading the table's comment and for others
 only from reading the java code in addition.  For example, `count` in
 table aggregated first of all shouldn't be used because of the function
 `count()` and secondly it's meaning can only be derived from the table's
 comment.  Changing `count` to `server_count'  would make the meaning
 obvious.  Similarly, `advertised_bandwidth` to
 `advertised_bandwidth_bytes`.
 * For multi-line comments C-style `/* ...*/` could and maybe should be
 used and `-- ...` only for one-liners.  (That's of minor importance,
 though.)
 * Indentation of code in functions for readability.

 Detailed comments (suggesting name changes, asking questions):
 * server_descriptors:
 {{{
 #!sql
 CREATE TABLE server_descriptors (
   digest BYTEA PRIMARY KEY,  -- digest of what?  Maybe: sha1_desc_digest
   advertised_bandwidth INTEGER, -- in bytes?  Maybe adv_bandwidth_bytes?
   announced BOOLEAN NOT NULL, -- announced_ipv6
   exiting BOOLEAN  -- exit_flag or exit_relay (making obvious that this
 will be null for bridges)
 );

 }}}

 * server enum:
 {{{
 #!sql
 CREATE TYPE server_enum AS ENUM ('relay', 'bridge');
 }}}

 * statuses
 {{{
 #!sql
 CREATE TABLE statuses (
   status_id SERIAL PRIMARY KEY,
   server server NOT NULL,  -- rather: server server_enum NOT NULL,
   timestamp TIMESTAMP WITHOUT TIME ZONE NOT NULL,  -- valid_after
   running INTEGER NOT NULL, -- running_count (otherwise I'd assume this to
 be a boolean)
   UNIQUE (server, timestamp)
 );
 }}}

 * status_entries
 {{{
 #!sql
 CREATE TABLE status_entries (
   status_id INTEGER REFERENCES statuses (status_id) NOT NULL,
   digest BYTEA NOT NULL,  -- as above in server_descriptors
   guard BOOLEAN,  -- guard_relay
   exit BOOLEAN,  -- exit_relay
   confirmed BOOLEAN, -- confirmed_ipv6_relay
   UNIQUE (status_id, digest)
 );
 }}}

 * aggregated
 {{{
 #!sql
 CREATE TABLE aggregated (  -- aggregated_flags_ipv6
   status_id INTEGER REFERENCES statuses (status_id) NOT NULL,
   guard BOOLEAN,  -- cf. above
   exit BOOLEAN,  -- cf. above
   announced BOOLEAN,  -- cf. above
   exiting BOOLEAN,  -- cf. above
   confirmed BOOLEAN,  -- cf. above
   count INTEGER NOT NULL,  -- server_count or server_count_sum
   advertised_bandwidth BIGINT, -- adv_bandwidth_bytes or
 adv_bandwidth_bytes_sum
   CONSTRAINT aggregated_unique
 UNIQUE (status_id, guard, exit, announced, exiting, confirmed)
 );
 }}}

 * function aggregate:
 Maybe, call it `aggregate_flags_ipv6`?
 For the aggregate function I got the following error running the script:
 {{{
 psql --dbname=reviewipv6 -f modules/servers-ipv6/src/main/resources/init-
 servers-ipv6.sql
 CREATE TABLE
 CREATE TYPE
 CREATE TABLE
 CREATE TABLE
 CREATE TABLE
 psql:modules/servers-ipv6/src/main/resources/init-servers-ipv6.sql:75:
 ERROR:  syntax error at or near "ON"
 LINE 9: ON CONFLICT ON CONSTRAINT aggregated_unique
 ^
 CREATE VIEW
 }}}

 * servers_ipv6: Maybe: `ipv6servers`?  And, the `date` column need to be
 renamed.


 Some java related questions (from only skimming the code):
 The package name as mentioned at 

[tor-bugs] #24562 [Metrics]: Define SQL coding guidelines for Merrics' products

[Tor Bug Tracker & Wiki]

#24562: Define SQL coding guidelines for Merrics' products
-+--
 Reporter:  iwakeh   |  Owner:  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 Some points with examples are stated in
 [https://trac.torproject.org/projects/tor/ticket/24218#comment:8 #24218
 comment 8].  We shouldn't re-invent the wheel here.  Thus, for reference
 some [https://oracle.readthedocs.io/en/latest/sql/basics/style-guide.html
 ideas from Oracle]  and another
 [https://databaseline.bitbucket.io/guidelines.html reference] suggested
 there.

 I wouldn't want to copy these entirely, especially the 'space before
 comma' rule is troublesome.  We don't change sql often enough to justify
 that.

 There are probably other nice references out there, which should be
 considered.

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

Re: [tor-bugs] #24264 [Core Tor/Tor]: Enable IPv6 reachability testing for the Bridge Authority

[Tor Bug Tracker & Wiki]

#24264: Enable IPv6 reachability testing for the Bridge Authority
---+--
 Reporter:  isis   |  Owner:  isis
 Type:  task   | Status:  reopened
 Priority:  High   |  Milestone:
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  dirauth, bridgeauth, ipv6  |  Actual Points:
Parent ID: | Points:  .2
 Reviewer: |Sponsor:  SponsorM
---+--

Comment (by karsten):

 Hmm, looks like Bifroest is down 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] #24203 [Core Tor/Tor]: Snowflake can't be configured to run with system tor: ENV-ERROR no TOR_PT_STATE_LOCATION environment variable

[Tor Bug Tracker & Wiki]

#24203: Snowflake can't be configured to run with system tor: ENV-ERROR no
TOR_PT_STATE_LOCATION environment variable
--+--
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Major | Resolution:
 Keywords:  snowflake |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Replying to [comment:5 dcf]:
 > There might be some other problem in your setup. That ENV-ERROR comes
 from [https://gitweb.torproject.org/pluggable-
 transports/goptlib.git/tree/pt.go?h=0.7#n368 pt.MakeStateDir]. But
 snowflake-client doesn't call pt.MakeStateDir; only snowflake-server does.
 Are you use you copied the client to /usr/bin, and not the server? (Your
 comment:3 refers to /usr/bin/snowflake, but the ticket description refers
 to /usr/bin/snowflake-client.)
 Yes (I copied `snowflake-client` from a Tor Browser alpha directory and
 renamed it to `snowflake` in my case).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #24561 [Applications/Tor Browser]: Add authenticode/marsigning check scripts to tor-browser-build

[Tor Bug Tracker & Wiki]

#24561: Add authenticode/marsigning check scripts to tor-browser-build
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  tbb-rbm
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 We should add our two scripts, which check whether we correctly signed our
 .exe and .mar files, to `tor-browser-build`.

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

Re: [tor-bugs] #10573 [Applications/Tor Browser]: `nsILocalFile` should be replaced with `nsIFile` in our extensions

[Tor Bug Tracker & Wiki]

#10573: `nsILocalFile` should be replaced with `nsIFile` in our extensions
+--
 Reporter:  cypherpunks |  Owner:  tbb-team
 Type:  defect  | Status:
|  needs_revision
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Minor   | Resolution:
 Keywords:  tbb-easy, TorBrowserTeam201712  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * keywords:  tbb-easy, TorBrowserTeam201712R => tbb-easy,
 TorBrowserTeam201712
 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:19 mcs]:
 > I think we are missing the Tor Launcher patch now. The two remaining
 attachments contain the same patch; the second has a corrected bug number
 in the commit message.

 Indeed, my bad. aruna1234: could you add the Tor Launcher patch again?
 Thanks!

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