[tor-bugs] #31126 [Circumvention/Snowflake]: Query.parse returns spurious keys (originating from Object.prototype)

2019-07-09 Thread Tor Bug Tracker & Wiki
#31126: Query.parse returns spurious keys (originating from Object.prototype)
-+--
 Reporter:  dcf  |  Owner:  dcf
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Minor|   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+--
 For example, these test cases would fail:
 {{{#!javascript
 describe 'query string', ->
   it 'should parse correctly', ->
 expect ("toString" in (Query.parse ''))
   .toBe(false)
 expect ((Query.parse '')["hasOwnProperty"])
   .toBeUndefined()
 }}}

 I'm tempted to replace all this with [https://developer.mozilla.org/en-
 US/docs/Web/API/URL new URL] and [https://developer.mozilla.org/en-
 US/docs/Web/API/URLSearchParams URLSearchParams].

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

Re: [tor-bugs] #30933 [Circumvention/Snowflake]: Get rid of CoffeeScript from the JS proxy

2019-07-09 Thread Tor Bug Tracker & Wiki
#30933: Get rid of CoffeeScript from the JS proxy
-+---
 Reporter:  arlolra  |  Owner:  arlolra
 Type:  defect   | Status:  needs_information
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:  dcf  |Sponsor:
-+---
Changes (by dcf):

 * status:  needs_review => needs_information


Comment:

 Great job on this. You covered some details that I would have missed. I
 looked at
 
[https://github.com/keroserene/snowflake/commits/4b97c9d524268f5e1242d0e9b537a4dc6486c01f
 4b97c9d524268f5e1242d0e9b537a4dc6486c01f]. Just a couple of questions.

 1.
 
[https://github.com/keroserene/snowflake/commit/b5934883d45a322dd45f2b7467798ec48b5552e1
 b5934883d4] "Don't overwrite global location": The commit also adds checks
 for `snowflake !== null`. Are those related to the `location` change, or
 could they be split out?
 2.
 
[https://github.com/keroserene/snowflake/commit/d1af00da676094a6842501f87faf2367f679cf02
 d1af00da67] "Don't specify port for stun server": How was this working
 before? Was there a hardcoded default inside libwebrtc?

 I did the CoffeeScript rebuild step myself starting from
 
[https://github.com/keroserene/snowflake/commit/7f5cd81f94c530d0142f7caec90581d56a65bafb
 60fe1ae18b^] and got the same output as your
 
[https://github.com/keroserene/snowflake/commit/60fe1ae18b7a1a76a180f6334faa306a64265277
 60fe1ae18b].

 In order to download the newer version of CoffeeScript needed, I had to
 modify package.json. It might be worth sneaking in a commit to this
 effect, as documentation in the log.
 {{{#!diff
 -"coffee-script": "^1.12.2",
 +"coffeescript": "^2",
 }}}

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

Re: [tor-bugs] #30468 [Applications/Tor Browser]: Ship macedonian Tor Browser in alpha series

2019-07-09 Thread Tor Bug Tracker & Wiki
#30468: Ship macedonian Tor Browser in alpha series
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  localization,|  Actual Points:
  TorBrowserTeam201907R, GeorgKoppen201907   |
Parent ID:  #29935   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by boklm):

 Commit 7393339e1d9a569f4f57a98c3cd06aaffa6063f0 on the website is adding
 the mk locale for Tor Browser alpha:
 
https://gitweb.torproject.org/project/web/tpo.git/commit/?id=7393339e1d9a569f4f57a98c3cd06aaffa6063f0

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

Re: [tor-bugs] #31125 [Webpages/Website]: Add Android to the Tor Browser Alpha download page

2019-07-09 Thread Tor Bug Tracker & Wiki
#31125: Add Android to the Tor Browser Alpha download page
--+--
 Reporter:  boklm |  Owner:  hiro
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by boklm):

 * cc: tbb-team (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

[tor-bugs] #31125 [Webpages/Website]: Add Android to the Tor Browser Alpha download page

2019-07-09 Thread Tor Bug Tracker & Wiki
#31125: Add Android to the Tor Browser Alpha download page
--+--
 Reporter:  boklm |  Owner:  hiro
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Webpages/Website  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 The Tor Browser Alpha download page at
 https://www.torproject.org/download/alpha/ does not provide Android
 builds.

 We should add the armv7, x86 and aarch64 Android builds somewhere on this
 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] #10314 [Circumvention/Pluggable transport]: Think of strategy for deprecating pluggable transports (e.g. obfs2)

2019-07-09 Thread Tor Bug Tracker & Wiki
#10314: Think of strategy for deprecating pluggable transports (e.g. obfs2)
---+
 Reporter:  asn|  Owner:  (none)
 Type:  task   | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Circumvention/Pluggable transport  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by phw):

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


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

[tor-bugs] #31124 [Circumvention/Snowflake]: Make it more expensive (CPU wise, or other thing) to make the initial connection to a snowflake

2019-07-09 Thread Tor Bug Tracker & Wiki
#31124: Make it more expensive (CPU wise, or other thing) to make the initial
connection to a snowflake
-+-
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  Circumvention/Snowflake
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
 That way it's harder for an adversary to cramp up a list of all the
 snowflakes

 I don't know if this is a good idea (possible problems: each x seconds one
 has to reconnect to a snowflake if one makes a network request which will
 take even more time)

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

Re: [tor-bugs] #29450 [Circumvention/BridgeDB]: Option to view BridgeDB in English

2019-07-09 Thread Tor Bug Tracker & Wiki
#29450: Option to view BridgeDB in English
+---
 Reporter:  gecko   |  Owner:  sysrqb
 Type:  enhancement | Status:  closed
 Priority:  Low |  Milestone:
Component:  Circumvention/BridgeDB  |Version:
 Severity:  Normal  | Resolution:  duplicate
 Keywords:  bridgedb|  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+---
Changes (by phw):

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


Comment:

 Replying to [comment:2 emmapeel]:
 > I think this ticket can be seen as a duplicate of #26543: Provide a
 language switcher menu on BridgeDB
 [[br]]
 Right, let's continue in #26543.

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

Re: [tor-bugs] #31082 [Internal Services/Tor Sysadmin Team]: decommission arlgirdense

2019-07-09 Thread Tor Bug Tracker & Wiki
#31082: decommission arlgirdense
-+-
 Reporter:  weasel   |  Owner:  anarcat
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by weasel):

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


Comment:

 {{{
 root@kvm4:~# at 2019-07-30
 warning: commands will be executed using /bin/sh
 at> rm -v /srv/vmstore/arlgirdense.torproject.org/arlgirdense.torproject
 .org-lvm-cache
 at> rm -v /srv/vmstore/arlgirdense.torproject.org/arlgirdense.torproject
 .org-root
 at> rm -v /srv/vmstore/arlgirdense.torproject.org/arlgirdense.torproject
 .org-swap
 at> rm -v /srv/big/vmstore-
 big/arlgirdense.torproject.org/arlgirdense.torproject.org-lvm
 at> rmdir -v /srv/vmstore/arlgirdense.torproject.org
 at> rmdir -v /srv/big/vmstore-big/arlgirdense.torproject.org
 at> 
 job 2 at Tue Jul 30 20:03:00 2019
 }}}

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

Re: [tor-bugs] #30600 [Applications/Tor Browser]: Restore NoScript control widget icon to the Tor Browser toolbar

2019-07-09 Thread Tor Bug Tracker & Wiki
#30600: Restore NoScript control widget icon to the Tor Browser toolbar
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:  wontfix
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Replying to [comment:12 torlove]:
 > Unfortunately, the 101 Redesign document referred to above
 ​https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/101
 -security-controls-redesign.txt has not been followed.
 >
 > As a result I created this ticket (in error):
 > https://trac.torproject.org/projects/tor/ticket/31096
 >
 > --
 >
 > It seems that another ticket has been created regarding re-instating per
 site permission (aka NoScript). In the ticket I have outlined how the 101
 Re-design document has not been followed and some UI suggestions:
 > https://trac.torproject.org/projects/tor/ticket/30570
 >
 > The ticket has a sponsor. I suggest we keep a level head and continue
 any discussions in the above ticket.

 Sounds good. Let's try closing this ticket again.

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

Re: [tor-bugs] #31117 [Applications/Tor Browser]: On connect (app start), Tor Browser (Android) produces "Warning: Unresponsive script" dialog on home screen.

2019-07-09 Thread Tor Bug Tracker & Wiki
#31117: On connect (app start), Tor Browser (Android) produces "Warning:
Unresponsive script" dialog on home screen.
--+---
 Reporter:  torlove   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by torlove):

 More specifically, I choose not to enable it at this time.

 How do other installations deal with the failure to load it?

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

Re: [tor-bugs] #31117 [Applications/Tor Browser]: On connect (app start), Tor Browser (Android) produces "Warning: Unresponsive script" dialog on home screen.

2019-07-09 Thread Tor Bug Tracker & Wiki
#31117: On connect (app start), Tor Browser (Android) produces "Warning:
Unresponsive script" dialog on home screen.
--+---
 Reporter:  torlove   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by torlove):

 Yes it's disabled at the moment. I cannot choose to enable it at this
 time.

 Yes it happens on every start.

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

Re: [tor-bugs] #30570 [Applications/Tor Browser]: Implement per-site security settings support

2019-07-09 Thread Tor Bug Tracker & Wiki
#30570: Implement per-site security settings support
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:  #25658| Points:
 Reviewer:|Sponsor:  Sponsor9
--+--

Comment (by cypherpunks):

 Can we get something like Firefox Containers type UX?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31123 [Applications/Tor Browser]: Enable AssertEvalNotUsingSystemPrincipal

2019-07-09 Thread Tor Bug Tracker & Wiki
#31123: Enable AssertEvalNotUsingSystemPrincipal
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:  #28707
   Points:|   Reviewer:
  Sponsor:|
--+--
 Similar to #31120 this is a defense in depth Tor should probably turn on.

 This one is a little dicier though; it's currently only enabled in debug
 builds so it hasn't gotten as much testing.  Maybe if Mozilla enables it
 soon we'd have more confidence doing so...

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

Re: [tor-bugs] #30600 [Applications/Tor Browser]: Restore NoScript control widget icon to the Tor Browser toolbar

2019-07-09 Thread Tor Bug Tracker & Wiki
#30600: Restore NoScript control widget icon to the Tor Browser toolbar
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Very High |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Major | Resolution:
 Keywords:  noscript  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by torlove):

 Unfortunately, the 101 Redesign document referred to above
 ​https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/101
 -security-controls-redesign.txt has not been followed.

 As a result I created this ticket (in error):
 https://trac.torproject.org/projects/tor/ticket/31096

 --

 It seems that another ticket has been created regarding re-instating per
 site permission (aka NoScript). In the ticket I have outlined how the 101
 Re-design document has not been followed and some UI suggestions:
 https://trac.torproject.org/projects/tor/ticket/30570

 The ticket has a sponsor. I suggest we keep a level head and continue any
 discussions in the above ticket.

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

Re: [tor-bugs] #31120 [Applications/Tor Browser]: Enable AssertSystemPrincipalMustNotLoadRemoteDocuments

2019-07-09 Thread Tor Bug Tracker & Wiki
#31120: Enable AssertSystemPrincipalMustNotLoadRemoteDocuments
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff68-esr  |  Actual Points:
Parent ID:  #28707| Points:
 Reviewer:|Sponsor:
--+--
Changes (by tom):

 * parent:   => #28707


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

Re: [tor-bugs] #30912 [Internal Services/Tor Sysadmin Team]: Investigate stunnel outage on crm-ext-01

2019-07-09 Thread Tor Bug Tracker & Wiki
#30912: Investigate stunnel outage on crm-ext-01
-+-
 Reporter:  peterh   |  Owner:  tpa
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 logging: good idea, done!

 ipsec: will consider if we can't find another option, it's a little more
 complicated to setup. :)

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

Re: [tor-bugs] #31096 [Applications/Tor Browser]: Tor Browser missing NoScript on Linux/Ubuntu version

2019-07-09 Thread Tor Bug Tracker & Wiki
#31096: Tor Browser missing NoScript on Linux/Ubuntu version
--+--
 Reporter:  torlove   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by torlove):

 Furthermore, in terms of simplifying the toolbar, the 'three dot icon' is
 redundant. The three options a user gets is:

 - Bookmark this page (the user already has a bookmark button)
 - Copy link.
 - Email link.

 None of these options add value, I'd much rather dedicate the space to the
 NoScript icon and subsequent tag.

 BTW I've added these UI suggestions to two other tickets relating to this
 subject, the main ticket being:
 https://trac.torproject.org/projects/tor/ticket/30570

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

Re: [tor-bugs] #30570 [Applications/Tor Browser]: Implement per-site security settings support

2019-07-09 Thread Tor Bug Tracker & Wiki
#30570: Implement per-site security settings support
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:  #25658| Points:
 Reviewer:|Sponsor:  Sponsor9
--+--

Comment (by torlove):

 Thanks for opening this ticket, gk. Good to see that there is a sponsor
 for this.

 The document referred to above:
 https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/101
 -security-controls-redesign.txt

 As I have said in another ticket:

 "It is a good document, whatever we can do to make things easier for
 beginners is good.

 There are two items discussed in the resource above that have not been
 done.

 1) Educating the user about the changes.

 Although it was not part of the scope of the document the author clearly
 states that this is an area that requires attention. It is important to
 tell users of impending changes, and to inform a user when a change is
 implemented. The home screen is the best place to do that.

 2) Moving per-site js permissions (NoScript) too the URL bar:

 In my opinion, NoScript should be moved to the URL bar to the right of the
 "Toggle Reader View" button. The icon should be one that suggests code or
 scripting, either:

 a) a tiny backslash inside angled brackets, or
 b) the standby/power symbol (​https://www.symbols.com/symbol/standby-
 symbol), or
 c) a gear icon with JS written lightly inside.

 Alongside the icon should be a small tag with the number of js domains
 blocked having a strike-though. The number of approved js domains used by
 the page would not have a strike-though.

 NoScript needs to continue being one click away because when a
 page/document loads and the JS is blocked there is no way to re-trigger
 the page load event. So there are times when the user must access NoScript
 after multiple page load events. Typically two page loads are needed, but
 I have seen websites where five page loads are needed. The user needs to
 repeat this process for a domain every time they restart Tor browser.

 In the interests of educating the user, after restarting the browser we
 might inform the user that editing the permissions may make fingerprinting
 easier. Especially if you repeatedly use the same settings.

 Furthermore, in terms of simplifying the toolbar, the 'three dot icon' is
 redundant. The three options a user gets is:

 - Bookmark this page (the user already has a bookmark button)
 - Copy link.
 - Email link.

 None of these options add value, I'd much rather dedicate the space to the
 NoScript icon and subsequent tag.

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

Re: [tor-bugs] #30912 [Internal Services/Tor Sysadmin Team]: Investigate stunnel outage on crm-ext-01

2019-07-09 Thread Tor Bug Tracker & Wiki
#30912: Investigate stunnel outage on crm-ext-01
-+-
 Reporter:  peterh   |  Owner:  tpa
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by peterh):

 You know, I like the idea of trying IPsec if that's not too hard for you
 guys to setup. Because it's lower level, it probably won't have connection
 issues if there's temporary problems with Redis.

 I think also you should up the debugging level for stunnel on crm-int-01.
 I think you did it on crm-ext-01 last time, but now we think its crm-int
 that has the problem.

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

Re: [tor-bugs] #31096 [Applications/Tor Browser]: Tor Browser missing NoScript on Linux/Ubuntu version

2019-07-09 Thread Tor Bug Tracker & Wiki
#31096: Tor Browser missing NoScript on Linux/Ubuntu version
--+--
 Reporter:  torlove   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by torlove):

 Thanks for the link to the resource, gk. It is a good document, whatever
 we can do to make things easier for beginners is good.

 There are two items discussed in the resource above that have not been
 done.

 1) Educating the user about the changes.

 Although it was not part of the scope of the document the author clearly
 states that this is an area that requires attention. It is important to
 tell users of impending changes, and to inform a user when a change is
 implemented. The home screen is the best place to do that.


 2) Moving per-site js permissions (NoScript) too the URL bar:

 In my opinion, NoScript should be moved to the URL bar to the right of the
 "Toggle Reader View" button. The icon should be one that suggests code or
 scripting, either:

 a) a tiny backslash inside angled brackets, or
 b) the standby/power symbol (https://www.symbols.com/symbol/standby-
 symbol), or
 c) a gear icon with JS written lightly inside.

 Alongside the icon should be a small tag with the number of js domains
 blocked having a strike-though. The number of approved js domains used by
 the page would not have a strike-though.

 NoScript needs to continue being one click away because when a
 page/document loads and the JS is blocked there is no way to re-trigger
 the page load event. So there are times when the user must access NoScript
 after multiple page load events. Typically two page loads are needed, but
 I have seen websites where five page loads are needed. The user needs to
 repeat this process for a domain every time they restart Tor browser.

 In the interests of educating the user, after restarting the browser we
 might inform the user that editing the permissions may make fingerprinting
 easier. Especially if you repeatedly use the same settings.

 Is there an open ticket where these suggestions can be placed?

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

Re: [tor-bugs] #30839 [Core Tor/Tor]: Update EndOfLifeTor.md with our latest end of life process

2019-07-09 Thread Tor Bug Tracker & Wiki
#30839: Update EndOfLifeTor.md with our latest end of life process
--+
 Reporter:  teor  |  Owner:  teor
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  041-should|  Actual Points:
Parent ID:  #30835| Points:  0.5
 Reviewer:|Sponsor:  Sponsor31-can
--+
Changes (by nickm):

 * points:   => 0.5


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

Re: [tor-bugs] #29656 [Core Tor/Tor]: describe global initialization in our tinytest-based unit tests

2019-07-09 Thread Tor Bug Tracker & Wiki
#29656: describe global initialization in our tinytest-based unit tests
---+--
 Reporter:  catalyst   |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  developer-doc  |  Actual Points:
Parent ID: | Points:  0.5
 Reviewer: |Sponsor:  Sponsor31-can
---+--
Changes (by nickm):

 * points:   => 0.5


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

Re: [tor-bugs] #29133 [Core Tor/Tor]: Refactor dirserv_read_measured_bandwidths

2019-07-09 Thread Tor Bug Tracker & Wiki
#29133: Refactor dirserv_read_measured_bandwidths
-+-
 Reporter:  teor |  Owner:  teor
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  technical-debt tor-crypto tor-   |  Actual Points:
  dirauth tor-bwauth 041-proposed|
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
 |  Sponsor31-can
-+-
Changes (by nickm):

 * points:   => 3


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

Re: [tor-bugs] #25950 [Core Tor/Tor]: Run "accounting_run_housekeeping" with a periodic event.

2019-07-09 Thread Tor Bug Tracker & Wiki
#25950: Run "accounting_run_housekeeping" with a periodic event.
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-roadmap-subtask, |  Actual Points:
  034-triage-20180328, 034-included-20180328 |
Parent ID:  #26070   | Points:  5
 Reviewer:   |Sponsor:
 |  Sponsor31-can
-+-
Changes (by nickm):

 * points:  3 => 5


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

Re: [tor-bugs] #29895 [Core Tor/Tor]: avoid storing ints in void* in mainloop event data

2019-07-09 Thread Tor Bug Tracker & Wiki
#29895: avoid storing ints in void* in mainloop event data
-+-
 Reporter:  catalyst |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  portability, technical-debt  |  Actual Points:
Parent ID:  #23714   | Points:  1
 Reviewer:   |Sponsor:  Sponsor31-can
-+-
Changes (by nickm):

 * points:   => 1


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

Re: [tor-bugs] #25950 [Core Tor/Tor]: Run "accounting_run_housekeeping" with a periodic event.

2019-07-09 Thread Tor Bug Tracker & Wiki
#25950: Run "accounting_run_housekeeping" with a periodic event.
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-roadmap-subtask, |  Actual Points:
  034-triage-20180328, 034-included-20180328 |
Parent ID:  #26070   | Points:  3
 Reviewer:   |Sponsor:
 |  Sponsor31-can
-+-
Changes (by nickm):

 * points:   => 3


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

Re: [tor-bugs] #29746 [Core Tor/Tor]: Improve Tor best practices tracker

2019-07-09 Thread Tor Bug Tracker & Wiki
#29746: Improve Tor best practices tracker
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  practracker, tech-debt,  |  Actual Points:
  refactoring, easy, 041-deferred-20190530   |
Parent ID:   | Points:  3
 Reviewer:   |Sponsor:
 |  Sponsor31-can
-+-
Changes (by nickm):

 * points:   => 3


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

Re: [tor-bugs] #30752 [Core Tor/Tor]: Practracker: usability improvements from May retrospective

2019-07-09 Thread Tor Bug Tracker & Wiki
#30752: Practracker: usability improvements from May retrospective
--+
 Reporter:  nickm |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  1.5
 Reviewer:|Sponsor:  Sponsor31-can
--+
Changes (by nickm):

 * points:   => 1.5


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

[tor-bugs] #31122 [Core Tor/Tor]: Use subsystems architecture in more places

2019-07-09 Thread Tor Bug Tracker & Wiki
#31122: Use subsystems architecture in more places
---+
 Reporter:  nickm  |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor:  Sponsor31-can  |
---+
 We introduced a "subsystems" architecture in Tor 0.3.5, where each module
 registers functions for setting itself up and tearing itself down.  We now
 use this mechanism in `lib` and `core/mainloop`.  We should push its usage
 through the rest of `core`, and into more of `features` and `app`.

 We shouldn't try to do this all in one go.  Please open subtickets for
 individual modules.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31121 [Core Tor/Tor]: Use publish-subscribe system in more places

2019-07-09 Thread Tor Bug Tracker & Wiki
#31121: Use publish-subscribe system in more places
---+--
 Reporter:  nickm  |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor:  Sponsor31-can  |
---+--
 Some likely code that we could replace includes:

  * directory_info_has_arrived
  * note_that_we_have_completed_a_circuit
  * note_that_we_maybe_cant_complete_circuits

  * circuit_has_opened()

  * All "we got a new consensus" events:
  * notify_before_networkstatus_changes
  * notify_after_networkstatus_changes

   * clock jump events:
 * circuit_note_clock_jumped
 * netstatus_note_clock_jumped

 There are probably more!

 As we do these, we should open subtickets, and not try to do them all as a
 part of this ticket.

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

Re: [tor-bugs] #31003 [Core Tor/Tor]: heap-use-after-free src/feature/nodelist/routerlist.c:704 in router_get_by_descriptor_digest

2019-07-09 Thread Tor Bug Tracker & Wiki
#31003: heap-use-after-free src/feature/nodelist/routerlist.c:704 in
router_get_by_descriptor_digest
-+-
 Reporter:  dgoulet  |  Owner:  nickm
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-crash, tor-hs, 041-backport? |  Actual Points:
  041-should? 041-regression? 041-must?  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * milestone:  Tor: 0.4.2.x-final => Tor: 0.4.1.x-final


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

Re: [tor-bugs] #31040 [Core Tor/Tor]: Stop showing git scripts changes, unless the base is master

2019-07-09 Thread Tor Bug Tracker & Wiki
#31040: Stop showing git scripts changes, unless the base is master
--+
 Reporter:  teor  |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.1-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  0.5
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * keywords:  041-should? =>


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

Re: [tor-bugs] #31003 [Core Tor/Tor]: heap-use-after-free src/feature/nodelist/routerlist.c:704 in router_get_by_descriptor_digest

2019-07-09 Thread Tor Bug Tracker & Wiki
#31003: heap-use-after-free src/feature/nodelist/routerlist.c:704 in
router_get_by_descriptor_digest
-+-
 Reporter:  dgoulet  |  Owner:  nickm
 Type:  defect   | Status:
 |  assigned
 Priority:  High |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-crash, tor-hs, 041-backport? |  Actual Points:
  041-should? 041-regression? 041-must?  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * owner:  (none) => nickm
 * keywords:  tor-crash, tor-hs, 041-backport? 041-should? 041-regression?
 => tor-crash, tor-hs, 041-backport? 041-should? 041-regression?
 041-must?
 * status:  new => assigned


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

Re: [tor-bugs] #31002 [Core Tor/Tor]: circpadding: Middle node did not accept our padding request

2019-07-09 Thread Tor Bug Tracker & Wiki
#31002: circpadding: Middle node did not accept our padding request
-+-
 Reporter:  dgoulet  |  Owner:
 |  mikeperry
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.1.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-circpadding 041-backport |  Actual Points:
  041-should? 041-must? 041-regression   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * owner:  (none) => mikeperry
 * status:  new => assigned
 * keywords:  tor-circpadding 041-backport 041-should? 041-regression =>
 tor-circpadding 041-backport 041-should? 041-must? 041-regression
 * milestone:  Tor: 0.4.2.x-final => Tor: 0.4.1.x-final


Comment:

 I am tentatively labeling this `041-must?`, but we can downgrade it if it
 turns out not to be a serious bug.

 Mike, could you please have a look at this?

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

Re: [tor-bugs] #30468 [Applications/Tor Browser]: Ship macedonian Tor Browser in alpha series

2019-07-09 Thread Tor Bug Tracker & Wiki
#30468: Ship macedonian Tor Browser in alpha series
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  localization,|  Actual Points:
  TorBrowserTeam201907R, GeorgKoppen201907   |
Parent ID:  #29935   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:17 Zarko_Gjurov]:
 > Since Firefox ESR for Desktop is available on Macedonian (MK) language
 for following platforms:
 > - Windows 64-bit
 > - Windows 32-bit
 > - macOS
 > - Linux 64-bit
 > - Linux 32-bit
 >
 > Does that mean that in Tor version 9.0 MK locale for TOR Browser for
 Desktop will be released (yes or no)?

 If we don't find any blocking issues while testing in the alpha series,
 then yes.

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

Re: [tor-bugs] #30409 [Core Tor/Tor]: Some of our tests require internet connectivity / an IPv4 stack

2019-07-09 Thread Tor Bug Tracker & Wiki
#30409: Some of our tests require internet connectivity / an IPv4 stack
-+-
 Reporter:  asn  |  Owner:  (none)
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-ipv6, tor-hs, tor-tests, tor-ci  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by nickm):

 * keywords:  tor-ipv6, tor-hs, tor-tests, tor-ci, 041-should => tor-ipv6,
 tor-hs, tor-tests, tor-ci


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

Re: [tor-bugs] #28694 [Core Tor/sbws]: When CircuitPadding is implemented in Tor, set it to 0 in sbws

2019-07-09 Thread Tor Bug Tracker & Wiki
#28694: When CircuitPadding is implemented in Tor, set it to 0 in sbws
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  sbws:
 |  1.1.x-final
Component:  Core Tor/sbws|Version:
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,|  Actual Points:
  padding, changes-version-patch, sbws-11x-  |
  final-removed-20190312, scanner|
Parent ID:  #29954   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor2
-+-
Changes (by nickm):

 * keywords:
 wtf-pad, tor-relay, tor-cell, padding, changes-version-patch, sbws-
 11x-final-removed-20190312, scanner, 041-should
 =>
 wtf-pad, tor-relay, tor-cell, padding, changes-version-patch, sbws-
 11x-final-removed-20190312, scanner


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

Re: [tor-bugs] #30468 [Applications/Tor Browser]: Ship macedonian Tor Browser in alpha series

2019-07-09 Thread Tor Bug Tracker & Wiki
#30468: Ship macedonian Tor Browser in alpha series
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  localization,|  Actual Points:
  TorBrowserTeam201907R, GeorgKoppen201907   |
Parent ID:  #29935   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by Zarko_Gjurov):

 Since Firefox ESR for Desktop is available on Macedonian (MK) language for
 following platforms:
 - Windows 64-bit
 - Windows 32-bit
 - macOS
 - Linux 64-bit
 - Linux 32-bit

 Does that mean that in Tor version 9.0 MK locale for TOR Browser for
 Desktop will be released (yes or no)?

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

Re: [tor-bugs] #31115 [Core Tor/Tor]: tor returns first 4 bytes of IPv6 address only when using SOCKS command "F0"

2019-07-09 Thread Tor Bug Tracker & Wiki
#31115: tor returns first 4 bytes of IPv6 address only when using SOCKS command
"F0"
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.8
 Severity:  Normal| Resolution:  not a bug
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 ah, ok

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

Re: [tor-bugs] #31115 [Core Tor/Tor]: tor returns first 4 bytes of IPv6 address only when using SOCKS command "F0"

2019-07-09 Thread Tor Bug Tracker & Wiki
#31115: tor returns first 4 bytes of IPv6 address only when using SOCKS command
"F0"
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.8
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by cypherpunks):

 exitmap reads only 10 bytes of the response, that is why it does not see
 more.

 You can close it.

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

Re: [tor-bugs] #31119 [Internal Services/Tor Sysadmin Team]: Need stunnel restarted on crm-int-01

2019-07-09 Thread Tor Bug Tracker & Wiki
#31119: Need stunnel restarted on crm-int-01
-+-
 Reporter:  peterh   |  Owner:  anarcat
 Type:  task | Status:  closed
 Priority:  Immediate|  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

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


Comment:

 this particular instance fixed by restarting both stunnels, starting with
 -ext, but -int was the actual fix. details in #30912, closing this one for
 now...

 sorry i don't have time to investigate much further for today, but i have
 a few more ideas on what to test next time...

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

Re: [tor-bugs] #30912 [Internal Services/Tor Sysadmin Team]: Investigate stunnel outage on crm-ext-01

2019-07-09 Thread Tor Bug Tracker & Wiki
#30912: Investigate stunnel outage on crm-ext-01
-+-
 Reporter:  peterh   |  Owner:  tpa
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 details from #31119 debugging...

 daemon.log on crm-ext-01:

 {{{
 Jul  9 16:21:58 crm-ext-01/crm-ext-01 stunnel[25094]: LOG5[17173]: Service
 [civicrm-redis-server] accepted connection from 127.0.0.1:55102
 Jul  9 16:21:58 crm-ext-01/crm-ext-01 stunnel[25094]: LOG6[17173]:
 failover: round-robin, starting at entry #1
 Jul  9 16:21:58 crm-ext-01/crm-ext-01 stunnel[25094]: LOG6[17173]:
 s_connect: connecting 138.201.212.235:16379
 Jul  9 16:21:58 crm-ext-01/crm-ext-01 stunnel[25094]: LOG5[17173]:
 s_connect: connected 138.201.212.235:16379
 Jul  9 16:21:58 crm-ext-01/crm-ext-01 stunnel[25094]: LOG5[17173]: Service
 [civicrm-redis-server] connected remote server from 138.201.212.236:54124
 Jul  9 16:21:58 crm-ext-01/crm-ext-01 stunnel[25094]: LOG6[17173]: SNI:
 sending servername: crm-int-01.torproject.org
 Jul  9 16:21:58 crm-ext-01/crm-ext-01 stunnel[25094]: LOG6[17173]: Peer
 certificate required
 Jul  9 16:21:59 crm-ext-01/crm-ext-01 stunnel[25094]: LOG5[17174]: Service
 [civicrm-redis-server] accepted connection from 127.0.0.1:55110
 Jul  9 16:21:59 crm-ext-01/crm-ext-01 stunnel[25094]: LOG6[17174]:
 failover: round-robin, starting at entry #0
 Jul  9 16:21:59 crm-ext-01/crm-ext-01 stunnel[25094]: LOG6[17174]:
 s_connect: connecting 2a01:4f8:172:39ca:0:dad3:11:1:16379
 Jul  9 16:21:59 crm-ext-01/crm-ext-01 stunnel[25094]: LOG5[17174]:
 s_connect: connected 2a01:4f8:172:39ca:0:dad3:11:1:16379
 Jul  9 16:21:59 crm-ext-01/crm-ext-01 stunnel[25094]: LOG5[17174]: Service
 [civicrm-redis-server] connected remote server from
 2a01:4f8:172:39ca:0:dad3:12:1:33678
 Jul  9 16:21:59 crm-ext-01/crm-ext-01 stunnel[25094]: LOG6[17174]: SNI:
 sending servername: crm-int-01.torproject.org
 Jul  9 16:21:59 crm-ext-01/crm-ext-01 stunnel[25094]: LOG6[17174]: Peer
 certificate required
 Jul  9 16:22:13 crm-ext-01/crm-ext-01 stunnel[25094]: LOG6[17165]:
 ssl_start: s_poll_wait: TIMEOUTbusy exceeded: sending reset
 Jul  9 16:22:13 crm-ext-01/crm-ext-01 stunnel[25094]: LOG5[17165]:
 Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket
 Jul  9 16:22:41 crm-ext-01/crm-ext-01 stunnel[25094]: LOG6[17166]:
 ssl_start: s_poll_wait: TIMEOUTbusy exceeded: sending reset
 Jul  9 16:22:41 crm-ext-01/crm-ext-01 stunnel[25094]: LOG5[17166]:
 Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket
 Jul  9 16:22:58 crm-ext-01/crm-ext-01 stunnel[25094]: LOG6[17167]:
 ssl_start: s_poll_wait: TIMEOUTbusy exceeded: sending reset
 Jul  9 16:22:58 crm-ext-01/crm-ext-01 stunnel[25094]: LOG5[17167]:
 Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket
 Jul  9 16:23:11 crm-ext-01/crm-ext-01 stunnel[25094]: LOG6[17168]:
 ssl_start: s_poll_wait: TIMEOUTbusy exceeded: sending reset
 Jul  9 16:23:11 crm-ext-01/crm-ext-01 stunnel[25094]: LOG5[17168]:
 Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket
 }}}

 the crm-int-01 perspective's:

 {{{
 Jul  9 16:21:58 crm-int-01/crm-int-01 stunnel[25139]: LOG5[1138]: Service
 [civicrm-redis-server] accepted connection from
 :::138.201.212.236:54124
 Jul  9 16:21:59 crm-int-01/crm-int-01 stunnel[25139]: LOG5[1139]: Service
 [civicrm-redis-server] accepted connection from
 2a01:4f8:172:39ca:0:dad3:12:1:33678
 }}}

 AKA "all is well here".

 redis is up on int-01:

 {{{
 root@crm-int-01:~# echo PING | nc localhost 6379
 +PONG
 }}}

 but hangs on ext-01:

 {{{
 root@crm-ext-01:~# echo PING | nc localhost 6379
 [nothing]
 }}}

 restarting stunnel on ext-01 does nothing. restarting stunnel on int-01
 fixes it. therefore, there might be something wrong on the int-01 side,
 some fd leak maybe?

 next debugging step is to restart int-01 only.

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

Re: [tor-bugs] #31115 [Core Tor/Tor]: tor returns first 4 bytes of IPv6 address only when using SOCKS command "F0"

2019-07-09 Thread Tor Bug Tracker & Wiki
#31115: tor returns first 4 bytes of IPv6 address only when using SOCKS command
"F0"
--+
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.8
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


Comment:

 Why? Is this not an issue?

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

Re: [tor-bugs] #31116 [Core Tor/Tor]: clarify socks-extensions.txt spec resolve command and response

2019-07-09 Thread Tor Bug Tracker & Wiki
#31116: clarify socks-extensions.txt spec resolve command and response
--+--
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by nickm):

 * milestone:   => Tor: unspecified


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

Re: [tor-bugs] #31113 [Core Tor/Tor]: Circuitpadding updated comments

2019-07-09 Thread Tor Bug Tracker & Wiki
#31113: Circuitpadding updated comments
--+
 Reporter:  pulls |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.1.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #31119 [Internal Services/Tor Sysadmin Team]: Need stunnel restarted on crm-int-01

2019-07-09 Thread Tor Bug Tracker & Wiki
#31119: Need stunnel restarted on crm-int-01
-+-
 Reporter:  peterh   |  Owner:  anarcat
 Type:  task | Status:
 |  assigned
 Priority:  Immediate|  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * owner:  tpa => anarcat
 * status:  new => assigned


Comment:

 will investigate.

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

Re: [tor-bugs] #26080 [Applications/Tor Browser]: torbrowser 7.5.4 update seems to generate file with unique uuid in it

2019-07-09 Thread Tor Bug Tracker & Wiki
#26080: torbrowser 7.5.4 update seems to generate file with unique uuid in it
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-easy  |  Actual Points:
Parent ID:  #18097| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * status:  needs_information => new
 * keywords:   => tbb-easy
 * parent:   => #18097


Comment:

 Thanks for the investigation. Anyone wants to write a tiny patch 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] #31111 [Core Tor/Tor]: negotiate one machine per index

2019-07-09 Thread Tor Bug Tracker & Wiki
#3: negotiate one machine per index
--+
 Reporter:  pulls |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by nickm):

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


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

Re: [tor-bugs] #26080 [Applications/Tor Browser]: torbrowser 7.5.4 update seems to generate file with unique uuid in it

2019-07-09 Thread Tor Bug Tracker & Wiki
#26080: torbrowser 7.5.4 update seems to generate file with unique uuid in it
--+---
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by Ephraim):

 This seems to be related to fontconfig, so this problem might not exist on
 Windows but Linux and MacOS only? And it might also depend on the versions
 of the libraries used.

 We've found .uuid files in other directories in linux font directories. No
 idea why that is, but having a .uuid file in a torbrowser-container
 doesn't feel like a good idea.

 The file is created on first start of torbrowser as ./Browser/fonts/.uuid
 and once it's created it doesn't change anymore so its mtime shows when
 this installation has been started the first time and the .uuid contains
 an actual unique uuid. Feels much like a tag.

 I've tested creating a symlink in that place pointing to /dev/null and my
 torbrowser still works fine without any sideeffects seen.

 So my suggestion is to address this issue by creating a symlink

 ln -s /dev/null ./Browser/fonts/.uuid

 Currently using torbrowser 8.5.3 on debian sid (fontconfig 2.13.1-2)
 I'm not using KDE, so it's not related.

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

Re: [tor-bugs] #30468 [Applications/Tor Browser]: Ship macedonian Tor Browser in alpha series

2019-07-09 Thread Tor Bug Tracker & Wiki
#30468: Ship macedonian Tor Browser in alpha series
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  localization,|  Actual Points:
  TorBrowserTeam201907R, GeorgKoppen201907   |
Parent ID:  #29935   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:15 Zarko_Gjurov]:
 > According to e-mail from **Delphine Lebédel from Mozilla** dated from
 Jul 6, 2019:
 > “Concerning the localization of Firefox for Android: we have not been
 adding new locales for a few months now which is why you can not request
 it on Pontoon. In fact, we are transitioning to the Fenix browser, and it
 makes no sense to start localizations now since it's a huge project that
 takes approximately at least 6 months to translate, and a year to reach
 release. By the time localization is complete, Firefox for Android will
 most surely not exist anymore.
 > Since Firefox for Android won't be here for much longer, I'm not really
 sure this effort still makes sense.”
 >
 > So can you explain me what will happen with Macedonian translation for
 Tor according to this statement of Mozilla’s officials?
 >
 > Keeping in mind that Tor MK translations were fully ready since last
 October, 2018, will be very unprofessional MK localization not to be
 published as final product.
 >
 > So as I see Tor for Android will stay on EN-US while there will be
 Macedonian Tor bundle for Desktop released together with all other
 languages in v9.0, am I right, or?

 I think that is correct, yes. We are dependent on Mozilla for providing
 translations of all non-Tor Browser-strings (which take up the vast
 majority of browser strings). If those are not available we can't ship a
 bundle in the respective locale.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31120 [Applications/Tor Browser]: Enable AssertSystemPrincipalMustNotLoadRemoteDocuments

2019-07-09 Thread Tor Bug Tracker & Wiki
#31120: Enable AssertSystemPrincipalMustNotLoadRemoteDocuments
--+--
 Reporter:  tom   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:  ff68-esr
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 AssertSystemPrincipalMustNotLoadRemoteDocuments is a defense in depth
 mitigation Tor should ensure is used by default.

 This will involve removing some ifdefs and possibly backporting the
 updates to the function from -central to -esr68

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

Re: [tor-bugs] #30468 [Applications/Tor Browser]: Ship macedonian Tor Browser in alpha series

2019-07-09 Thread Tor Bug Tracker & Wiki
#30468: Ship macedonian Tor Browser in alpha series
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  localization,|  Actual Points:
  TorBrowserTeam201907R, GeorgKoppen201907   |
Parent ID:  #29935   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by Zarko_Gjurov):

 According to e-mail from **Delphine Lebédel from Mozilla** dated from Jul
 6, 2019:
 “Concerning the localization of Firefox for Android: we have not been
 adding new locales for a few months now which is why you can not request
 it on Pontoon. In fact, we are transitioning to the Fenix browser, and it
 makes no sense to start localizations now since it's a huge project that
 takes approximately at least 6 months to translate, and a year to reach
 release. By the time localization is complete, Firefox for Android will
 most surely not exist anymore.
 Since Firefox for Android won't be here for much longer, I'm not really
 sure this effort still makes sense.”

 So can you explain me what will happen with Macedonian translation for Tor
 according to this statement of Mozilla’s officials?

 Keeping in mind that Tor MK translations were fully ready since last
 October, 2018, will be very unprofessional MK localization not to be
 published as final product.

 So as I see Tor for Android will stay on EN-US while there will be
 Macedonian Tor bundle for Desktop released together with all other
 languages in v9.0, am I right, or?

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

Re: [tor-bugs] #30219 [Metrics/CollecTor]: Add Tom's bandwidth file archive to CollecTor

2019-07-09 Thread Tor Bug Tracker & Wiki
#30219: Add Tom's bandwidth file archive to CollecTor
-+-
 Reporter:  irl  |  Owner:
 |  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/CollecTor|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth,tor-dirauth,metrics-  |  Actual Points:
  roadmap-2019-q2|
Parent ID:  #21378   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by karsten):

 Good questions! I think our goal here is to archive bandwidth files as
 they're being used in the network. If a bandwidth file had been used by
 more than one dirauth, we'd store the same file multiple times, once under
 each source name. (Or if we'd download it without including the source
 annotation, we'd store it only once, and it would be referenced using the
 same digest from multiple votes.) And if a bandwidth file had not been
 used by any dirauth, we wouldn't get to see it at all.

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

Re: [tor-bugs] #31117 [Applications/Tor Browser]: On connect (app start), Tor Browser (Android) produces "Warning: Unresponsive script" dialog on home screen.

2019-07-09 Thread Tor Bug Tracker & Wiki
#31117: On connect (app start), Tor Browser (Android) produces "Warning:
Unresponsive script" dialog on home screen.
--+---
 Reporter:  torlove   |  Owner:  tbb-team
 Type:  defect| Status:  needs_information
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => needs_information
 * keywords:   => tbb-mobile
 * component:  - Select a component => Applications/Tor Browser
 * owner:  (none) => tbb-team


Comment:

 I assume this happens on every start? If so, could you try setting the
 `javascript.options.wasm` preference to `true` in `about:config` and
 report back whether that changes things for you?

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

Re: [tor-bugs] #31118 [- Select a component]: Need stunnel restarted on crm-int-01

2019-07-09 Thread Tor Bug Tracker & Wiki
#31118: Need stunnel restarted on crm-int-01
--+---
 Reporter:  peterh|  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Immediate |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


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

Re: [tor-bugs] #30219 [Metrics/CollecTor]: Add Tom's bandwidth file archive to CollecTor

2019-07-09 Thread Tor Bug Tracker & Wiki
#30219: Add Tom's bandwidth file archive to CollecTor
-+-
 Reporter:  irl  |  Owner:
 |  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/CollecTor|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth,tor-dirauth,metrics-  |  Actual Points:
  roadmap-2019-q2|
Parent ID:  #21378   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by tom):

 Replying to [comment:11 irl]:
 > Is there always a one to one mapping of bwauth to dirauth?

 No

 > Can you run a bwauth without having a dirauth attached to it?

 Absolutely. In fact all of the maatuska-* files in the dataset are a
 bwauth whose bwauth files were never used by a dirauth.  Other people have
 run bwauths on the tor network without sending them to a dirauth also.

 Whether collector wants to support those is a whole other matter. For one
 thing the files would need to be important manually (or a new collector-
 scanner set up to download them in a non-standard way.)

 > Can one bwauth be consumed by multiple dirauths?

 Yes, although this is discouraged. I'm not sure it's ever happened,
 although we did consider it at one point to get the network kicked out of
 a state where we weren't using bwauth measurements for path selection.

 Also you didn't ask: can a dirauth use multiple bwauths?

 It can, although I don't think this has ever happened.  The dirauth would
 need to switch between the bwauths on some schedule or otherwise combine
 the files in a way I don't think we've ever considered.  Typically, to
 achieve diversity, a bwauth performs its downloads from multiple
 differingly-geolocated servers

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

Re: [tor-bugs] #30912 [Internal Services/Tor Sysadmin Team]: Investigate stunnel outage on crm-ext-01

2019-07-09 Thread Tor Bug Tracker & Wiki
#30912: Investigate stunnel outage on crm-ext-01
-+-
 Reporter:  peterh   |  Owner:  tpa
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by peterh):

 It happened again. The first notification I got was at 2019-07-08 19:12
 PDT. I made ticket https://trac.torproject.org/projects/tor/ticket/31119
 to get it restarted.

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

Re: [tor-bugs] #31118 [- Select a component]: Need stunnel restarted on crm-int-01

2019-07-09 Thread Tor Bug Tracker & Wiki
#31118: Need stunnel restarted on crm-int-01
--+
 Reporter:  peterh|  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Immediate |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (by peterh):

 I made https://trac.torproject.org/projects/tor/ticket/31119 with the
 correct component, so this one can be closed. Sorry.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31119 [Internal Services/Tor Sysadmin Team]: Need stunnel restarted on crm-int-01

2019-07-09 Thread Tor Bug Tracker & Wiki
#31119: Need stunnel restarted on crm-int-01
-+-
 Reporter:  peterh   |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Immediate|  Component:  Internal Services/Tor Sysadmin
 |  Team
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
 Sorry, I had to make another ticket because I forgot to set the component
 on the first one and can't edit it.

 crm-ext-01 can't talk to Redis again. The last time it happened we fixed
 it by restarting stunnel on crm-int-01. Could someone restart it?

 This is urgent because donation information isn't getting recorded in the
 CRM until this gets fixed.

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

Re: [tor-bugs] #25493 [Core Tor/Tor]: Improve patterns for cleaning up static variables on exit/restart

2019-07-09 Thread Tor Bug Tracker & Wiki
#25493: Improve patterns for cleaning up static variables on exit/restart
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-triage-20180328, 034-roadmap-|  Actual Points:
  subtask, 034-included-20180405, 035-roadmap-   |
  subtask, 035-triaged-in-20180711,  |
  040-deferred-201915|
Parent ID:  #25510   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor31-can
-+-

Comment (by nickm):

 I believe that this is in progress, via our "subsystems" design.

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

Re: [tor-bugs] #25493 [Core Tor/Tor]: Improve patterns for cleaning up static variables on exit/restart

2019-07-09 Thread Tor Bug Tracker & Wiki
#25493: Improve patterns for cleaning up static variables on exit/restart
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  034-triage-20180328, 034-roadmap-|  implemented
  subtask, 034-included-20180405, 035-roadmap-   |  Actual Points:
  subtask, 035-triaged-in-20180711,  |
  040-deferred-201915|
Parent ID:  #25510   | Points:
 Reviewer:   |Sponsor:
 |  Sponsor31-can
-+-
Changes (by nickm):

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

[tor-bugs] #31118 [- Select a component]: Need stunnel restarted on crm-int-01

2019-07-09 Thread Tor Bug Tracker & Wiki
#31118: Need stunnel restarted on crm-int-01
---+--
 Reporter:  peterh |  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Immediate  |  Component:  - Select a component
  Version: |   Severity:  Normal
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
 crm-ext-01 can't talk to Redis again. The last time it happened we fixed
 it by restarting stunnel on crm-int-01. Could someone restart it?

 This is urgent because donation information isn't getting recorded in the
 CRM until this gets fixed.

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

Re: [tor-bugs] #31100 [Circumvention/Snowflake]: Firefox addon not reporting any users

2019-07-09 Thread Tor Bug Tracker & Wiki
#31100: Firefox addon not reporting any users
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Circumvention/Snowflake  |Version:  Tor: unspecified
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+--

Comment (by cohosh):

 More information:

 I got it to go into an infinite loop again. This occurred when a client
 outside my network attempted to connect through my proxy. The debug logs
 show:
 {{{
 Snowflake: Broker: Successfully replied with answer. snowflake.js:1194:13
 XML Parsing Error: no element found
 Location: https://snowflake-broker.bamsoftware.com/answer
 Snowflake: At client capacity.
 ICE failed, add a STUN server and see about:webrtc for more details
 Snowflake: At client capacity.
 }}}
 And then the proxy stops polling and remains at capacity. It looks like
 the answer is received and so the proxypair is set to active, but the
 datachannel is never opened. When going to `about:webrtc` to look at my
 local candidates I see only
 {{{
 a=candidate:0 1 UDP 2122252543 192.168.1.2 58106 typ host

 a=candidate:1 1 TCP 2105524479 192.168.1.2 9 typ host tcptype active

 }}}
 which would work for a local client but not a remote one. So it seems STUN
 isn't giving non-local candidates. So there are two things that need
 fixing:
 - We should make set a timeout on datachannels opening to avoid infinite
 loops
 - We should figure out what's going wrong with STUN

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31117 [- Select a component]: On connect (app start), Tor Browser (Android) produces "Warning: Unresponsive script" dialog on home screen.

2019-07-09 Thread Tor Bug Tracker & Wiki
#31117: On connect (app start), Tor Browser (Android) produces "Warning:
Unresponsive script" dialog on home screen.
-+--
 Reporter:  torlove  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  - Select a component
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 Steps:
 - On Kitkat
 - Open Tor Browser
 - Click "Connect" to the Tor network (after a successful connection the
 Tor Browser opens automatically)

 At this moment a popup dialog appears. I'm going to try and repeat this
 verbatim, the heading of the pop-up reads "Warning: Unresponsive script".
 The body of the dialog says:

 "A script on this page may be busy, or it may have stopped responding. You
 can stop the script now, or you can continue to see if the script will
 complete.

 Script: moz-extension://5c52665b-1b57-...53/background-
 scripts/rules.js:323

 END

 The usual "Stop script" and "Continue" buttons.

 While the dialogue is on the screen the Tor home screen/page can be seen
 in the background. It is basically appears that a page produced by the Tor
 team has some kind of error.

 All versions of Tor Browser for Android that I've updated to have been
 presenting this dialog. I did not report it because I assumed that someone
 else would, but it seems that has not eventuated. I cannot remember if the
 first version (that worked on Kitkat) had this problem but definitely
 every other version has.

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

Re: [tor-bugs] #30219 [Metrics/CollecTor]: Add Tom's bandwidth file archive to CollecTor

2019-07-09 Thread Tor Bug Tracker & Wiki
#30219: Add Tom's bandwidth file archive to CollecTor
-+-
 Reporter:  irl  |  Owner:
 |  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/CollecTor|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth,tor-dirauth,metrics-  |  Actual Points:
  roadmap-2019-q2|
Parent ID:  #21378   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by irl):

 Is there always a one to one mapping of bwauth to dirauth? Can you run a
 bwauth without having a dirauth attached to it? Can one bwauth be consumed
 by multiple dirauths?

 If we're going to say $nickname then we should not have this be the same
 nickname as in a server descriptor, but rather one that we keep a registry
 of and can be more precise about. It's a key that you can use to look up
 more details about the source by asking the Metrics team (we'd probably
 put the list on collector.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] #31100 [Circumvention/Snowflake]: Firefox addon not reporting any users

2019-07-09 Thread Tor Bug Tracker & Wiki
#31100: Firefox addon not reporting any users
-+--
 Reporter:  cohosh   |  Owner:  cohosh
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Circumvention/Snowflake  |Version:  Tor: unspecified
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+--

Comment (by cohosh):

 Okay running it again this morning it's working fine for me:
 {{{
 XML Parsing Error: no element found
 Snowflake: WebRTC DataChannel opened! snowflake.js:1194:13
 Snowflake: websocket-relay connected! snowflake.js:1194:13
 Snowflake: At client capacity.
 Content Security Policy: Couldn’t parse invalid host 'wasm-eval'
 Snowflake: At client capacity.
 ICE failed, add a STUN server and see about:webrtc for more details
 Snowflake: At client capacity.
 }}}

 I think what might be happening is sometimes the webextension gets into an
 infinite loop and perpetually thinks that it's at client capacity. Maybe
 there's a promise that isn't ever returning somewhere. I also think I'm
 still seeing the behaviour where a datachannel is being closed but the
 proxy still thinks it's connected, even with the omission of the STUN
 port.

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

Re: [tor-bugs] #31115 [Core Tor/Tor]: tor returns first 4 bytes of IPv6 address only when using SOCKS command "F0"

2019-07-09 Thread Tor Bug Tracker & Wiki
#31115: tor returns first 4 bytes of IPv6 address only when using SOCKS command
"F0"
--+--
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.8
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 you can close this 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] #30304 [Applications/Tor Browser]: Browser locale can be obtained via DTD strings

2019-07-09 Thread Tor Bug Tracker & Wiki
#30304: Browser locale can be obtained via DTD strings
-+-
 Reporter:  acat |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, tbb-fingerprinting-|  Actual Points:
  locale, TorBrowserTeam201906   |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by acat):

 We can backport https://hg.mozilla.org/mozilla-central/rev/3b5afc9aa309
 and https://hg.mozilla.org/mozilla-central/rev/9276e88ea3fe for this. Note
 that the hack for Android/Desktop duplicated translations
 (https://github.com/acatarineu/tor-
 browser/commit/6647e87dc1ed59c5b39e8618bf8753d1d8423343) will have to be
 adapted after this (we need `parser.forceEnableDTD();`)

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

Re: [tor-bugs] #30219 [Metrics/CollecTor]: Add Tom's bandwidth file archive to CollecTor

2019-07-09 Thread Tor Bug Tracker & Wiki
#30219: Add Tom's bandwidth file archive to CollecTor
-+-
 Reporter:  irl  |  Owner:
 |  metrics-team
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Metrics/CollecTor|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-bwauth,tor-dirauth,metrics-  |  Actual Points:
  roadmap-2019-q2|
Parent ID:  #21378   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by karsten):

 Alright, it sounds like specifying annotations, including this one, is
 already under discussion in #28067.

 What remains to be discussed is what annotation we're using in this case.

 Regarding `"@source"` annotations, it's true that tor writes these as
 "FQDN (or IP) and port", but it also accepts other values such as
 `"@source controller"` when it attempts to parse a router descriptor
 received via the controller in `router_load_single_router()`. So it really
 doesn't care what's written in that annotation, which is fine.

 In this case we might want to use the directory authority nickname rather
 than IP address or domain name, with a port, because nicknames work so
 much better in file names than the others.

 How about we include an ''optional'' `"@source $nickname"` annotation for
 bandwidth files that we also add to the file name, such as:

 {{{
 2019-04-21-09-00-00-bandwidth-file-$nickname-
 42D07217935283D42CC559A61E7F788E3A92F0E2CB54BE58B5B83E25563C55A2 //
 nickname given
 2019-04-21-09-00-00-bandwidth-file-
 42D07217935283D42CC559A61E7F788E3A92F0E2CB54BE58B5B83E25563C55A2 // no
 nickname given
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31116 [Core Tor/Tor]: clarify socks-extensions.txt spec resolve command and response

2019-07-09 Thread Tor Bug Tracker & Wiki
#31116: clarify socks-extensions.txt spec resolve command and response
-+--
 Reporter:  cypherpunks  |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  Core Tor/Tor
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 https://gitweb.torproject.org/torspec.git/tree/socks-extensions.txt

 The spec leaves multiple open questions:

 - What does "initiates a remote lookup of the hostname" mean?
 The spec could be improved by saying "A" or/and "" DNS lookup is
 performed.

 - There is no information about the response in torspec.git/tree/socks-
 extensions.txt at all


 related:
 #31115


 https://lists.torproject.org/pipermail/tor-dev/2019-July/013931.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] #31115 [Core Tor/Tor]: tor returns first 4 bytes of IPv6 address only when using SOCKS command "F0"

2019-07-09 Thread Tor Bug Tracker & Wiki
#31115: tor returns first 4 bytes of IPv6 address only when using SOCKS command
"F0"
--+--
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.3.5.8
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 example:

 SOCKS response for resolving "ipv6.google.com"
 ("2a00:1450:4007:80c::200e")

 {{{
 0x05 00 00 04 2a001450 4001
 }}}

 05 = version
 00 = resp code: succeeded
 00 = reserved
 04 = ATYP: IPv6
 2a001450

 last to bytes are "BND.PORT" as per spec but they might also be part of
 the IPv6 address
 so the answer might contain the first 6 bytes not just 4 bytes.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31115 [Core Tor/Tor]: tor returns first 4 bytes of IPv6 address only when using SOCKS command "F0"

2019-07-09 Thread Tor Bug Tracker & Wiki
#31115: tor returns first 4 bytes of IPv6 address only when using SOCKS command
"F0"
--+--
 Reporter:  cypherpunks   |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Component:  Core Tor/Tor
  Version:  Tor: 0.3.5.8  |   Severity:  Normal
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 Context:

 Tor has a custom extension to the SOCKS protocol, defined in:
 https://gitweb.torproject.org/torspec.git/tree/socks-extensions.txt#n48

 that allows resolving hostnames.

 exitmap makes use of this SOCKS extension.

 When the answer is an IPv6 address (ATYP=04) only the first 4 bytes are
 contained in the response instead of the entire IPv6 address.

 Expected behavior: The entire IPv6 address should be in the response (128
 bit instead of 32 bit).

 https://lists.torproject.org/pipermail/tor-dev/2019-July/013931.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] #26597 [Metrics/Website]: Investigate and document additional overhead for first hop when not using guards

2019-07-09 Thread Tor Bug Tracker & Wiki
#26597: Investigate and document additional overhead for first hop when not 
using
guards
---+
 Reporter:  irl|  Owner:  metrics-team
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:
Component:  Metrics/Website|Version:
 Severity:  Normal | Resolution:
 Keywords:  acute-2019-q1-planned  |  Actual Points:
Parent ID: | Points:
 Reviewer:  acute  |Sponsor:
---+
Changes (by irl):

 * component:  Metrics/Onionperf => Metrics/Website


Comment:

 This turned into a website ticket.

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

Re: [tor-bugs] #31105 [- Select a component]: Extremely slow connection speeds

2019-07-09 Thread Tor Bug Tracker & Wiki
#31105: Extremely slow connection speeds
--+---
 Reporter:  resistance17  |  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Immediate |  Milestone:
Component:  - Select a component  |Version:
 Severity:  Critical  | Resolution:  not a bug
 Keywords:  slow connection   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

 * status:  new => closed
 * version:  Tor: 0.4.1.3-alpha =>
 * resolution:   => not a bug


Comment:

 You might have got a slow guard which would not change if you do a new
 identity or change the circuit. Or your regular guard node could have
 issues with the network right now. Or your government/ISP could throttle
 traffic that it does not know about and it would affected your Tor
 connections. Or maybe there is even another explanation.

 Either way, I don't think that's a Tor bug. However, you could try bridges
 and see whether that solves your problem.

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

Re: [tor-bugs] #26597 [Metrics/Onionperf]: Investigate and document additional overhead for first hop when not using guards

2019-07-09 Thread Tor Bug Tracker & Wiki
#26597: Investigate and document additional overhead for first hop when not 
using
guards
---+
 Reporter:  irl|  Owner:  metrics-team
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:
 Keywords:  acute-2019-q1-planned  |  Actual Points:
Parent ID: | Points:
 Reviewer:  acute  |Sponsor:
---+
Changes (by irl):

 * status:  needs_review => needs_revision


Comment:

 I don't think this text is actually correct. The first hop build time is
 the same as for regular Tor clients, but regular Tor clients won't see
 that latency because they have already got the connection to the guard set
 up.

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

Re: [tor-bugs] #29375 [Metrics/Onionperf]: Improve code documentation coverage for OnionPerf

2019-07-09 Thread Tor Bug Tracker & Wiki
#29375: Improve code documentation coverage for OnionPerf
---+
 Reporter:  irl|  Owner:  acute
 Type:  enhancement| Status:  closed
 Priority:  Medium |  Milestone:
Component:  Metrics/Onionperf  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  acute-2019-q1-planned  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by irl):

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


Comment:

 Documentation is now built at onionperf.torproject.org

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31114 [Webpages/Blog]: Threading in blog comments is hardly visible and blog comment formatting is broken

2019-07-09 Thread Tor Bug Tracker & Wiki
#31114: Threading in blog comments is hardly visible and blog comment 
formatting is
broken
---+--
 Reporter:  gk |  Owner:  hiro
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Webpages/Blog  |Version:
 Severity:  Normal |   Keywords:
Actual Points: |  Parent ID:
   Points: |   Reviewer:
  Sponsor: |
---+--
 Probably due to the recent Drupal security upgrade the threading in blog
 comments is hard to follow and blog comment formatting is broken. This
 makes interacting with our blog pretty painful.

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

Re: [tor-bugs] #31110 [Applications/Tor Browser]: Tor Browser is having sex with CPU on Safest security level

2019-07-09 Thread Tor Bug Tracker & Wiki
#31110: Tor Browser is having sex with CPU on Safest security level
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:  tbb-performance   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Yes, without JavaScript certain sites are not working properly. This is
 not a Tor Browser bug, though, but part of the trade-off users have to
 make.

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

Re: [tor-bugs] #31113 [Core Tor/Tor]: Circuitpadding updated comments

2019-07-09 Thread Tor Bug Tracker & Wiki
#31113: Circuitpadding updated comments
--+
 Reporter:  pulls |  Owner:  (none)
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  new => needs_review


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

Re: [tor-bugs] #31112 [Core Tor/Tor]: remove specified target_hopnum from relay-side machines

2019-07-09 Thread Tor Bug Tracker & Wiki
#31112: remove specified target_hopnum from relay-side machines
--+
 Reporter:  pulls |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  new => needs_review


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

Re: [tor-bugs] #31111 [Core Tor/Tor]: negotiate one machine per index

2019-07-09 Thread Tor Bug Tracker & Wiki
#3: negotiate one machine per index
--+
 Reporter:  pulls |  Owner:  (none)
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:  Tor: 0.4.1.3-alpha
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by teor):

 * status:  new => needs_review


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

Re: [tor-bugs] #30145 [Internal Services/Tor Sysadmin Team]: Please give phw 'bridgedb' group membership

2019-07-09 Thread Tor Bug Tracker & Wiki
#30145: Please give phw 'bridgedb' group membership
-+
 Reporter:  sysrqb   |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by weasel):

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


Comment:

 I think this has already happened some time in the past.

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

Re: [tor-bugs] #31083 [Internal Services/Tor Sysadmin Team]: kvm5 uses unexpected IP address

2019-07-09 Thread Tor Bug Tracker & Wiki
#31083: kvm5 uses unexpected IP address
-+-
 Reporter:  weasel   |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by weasel):

 yes, almost certainly

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31113 [Core Tor/Tor]: Circuitpadding updated comments

2019-07-09 Thread Tor Bug Tracker & Wiki
#31113: Circuitpadding updated comments
+--
 Reporter:  pulls   |  Owner:  (none)
 Type:  enhancement | Status:  new
 Priority:  Medium  |  Component:  Core Tor/Tor
  Version:  Tor: 0.4.1.3-alpha  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 Went over `src/core/or/circuitpadding.{h,c}` and updated a number of code
 comments. Most of them minor enhancements, but one defect: clarifying the
 purpose of event `CIRCPAD_EVENT_LENGTH_COUNT`. PR here:
 https://github.com/torproject/tor/pull/1169.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31112 [Core Tor/Tor]: remove specified target_hopnum from relay-side machines

2019-07-09 Thread Tor Bug Tracker & Wiki
#31112: remove specified target_hopnum from relay-side machines
+--
 Reporter:  pulls   |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  Core Tor/Tor
  Version:  Tor: 0.4.1.3-alpha  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 For circuit padding machines, the `target_hopnum`field in `struct
 circpad_machine_spec_t`is only for origin-side machines. Currently, the
 relay side of the two onion-related machines set the field. This should be
 safe to remove. PR here: https://github.com/torproject/tor/pull/1170.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31111 [Core Tor/Tor]: negotiate one machine per index

2019-07-09 Thread Tor Bug Tracker & Wiki
#3: negotiate one machine per index
+--
 Reporter:  pulls   |  Owner:  (none)
 Type:  defect  | Status:  new
 Priority:  Medium  |  Component:  Core Tor/Tor
  Version:  Tor: 0.4.1.3-alpha  |   Severity:  Normal
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
 As part of `circuitpadding.c`, in `circpad_add_matching_machines()`, the
 macros `FOR_EACH_CIRCUIT_MACHINE_BEGIN` and
 `SMARTLIST_FOREACH_REVERSE_BEGIN` currently expand to a for loop each.
 Below a slightly cropped (...) version of
 `circpad_add_matching_machines()`:

 {{{
 circpad_add_matching_machines(origin_circuit_t *on_circ,
   smartlist_t *machines_sl)
 {
   ...
   FOR_EACH_CIRCUIT_MACHINE_BEGIN(i) {
 ...
 SMARTLIST_FOREACH_REVERSE_BEGIN(machines_sl,
 circpad_machine_spec_t *,
 machine) {
 ...
 if (circpad_negotiate_padding(on_circ, machine->machine_num,
   machine->target_hopnum,
   CIRCPAD_COMMAND_START) < 0) {
   log_info(LD_CIRC, "Padding not negotiated. Cleaning machine");
   circpad_circuit_machineinfo_free_idx(circ, i);
   circ->padding_machine[i] = NULL;
   on_circ->padding_negotiation_failed = 1;
 } else {
   /* Success. Don't try any more machines */
   return;
 }
   }
 } SMARTLIST_FOREACH_END(machine);
   } FOR_EACH_CIRCUIT_MACHINE_END;
 }
 }}}

 The outer loop goes over each machine index (currently 2, set by
 `CIRCPAD_MAX_MACHINES`), while the inner loop looks for a suitable machine
 for that index to negotiate. As soon as one is found and negotiated,
 currently, the function returns without looking for a machine for later
 indices in the outer loop. The `return` should be replaced by a `break` to
 continue looking for a machine for the next index.

 See https://github.com/torproject/tor/pull/1168 for a PR.

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

Re: [tor-bugs] #31110 [Applications/Tor Browser]: Tor Browser is having sex with CPU on Safest security level

2019-07-09 Thread Tor Bug Tracker & Wiki
#31110: Tor Browser is having sex with CPU on Safest security level
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-performance   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 > I think it's due to NoScript.
 Hi, another cypherpunk! It's not so easy to find out, because it's
 reproducible on Standard security level with `javascript.enabled` set to
 `false`.

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

Re: [tor-bugs] #31110 [Applications/Tor Browser]: Tor Browser is having sex with CPU on Safest security level

2019-07-09 Thread Tor Bug Tracker & Wiki
#31110: Tor Browser is having sex with CPU on Safest security level
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-performance   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 I think it's due to NoScript.

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

Re: [tor-bugs] #31110 [Applications/Tor Browser]: Tor Browser is having sex with CPU on Safest security level

2019-07-09 Thread Tor Bug Tracker & Wiki
#31110: Tor Browser is having sex with CPU on Safest security level
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  reopened
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-performance   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by cypherpunks):

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


Comment:

 Hah, professional deformation? When you're looking at some GitHub page,
 e.g. as above, Tor Browser or NoScript (again?) is fucking your CPU.
 (Don't look at Android resources ;) )

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

Re: [tor-bugs] #31110 [Applications/Tor Browser]: Tor Browser is having sex with CPU on Safest security level

2019-07-09 Thread Tor Bug Tracker & Wiki
#31110: Tor Browser is having sex with CPU on Safest security level
--+--
 Reporter:  cypherpunks   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  invalid
 Keywords:  tbb-performance   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 I don't think Android resources play a role 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] #31109 [Circumvention/Snowflake]: Better gamify the UX for snowflake extension

2019-07-09 Thread Tor Bug Tracker & Wiki
#31109: Better gamify the UX for snowflake extension
-+---
 Reporter:  cohosh   |  Owner:  (none)
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:  snowflake-webextension, ux-team  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:  Sponsor28
-+---
Changes (by arlolra):

 * keywords:  snowflake-extension, ux-team => snowflake-webextension, ux-
   team


--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #31110 [Applications/Tor Browser]: Tor Browser is having sex with CPU on Safest security level

2019-07-09 Thread Tor Bug Tracker & Wiki
#31110: Tor Browser is having sex with CPU on Safest security level
-+--
 Reporter:  cypherpunks  |  Owner:  tbb-team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  Applications/Tor Browser
  Version:   |   Severity:  Normal
 Keywords:  tbb-performance  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 When you're looking at https://github.com/sisbell/tor-android-
 service/commit/1513f8d2ccaf99fa9d7e8fe1ae00b1f535697030

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

Re: [tor-bugs] #31047 [Applications/Tor Browser]: Resources Should Exactly Match Orbot

2019-07-09 Thread Tor Bug Tracker & Wiki
#31047: Resources Should Exactly Match Orbot
--+--
 Reporter:  sisbell   |  Owner:  tbb-team
 Type:  defect| Status:  needs_review
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201906  |  Actual Points:
Parent ID:  #31042| Points:
 Reviewer:|Sponsor:
--+--

Comment (by cypherpunks):

 Why not the direct link to https://github.com/sisbell/tor-android-
 service/commit/1513f8d2ccaf99fa9d7e8fe1ae00b1f535697030 and
 `TorBrowserTeam201907R`?

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

Re: [tor-bugs] #28745 [Applications/Tor Browser]: THE Torbutton clean-up

2019-07-09 Thread Tor Bug Tracker & Wiki
#28745: THE Torbutton clean-up
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-torbutton TorBrowserTeam201907R  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by cypherpunks):

 > Refactor code to always use tor-control-port.js
 It's a rewriting, not only refactoring. Should we do it inside the general
 clean-up?

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

Re: [tor-bugs] #31096 [Applications/Tor Browser]: Tor Browser missing NoScript on Linux/Ubuntu version

2019-07-09 Thread Tor Bug Tracker & Wiki
#31096: Tor Browser missing NoScript on Linux/Ubuntu version
--+--
 Reporter:  torlove   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  wontfix
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [comment:2 torlove]:
 > The icon was never there in the first place. Whereas it is for other
 implementations that I've seen. This in theory could create a
 fingerprinting problem based on the os? (Yes I know that using NoScript
 may create it's own fingerprinting problem).

 No, websites don't have access to the toolbar. So, it should be fine
 whether you have or have not icons on the toolbar.

 > Is NoScript being dropped from the toolbar?

 Yes. For the full proposal behind this, see: https://gitweb.torproject.org
 /tor-browser-spec.git/tree/proposals/101-security-controls-redesign.txt

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