Re: [tor-bugs] #26543 [Circumvention/BridgeDB]: Provide a language switcher menu on BridgeDB

2019-10-10 Thread Tor Bug Tracker & Wiki
#26543: Provide a language switcher menu on BridgeDB
-+-
 Reporter:  teor |  Owner:  phw
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  anti-censorship-roadmap-september,   |  Actual Points:
  s30-o22a3  |
Parent ID:  #31279   | Points:  3
 Reviewer:  cohosh   |Sponsor:
 |  Sponsor30-must
-+-

Comment (by emmapeel):

 Also, the Tier 1 languages are available at
 https://storm.torproject.org/shared/o7Rh2S9bsMNN7Eh7C9cKaqxR371pR1AmpRxbu
 --nC34

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

Re: [tor-bugs] #26543 [Circumvention/BridgeDB]: Provide a language switcher menu on BridgeDB

2019-10-10 Thread Tor Bug Tracker & Wiki
#26543: Provide a language switcher menu on BridgeDB
-+-
 Reporter:  teor |  Owner:  phw
 Type:  enhancement  | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Circumvention/BridgeDB   |Version:
 Severity:  Normal   | Resolution:
 Keywords:  anti-censorship-roadmap-september,   |  Actual Points:
  s30-o22a3  |
Parent ID:  #31279   | Points:  3
 Reviewer:  cohosh   |Sponsor:
 |  Sponsor30-must
-+-

Comment (by emmapeel):

 Replying to [comment:21 phw]:
 > Regarding the languages that are at least 80% complete: these are >=80%
 ''reviewed'' and not >=80% ''translated'', right? If we go down that
 route, we would be giving up several languages that are (almost) entirely
 translated but not sufficiently reviewed, like Russian, or Persian. Do we
 really want this?
 Unfortunately we dont have many reviewed translations. I was talking about
 translated strings only.

 This is an issue also on the translation platform, because once strings
 are reviewed, the suggested changes to them are hard to notice and the
 strings cannot be changed by people without the reviewer status. I am
 trying to get more strings reviewed but it is unfortunately going slow for
 many languages. Also we need more trusted reviewers in all languages.

 Russian is the second most downloaded locale after English... so I think
 it will be a pity to lose 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] #31747 [Applications/Tor Browser]: Some browser UI is always shown in English

2019-10-10 Thread Tor Bug Tracker & Wiki
#31747: Some browser UI is always shown in English
-+-
 Reporter:  acat |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  reopened
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr tbb-9.0-must-alpha  |  Actual Points:  1
  TorBrowserTeam201910R, GeorgKoppen201910R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by acat):

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


Comment:

 One more fixup for mk locale:
 https://github.com/acatarineu/torbutton/commit/31747+3. Strings from
 https://share.riseup.net/#k1gL4rYC9_ksqY35EyOvzA.

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

Re: [tor-bugs] #31747 [Applications/Tor Browser]: Some browser UI is always shown in English

2019-10-10 Thread Tor Bug Tracker & Wiki
#31747: Some browser UI is always shown in English
-+-
 Reporter:  acat |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr tbb-9.0-must-alpha  |  Actual Points:  1
  TorBrowserTeam201910R, GeorgKoppen201910R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by acat):

 * status:  reopened => 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] #31747 [Applications/Tor Browser]: Some browser UI is always shown in English

2019-10-10 Thread Tor Bug Tracker & Wiki
#31747: Some browser UI is always shown in English
-+-
 Reporter:  acat |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff68-esr tbb-9.0-must-alpha  |  Actual Points:  1
  TorBrowserTeam201910R, GeorgKoppen201910R  |
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Looks good. Cherry-picked to `master` (commit
 1fb06b910d8e896084d3c515e26cf11b1b95b858).

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

Re: [tor-bugs] #15949 [Internal Services/Service - git]: Can we migrate internal SVN to a document store, wiki, or set of git repositories?

2019-10-10 Thread Tor Bug Tracker & Wiki
#15949: Can we migrate internal SVN to a document store, wiki, or set of git
repositories?
-+-
 Reporter:  nickm|  Owner:  tor-gitadm
 Type:  defect   | Status:
 |  needs_information
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #17202   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Note that I'm going to treat this ticket as being what it says it's about
 in the ticket description -- svninternal, not corpsvn.

 I believe I am the only user of svninternal at this point, either reading
 or writing. And I'm fine stopping my use of it if it simplifies things for
 others.

 So I believe that we can turn it off as a service, so long as we keep the
 files around for the future "sorting and filing and discarding" exercise
 that we're going to need to do.

 When we get to that sorting step, we might decide to dump the files into
 nextcloud en masse to start, or we might decide to do some triaging on
 them first and only import the ones we want to import. We should stick the
 files somewhere and open a new ticket for that triaging, once we turn off
 the svninternal service.

 Also, when we do turn off svninternal, we can disable the tor-
 svninter...@lists.tpo list which is where commits get sent currently.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32025 [Internal Services/Service - git]: Stop using corpsvn and disable it as a service

2019-10-10 Thread Tor Bug Tracker & Wiki
#32025: Stop using corpsvn and disable it as a service
-+
 Reporter:  arma |  Owner:  tor-gitadm
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:  #17202
   Points:   |   Reviewer:
  Sponsor:   |
-+
 In #17202 we're going to decommission the server that runs our various svn
 services.

 We have a plan for the public svn.tpo service: #15948

 and we are making a plan for svninternal: #15949

 That leaves corpsvn, which I think is the most actively used still -- for
 example our accounting folks use it. This ticket is about making and
 finishing the plan for shutting down the corpsvn service.

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

Re: [tor-bugs] #17202 [Internal Services/Tor Sysadmin Team]: Shut down SVN and decomission the host (gayi)

2019-10-10 Thread Tor Bug Tracker & Wiki
#17202: Shut down SVN and decomission the host (gayi)
-+-
 Reporter:  nickm|  Owner:  (none)
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #31686   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 Ok, I added #32025, for the third prong of this task: retiring corpsvn.

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

Re: [tor-bugs] #32025 [Internal Services/Service - git]: Stop using corpsvn and disable it as a service

2019-10-10 Thread Tor Bug Tracker & Wiki
#32025: Stop using corpsvn and disable it as a service
-+
 Reporter:  arma |  Owner:  tor-gitadm
 Type:  project  | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Service - git  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #17202   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by arma):

 On the plus side, I think we're much closer to being able to do this
 ticket now, since the main person who puts things into corpsvn these days
 is Sue, and I suspect she just commits things to have them somewhere for
 posterity, i.e. she isn't using any of the actual revision control
 features.

 So if we froze the corpsvn repo and gave her new instructions on where to
 send new things (probably Nextcloud), I bet we'd have a good start here.

 She would still need to reference a checkout of corpsvn e.g. for giving
 documents to the auditors, but she probably has one on her laptop, so
 maybe "being available to help her if that checkout breaks" is a win over
 "need to keep corpsvn going as a service".

 There might be other folks who still use their copy of corpsvn in a read-
 only kind of way. Maybe that's Erin. Or more? We need to ask the
 operations team.

 Then we would have a next task which is "triage and sort the current
 corpsvn files, probably by category, and do something smart with them" but
 in theory that step can be orthogonal to shutting down the corpsvn
 service.

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

Re: [tor-bugs] #30429 [Applications/Tor Browser]: Rebase Tor Browser patches for Firefox ESR 68

2019-10-10 Thread Tor Bug Tracker & Wiki
#30429: Rebase Tor Browser patches for Firefox ESR 68
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  task | Status:
 |  needs_review
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201910R  |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by gk):

 Replying to [comment:2 acat]:

 [snip]

 > 2eb11a17e593 Bug 16439: remove screencasting code. --- [Investigate, is
 'secondscreen/RokuApp.jsm' and 'secondscreen/SimpleServiceDiscovery.jsm'
 only used in Android now? or is there a different mechanism for desktop?]

 Desktop support just got ripped out, see:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1393582 we should probably
 adjust the commit message of that commit accordingly while we are at it
 (we forgot to do so for esr60 it seems).

 [snip]

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

Re: [tor-bugs] #32018 [Applications/Quality Assurance and Testing]: Remove unicode Character 'NO-BREAK SPACE' (U+00A0) from fp-central/run.py

2019-10-10 Thread Tor Bug Tracker & Wiki
#32018: Remove unicode Character 'NO-BREAK SPACE' (U+00A0) from 
fp-central/run.py
-+-
 Reporter:  boklm|  Owner:  boklm
 Type:  defect   | Status:  closed
 Priority:  Low  |  Milestone:
Component:  Applications/Quality Assurance and   |Version:
  Testing|
 Severity:  Minor| Resolution:  fixed
 Keywords:  fpcentral, TorBrowserTeam201910R,|  Actual Points:  0.1
  boklm201910|
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Replying to [comment:1 boklm]:
 > There is a patch in my branch `bug_32018`:
 >
 
https://gitweb.torproject.org/user/boklm/fpcentral.git/commit/?h=bug_32018&id=aee05b9a67d1127920b07de65598b4302e2d88d5

 Looks good. Merged to `master` (commit
 aee05b9a67d1127920b07de65598b4302e2d88d5).

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

Re: [tor-bugs] #30665 [Applications/Tor Browser]: Get Firefox 68 ESR Working with latest android toolchain

2019-10-10 Thread Tor Bug Tracker & Wiki
#30665: Get Firefox 68 ESR Working with latest android toolchain
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  alpha, TorBrowserTeam201910|
Parent ID:  #30324   | Points:  2
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-
Changes (by gk):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:22 sisbell]:
 > I verified that we no longer need the armv7 clang.so copy with the
 latest code. Also removed patch from config.
 >
 > https://github.com/sisbell/tor-browser-
 build/commit/24b8dd8a93b4960888cb269446058de711b94b04

 Thanks. I started to look at the other two patches you added. Why do we
 have the `android-packages.patch`? First of all we don't use `android-
 packages.txt` in our build. Then the `doc` package got added because the
 build *required* a network connection before which caused bugs. Thus, we
 should not be affected by having the `doc` package added in our setup
 given that we build offline. So, it seems to me we can drop this patch,
 too. A test build seems to support that.

 Why do we need the other patch? (apart from making the build not break) Is
 there something wrong with how we set up our toolchain? Is that a bug in
 Mozilla's configure code?

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

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

2019-10-10 Thread Tor Bug Tracker & Wiki
#30786: Ship Thai  Tor Browser in alpha series
--+--
 Reporter:  emmapeel  |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201910  |  Actual Points:
Parent ID:  #29935| Points:  0.25
 Reviewer:|Sponsor:
--+--

Comment (by emmapeel):

 ey there!

 the translators translated TBB in June, it can be a little demotivating to
 wait so long to see their results, is there a way to speed the addition of
 this translation, at least in alpha?

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

Re: [tor-bugs] #30665 [Applications/Tor Browser]: Get Firefox 68 ESR Working with latest android toolchain

2019-10-10 Thread Tor Bug Tracker & Wiki
#30665: Get Firefox 68 ESR Working with latest android toolchain
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  alpha, TorBrowserTeam201910|
Parent ID:  #30324   | Points:  2
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by gk):

 Oh, and if we really need to patch Firefox's source code here, please add
 the patch to the `tor-browser` repository. (For which we went differently
 with the other patch you just dropped, see: #29843)

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

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

2019-10-10 Thread Tor Bug Tracker & Wiki
#30786: Ship Thai  Tor Browser in alpha series
--+--
 Reporter:  emmapeel  |  Owner:  tbb-team
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  TorBrowserTeam201910  |  Actual Points:
Parent ID:  #29935| Points:  0.25
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [comment:8 emmapeel]:
 > ey there!
 >
 > the translators translated TBB in June, it can be a little demotivating
 to wait so long to see their results, is there a way to speed the addition
 of this translation, at least in alpha?

 Yes, there is. It would greatly speed up the process if you or someone
 else provided a patch for review, ideally with bundles built for all
 supported platforms.

 We plan to do exactly that once the 9.5 alpha cycle starts and the 9.0
 dust has settled. If you get to it earlier, please do.

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

Re: [tor-bugs] #30665 [Applications/Tor Browser]: Get Firefox 68 ESR Working with latest android toolchain

2019-10-10 Thread Tor Bug Tracker & Wiki
#30665: Get Firefox 68 ESR Working with latest android toolchain
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  alpha, TorBrowserTeam201910|
Parent ID:  #30324   | Points:  2
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by sisbell):

 The emulator would be used when executing

 {{{
 mach install
 mach run
 }}}

 this installs/deploys the apk to an emulator, which we don't need to do.

 So the solution would be to create a patch the removes emulator check in
 firefox or to debug and find out why the build can't find the emulator,
 which we don't use. The code seems like it should find the emulator since
 its located in the android-toolchain. I didn't think it was worth digging
 into very much.

 I think you are right the android-packages patch can go away. I'll remove
 that.

 Replying to [comment:23 gk]:
 > Replying to [comment:22 sisbell]:
 > > I verified that we no longer need the armv7 clang.so copy with the
 latest code. Also removed patch from config.
 > >
 > > https://github.com/sisbell/tor-browser-
 build/commit/24b8dd8a93b4960888cb269446058de711b94b04
 >
 > Thanks. I started to look at the other two patches you added. Why do we
 have the `android-packages.patch`? First of all we don't use `android-
 packages.txt` in our build. Then the `doc` package got added because the
 build *required* a network connection before which caused bugs. Thus, we
 should not be affected by having the `doc` package added in our setup
 given that we build offline. So, it seems to me we can drop this patch,
 too. A test build seems to support that.
 >
 > Why do we need the other patch? (apart from making the build not break)
 Is there something wrong with how we set up our toolchain? Is that a bug
 in Mozilla's configure code?

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

Re: [tor-bugs] #30665 [Applications/Tor Browser]: Get Firefox 68 ESR Working with latest android toolchain

2019-10-10 Thread Tor Bug Tracker & Wiki
#30665: Get Firefox 68 ESR Working with latest android toolchain
-+-
 Reporter:  sisbell  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-rbm, ff68-esr, tbb-9.0-must- |  Actual Points:
  alpha, TorBrowserTeam201910|
Parent ID:  #30324   | Points:  2
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by sisbell):

 I see that the code is checking that the emulator is directly under the
 sdk_directory, while its packaged under sdk/tools directory. I can see if
 a simple move of the emulator to the sdk root directory will fix the
 emulator check.

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

Re: [tor-bugs] #18862 [Applications/Tor Browser]: Make sure the Presentation API is no risk for our users

2019-10-10 Thread Tor Bug Tracker & Wiki
#18862: Make sure the Presentation API is no risk for our users
--+--
 Reporter:  gk|  Owner:  tbb-team
 Type:  defect| Status:  assigned
 Priority:  High  |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff68-esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

 * keywords:  ff60-esr => ff68-esr


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

Re: [tor-bugs] #31144 [Applications/Tor Browser]: ESR68 Network Code Review

2019-10-10 Thread Tor Bug Tracker & Wiki
#31144: ESR68 Network Code Review
-+-
 Reporter:  pili |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201910, tbb-9.0|  Actual Points:
  -alpha-must|
Parent ID:   | Points:  10
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:7 mikeperry]:
 > Ok, I'm wrapping this up. I have the following questions/observations
 first:
 > 1. ./devtools/shared/discovery/discovery.js uses UDP multicast for
 debugger discovery. This should only be local network, but maybe we should
 disable it anyway. Do we?

 It seems we disabled that via pref (see: comment:7:ticket:18546 and
 comment:10:ticket:16222). We should make sure this still works.

 > 2. ./dom/presentation/PresentationTCPSessionTransport.cpp seems to use
 TCP for app-to-app communication. Do we disable the DOM presentation
 stuff?

 We have #18862 for that Arthur checked back then that the prefs are
 disabling everything. They are still set to `false` for desktop. We had
 #22165 as well which got upstreamed meanwhile.

 I am not exactly sure what we did when Tor Browser on Android entered the
 picture. sysrqb: did you look at that?

 > 3. ./toolkit/modules/secondscreen/RokuApp.jsm also makes connections..
 ISTR disabling this? Is it off?

 I think it is. We had #16439 for that and are not including `RokuApp.jsm`
 and `SimpleServiceDiscovery.jsm` in our code (it's mobile only since
 https://bugzilla.mozilla.org/show_bug.cgi?id=1393582 landed and there even
 governed by a pref we set to `false`)

 > 4. For Rust, I found sendmsg and recvmsg only in mio and audioipc. I
 think this is fine? (I am asking about those two because Ritter's tool
 whitelisted them and I wanna double check).



 > 5. Otherwise has Ritter's network symbol tool been run on FF68ESR for
 Rust?

 I don't think so. I thought that would be a nice thing to do during the
 network code review.

 I leave the (other) mobile questions to sysrqb.

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

Re: [tor-bugs] #31144 [Applications/Tor Browser]: ESR68 Network Code Review

2019-10-10 Thread Tor Bug Tracker & Wiki
#31144: ESR68 Network Code Review
-+-
 Reporter:  pili |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201910, tbb-9.0|  Actual Points:
  -alpha-must|
Parent ID:   | Points:  10
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:8 gk]:
 > Replying to [comment:7 mikeperry]:
 > > Ok, I'm wrapping this up. I have the following questions/observations
 first:
 > > 1. ./devtools/shared/discovery/discovery.js uses UDP multicast for
 debugger discovery. This should only be local network, but maybe we should
 disable it anyway. Do we?
 >
 > It seems we disabled that via pref (see: comment:7:ticket:18546 and
 comment:10:ticket:16222). We should make sure this still works.
 >
 > > 2. ./dom/presentation/PresentationTCPSessionTransport.cpp seems to use
 TCP for app-to-app communication. Do we disable the DOM presentation
 stuff?
 >
 > We have #18862 for that Arthur checked back then that the prefs are
 disabling everything. They are still set to `false` for desktop. We had
 #22165 as well which got upstreamed meanwhile.
 >
 > I am not exactly sure what we did when Tor Browser on Android entered
 the picture. sysrqb: did you look at that?

 It seems we flipped the prefs there explicitly, so we should be good, I
 guess. sysrqb: I guess that's something we can move to the non-mobile
 specific prefs file as that beast should be disabled for all platforms.

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

Re: [tor-bugs] #31882 [Core Tor/Tor]: move Android build config into core tor

2019-10-10 Thread Tor Bug Tracker & Wiki
#31882: move Android build config into core tor
-+
 Reporter:  eighthave|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, tbb-mobile  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by eighthave):

 * Attachment "0002-move-Android-build-setup-into-enable-android-
 flag.patch" added.


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

Re: [tor-bugs] #31882 [Core Tor/Tor]: move Android build config into core tor

2019-10-10 Thread Tor Bug Tracker & Wiki
#31882: move Android build config into core tor
-+
 Reporter:  eighthave|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, tbb-mobile  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by eighthave):

 * Attachment "0001-use-standard-__ANDROID__-macro-for-detecting-
 Android.patch" added.


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

Re: [tor-bugs] #31882 [Core Tor/Tor]: move Android build config into core tor

2019-10-10 Thread Tor Bug Tracker & Wiki
#31882: move Android build config into core tor
-+
 Reporter:  eighthave|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, tbb-mobile  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by eighthave):

 * Attachment "0003-Android-s-logging-mechanism-is-called-logcat.patch"
 added.


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

Re: [tor-bugs] #31882 [Core Tor/Tor]: move Android build config into core tor

2019-10-10 Thread Tor Bug Tracker & Wiki
#31882: move Android build config into core tor
-+
 Reporter:  eighthave|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, tbb-mobile  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by eighthave):

 * Attachment "0004-gitlab-ci-purge-old-job-for-mirroring-its-unused-
 and.patch" added.


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

Re: [tor-bugs] #31882 [Core Tor/Tor]: move Android build config into core tor

2019-10-10 Thread Tor Bug Tracker & Wiki
#31882: move Android build config into core tor
-+
 Reporter:  eighthave|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, tbb-mobile  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by eighthave):

 * Attachment "0005-gitlab-ci-add-Debian-testing-and-ubuntu-LTS.patch"
 added.


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

Re: [tor-bugs] #31882 [Core Tor/Tor]: move Android build config into core tor

2019-10-10 Thread Tor Bug Tracker & Wiki
#31882: move Android build config into core tor
-+
 Reporter:  eighthave|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, tbb-mobile  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by eighthave):

 * Attachment "0006-gitlab-ci-add-barebones-Android-job-as-
 smokecheck.patch" added.


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

Re: [tor-bugs] #31561 [Core Tor/Tor]: hs-v3: Service can keep unused intro points in its list

2019-10-10 Thread Tor Bug Tracker & Wiki
#31561: hs-v3: Service can keep unused intro points in its list
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, hv-v3, 042-should  |  Actual Points:  0.1
Parent ID:  #30200 | Points:  0.2
 Reviewer:  asn|Sponsor:  Sponsor27-must
---+---
Changes (by asn):

 * status:  merge_ready => needs_revision
 * cc: mikeperry (added)


Comment:

 Replying to [comment:13 nickm]:
 > I'm concerned that this patch makes `purpose ==
 CIRCUIT_PURPOSE_HS_VANGUARDS` count as both a client purpose and a service
 purpose.  Won't that result in us sometimes calling
 `hs_service_circuit_timed_out` on a client circuit?

 Hmm, there is indeed a bug here! Thanks for catching that, and sorry for
 missing that.

 `CIRCUIT_PURPOSE_HS_VANGUARDS` is the purpose that Tor uses to pre-built
 vanguard circuits '''before''' they are used by the vanguard subsystem for
 specific HS-related purposes (they can be used for HS client or for HS
 service activities).

 However, while the circuit is in this vanguards purpose, it shouldn't have
 any duties as an HS circuit (i.e. be an active intro circuit) and hence we
 shouldn't call `hs_service_circuit_timed_out()` on it.

 Vanguards circuits are taken into account in the
 `circuit_purpose_is_hidden_service()` function because it is used by the
 vanguard subsystem to take decision about vanguards; but for our use case
 it's safe to ignore vanguard circuits.

 So takeaways and plans for the patch:
 a) The `circuit_purpose_is_hidden_service()` should remain as is
 (behavior-wise) because it's used (correctly) by the vanguard subsystem.
 But IMO the name is a bit misleading because IIUC vanguard circuits don't
 have active hidden service duties, but they can be repurposed to HS circs
 in the future.
 b) Our new function `circuit_purpose_is_hs_service()` should not take into
 account vanguard circuits since we only care about active onion service
 circs. Perhaps `circuit_purpose_is_hidden_service()` can use our new
 function to avoid code dedup.
 c) Let's ask Mike if he agrees with the above.

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

Re: [tor-bugs] #31741 [Community/Tor Support]: Tor2Web blocks access

2019-10-10 Thread Tor Bug Tracker & Wiki
#31741: Tor2Web blocks access
---+---
 Reporter:  TheCurve   |  Owner:  hiro
 Type:  defect | Status:  needs_information
 Priority:  Low|  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---

Comment (by TheCurve2):

 ah. Sorry for the delayed reply. It ends in onion.to

 I guess I will have to search for the original page.

 Thanks for your help though :)

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

Re: [tor-bugs] #31882 [Core Tor/Tor]: move Android build config into core tor

2019-10-10 Thread Tor Bug Tracker & Wiki
#31882: move Android build config into core tor
-+
 Reporter:  eighthave|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, tbb-mobile  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by eighthave):

 Attached is the patch series to implement this all on top of ''master''.
 ''0003-Android-s-logging-mechanism-is-called-logcat.patch'' and the
 gitlab-ci patches could be omitted if it delays merging the first 2.

 In order to make sure I didn't mess up `./configure` on other platforms, I
 added tests to ''.gitlab-ci.yml'' for lots of GNU/Linux distros (the MinGW
 job isn't quite working yet, so ignore its failure).  You can see a full
 run here:
 https://gitlab.com/eighthave/tor/pipelines/87935658

 I'm happy to submit the rest of the ''.gitlab-ci.yml'' changes as desired.
 You can see them in my gitlab fork.

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

Re: [tor-bugs] #31882 [Core Tor/Tor]: move Android build config into core tor

2019-10-10 Thread Tor Bug Tracker & Wiki
#31882: move Android build config into core tor
-+
 Reporter:  eighthave|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, tbb-mobile  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by eighthave):

 * Attachment "0002-move-Android-build-setup-into-enable-android-
 flag.patch" added.


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

Re: [tor-bugs] #31882 [Core Tor/Tor]: move Android build config into core tor

2019-10-10 Thread Tor Bug Tracker & Wiki
#31882: move Android build config into core tor
-+
 Reporter:  eighthave|  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, tbb-mobile  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by eighthave):

 * 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] #32019 [Applications/Tor Browser]: TB9: Address bar and hotkey broken if homepage is about:blank

2019-10-10 Thread Tor Bug Tracker & Wiki
#32019: TB9: Address bar and hotkey broken if homepage is about:blank
-+-
 Reporter:  rustybird|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, AffectsTails,  |  Actual Points:
  TorBrowserTeam201910, GeorgKoppen201910|
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by rustybird):

 Setting `data:,` as the homepage just now happened to still trigger the
 bug, so it really doesn't look like it's `about:blank` specific - just
 more likely in that case. (I don't think I'm allowed to edit the ticket
 title)

 `browser.urlbar.quantumbar=false` has been working good so far.

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

Re: [tor-bugs] #32019 [Applications/Tor Browser]: TB9: Address bar and hotkey broken (was: TB9: Address bar and hotkey broken if homepage is about:blank)

2019-10-10 Thread Tor Bug Tracker & Wiki
#32019: TB9: Address bar and hotkey broken
-+-
 Reporter:  rustybird|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, AffectsTails,  |  Actual Points:
  TorBrowserTeam201910, GeorgKoppen201910|
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by gk):

 Replying to [comment:5 rustybird]:
 > Setting `data:,` as the homepage just now happened to still trigger the
 bug, so it really doesn't look like it's `about:blank` specific - just
 more likely in that case. (I don't think I'm allowed to edit the ticket
 title)
 >
 > `browser.urlbar.quantumbar=false` has been working good so far.

 Does this bug happen reliably for you? Or am I right in my assumption that
 it is happening sometimes/often but that we don't have steps to repro it
 100%?

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

Re: [tor-bugs] #32019 [Applications/Tor Browser]: TB9: Address bar and hotkey broken

2019-10-10 Thread Tor Bug Tracker & Wiki
#32019: TB9: Address bar and hotkey broken
-+-
 Reporter:  rustybird|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, AffectsTails,  |  Actual Points:
  TorBrowserTeam201910, GeorgKoppen201910|
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by intrigeri):

 Replying to [comment:6 gk]:
 > Does this bug happen reliably for you? Or am I right in my assumption
 that it is happening sometimes/often but that we don't have steps to repro
 it 100%?

 FWIW, in Tails' context it happens very reliably on slower systems, and
 very rarely (or never at all) on faster ones. Sounds like a race condition
 to me.

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

Re: [tor-bugs] #31286 [Applications/Tor Browser]: Include bridge configuration into about:preferences

2019-10-10 Thread Tor Bug Tracker & Wiki
#31286: Include bridge configuration into about:preferences
-+-
 Reporter:  gk   |  Owner:
 |  pospeselr
 Type:  task | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-alpha, ff68-esr, ux-|  Actual Points:
  team, TorBrowserTeam201910 |
Parent ID:  #10760   | Points:  15
 Reviewer:   |Sponsor:
 |  Sponsor44-can
-+-

Comment (by antonela):

 Replying to [comment:30 steph]:
 > Suggestions for copy changes:
 >
 > "Tor Browser routes your traffic over the Tor Network, run by thousands
 of volunteers around the world."
 >
 > "Bridges help you access the Tor Network in places where Tor is blocked.
 Depending on where you are, one bridge may work better than another." (cut
 the following dummy text sentence)
 >
 > "Provide a bridge" (cut "I know")

 Thanks steph! Those suggestions are great. Pospeselr, let me know when
 those strings get published so we let emmapeel know about it. Thanks!

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

Re: [tor-bugs] #31768 [Applications/Tor Browser]: Introduce Tor network settings and other updates in TB9 onboarding

2019-10-10 Thread Tor Bug Tracker & Wiki
#31768: Introduce Tor network settings and other updates in TB9 onboarding
-+-
 Reporter:  antonela |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_revision
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.0-must-alpha, |  Actual Points:
  TorBrowserTeam201910, tbb-onboarding   |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

 * keywords:  ux-team, tbb-9.0-must-alpha, TorBrowserTeam201910R, tbb-
 onboarding => ux-team, tbb-9.0-must-alpha, TorBrowserTeam201910, tbb-
 onboarding
 * status:  needs_review => needs_revision


Comment:

 Two things I've found while testing:
 1) The security item should lose its "New" flag. That feature was new in
 8.5 but is not in 9.0
 2) I think requesting a New Identity should be done via the toolbar
 button, for two reasons: a) we are showing the toolbar + the icon on the
 onboarding card. It seems weird doing that and then using a menuitem
 instead of requesting a New Identity. b) the preferred way of requesting a
 New Identity is likely via the toolbar as this requires less clicks. Thus,
 we should teach the users to use that one instead of the backup option via
 the menu.

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

Re: [tor-bugs] #31882 [Core Tor/Tor]: move Android build config into core tor

2019-10-10 Thread Tor Bug Tracker & Wiki
#31882: move Android build config into core tor
-+
 Reporter:  eighthave|  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  Android, tbb-mobile  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by eighthave):

 The last piece, which is not implemented in the patches, is making the
 output filename be ''libtor.so''.  There is currently no support for
 different output file names in ''Makefile.am'' so it would be non-trivial
 to implement, and I'm not sure the approach that should be taken.

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

Re: [tor-bugs] #32019 [Applications/Tor Browser]: TB9: Address bar and hotkey broken

2019-10-10 Thread Tor Bug Tracker & Wiki
#32019: TB9: Address bar and hotkey broken
-+-
 Reporter:  rustybird|  Owner:  tbb-
 |  team
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ff68-esr, AffectsTails,  |  Actual Points:
  TorBrowserTeam201910, GeorgKoppen201910|
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by rustybird):

 Replying to [comment:6 gk]:
 > Does this bug happen reliably for you?

 With `about:tor`, `data:,` or a `file://` homepage (the latter is the
 default on Whonix Workstation), it only happens sometimes.
 `TOR_SKIP_LAUNCH=1` seems to increase the chance. OTOH `about:blank` has
 triggered it 100% of the times I went through the steps in the ticket
 description.

 Replying to [comment:7 intrigeri]:
 > FWIW, in Tails' context it happens very reliably on slower systems, and
 very rarely (or never at all) on faster ones. Sounds like a race condition
 to me.

 Yeah, my system is also rather slow...

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

Re: [tor-bugs] #29164 [Applications/Tor Browser]: with dark desktop theme: unreadable guard text: coloured white with bright grey background

2019-10-10 Thread Tor Bug Tracker & Wiki
#29164: with dark desktop theme: unreadable guard text: coloured white with 
bright
grey background
--+--
 Reporter:  pabs  |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Low   |  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Minor | Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:  #31778| Points:
 Reviewer:|Sponsor:
--+--
Changes (by gk):

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


Comment:

 Fixed in the parent, closing.

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

Re: [tor-bugs] #31778 [Applications/Tor Browser]: Support default dark-theme for the Circuit Display UI

2019-10-10 Thread Tor Bug Tracker & Wiki
#31778: Support default dark-theme for the Circuit Display UI
-+-
 Reporter:  antonela |  Owner:  tbb-
 |  team
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  ff68-esr, tbb-9.0-must-alpha, ux-|  Actual Points:  1.1
  team, TorBrowserTeam201910R|
Parent ID:   | Points:  1
 Reviewer:  antonela |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Looks good to me, nice work. Cherry-picked to `master` (commit
 ad8abfab6030a92d3893166f0ba3bc33b186122).  Should be available in
 tomorrow's nightly builds.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32026 [Circumvention/Censorship analysis]: Using An Alternative To TCP To Avoid Packet Injection?

2019-10-10 Thread Tor Bug Tracker & Wiki
#32026: Using An Alternative To TCP To Avoid Packet Injection?
-+-
 Reporter:   |  Owner:  (none)
  Aphrodites1995 |
 Type:  enhancement  | Status:  new
 Priority:  Medium   |  Component:  Circumvention/Censorship
 |  analysis
  Version:   |   Severity:  Normal
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
 According to https://www.cs.tufts.edu/comp/116/archive/fall2016/ctang.pdf
 , the GFW only injects packets, mostly TCP RST signals. What if TOR has
 bridges/servers that do not respond to TCP RST? This would render the
 connection interfering part of GFW useless. Here, a connection ends only
 when both sides send a "END" signal to the other side with their private
 key for the connection only that is shared through the connection. We
 don't even need to obfuscate TOR traffic anymore as the packets are not
 blocked. With the DNS inspection, we could have IPs for bridges/servers,
 which do the DNS queries on non censored DNS 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] #31741 [Community/Tor Support]: Tor2Web blocks access

2019-10-10 Thread Tor Bug Tracker & Wiki
#31741: Tor2Web blocks access
---+---
 Reporter:  TheCurve   |  Owner:  hiro
 Type:  defect | Status:  closed
 Priority:  Low|  Milestone:
Component:  Community/Tor Support  |Version:
 Severity:  Normal | Resolution:  not a bug
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+---
Changes (by ggus):

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


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

Re: [tor-bugs] #13543 [Applications/Tor Browser]: HTML5 media support may lead to fingerprinting

2019-10-10 Thread Tor Bug Tracker & Wiki
#13543: HTML5 media support may lead to fingerprinting
-+-
 Reporter:  cypherpunks  |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-fingerprinting, ff68-esr,|  Actual Points:
  TorBrowserTeam201910R, tbb-9.0-must|
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by acat):

 * keywords:  tbb-fingerprinting, ff68-esr, TorBrowserTeam201910,
 tbb-9.0-must => tbb-fingerprinting, ff68-esr, TorBrowserTeam201910R,
 tbb-9.0-must
 * status:  new => needs_review


Comment:

 For review: https://github.com/acatarineu/tor-browser/commit/13543

 This should skip checking for hardware acceleration or performing a
 benchmark when RFP is enabled, and always set `smooth = true` and
 `powerEfficient = true` instead. I only modified one case, since AFAIK
 it's the only one where the value `smooth` or `powerEfficient` depend on
 hardware capabilities.

 The intent was to implement the solution mentioned in
 https://bugzilla.mozilla.org/show_bug.cgi?id=1461454#c6.

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

Re: [tor-bugs] #21140 [Internal Services/Services Admin Team]: Document the distinction between sys admin and service admin

2019-10-10 Thread Tor Bug Tracker & Wiki
#21140: Document the distinction between sys admin and service admin
-+-
 Reporter:  arma |  Owner:  hiro
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

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


Comment:

 hehe, yeah, i guess I figured out the distinction. i did take another stab
 at the document and expanded on it and reformated it a little. i think
 it's alright now, and that this can be closed. since you opened the
 ticket, i figured you were in a good position to know if it's good or not,
 but since you asked, i'll just close the 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] #31910 [Applications/Tor Browser]: replace meek_lite with meek in circuit display

2019-10-10 Thread Tor Bug Tracker & Wiki
#31910: replace meek_lite with meek in circuit display
-+-
 Reporter:  mcs  |  Owner:  mcs
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  meek, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201910R, ux-team |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * keywords:  meek, tbb-9.0-must-alpha, TorBrowserTeam201910, ux-team =>
 meek, tbb-9.0-must-alpha, TorBrowserTeam201910R, ux-team
 * status:  assigned => needs_review


Comment:

 For now, we should do the simple thing and restore "Bridge: meek" (so
 users see the same thing in TB 9.0 as they do in 8.5). Here is a patch:
 
https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug31910-01&id=71bb89e923be7be2388ce77684a06c7782f7a6f4

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

Re: [tor-bugs] #31261 [Internal Services/Services Admin Team]: cleanup services inventories in the wiki

2019-10-10 Thread Tor Bug Tracker & Wiki
#31261: cleanup services inventories in the wiki
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Services Admin |Version:
  Team   |
 Severity:  Normal   | Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

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


Comment:

 marked the hosts page as deprecated, it seems like a lost cause and
 covered by the hardware inventory problem described in #30273.

 i think we're all done here, closing.

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

Re: [tor-bugs] #31683 [Core Tor/Tor]: md: Bad family line in cached-microdescs.new

2019-10-10 Thread Tor Bug Tracker & Wiki
#31683: md: Bad family line in cached-microdescs.new
---+
 Reporter:  dgoulet|  Owner:  nickm
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  microdesc, 042-should  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by nickm):

 Musing aloud:

 I'm trying to make sense of this and of #31364, which I strongly suspect
 have the same underlying cause.

 In both cases, it's microdescriptors, and it's the journal, not the cache.

 In both cases, it looks like we have started writing at the wrong point in
 the file: here, it seems we've started in the middle of another
 microdescriptor, and in #31364, it looks like we've seeked to a point
 after the end of the file.

 This makes me kind of suspect that our fake O_APPEND implementation in
 start_writing_to_file() might have something to do with this.  Or maybe
 something is doing concurrent modifications on the microdescriptors
 journal.

 Next to investigate: why do we not observe this with routerdescs?  Are we
 more tolerant of errors in cached_descriptors.new, or is there an
 important difference in the code?  If this is a concurrent modification
 problem, what could be causing 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] #31781 [Internal Services/Tor Sysadmin Team]: ping on new VMs

2019-10-10 Thread Tor Bug Tracker & Wiki
#31781: ping on new VMs
-+-
 Reporter:  weasel   |  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:
-+-
Changes (by anarcat):

 * status:  new => needs_information


Comment:

 I'm not sure how this happened on loghost, but it didn't happen on bacula-
 director-01, as created in #31786 (which has the detailed commandline used
 in the creation).

 {{{
 root@bacula-director-01:~# /sbin/getcap /usr/bin/ping
 /usr/bin/ping = cap_net_raw+ep
 root@bacula-director-01:~# stat /usr/bin/ping
   Fichier : /usr/bin/ping
Taille : 65272   Blocs : 128Blocs d'E/S : 4096   fichier
 Périphérique : 801h/2049d   Inœud : 137498  Liens : 1
 Accès : (0755/-rwxr-xr-x)  UID : (0/root)   GID : (0/root)
  Accès : 2019-10-03 20:31:00.957049432 +
 Modif. : 2018-08-03 16:53:09.0 +
 Changt : 2019-10-03 20:30:49.057153189 +
   Créé : -
 root@bacula-director-01:~#
 }}}

 On the other hand, gettor-01, created as part of #31785, *does* have the
 problem so I'm not sure what's going on here.

 {{{
 root@gettor-01:~# getcap /usr/bin/ping
 root@gettor-01:~# stat /usr/bin/ping
   Fichier : /usr/bin/ping
Taille : 65272   Blocs : 128Blocs d'E/S : 4096   fichier
 Périphérique : 801h/2049d   Inœud : 393547  Liens : 1
 Accès : (0755/-rwxr-xr-x)  UID : (0/root)   GID : (0/root)
  Accès : 2019-10-04 11:56:47.972263612 +
 Modif. : 2018-08-03 16:53:09.0 +
 Changt : 2019-10-02 17:16:26.60031 +
   Créé : -
 root@gettor-01:~#
 }}}

 It seems to me we don't have a clear way of reproducing this. From here
 on, maybe we need VM creators to *explicitly* document exactly which steps
 were taken to create the box? Maybe there's a slight change in the way
 partitions are created or something...

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

Re: [tor-bugs] #31781 [Internal Services/Tor Sysadmin Team]: ping on new VMs

2019-10-10 Thread Tor Bug Tracker & Wiki
#31781: ping on new VMs
-+-
 Reporter:  weasel   |  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):

 I reinstalled `iputils-ping` on gettor-01 and confirms it fixes the
 problem. I have not done that on bacula-director-01, just to be clear.

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

Re: [tor-bugs] #31683 [Core Tor/Tor]: md: Bad family line in cached-microdescs.new

2019-10-10 Thread Tor Bug Tracker & Wiki
#31683: md: Bad family line in cached-microdescs.new
---+
 Reporter:  dgoulet|  Owner:  nickm
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  microdesc, 042-should  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by nickm):

 Hm.  There is a signed/unsigned bug in the handling of
 dump_microdescriptor()'s return value.  I wonder if that could account for
 this.  dump_microdescriptor() returns -1 on error, but we store its return
 value in an (unsigned) size_t, and then check whether it is less than
 zero.

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

Re: [tor-bugs] #31786 [Internal Services/Tor Sysadmin Team]: move dictyotum off moly

2019-10-10 Thread Tor Bug Tracker & Wiki
#31786: move dictyotum off moly
-+-
 Reporter:  anarcat  |  Owner:  anarcat
 Type:  task | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #29974   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 with weasel's help, i figured out a direct procedure and restored the
 server, next up is to figure out how to operate the transition. weasel
 proposed:

  1. set up streaming replication,
  2. shut down the bacula director on dictyotum,
  3. switch things over to the new director with puppet, run it everywhere
 (make sure director is not restarted on dictyotum)
  4. promote the pg on the new host to primary (or whatever it's called)
  5. see if you see jobs in bconsole

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

Re: [tor-bugs] #31683 [Core Tor/Tor]: md: Bad family line in cached-microdescs.new

2019-10-10 Thread Tor Bug Tracker & Wiki
#31683: md: Bad family line in cached-microdescs.new
---+
 Reporter:  dgoulet|  Owner:  nickm
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  microdesc, 042-should  |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by nickm):

 Oh, that's not true.  annotation_len is a size_t, but "size" is a ssize_t,
 as it should be.

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

Re: [tor-bugs] #32005 [Webpages/Website]: Scrolling messes up the display on the 'About' site

2019-10-10 Thread Tor Bug Tracker & Wiki
#32005: Scrolling messes up the display on the 'About' site
-+---
 Reporter:  AsongfacLilyRospeen  |  Owner:  hiro
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Webpages/Website |Version:
 Severity:  Major| Resolution:  duplicate
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+---

Comment (by antonela):

 The menu container needs a `.bg-white` class. It will fix that problem.

 This menu lives in /lego.

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

Re: [tor-bugs] #29013 [Applications/Tor Browser]: Provide stack smashing protection for mingw-clang builds

2019-10-10 Thread Tor Bug Tracker & Wiki
#29013: Provide stack smashing protection for mingw-clang builds
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-rbm, GeorgKoppen201910,  |  Actual Points:  1.5
  tbb-9.0, TorBrowserTeam201910R |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by boklm):

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


Comment:

 The two patches look good to me. I also checked that a 32bit and 64bit
 build with those two patches are still working for me on a Windows 7 VM.

 I cherry-picked the tor-browser commit as
 `4b8a33af9610111d87dc5a901d06bcc20f1cc7b0`, and merged the tor-browser-
 build commit with `effde40cc5643080d45670d889a2fd81a6d39c67`.

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

Re: [tor-bugs] #31698 [Core Tor/Tor]: Reconsider HAVE_XXX_H usage in the Tor code

2019-10-10 Thread Tor Bug Tracker & Wiki
#31698: Reconsider HAVE_XXX_H usage in the Tor code
--+--
 Reporter:  ahf   |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Low   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor  |Version:  Tor: unspecified
 Severity:  Normal| Resolution:
 Keywords:  easy  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by eighthave):

 ''android/log.h'' is always present when building for Android.  No need to
 test for it, just use it:
 {{{
 #ifdef __ANDROID__
 #include 
 #endif
 }}}

 And `__ANDROID__` is always present, try this with an NDK version since at
 least r10, probably earlier even:

 {{{
 $ for clang in /opt/android-ndk-r20/toolchains/llvm/prebuilt/linux-
 x86_64/bin/*-clang; do printf "%s\t" `basename $clang`; $clang -E -dM - <
 /dev/null | grep __ANDROID__; done
 $ for gcc in /opt/android-ndk-r10e/toolchains/*/prebuilt/*/bin/*-gcc; do
 printf "%s\t" `basename $gcc`; $gcc  -E -dM - < /dev/null | grep
 __ANDROID__; done
 }}}

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

Re: [tor-bugs] #31253 [Circumvention/Snowflake]: Add a webext packaging target to the build script

2019-10-10 Thread Tor Bug Tracker & Wiki
#31253: Add a webext packaging target to the build script
-+--
 Reporter:  arlolra  |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by cohosh):

 * status:  new => needs_review


Comment:

 https://github.com/cohosh/snowflake/pull/10

 I opted to not push automatically in the script, but it will make a local
 commit that updates the manifest to bump the version.

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

Re: [tor-bugs] #30607 [Applications/Tor Browser]: Support Tor Running on Android Q

2019-10-10 Thread Tor Bug Tracker & Wiki
#30607: Support Tor Running on Android Q
--+--
 Reporter:  sisbell   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by eighthave):

 Also, FYI, the native ''TorService'' work will eliminate this kind of
 concern entirely since it'll link and run Tor via the officially supported
 methods, rather than the UNIX daemon hack.

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

Re: [tor-bugs] #31942 [Applications/Tor Browser]: Re-enable language pack signature checks for Linux and Windows and double-check macOS

2019-10-10 Thread Tor Bug Tracker & Wiki
#31942: Re-enable language pack signature checks for Linux and Windows and 
double-
check macOS
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tbb-9.0-must-alpha,  |  Actual Points:  0.25
  TorBrowserTeam201910R, GeorgKoppen201910   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-

Comment (by acat):

 Looks good to me, I verified this indeed works for Linux and Windows.

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

Re: [tor-bugs] #31781 [Internal Services/Tor Sysadmin Team]: ping on new VMs

2019-10-10 Thread Tor Bug Tracker & Wiki
#31781: ping on new VMs
-+-
 Reporter:  weasel   |  Owner:  anarcat
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

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


Comment:

 i confirm the problem occurs when the filesystem is cached. filed the bug
 in Debian in https://bugs.debian.org/942114 and wrote a patch that fixes
 the problem, deployed on both nodes.

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

Re: [tor-bugs] #31781 [Internal Services/Tor Sysadmin Team]: ping on new VMs

2019-10-10 Thread Tor Bug Tracker & Wiki
#31781: ping on new VMs
-+-
 Reporter:  weasel   |  Owner:  anarcat
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by anarcat):

 * status:  assigned => needs_review


Comment:

 i tested this and it seems to work. next step is to have another person
 confirm that, to get this merged in the debian package, have an upload to
 fix it in unstable and then stable, and then deploy this debian package on
 the nodes.

 in the meantime, we should at least add a note in the new-machine docs
 before this ticket is marked as resolved.

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

Re: [tor-bugs] #32026 [Circumvention/Censorship analysis]: Using An Alternative To TCP To Avoid Packet Injection?

2019-10-10 Thread Tor Bug Tracker & Wiki
#32026: Using An Alternative To TCP To Avoid Packet Injection?
---+
 Reporter:  Aphrodites1995 |  Owner:  (none)
 Type:  enhancement| Status:  new
 Priority:  Medium |  Milestone:
Component:  Circumvention/Censorship analysis  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by dcf):

 Replying to [ticket:32026 Aphrodites1995]:
 > According to
 https://www.cs.tufts.edu/comp/116/archive/fall2016/ctang.pdf , the GFW
 only injects packets, mostly TCP RST signals.

 Well, that statement is not fully correct. While it's true that, according
 to our current understanding, the GFW cannot selectively drop single
 packets from a flow (but see https://censorbib.nymity.ch/#Marczak2015a for
 contrary evidence), the GFW is also capable of just blocking ''all''
 packets for a single IP address. That's how Tor relays and bridges are
 blocked, by IP blocking, not by RST injection. So a protocol that uses TCP
 tricks to avoid RST injection would not be helpful in unblocking Tor
 relays and bridges. As your reference acknowledges, as network protocols
 have become more encrypted, the firewall relies less on RST injection and
 more on IP blocking. See Section II of
 https://censorbib.nymity.ch/#Tschantz2016a for a brief overview of typical
 assumed censor capabilities.

 > What if TOR has bridges/servers that do not respond to TCP RST? This
 would render the connection interfering part of GFW useless. Here, a
 connection ends only when both sides send a "END" signal to the other side
 with their private key for the connection only that is shared through the
 connection. We don't even need to obfuscate TOR traffic anymore as the
 packets are not blocked.

 There's a history of research on this kind of idea, going back to 2006 at
 least. You may want to skim some of these to get up to speed.
  * [https://censorbib.nymity.ch/#Clayton2006a Ignoring the Great Firewall
 of China]
  * [https://censorbib.nymity.ch/#Khattak2013a Towards Illuminating a
 Censorship Monitor's Model to Facilitate Evasion]
  * [https://censorbib.nymity.ch/#Wang2017a Your State is Not Mine: A
 Closer Look at Evading Stateful Internet Censorship]

 Here's a proof-of-concept tool to ignore RST packets:
  * https://github.com/darkk/rstlss

 See also the [https://github.com/net4people/bbs/issues/9 Turbo Tunnel]
 idea, among whose claimed benefits are decoupling the circumvention state
 from the state of any single TCP connection.

 There's no shortage of abstract ideas on this topic--what helps more is a
 concrete plan for implementation of a specific selection of ideas. But any
 plan would also have to have a good story regarding IP blocking and active
 probing--that's really the reason for protocol obfuscation.

 > With the DNS inspection, we could have IPs for bridges/servers, which do
 the DNS queries on non censored DNS servers.

 That is already how it works. Try this: `tor-resolve example.com`. When
 you're using Tor, all DNS queries are tunneled through the Tor circuit and
 resolved by the exit node.

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

Re: [tor-bugs] #31781 [Internal Services/Tor Sysadmin Team]: ping on new VMs

2019-10-10 Thread Tor Bug Tracker & Wiki
#31781: ping on new VMs
-+-
 Reporter:  weasel   |  Owner:  anarcat
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 I audited all the machines accessible through Cumin, and found the
 following machines without proper caps set:

 * crm-ext-01.torproject.org
 * crm-int-01.torproject.org
 * gitlab-01.torproject.org
 * hetzner-hel1-01.torproject.org
 * hetzner-nbg1-01.torproject.org
 * oo-hetzner-03.torproject.org

 It's strange, because they also didn't have the `getcap` binary (from the
 `libcap2-bin`) package was also missing. So I ran this everywhere:

 {{{
 apt install libcap2-bin; getcap /bin/ping | grep -q . || apt install
 --reinstall iputils-ping; getcap /bin/ping
 }}}

 Particularly interesting are `hetzner-hel1-01.torproject.org` and
 `hetzner-nbg1-01.torproject.org` because they were setup using the Hetzner
 cloud stuff, so our install procedure is broken there as well.

 So, long story short, remaining todo is:

  1. document the workaround in the ganeti installer
  2. ship the new package in Debian, get it to stable
  3. fix the hetzner-cloud installer or at least add a node to check it
  4. check the other installers

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

Re: [tor-bugs] #31682 [Core Tor/Tor]: CID 1453653: Integer handling (NEGATIVE_RETURNS) in build_establish_intro_dos_extension()

2019-10-10 Thread Tor Bug Tracker & Wiki
#31682: CID 1453653: Integer handling (NEGATIVE_RETURNS) in
build_establish_intro_dos_extension()
-+-
 Reporter:  teor |  Owner:  dgoulet
 Type:  defect   | Status:
 |  merge_ready
 Priority:  Medium   |  Milestone:  Tor:
 |  0.4.2.x-final
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs, prop305, coverity|  Actual Points:  0.1
  042-should |
Parent ID:  #2   | Points:  0.1
 Reviewer:  asn  |Sponsor:
 |  Sponsor27-must
-+-
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 LGTM!

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

Re: [tor-bugs] #31942 [Applications/Tor Browser]: Re-enable language pack signature checks for Linux and Windows and double-check macOS

2019-10-10 Thread Tor Bug Tracker & Wiki
#31942: Re-enable language pack signature checks for Linux and Windows and 
double-
check macOS
-+-
 Reporter:  gk   |  Owner:  tbb-
 |  team
 Type:  enhancement  | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  tbb-9.0-must-alpha,  |  Actual Points:  0.25
  TorBrowserTeam201910R, GeorgKoppen201910   |
Parent ID:   | Points:  1
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Thanks. Fixed with commit 293608f16682a977f22527bd74a449cd04d0fcd3 on
 `tor-browser-68.1.0esr-9.0-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] #31910 [Applications/Tor Browser]: replace meek_lite with meek in circuit display

2019-10-10 Thread Tor Bug Tracker & Wiki
#31910: replace meek_lite with meek in circuit display
-+-
 Reporter:  mcs  |  Owner:  mcs
 Type:  defect   | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:  fixed
 Keywords:  meek, tbb-9.0-must-alpha,|  Actual Points:
  TorBrowserTeam201910R, ux-team |
Parent ID:   | Points:  0.1
 Reviewer:   |Sponsor:
-+-
Changes (by gk):

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


Comment:

 Replying to [comment:6 mcs]:
 > For now, we should do the simple thing and restore "Bridge: meek" (so
 users see the same thing in TB 9.0 as they do in 8.5). Here is a patch:
 >
 
https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug31910-01&id=71bb89e923be7be2388ce77684a06c7782f7a6f4

 Looks good to me, thanks. Cherry-picked to `master` (commit
 e54639aab0c60274c14809cd9129b534bb79f92c).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32027 [Applications/Tor Browser]: Bump version of Go to 1.13+

2019-10-10 Thread Tor Bug Tracker & Wiki
#32027: Bump version of Go to 1.13+
--+--
 Reporter:  cohosh|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal|   Keywords:
Actual Points:  snowflake |  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+--
 We're going to need it eventually for newer versions of pion/webrtc, and
 there's a nice feature in to log package that allows us to pass the log
 output writer to libraries.

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

Re: [tor-bugs] #31684 [Core Tor/Tor]: Add control port GETINFO support for dumping the local consensus

2019-10-10 Thread Tor Bug Tracker & Wiki
#31684: Add control port GETINFO support for dumping the local consensus
---+
 Reporter:  asn|  Owner:  (none)
 Type:  task   | Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  control-port easy  |  Actual Points:
Parent ID: | Points:  1
 Reviewer:  asn|Sponsor:
---+
Changes (by asn):

 * status:  needs_review => needs_revision


Comment:

 This seems pretty much ready, but you should use
 `networkstatus_get_flavor_name()` instead of making a new function 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] #31890 [Circumvention/meek]: Redeploy meek-server instances using Go 1.12.10+ / 1.13.1+

2019-10-10 Thread Tor Bug Tracker & Wiki
#31890: Redeploy meek-server instances using Go 1.12.10+ / 1.13.1+
+--
 Reporter:  dcf |  Owner:  dcf
 Type:  task| Status:  assigned
 Priority:  High|  Milestone:
Component:  Circumvention/meek  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by dcf):

 * owner:  (none) => dcf
 * 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] #32027 [Applications/Tor Browser]: Bump version of Go to 1.13+

2019-10-10 Thread Tor Bug Tracker & Wiki
#32027: Bump version of Go to 1.13+
--+---
 Reporter:  cohosh|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  snowflake
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by cohosh):

 Note: as mentioned in
 https://trac.torproject.org/projects/tor/ticket/28942#comment:66 we should
 be careful about how modules are handled in 1.13

 Perhaps we want to tackle #28325 first.

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

Re: [tor-bugs] #28942 [Circumvention/Snowflake]: Evaluate pion WebRTC

2019-10-10 Thread Tor Bug Tracker & Wiki
#28942: Evaluate pion WebRTC
+--
 Reporter:  backkem |  Owner:  cohosh
 Type:  enhancement | Status:  closed
 Priority:  Medium  |  Milestone:
Component:  Circumvention/Snowflake |Version:
 Severity:  Normal  | Resolution:  fixed
 Keywords:  anti-censorship-roadmap-august  |  Actual Points:
Parent ID:  | Points:  5
 Reviewer:  |Sponsor:
|  Sponsor28-must
+--

Comment (by cohosh):

 Replying to [comment:66 dcf]:
 > I think we'll need to file a ticket to upgrade to Go 1.13 (actually
 1.13.1 now) in Tor Browser. The thing to watch out for is
 [https://golang.org/doc/go1.13#modules changed defaults relating to
 modules]. Now `$GOPATH` will be ignored in any directory that contains a
 go.mod file--so we'll have to make sure that the libraries we stage in
 `$GOPATH` are being used, and separate copies not being downloaded
 implicitly by `go build`.

 Created #32027

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32028 [Applications/Tor Browser]: remove obsolete media.audio_data.enabled

2019-10-10 Thread Tor Bug Tracker & Wiki
#32028: remove obsolete media.audio_data.enabled
--+--
 Reporter:  Thorin|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Component:  Applications/Tor Browser
  Version:|   Severity:  Normal
 Keywords:  ff-68esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--
 The pref `media.audio_data.enabled` can be removed from the default
 profile prefs, it was deprecated / removed in FF43

 [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1206091

--
Ticket URL: 
Tor Bug Tracker & Wiki 
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] #32029 [Internal Services/Tor Sysadmin Team]: make new job-shadow-dev@ alias for receiving submissions

2019-10-10 Thread Tor Bug Tracker & Wiki
#32029: make new job-shadow-dev@ alias for receiving submissions
-+-
 Reporter:  arma |  Owner:  tpa
 Type:  task | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 We have an upcoming NSF grant where we will get to fund a person to work
 with Rob Jansen to improve Shadow.

 We should set up an email alias for receiving job applications.

 I'm going to call it job-shadow-dev@tpo.

 And it will go to: arma ahf ewyatt gaba mikeperry, plus also Rob and
 Micah.

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

Re: [tor-bugs] #31253 [Circumvention/Snowflake]: Add a webext packaging target to the build script

2019-10-10 Thread Tor Bug Tracker & Wiki
#31253: Add a webext packaging target to the build script
-+--
 Reporter:  arlolra  |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by dcf):

 {{{
 +  execSync(`git clean -x -d -f .`);
 }}}

 `git clean` makes me nervous because it has the potential to delete work
 in progress. Instead of archiving files directly in the working directory,
 would it be possible to cpoy the files into a temporary directory, and
 leave the working directory untouched? Something like this may be safer:

 {{{
 npm run webext
 TMPDIR=$(mktemp -d webext.)
 git archive HEAD ./webext | tar -C "$TMPDIR" -xf -
 cp webext/snowflake.js "$TMPDIR/webext/"
 rm -f webext.zip
 (cd "$TMPDIR/webext" && zip -rX ../../webext.zip .)
 }}}

 You need to `rm -f webext.zip` first, because otherwise `zip` will modify
 an existing file, potentially leaving garbage in it. The `-X` option to
 `zip` omits filesystem metadata such as uid/gid. (You can inspect the
 difference using `zipinfo -v webext.zip`.)

 Here's potentially a better way to make source.zip, that only includes
 versioned files without the need for `git clean`:
 {{{
 snowflake/proxy$ git archive -o source.zip HEAD .
 }}}

 What happens if one of the `execSync` calls fails? Does the whole `pack-
 webext` task fail, or does it try to execute the remaining code?

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

Re: [tor-bugs] #32029 [Internal Services/Tor Sysadmin Team]: make new job-shadow-dev@ alias for receiving submissions

2019-10-10 Thread Tor Bug Tracker & Wiki
#32029: make new job-shadow-dev@ alias for receiving submissions
-+-
 Reporter:  arma |  Owner:  tpa
 Type:  task | Status:  closed
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 |  implemented
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by arma):

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


Comment:

 It is done. (It will take effect in 0-4 hours.)

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

Re: [tor-bugs] #31684 [Core Tor/Tor]: Add control port GETINFO support for dumping the local consensus

2019-10-10 Thread Tor Bug Tracker & Wiki
#31684: Add control port GETINFO support for dumping the local consensus
---+
 Reporter:  asn|  Owner:  (none)
 Type:  task   | Status:  needs_review
 Priority:  Medium |  Milestone:  Tor: 0.4.3.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  control-port easy  |  Actual Points:
Parent ID: | Points:  1
 Reviewer:  asn|Sponsor:
---+
Changes (by ltbringer):

 * status:  needs_revision => 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] #32028 [Applications/Tor Browser]: remove obsolete media.audio_data.enabled

2019-10-10 Thread Tor Bug Tracker & Wiki
#32028: remove obsolete media.audio_data.enabled
--+--
 Reporter:  Thorin|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff-68esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Thorin):

 Additionally, remove (or update the value in hardwareConcurrency)) for
 redundant prefs due to RFP (or keep them as defense in depth if someone
 disabled RFP). The RFP patches for these override the pref values - all
 tested in alpha 9.0a.7

 - `dom.maxHardwareConcurrency` (or at least set as value `2` to match RFP)
* https://bugzilla.mozilla.org/show_bug.cgi?id=1360039
 - `ui.use_standins_for_native_colors`
* https://bugzilla.mozilla.org/show_bug.cgi?id=1485266
 - `browser.zoom.siteSpecific`
* https://bugzilla.mozilla.org/show_bug.cgi?id=1369357

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

Re: [tor-bugs] #32028 [Applications/Tor Browser]: remove obsolete media.audio_data.enabled

2019-10-10 Thread Tor Bug Tracker & Wiki
#32028: remove obsolete media.audio_data.enabled
--+--
 Reporter:  Thorin|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff-68esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by Thorin):

 ...nd

 - `network.jar.block-remote-files` was removed in FF61
* https://bugzilla.mozilla.org/1427726

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

Re: [tor-bugs] #32027 [Applications/Tor Browser]: Bump version of Go to 1.13+

2019-10-10 Thread Tor Bug Tracker & Wiki
#32027: Bump version of Go to 1.13+
--+---
 Reporter:  cohosh|  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  snowflake
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---

Comment (by dcf):

 Another thing to watch out for in Go 1.13. By default, even commands like
 `go build` will phone home to proxy.golang.org and sum.golang.org. See:
  * https://golang.org/doc/go1.13#modules
  * https://proxy.golang.org/
> As of Go 1.13, the go command by default downloads and authenticates
 modules using the Go module mirror and Go checksum database.
  * https://golang.org/cmd/go/#hdr-Module_downloading_and_verification
> The go command can fetch modules from a proxy or connect to source
 control servers directly, according to the setting of the GOPROXY
 environment variable (see 'go help env'). The default setting for GOPROXY
 is "https://proxy.golang.org,direct";, which means to try the Go module
 mirror run by Google and fall back to a direct connection if the proxy
 reports that it does not have the module (HTTP error 404 or 410).

 The phone-home behavior is annoying, but probably mostly harmless in the
 rbm context. To disable the proxy.golang.org reporting, you can set
 `GOPROXY=direct` -- but even better for us may be `GOPROXY=off`, which is
 supposed to "disallow downloading modules from any source," which is what
 we want during the offline portion of the build.

 To disable the sum.golang.org reporting, you can set `GOSUMDB=off`.
 https://golang.org/cmd/go/#hdr-Module_authentication_failures
 > If GOSUMDB is set to "off", or if "go get" is invoked with the -insecure
 flag, the checksum database is not consulted, and all unrecognized modules
 are accepted, at the cost of giving up the security guarantee of verified
 repeatable downloads for all modules.

 I personally had problems this week with checksum mismatches using
 go1.13.1 -- it turns out they changed how checksums are calculated with
 respect to symlinks, or something, and invalidated previous checksums. I
 tried clearing my cache and everything, and could not get
 https://github.com/lucas-clemente/quic-go to build using go1.13.1 because
 of checksum mismatches. So if you get "checksum mismatch" errors, it's
 something related to that.
  * https://github.com/golang/go/issues/29278
  *
 https://github.com/search?utf8=%E2%9C%93&q=golang+checksum+mismatch&type=Issues

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

Re: [tor-bugs] #31253 [Circumvention/Snowflake]: Add a webext packaging target to the build script

2019-10-10 Thread Tor Bug Tracker & Wiki
#31253: Add a webext packaging target to the build script
-+--
 Reporter:  arlolra  |  Owner:  (none)
 Type:  defect   | Status:  needs_review
 Priority:  Medium   |  Milestone:
Component:  Circumvention/Snowflake  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by cohosh):

 Replying to [comment:2 dcf]:
 Thanks, I updated that same link above.
 > {{{
 > +  execSync(`git clean -x -d -f .`);
 > }}}
 > I
 > `git clean` makes me nervous because it has the potential to delete work
 in progress. Instead of archiving files directly in the working directory,
 would it be possible to cpoy the files into a temporary directory, and
 leave the working directory untouched? Something like this may be safer:
 I switched to using the archive option. Note that a call to `npm run
 webext` will do a `git clean` on the webext/ subdirectory anyway.
 > You need to `rm -f webext.zip` first, because otherwise `zip` will
 modify an existing file, potentially leaving garbage in it. The `-X`
 option to `zip` omits filesystem metadata such as uid/gid. (You can
 inspect the difference using `zipinfo -v webext.zip`.)
 Done
 > What happens if one of the `execSync` calls fails? Does the whole `pack-
 webext` task fail, or does it try to execute the remaining code?
 The task fails. I added some try-catch code around commands that are
 likely to fail.

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

Re: [tor-bugs] #31561 [Core Tor/Tor]: hs-v3: Service can keep unused intro points in its list

2019-10-10 Thread Tor Bug Tracker & Wiki
#31561: hs-v3: Service can keep unused intro points in its list
---+---
 Reporter:  dgoulet|  Owner:  dgoulet
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:  Tor:
   |  0.4.2.x-final
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs, hv-v3, 042-should  |  Actual Points:  0.1
Parent ID:  #30200 | Points:  0.2
 Reviewer:  asn|Sponsor:  Sponsor27-must
---+---

Comment (by mikeperry):

 Replying to [comment:14 asn]:
 > Replying to [comment:13 nickm]:
 > > I'm concerned that this patch makes `purpose ==
 CIRCUIT_PURPOSE_HS_VANGUARDS` count as both a client purpose and a service
 purpose.  Won't that result in us sometimes calling
 `hs_service_circuit_timed_out` on a client circuit?
 >
 > Hmm, there is indeed a bug here! Thanks for catching that, and sorry for
 missing that.
 >
 > `CIRCUIT_PURPOSE_HS_VANGUARDS` is the purpose that Tor uses to pre-built
 vanguard circuits '''before''' they are used by the vanguard subsystem for
 specific HS-related purposes (they can be used for HS client or for HS
 service activities).
 >
 > However, while the circuit is in this vanguards purpose, it shouldn't
 have any duties as an HS circuit (i.e. be an active intro circuit) and
 hence we shouldn't call `hs_service_circuit_timed_out()` on it.

 This is a good reason to have vanguard purpose circuits count as neither
 client *nor* service HS circs. Maybe they should not even count as HS
 circs at all, for function sanity.

 > Vanguards circuits are taken into account in the
 `circuit_purpose_is_hidden_service()` function because it is used by the
 vanguard subsystem to take decision about vanguards; but for our use case
 it's safe to ignore vanguard circuits.

 I think for every HS case it is safe to ignore vanguards purpose circuits.
 They are pre-built only and not used yet.. This might be a good reason to
 have every place where vanguards calls circuit_purpose_is_hidden_service()
 *also* check explicitly for its vanguard purpose...

 > So takeaways and plans for the patch:
 > a) The `circuit_purpose_is_hidden_service()` should remain as is
 (behavior-wise) because it's used (correctly) by the vanguard subsystem.
 But IMO the name is a bit misleading because IIUC vanguard circuits don't
 have active hidden service duties, but they can be repurposed to HS circs
 in the future. Perhaps the function should have a vanguard-centric name,
 instead of an onion service-centric name.

 If we decide to leave this as including vanguards, they definitely should
 not count as hs client circuits (which the branch currently does). There
 should just be an extra check for them in this function.

 > b) Our new function `circuit_purpose_is_hs_service()` should not take
 into account vanguard circuits since we only care about active onion
 service circs. Perhaps `circuit_purpose_is_hidden_service()` can use our
 new function to avoid code dedup.
 > c) Let's ask Mike if he agrees with the above.

 Additionally, circuits can time out in
 circuit_build_times_handle_completed_hop(), where they can get marked as
 measurement circuits via circuit_change_purpose(). However, the fix for
 #29034 cause them to get removed from the hs circuit map whenever we
 change purposes. Is this enough to keep them out of the HS descriptor's
 intropoint list as well? If so, then I guess that part is handled, at
 least.

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

Re: [tor-bugs] #31768 [Applications/Tor Browser]: Introduce Tor network settings and other updates in TB9 onboarding

2019-10-10 Thread Tor Bug Tracker & Wiki
#31768: Introduce Tor network settings and other updates in TB9 onboarding
-+-
 Reporter:  antonela |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.0-must-alpha, |  Actual Points:
  TorBrowserTeam201910R, tbb-onboarding  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-
Changes (by mcs):

 * status:  needs_revision => needs_review
 * keywords:  ux-team, tbb-9.0-must-alpha, TorBrowserTeam201910, tbb-
 onboarding => ux-team, tbb-9.0-must-alpha, TorBrowserTeam201910R, tbb-
 onboarding


Comment:

 Replying to [comment:38 gk]:
 > Two things I've found while testing:
 >
 > 1) The security item should lose its "New" flag. That feature was new in
 8.5 but is not in 9.0

 Good catch.

 > 2) I think requesting a New Identity should be done via the toolbar
 button, for two reasons: a) we are showing the toolbar + the icon on the
 onboarding card. It seems weird doing that and then using a menuitem
 instead of requesting a New Identity. b) the preferred way of requesting a
 New Identity is likely via the toolbar as this requires less clicks. Thus,
 we should teach the users to use that one instead of the backup option via
 the menu.

 Makes sense. Here is a revised patch:
 https://gitweb.torproject.org/user/brade/tor-
 browser.git/commit/?h=bug31768-02&id=28e7c573ad2c0ffba5eb675447ee0c70a24e1a57

 The New Identity toolbar button highlight is a little subtle. We tried all
 three of the animated methods that the existing Mozilla-derived UITour
 code supports and picked `zoom` because it provides a pulsating effect
 that loops indefinitely. The other two choices are `wobble` which briefly
 rotates the button background and `color` which does not seem to have any
 effect (at least on macOS; it looks like it changes border color).  I
 don't think we have time to do better for TB 9.0, but for future reference
 the animations are defined in here:
 https://searchfox.org/mozilla-
 esr68/source/browser/base/content/browser.css#1281
 and here:
 https://searchfox.org/mozilla-
 esr68/source/browser/base/content/browser.css#1331

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

Re: [tor-bugs] #31823 [Core Tor/Stem]: HSv3 descriptor support in stem [encoding]

2019-10-10 Thread Tor Bug Tracker & Wiki
#31823: HSv3 descriptor support in stem [encoding]
-+-
 Reporter:  asn  |  Owner:  atagar
 Type:  defect   | Status:
 |  needs_review
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Stem|Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-hs scaling onionbalance  |  Actual Points:  2
  network-team-roadmap-september tor-spec|
Parent ID:  #26768   | Points:  5
 Reviewer:   |Sponsor:
-+-
Changes (by asn):

 * cc: atagar (added)
 * status:  new => needs_review


Comment:

 OK I present a draft version of this functionality at:
 https://github.com/torproject/stem/pull/24

 It's a big branch with over 1k lines of code. It's not yet ready for
 production, but I posted it here to get some feedback from you atagar on
 what needs to be changed and improved.

 The branch basically builds up from small things (key blinding), to
 encoding descriptors and finally to being able to do a full on encode-to-
 decode unittest using the branch from #31369. The format of this unittest
 is the same logic I'm planning to use in onionbalance when encoding v3
 descriptors. Also, I passed a stem descriptor to little-t-tor and verified
 that little-t-tor parses it well.

 Starting tomorrow I will be offline for two weeks, so feel free to take
 your time reading this code. When I get back I will have more time to
 revise this branch and do any changes you might like.

 Enjoy and thanks for the feedback!

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

Re: [tor-bugs] #32016 [Core Tor/Tor]: spec: ClientAuth option of ADD_ONION is only v2

2019-10-10 Thread Tor Bug Tracker & Wiki
#32016: spec: ClientAuth option of ADD_ONION is only v2
--+
 Reporter:  dgoulet   |  Owner:  dgoulet
 Type:  defect| Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-spec, tor-hs  |  Actual Points:
Parent ID:| Points:  0.1
 Reviewer:  asn   |Sponsor:  Sponsor27-must
--+
Changes (by asn):

 * status:  needs_review => merge_ready


Comment:

 LGTM! Thanks!

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

Re: [tor-bugs] #31768 [Applications/Tor Browser]: Introduce Tor network settings and other updates in TB9 onboarding

2019-10-10 Thread Tor Bug Tracker & Wiki
#31768: Introduce Tor network settings and other updates in TB9 onboarding
-+-
 Reporter:  antonela |  Owner:  tbb-
 |  team
 Type:  defect   | Status:
 |  needs_review
 Priority:  High |  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  ux-team, tbb-9.0-must-alpha, |  Actual Points:
  TorBrowserTeam201910R, tbb-onboarding  |
Parent ID:   | Points:  0.5
 Reviewer:   |Sponsor:
-+-

Comment (by antonela):

 Replying to [comment:39 mcs]:
 > The New Identity toolbar button highlight is a little subtle. We tried
 all three of the animated methods that the existing Mozilla-derived UITour
 code supports and picked `zoom` because it provides a pulsating effect
 that loops indefinitely.

 That is awesome. Thank you for this!

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

Re: [tor-bugs] #32001 [Applications/Tor Browser]: Android Tor Browser 60esr-based doesn't work on Android 10 (Q)

2019-10-10 Thread Tor Bug Tracker & Wiki
#32001: Android Tor Browser 60esr-based doesn't work on Android 10 (Q)
--+---
 Reporter:  sysrqb|  Owner:  (none)
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  duplicate
 Keywords:  tbb-mobile|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+---
Changes (by gk):

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


Comment:

 Duplicate of #30607.

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

Re: [tor-bugs] #30607 [Applications/Tor Browser]: Support Tor Running on Android Q

2019-10-10 Thread Tor Bug Tracker & Wiki
#30607: Support Tor Running on Android Q
+--
 Reporter:  sisbell |  Owner:  tbb-team
 Type:  defect  | Status:  new
 Priority:  Medium  |  Milestone:
Component:  Applications/Tor Browser|Version:
 Severity:  Normal  | Resolution:
 Keywords:  tbb-mobile, ff68-esr-will-have  |  Actual Points:
Parent ID:  | Points:
 Reviewer:  |Sponsor:
+--
Changes (by gk):

 * keywords:  tbb-mobile => tbb-mobile, ff68-esr-will-have


Comment:

 #32001 is a 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] #31684 [Core Tor/Tor]: Add control port GETINFO support for dumping the local consensus

2019-10-10 Thread Tor Bug Tracker & Wiki
#31684: Add control port GETINFO support for dumping the local consensus
+--
 Reporter:  asn |  Owner:  (none)
 Type:  task| Status:
|  needs_revision
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  control-port easy extra-review  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  asn |Sponsor:
+--
Changes (by asn):

 * status:  needs_review => needs_revision


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

Re: [tor-bugs] #31684 [Core Tor/Tor]: Add control port GETINFO support for dumping the local consensus

2019-10-10 Thread Tor Bug Tracker & Wiki
#31684: Add control port GETINFO support for dumping the local consensus
+--
 Reporter:  asn |  Owner:  (none)
 Type:  task| Status:  needs_review
 Priority:  Medium  |  Milestone:  Tor:
|  0.4.3.x-final
Component:  Core Tor/Tor|Version:
 Severity:  Normal  | Resolution:
 Keywords:  control-port easy extra-review  |  Actual Points:
Parent ID:  | Points:  1
 Reviewer:  asn |Sponsor:
+--
Changes (by asn):

 * keywords:  control-port easy => control-port easy extra-review


Comment:

 Thanks. Two more minor issues and we are done.

 I also tested that this works fine with a stem script that looks like
 this:
 {{{
  controller = Controller.from_port(port=9090)
  controller.authenticate()
  ns = controller.get_info("dir/status-vote/current/consensus-microdesc")
  print("microdesc: %s" % ns)
  ns = controller.get_info("dir/status-vote/current/consensus")
  print("ns: %s" % ns)
 }}}

 After you change these two minor issues please mark it as `merge_ready`.

 Marking as extra review so that the merger checks that the issues have
 been fixed before merging (I will be away for two weeks)

 Thanks again for the code!

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

Re: [tor-bugs] #32028 [Applications/Tor Browser]: remove obsolete media.audio_data.enabled

2019-10-10 Thread Tor Bug Tracker & Wiki
#32028: remove obsolete media.audio_data.enabled
--+--
 Reporter:  Thorin|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  ff-68esr  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 Replying to [comment:2 Thorin]:
 > ...nd
 >
 > - `network.jar.block-remote-files` was removed in FF61
 >* https://bugzilla.mozilla.org/1427726
 > - `security.tls.unrestricted_rc4_fallback` was removed in FF53
 >* https://bugzilla.mozilla.org/1130670
 > - `browser.search.countryCode` was removed in FF63
 >* https://bugzilla.mozilla.org/1462015
 > - I have more, should I list them?

 Please do. I have made a collection of prefs while looking at all the
 closed bugs. So far I have roughly the same list as you. :)

 > PS: feel free to re-title the ticket to e.g. **default prefs cleanup**
 or something

 There is a separate ticket for prefs clean-up #27268 which we started for
 ESR 60. Should we go over there adding your stuff for ESR 68?

 Feel free to do so and close this ticket as a 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] #30753 [Applications/Tor Browser]: Think about using DNS over HTTPS for Tor Browser 9

2019-10-10 Thread Tor Bug Tracker & Wiki
#30753: Think about using DNS over HTTPS for Tor Browser 9
--+---
 Reporter:  gk|  Owner:  tbb-team
 Type:  task  | Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:  Sponsor44-can
--+---
Changes (by mrphs):

 * cc: mrphs (added)


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

Re: [tor-bugs] #30966 [Community/Tor Browser Manual]: Install instructions for Linux/Ubuntu users who might not be entirely familiar with tar.xz

2019-10-10 Thread Tor Bug Tracker & Wiki
#30966: Install instructions for Linux/Ubuntu users who might not be entirely
familiar with tar.xz
--+-
 Reporter:  torlove   |  Owner:  wayward
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:
Component:  Community/Tor Browser Manual  |Version:
 Severity:  Normal| Resolution:  fixed
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+-
Changes (by ggus):

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


Comment:

 It's done - https://tb-manual.torproject.org/installation/

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

Re: [tor-bugs] #30267 [Core Tor/Tor]: Simplify the code logic of launching HS circuits

2019-10-10 Thread Tor Bug Tracker & Wiki
#30267: Simplify the code logic of launching HS circuits
---+---
 Reporter:  asn|  Owner:  (none)
 Type:  defect | Status:  new
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs refactoring tech-debt easy  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+---
Changes (by neel):

 * status:  assigned => new


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

Re: [tor-bugs] #30267 [Core Tor/Tor]: Simplify the code logic of launching HS circuits

2019-10-10 Thread Tor Bug Tracker & Wiki
#30267: Simplify the code logic of launching HS circuits
---+---
 Reporter:  asn|  Owner:  (none)
 Type:  defect | Status:  assigned
 Priority:  Medium |  Milestone:  Tor:
   |  unspecified
Component:  Core Tor/Tor   |Version:
 Severity:  Normal | Resolution:
 Keywords:  tor-hs refactoring tech-debt easy  |  Actual Points:
Parent ID: | Points:  1
 Reviewer: |Sponsor:
---+---
Changes (by neel):

 * owner:  neel => (none)


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

Re: [tor-bugs] #28514 [Core Tor/Tor]: Open NUM_PARALLEL_TESTING_CIRCS when a bandwidth test is initiated

2019-10-10 Thread Tor Bug Tracker & Wiki
#28514: Open NUM_PARALLEL_TESTING_CIRCS when a bandwidth test is initiated
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dos, tor-bwauth, 035-backport,   |  Actual Points:
  029-backport-maybe-not, needs-proposal, 034|
  -unreached-backport-maybe, 033-unreached-  |
  backport-maybe |
Parent ID:  #22453   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by neel):

 * status:  assigned => new


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

Re: [tor-bugs] #28514 [Core Tor/Tor]: Open NUM_PARALLEL_TESTING_CIRCS when a bandwidth test is initiated

2019-10-10 Thread Tor Bug Tracker & Wiki
#28514: Open NUM_PARALLEL_TESTING_CIRCS when a bandwidth test is initiated
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  tor-dos, tor-bwauth, 035-backport,   |  Actual Points:
  029-backport-maybe-not, needs-proposal, 034|
  -unreached-backport-maybe, 033-unreached-  |
  backport-maybe |
Parent ID:  #22453   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by neel):

 * owner:  neel => (none)


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

Re: [tor-bugs] #26971 [Core Tor/Tor]: Add rendezvous point unrecognised link specifiers to client introduce cells

2019-10-10 Thread Tor Bug Tracker & Wiki
#26971: Add rendezvous point unrecognised link specifiers to client introduce 
cells
-+
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  assigned
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:  #24403   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by neel):

 * cc: neel (removed)
 * owner:  neel => (none)


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

Re: [tor-bugs] #26971 [Core Tor/Tor]: Add rendezvous point unrecognised link specifiers to client introduce cells

2019-10-10 Thread Tor Bug Tracker & Wiki
#26971: Add rendezvous point unrecognised link specifiers to client introduce 
cells
-+
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: unspecified
Component:  Core Tor/Tor |Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal   | Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:  #24403   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by neel):

 * status:  assigned => new


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

Re: [tor-bugs] #28511 [Core Tor/Tor]: Limit the number of open testing circuits, and the total number of testing circuits

2019-10-10 Thread Tor Bug Tracker & Wiki
#28511: Limit the number of open testing circuits, and the total number of 
testing
circuits
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  fast-fix, tor-bwauth, tor-dos,   |  Actual Points:
  035-backport, 029-backport, 041-proposed,  |
  needs-proposal, 033-unreached-backport |
Parent ID:  #22453   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by neel):

 * status:  assigned => new


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

Re: [tor-bugs] #28511 [Core Tor/Tor]: Limit the number of open testing circuits, and the total number of testing circuits

2019-10-10 Thread Tor Bug Tracker & Wiki
#28511: Limit the number of open testing circuits, and the total number of 
testing
circuits
-+-
 Reporter:  teor |  Owner:  (none)
 Type:  defect   | Status:
 |  assigned
 Priority:  Medium   |  Milestone:  Tor:
 |  unspecified
Component:  Core Tor/Tor |Version:
 Severity:  Normal   | Resolution:
 Keywords:  fast-fix, tor-bwauth, tor-dos,   |  Actual Points:
  035-backport, 029-backport, 041-proposed,  |
  needs-proposal, 033-unreached-backport |
Parent ID:  #22453   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by neel):

 * cc: neel (removed)
 * owner:  neel => (none)


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

Re: [tor-bugs] #31144 [Applications/Tor Browser]: ESR68 Network Code Review

2019-10-10 Thread Tor Bug Tracker & Wiki
#31144: ESR68 Network Code Review
-+-
 Reporter:  pili |  Owner:  tbb-
 |  team
 Type:  task | Status:  new
 Priority:  Very High|  Milestone:
Component:  Applications/Tor Browser |Version:
 Severity:  Normal   | Resolution:
 Keywords:  TorBrowserTeam201910, tbb-9.0|  Actual Points:
  -alpha-must|
Parent ID:   | Points:  10
 Reviewer:   |Sponsor:
-+-

Comment (by mikeperry):

 > > 5. Otherwise has Ritter's network symbol tool been run on FF68ESR for
 Rust?
 >
 > I don't think so. I thought that would be a nice thing to do during the
 network code review.

 Hrmm I don't have a TBB build environment anymore... Maybe we can just ask
 Ritter if he's run it recently/to rerun it.

 I am going to fall into this Intent rabbithole instead for now.

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

  1   2   >